Understanding MoveIt's default setup

[michaelcarvajal]

Hello,

(The following question is regarding the same project mentioned here, but this particular thread is regarding a different aspect of the project.)

We replaced the end-effector on a VX300 arm with a custom one and ended up redefining some of the upper/lower joint limits along the arm in order to both accommodate the new end-effector as well as the new mobile base that the arm sits on. With that said, whenever we launch the interbotix_xsarm_move_it command, the arm jumps to some oddball position instead of just, say, locking in place (the same way it does when launching the interbotix_xsarm_control command). On top of that, the arm doesn't always jump to the same pose. When we changed the joint limits in the URDF, we also updated the SRDF's "group_state" definitions to define what "Home," "Sleep," and "Upright" means (joint position-wise). Changing these values in the SRDF seem to have zero effect on how the arm behaves when starting up under the MoveIt command.

Is there a file that defines what state the arm attempts to travel to upon execution of the MoveIt command?

[lukeschmitt-tr]

When running the xsarm_ros_control package like the xsarm_moveit package does, the arm attempts to maintain a "valid" configuration - i.e. one in which the joints limits as defined by the URDF are not violated. The default joint limits for the arms are very close to the position values when the arm is powered off, so the arm jumps a little bit on startup to achieve a "valid" configuration. If your modified joints limits are significantly different than the default values, you may see quite a bit of movement.

These limits are enforced by the XSHardwareInterface's position_joint_saturation_interface on this line. You can check out ros_control's PositionJointSaturationHandle source to learn more about this behavior.

One way that you can avoid this issue is by commanding the robot to a valid configuration before registering the saturation interface. You can use the XSHardwareInterface's existing pub_group JointGroupCommand publisher to do this.