Integration of JointLimitsInterface into components structure

[destogl]

Status and future steps (Nov. 2023)

There is currently an implementation of joint limiters using clamping method. The implementation is in #971 and enables position, velocity, and acceleration limiting. We also have tested the usability of the Ruckig library for joint limiting in #970 to achieve trajectories with limited Jerk. This approach is suboptimal, and the conclusion is to rather use Ruckig for trajectory generation inside a controller, e.g., Joint Trajectory Controller (JTC), than as a filter. This means that Jerk limiting has more chances to be implemented using clamping method (see #971) in the future.

The PR currently implements only use of the joint limits from parameter server. Although, there is already setup of the interface to get the robot description from topic and therefore also the joint limits.

Feature parity with ros_control

Missing features

• URDF parsing to get joint limits
• (optional) URDF passing instead of getting robot's description from the parameter. This is inline with Pass URDF to controllers on init #1088 where URDF is passed to controllers when they are initialized. This approach does not allows the update of robot description after a controller is loaded, but ensures the state across the framework.
• SafetyLimiter that uses Safety limits to reduce the speed near the position limits (previously called SafetyController

Features to test

• parsing SoftLimits from parameter server

Open discussion points

• Forcing the limits on hardware level is not ensured with the current approach, but for now, the controllers are implementing limiters. The implementation can also be used in Hardware, but what we are missing is the concept of automatic limit application for all hardware if those are defined.
• Should limiters be fully dynamic and handled inside the Resource Manager too? This is good for safety, but less good for the flexibility. Besides that, to implement this in a general way will need a lot of effort.

Old (and obsolete) description from Dec 2020

There a few issues regarding joint_limits_interface, this one should be an overview issue for their integration into components architecture. If you know other related PRs and issues please add those.

Review #271 and thinking about its test I came to the following conclusion/proposal:
joint_limit_interface should be integrated into ResourceManager. ResourceManager represent (logically) RobotHardware from ROS1.

Here a list of consequences of this approach:

• Joint limits are defined in URDF (primary) and YAML (overlading them)
• They are always enforced if defined (maybe we could add a parameter to avoid this)
• Users don't have to care about them anymore, but just define them in URDF.
• The limits are enforced over hardware borders (e.g. state and commands interfaces are read/written from separate hardware - encoder and motor have separate communication paths) - Example 6 in the roadmap

Related issues:

• joint_limits_interface should not wrap JointHandle in shared_ptr #191
• Refactor enforceLimits in joint_limits_interface #188
• Acceleration Limits from URDF #340