ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Hi Florian,

This is possible but pretty tricky. The IK solvers are instantiated when MoveIt! starts and the URDF and SRDF (containing the joint limits) are read from the ROS parameter server. As far as I know, there is currently no way to change the limits in the Kinematics plugin, nor is there an (easy) way to instantiate a new plugin with adjusted limits so this is a bit of a dead end.

However, it is possible to supply the IK plugin with an IKCallback function, that is used to test the validity of the solution using a specified function. In the robot state, this is the GroupStateValidityCallbackFn argument of the setFromIK function. (Typedef found here). This allows you to reject all solutions that lie outside of your new joint limits. Note that this will only allow for stricter joint limits rather than wider. As the IK plugin will still have the original joint limits, there is the chance that the IK solver will come up with the same (invalid) solution each time. To somewhat counter this, the solver will be called with a random seed state for all but the first attempt (out of n attempts as specified in your kinematics.yaml).

Quick note: These random seed states are generated by the supplied JointModelGroup, so if you want to ensure that the random seed state are inside your new limits, you will need to create a JointModelGroup based on JointModel objects with the new limits.

Anyhow, this will hopefully provide you with a solution within your new joint limits. If you want to find a plan to this new joint state, you probably also want to satisfy these limits during the path. Using the JointConstraint field of path_constraints from moveit_msgs::MotionPlanRequest, you can specify contraints on the path that should ensure that the planned path stays within your specified limits. I am not sure how these limits are applied, so I can't say much about the effect on planner performance this has.

In any case, this should give you a solution with satisfying stricter joint limits, but as you can see it will take quite some work to get there. If you get this to work, I'd be interested to hear how it performs!