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

  • Post author:
  • Post category:其他



“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.