Moveit low precision when executing cartesian path

asked 2018-11-13 08:18:23 -0600

iabadia gravatar image

updated 2018-11-13 08:23:12 -0600


I am using MoveIt with Baxter Robot on Gazebo7 to create a circular trajectory of 500 waypoints (running ROS Kinetic on Ubuntu 16.04 and everything was installed according to Rethink Robotics webpage )

To make the cartesian path I have followed the tutorial on There is no problem when creating the trajectory, however I would expect higher precision on execution. In the image you can see in blue the desired trajectory and in red the actual execution. image description

Once I have the circle coordinates stored as waypoints I compute and execute the trajectory as follows:


moveit_msgs::RobotTrajectory trajectory;
const double jump_threshold = 0.0;
const double eef_step = 1.0;
double fraction = move_group.computeCartesianPath(waypoints, eef_step, jump_threshold, trajectory);
moveit::planning_interface::MoveGroupInterface::Plan my_plan2;
my_plan2.trajectory_ = trajectory;
ROS_INFO("Cartesian path (%.2f%% achieved)", fraction * 100.0);

The computeCartesianPath() function returns a 100% of achievement for the trajectory and also the MoveIt terminal displays the message "Computed Cartesian path with 501 points (followed 100.000000% of requested trajectory)". I have tried decreasing the GoalTolerance parameter of the MoveGroupInterface object but the issue still remains (even setting the GoalTolerance to 0.0 a 100% of achievement is reached but the executed trajectory is not close to being the desired one).

Are there any other parameters that may affect the precision of the trajectory execution? Any ideas on why this is happening and how it could be fixed?

I have tried doing the trajectory with and without PathConstraints, I have modified the eef_step and jump_threshold too just in case that would do it but I can't find a solution. Having a good trajectory is key for our research, any help will be very much appreciated. Please do not hesitate asking for more details if needed.



edit retag flag offensive close merge delete



My first thought would be that the trajectory is probably being planned correctly the simulated robot is not following the given trajectory as accurately as you want. To test this you could slow down the speed of the trajectory and see if the precision improves.

PeteBlackerThe3rd gravatar image PeteBlackerThe3rd  ( 2018-11-13 08:44:57 -0600 )edit

Hi Peter, thanks for your answer. How do you change the speed of the trajectory? I have decreased the velocity scaling factor but that doesn't change the execution.

iabadia gravatar image iabadia  ( 2018-11-13 09:00:00 -0600 )edit

I don't know of a single function to do this but you can modify the RobotTrajectory message directly quite easily. The joint_trajectory.points member is a list of TrajectoryPoints. . .

PeteBlackerThe3rd gravatar image PeteBlackerThe3rd  ( 2018-11-13 09:10:16 -0600 )edit

Each of these trajectory points includes a time_from_start member. So you can loop through the points vector and multiply each time_from_start member by a constant to speed up / slow down the trajectory. Let us know how you get on.

PeteBlackerThe3rd gravatar image PeteBlackerThe3rd  ( 2018-11-13 09:11:48 -0600 )edit

Should we take a step back here?

@iabadia: do you see the same issue with a different robot in Gazebo? I don't know how Baxter is simulated exactly in Gazebo, but the real robot wasn't known for it's path accuracy. If the simulation is using effort interfaces fi and the PIDs aren't tuned ..

gvdhoorn gravatar image gvdhoorn  ( 2018-11-13 09:18:28 -0600 )edit

.. (correctly) or the simulation was made for (ie: tuned) a different version of Gazebo, then that could all influence what you're seeing.

Second: there is no magic in computeCartesianPath(..). All it does is linearly interpolate between the poses you give it (with eef_step increments) and ..

gvdhoorn gravatar image gvdhoorn  ( 2018-11-13 09:19:43 -0600 )edit

.. then call your IK solver to retrieve jointspace solutions for the poses it calculated.

So if you write that: "there is no problem when creating the trajectory", then it would appear that bit is working (but then: how did you verify this).

If it's the execution, the function itself is ..

gvdhoorn gravatar image gvdhoorn  ( 2018-11-13 09:21:17 -0600 )edit

.. no longer involved (as it really only interpolates, nothing more) and the cause would seem to be somewhere else.

If the "desired trajectory" you show is the input to computeCartesianPath(..) and the other trajectory the output, then the function itself would seem to be involved somehow.

gvdhoorn gravatar image gvdhoorn  ( 2018-11-13 09:22:32 -0600 )edit