nicob's profile - activity

Thank you! The driver works fine for me.

Thanks, this would be great! I send you an e-mail with my contact information to your CoR adress. The main problem is,

I think it is not a problem with write permissions in the directories. Rossum works perfectly with absolut path specific

I think it is not a problem with write permissions in the directories. Rossum works perfectly with absolut path specific

Now, I run into the same trouble. It is not possible for my to compile the driver for controller version 9.10-1 by mysel

Hi!

Is there a python command of the moveit_commander lib to get the used (!) planning time for the last planning? Perhaps the time is also stored in the result of the "plan" command?

At the moment I have identified the following information in the results:

plan = self.move_group.plan()
# plan[0] == True if planning was successfull
# plan[1] <- trajectory

Is there an overview of the structure of the "plan" result? Thanks in advance!

nico

I found the solution by myself after some study of the planning results array... It is much more simple as I expected:

Get used time for planning path Hi! Is there a python command of the moveit_commander lib to get the used (!) planning

I am working with the FANUC models from ROS industrial package. For FANUC robots base is the origin of the "world coordi

For an application I am planning in different static frames (tf2). On the first screenshot you see an example frame, named pm_slot2. By using the command move_group.set_pose_reference_frame('pm_slot2'), I can describe the pose target in this frame and planning works as expected. Target 0,0,0 is right in the center of the pm_slot2 frame.

But if I turn the frame like in the next screenshot, the planning fails. I am 100% sure, the pose is possible for the robot (like in first screenshot but tool turned 45 degrees).

For the orientation of the pose_target in quaternions I am using both times 0,0,0,1 (qX, qY, qZ, qW).

Whats going wrong? Any ideas? Thanks in advance!

nico

Finally, I found the solution. I had to transform my target to the pm_slot2 frame. It was just one line of code: target

[...] and can you tell me why the arrow link is starting from 2 Joint? Sorry, I do not fully understand this ques

please delete me

Wrong answer... please delete

[...] and can you tell me why the arrow link is starting from 2 Joint? Sorry, I do not fully understand this ques

[...] and can you tell me why the arrow link is starting from 2 Joint? Sorry, I do not fully understand this ques

The position of the pm_slot2 frame is in both screenshots the same, but the orientation is different. In the second scre

I am planning a robot motion in two steps. So I can modify the boundary conditions of the target pose of the first step (orienation of gripper), if the planning of step two fails (bring part to target pose). Background is to handle parts of high varity in geometry without teaching.

In a first development step I planned AND executed the steps subsequently. All motions worked fine and there were no collisions. Now, I observe some collisions in the second step in RViz but the motion is executed without recognition of the collision. Furthermore all of the end poses are correct. Planning algorithm is the same.

Some background info of my code: I plan the first motion in classic way with

tubehandling.move_group.set_pose_target(targets[0])
plan1 = tubehandling.move_group.plan()

If plan1[0] == True the next planning step follows. For this I get the joint angles of the last plannend point in plan1 and update with this angels the robot_start_state for the second planning:

target_joints = plan1[1].joint_trajectory.points[-1].positions
target_joints = list(target_joints)
robot_state = tubehandling.robot.get_current_state().joint_state.position
robot_state = list(robot_state)
# Update joint angles with planned robot state at gripping point
robot_state[0:6] = target_joints[0:6]
print("Robot end state (angles):")
print(robot_state[0:6])

robot_state = tuple(robot_state)
robot_start_state = tubehandling.robot.get_current_state()
robot_start_state.joint_state.position = robot_state

# Set new start state for 2nd planning
tubehandling.move_group.set_start_state(robot_start_state)

After this the planning follows WITH attached part and if plan2[0] == True the two plans are carried out.

tubehandling.move_group.set_pose_target(targets[1])
tubehandling.attach_part(tubename) 
plan2 = tubehandling.move_group.plan()
tubehandling.detach_part(tubename)

Do I overlook something? Do I have to update somethin else? As usual, thanks in advance!

After long hours of puzzling over the problem I found a working solution. Perhaps it is not the most elegant solution bu

Planning in turned static frame fails For an application I am planning in different static frames (tf2). On the first sc

Planning of motion in two steps leads to collisions I am planning a robot motion in two steps. So I can modify the bound

One more comment... I think it is definitv a problem of an incomplete definition of the robot_state msg. The command ro

print(tubehandling.scene.get_attached_objects()) shows the attached object correctly in the second planning.

It was possible for me to pinpoint the fault more. With the MotionPlanning - Trajectory Slider in RViz I recognized that

Planning of motion in two steps leads to collisions I am planning a robot motion in two steps. So I can modify the bound

I am using the the python commands set_max_acceleration_scaling_factor(x) and set_max_velocity_scaling_factor(y) of the MoveGroupCommander class to control the speed behaviour of a FANUC robot, based on the industrial package.

This works finse in a simulation only environment in RViz accordingly to the joint limits defined in the file joint_limits.yaml. But if I connect ROS to the controller of the real robot, the robot is much more slowly. The robot does not seem to follow the max factors. Are there additional limits defined in the FANUC industrial package?

Thanks in advance!

nico

Thanks for de detailed answer! This helps me a lot to understand the system better.

Hi!

Is there a ROS node which I can send with python a frame similar to the addTf() command and the node broadcasts this frame all the time? I want to create, modify and delete frames in one program run/sequenze without broadcast it periodically by myself. So the static_transform_publisher is not the right choice for me.

<node pkg="tf" type="static_transform_publisher" name="app_bcast" args= "0.0 0.0 0.0 0.0 0.0 0.0 1.0 p_frame c_frame 100" />

Thanks in advance!

nico