MoveIt! compute_cartesian_path() does not compute correct joint trajectory

asked 2014-06-27 08:42:41 -0500

Rick C NIST
28 ●4 ●6 ●7

Hello, I am using ROS Hydro on Ubuntu 12.04. When calling MoveIt! Commander's (Python) move_group.compute_cartesian_path() method, the return value is always the current joint configuration. The code looks something like this.

eef_link = "gripper_palm_link"
waypoints = []
waypoints = group.get_random_pose(eef_link)
poses.append(copy.deepcopy(pose.pose))
waypoints = group.get_random_pose(eef_link)
poses.append(copy.deepcopy(pose.pose))
(plan, fraction) = group.compute_cartesian_path(waypoints, eef_step=0.01, jump_threshold=0.0, avoid_collisions=True)

My robot starts off in the home position which is essentially joint positions set to all zeros. After the call to compute_cartesian_path() the resultant joint trajectory look like this:

header: 
  seq: 20
  stamp: 
    secs: 0
    nsecs: 0
  frame_id: base_link
joint_names: ['arm_joint_1', 'arm_joint_2', 'arm_joint_3', 'arm_joint_4', 'arm_joint_5']
points: 
  - 
    positions: [0.001216606411158061, 0.0001137616260065144, -0.0006536926007463251, 0.0025598054398985326, 0.0007543179427678126]
    velocities: [0.0, 0.0, 0.0, 0.0, 0.0]
    accelerations: [0.0, 0.0, 0.0, 0.0, 0.0]
    effort: []
    time_from_start: 
      secs: 2
      nsecs: 0

The positions are essentially zero (i.e., the home position). I suspect that the call to group.get_random_pose(eef_link) is returning an invalid end effector position, but I don't know why it would do that. Any help would be appreciated.

edit retag flag offensive close merge delete

Comments

My guess would be that you might have screwed up in the Setup-Assistant or your urdf? Did you check the limits in the urdf?

Rabe ( 2014-06-27 09:31:15 -0500 )edit

I am using the Kuka youbot URDF unmodified which I am assuming is correct. The setup assistant could be the problem or maybe that I am not setting the end effector link? One interesting data point is that if I call group.set_pose_target(pose) and then group.plan(), I get a valid trajectory from Moveit.

Rick C NIST ( 2014-06-27 11:45:37 -0500 )edit

add a comment

0

answered 2014-06-27 13:50:23 -0500

fergs

13902 ●59 ●157 ●196 http://www.robotandchisel.com

I presume that the pose with all joints at 0 is basically the arm completely stretched out -- thus it as the limit of it's workspace. Even if the random pose is valid, there may not be a cartesian path between the points since the starting point is near the limits of the workspace. Have you tried a different starting point that is somewhat centered in the workspace of the arm?

edit flag offensive delete link

Comments

Joints at all 0 means the home position (i.e. all scrunched up) Here is a picture of the home position: http://www.kuka-labs.com/NR/rdonlyres/17026737-5839-4346-9939-5D012133E9FE/0/service_youBot_Features.jpg. I would have thought that get_random_pose() would give me a valid pose.

Rick C NIST ( 2014-06-27 14:36:50 -0500 )edit

add a comment

0

answered 2018-04-09 14:58:52 -0500

raequin
368 ●13 ●23 ●27

It looks to me like there is a simple problem with the code. You define "waypoints" to be a random pose twice and append this to "poses." How about this instead?

  eef_link = "gripper_palm_link"
  waypoints = []
  poses = group.get_random_pose(eef_link)
  waypoints.append(copy.deepcopy(poses.pose))
  poses = group.get_random_pose(eef_link)
  waypoints.append(copy.deepcopy(poses.pose))
  (plan, fraction) = group.compute_cartesian_path(waypoints, eef_step=0.01, jump_threshold=0.0, avoid_collisions=True)

edit flag offensive delete link

add a comment

MoveIt! compute_cartesian_path() does not compute correct joint trajectory

Comments

2 Answers

Comments

Question Tools

Stats

Related questions

MoveIt! compute_cartesian_path() does not compute correct joint trajectory edit

Comments

2 Answers

Comments

Question Tools

Stats

Related questions

MoveIt! compute_cartesian_path() does not compute correct joint trajectory