Invalid Trajectory: start point deviates from current robot state more than

“Invalid Trajectory: start point deviates from current robot state more than …“ MoveIt 0.7.3+ ensures that the start state of the robot is near the current state before executing a trajectory. The check might be violated if the noise in your JointStates exceeds the default threshold value of 0.01 per joint even if your robot did not move between planning and execution. In this case you can increase the threshold value in the ros parameter /move_group/trajectory_execution/allowed_start_tolerance - or disable the check by setting it to 0.0

http://moveit.ros.org/moveit!/ros/2017/01/03/firstIndigoRelease.html

> [ERROR] [1511284205.660285187]: 
> Invalid Trajectory: start point deviates from current robot state more than 
> 0.01 
> joint 'arm_elbow_joint': expected: 0, current: 1.84494 

This means the trajectory you try to execute starts far away from the current 
state of the robot. Likely your trajectory starts at the all-zero configuration 
which means whichever node plans the trajectory doesn't know, or less likely 
ignores, the current joint configuration. The most common source of error to 
trigger this would be that the `move_group` node does not subscribe to the 

correct JointState topic. 

*******************************************************

Hi all,

So this new feature has been introduced, however it is causing me all ends of problems when running the ARIAC Gazebo competition simulator.

Even though it seems we can disable or alter the threshold through setting the ROSPARAM:

rosparam set /move_group/trajectory_execution/allowed_start_tolerance 0.0

or in rospy

# Set trajectory execution ros paramters
rospy.set_param('/move_group/trajectory_execution/allowed_start_tolerance', 0.0)

It seems to have no discernible effect and I still get this error, even when I check ROSPARAM again and it is definitely set to 0.0.

Is there any possible way that the code call or rosparam call is being ignored?

This is on ROS Indigo / 14.04.

Any help is appreciated

Cdr

> Even though it seems we can disable or alter the threshold through setting the ROSPARAM: 
> 
> rosparam set /move_group/trajectory_execution/allowed_start_tolerance 0.0 
> 
> or in rospy 
> 
> # Set trajectory execution ros paramters 
> rospy.set_param('/move_group/trajectory_execution/allowed_start_tolerance', 
> 0.0) 

Where did you find these lines? 
You should set the parameter in the launch files instead. 
The parameter is managed by dynamic_reconfigure. As far as I understood 
from its implementation, this only fetches the parameters from the parameter 
server *initially*. After that the values can/should be configured by 
ROS service calls. So if you really want to change the parameter at runtime, 
you have to call the service, e.g. by 

$ rosservice call /move_group/trajectory_execution/set_parameters "config: 
  doubles: 
    - {name: 'allowed_start_tolerance', value: 0.0}" 


v4hn 

-- 
Michael Görner, M.Sc. Cognitive Science, PhD Student 
Universität Hamburg 
Faculty of Mathematics, Informatics and Natural Sciences 
Department of Informatics 
Group Technical Aspects of Multimodal Systems 

Vogt-Kölln-Straße 30 
D-22527 Hamburg 

Room: F-315 

Phone: +49 40 42883-2432

**********************************************

I am using Moveit with ROS kinetic for planning the motions for a UR5 arm. I am using the Track_IK kinematic solver. The problem is , I am speicifying simple goal poses for the gripper in cartesian space, but I am getting the error message in the terminal of moveit_planning execution.launch.

[ERROR] [1511284205.660285187]:
Invalid Trajectory: start point deviates from current robot state more than 0.01
joint 'arm_elbow_joint': expected: 0, current: 1.84494

I looked into the issue mentioned here. But I'm using trac_Ik instead of Descartes. So I am not sure how to implement a proper solution.

From that thread, it seems like the general solution is independent of whatever IK solver you're using, Trak-IK or Descartes. I think the most relevant part of that thread is this:

The way to handle this is to "connect" the start of the descartes-generated trajectory with the current position of the robot. You can do this manually by inserting a trajectory_msgs::JointTrajectoryPoint with the positions variables set to the robot's current position into the trajectory before attempting execution.

You also mentioned that:

I also referenced this, but then changing the

/move_group/trajectory_execution/allowed_start_tolerance to 0.0 is giving me another error.
[ WARN] [1511285456.138267775]: Controller failed with error code INVALID_GOAL
[ WARN] [1511285456.138359326]: Controller handle reports status FAILED
[ INFO] [1511285456.138473683]: Execution completed: FAILED
[ INFO] [1511285456.168054862]: Execution request received for ExecuteTrajectory action.

in the terminal where I launch the UR_driver to interface with the real robot I have the error

[ERROR] [1511285455.959112929]: Goal start doesn't match current pose
[ INFO] [1511285455.995846536]: on_goal
[ERROR] [1511285455.996445868]: Goal start doesn't match current pose
[ INFO] [1511285456.036065982]: on_goal

This is because the controller on the UR has a similar protection mechanism that you disabled in MoveIt: it will refuse to execute the trajectory if the start state isn't the current state of the robot. (See this for some more info). I would suggest re-enabling the check in MoveIt and adding your current state to the beginning of the path you are trying to execute.

It looks like the relevant portion of your code is in the move2pose method.

Hope that helps you figure out how to tackle your problem.