Goal position contstraint for trajectory controller

Questions that are not language-specific
Post Reply
Posts: 1
Joined: Sun Jun 14, 2020 7:06 am

Goal position contstraint for trajectory controller

Post by Leon_House » Sun Jun 14, 2020 7:20 am

For my project I am using Reinforcement Learning for auto-tuning PID gains on a hebi actuator in gazebo.
To increase the influence of the pid control I use control strategy 3 and set all but the position control to 0.
Now when I set the velocity and acceleration limits in the joint_limits.yaml file very high the trajectory controller prematurely "succeeds" the trajectory movement.
I use the ROS JointTrajectoryController, but for normal ROS controllers there is a goal constraint which specifies the goal position tolerance, as seen on the site: http://wiki.ros.org/joint_trajectory_controller .
For the Hebi controllers I can't seem to find such a setting, so my question is how to specify such a constraint for hebi controllers.
Thanks in advance
User avatar
HEBI Official
Posts: 26
Joined: Mon Mar 30, 2020 9:14 am
Location: Pittsburgh, USA

Re: Goal position contstraint for trajectory controller

Post by matt_tesch » Mon Jun 22, 2020 1:56 pm


Sorry for the slow reply!

We looked into this, and believe we know what is happening here. I just want to clarify our understanding of the issue.

It looks like you are using our MoveIt integration:
https://github.com/HebiRobotics/hebi_cp ... c/kits/arm
https://github.com/HebiRobotics/hebi_cp ... t_node.cpp

and you are sending the FollowJointTrajectory action message, as linked from your post and further documented here:
http://docs.ros.org/api/control_msgs/ht ... ctory.html

The current implementation we currently have of the FollowJointTrajectory action is ignoring the following fields:

Code: Select all

JointTolerance[] path_tolerance
JointTolerance[] goal_tolerance
duration goal_time_tolerance
This means that right now, the "success" is purely based on the planned trajectory commands; when the trajectory controller reaches the end of the commanded trajectory, it will return "success" regardless of the current position of the robot. Does this match the behavior you are seeing?

Thanks for bringing up this issue -- we are getting this implemented, and will have a fix pushed out ASAP.

Post Reply