Velocity limits are provided in multiple locations, but I think there are valid reasons:
- joint_limits.yaml is needed because URDF only provides velocity limits (not accel limits)
- both velocity and accel limits are needed for trajectory filtering
- both URDF and joint_limits.yaml specify
maximum robot capabilities. These should not be changeable at runtime.
- separate interface is needed to specify
desired trajectory velocity for each motion
It would be the most explicit/flexible to do as Ioan suggests and specify absolute maximum joint velocities for each joint in the MotionPlanRequest. However, I think that's overkill, and that most applications will not need that level of detail. In my experience, you don't specify desired joint velocities to get precise control over your motion. At the joint-level, that's fairly abstracted from the actual manipulation task. Instead, you typically specify joint velocities to "scale" the overall motion speed: Fast, Slow, intermediate. You might initially run an application with all joints de-rated to 10% or 25% of maximum speed, until you're confident in the robot's control logic. Then, you can gradually speed up the motions to 100% speed. In my opinion, a per-group scaling factor (not per-joint absolute limit) is sufficient. This could be implemented as a wrapper around a lower-level per-joint absolute velocity limit, but I think that's needlessly complex.
My preference:
- add a joint_velocity_scale field to the MotionPlanRequest (or maybe TrajectoryConstraints?)
- valid range is 0-1 (0 means 100% or "use default", or similar)
- add a new PlanningRequestAdapter (or enhance existing TimeParameterization) to limit trajectory velocities to joint_velocity_scale * joint_max_vel[i]
- add new method to move_group_interface: set_joint_velocity_scale()
- [optional] add a ROS param default_joint_velocity_scale. If MotionPlanRequest.joint_velocity_scale == 0, use the default_joint_velocity_scale instead.
Ideally, I'd like to be able to specify cartesian velocity limits for the end-effector as well, but I'm okay if we want to leave that discussion for later.
- Jeremy