Let's always enforce joint limits being set

[henningkayser]

There are so many features in MoveIt that depend on proper joint limits being set, and I don't see any meaningful use case in MoveIt that works without them. We can't compute trajectory profiles based on force and payload, and even then, it would make sense to always require velocity/acceleration limits. So instead of checking for those everywhere we need them, let's always require them to be set in the RobotModelLoader once and drop the logic for them being optional.

[AndyZe]

Are we sure the RobotModelLoader is the only way a robot model could be loaded and passed to, for example, TOTG?

[AndyZe]

Another small issue here: URDF only allows position/vel/effort limits. The URDF can't hold acceleration limits. ros-controls/ros2_control#340

That means, we'll be requiring everybody to add a joint_limits.yaml if this change is made.

[AndyZe]

Another small issue. I'm discovering these issues as I try to implement the idea:

[rviz2-1] [INFO] [1671550775.800705321] [moveit_robot_model.robot_model]: Loading robot model 'panda'...
[rviz2-1] [ERROR] [1671550775.807744666] [moveit_ros.robot_model_loader]: Joint panda_finger_joint1 requires an acceleration limit
[rviz2-1] [ERROR] [1671550775.807968918] [moveit_ros.robot_model_loader]: Joint panda_finger_joint2 requires an acceleration limit

I don't think gripper joints should require acceleration limits, eh?

Overall, I'm starting to think there are too many issues for this idea to be practical.

[v4hn]

You just merged the patch that requires acceleration limits for all gripper joints, if you want to plan with them, right? I agree with your comment here in that it seems very superfluous to enforce acceleration limits for grippers so I'm not sure why you merged that patch.

[v4hn]

We can't compute trajectory profiles based on force and payload,

Yes, and it's a huge shortcoming of MoveIt these days that this is not possible right now. By the state of the art this should simply exist in MoveIt. Looking at obvious cases as BD's Atlas, dynamics limits are a complex function of system state depending on maximum motor torques and this function can be modeled and evaluated for trajectory generation/optimization.
Aside from actually calibrating a model sufficiently well to provide proper inertia/mass values it is just a bit of math to come up with acceleration limits for given configurations. These could serve as input for TOTG and you could get parameterizations at the limit of the robot's capabilities instead of being limited by worst-case configurations (usually fully extended arms) and having to guess acceleration limits.

[sea-bass]

I just ran into issues with this in the context of TOTG requiring velocity/acceleration limits for all joints, and have my two cents to contribute:

Agreed that a default of 1.0 rad/s doesn't make any sense and I'm in favor of removing that. However, I don't think this should require ALL joint limits to be defined.

Take, for example, a robot with 5 joints where 3 of them have velocity/acceleration limits and 2 don't. Rather than erroring out, should we just bypass those 2 unbounded joints and have the 3 bounded joints set the limits?

I'd be OK with throwing an error if NONE of the active joints in the group had bounds, but so long as there is one valid bounded joint, we should be able to progress.