Proposal to Extend `JointLimits` in URDF

[saikishor]

Hello Community!

We, the ros2_control PMC, would like to open this discussion to propose an extension to the JointLimits struct in URDF XML and gather community feedback.

ROS 2 is designed to integrate seamlessly with industrial manipulators, service robots, and other robotic ecosystems. While the existing position and velocity limits cover basic use cases, more advanced motion planning and task execution require additional constraints. Specifically, acceleration and jerk limits play a crucial role in ensuring smooth, safe, and precise motion. The proposed PRs introduce these additional limits into the URDF specification, enhancing motion control capabilities:

• Extend parsing of acceleration, deceleration and jerk limits from `limit` tag by saikishor · Pull Request #212 · ros/urdfdom · GitHub
• Extend JointLimits class to include acceleration, deceleration and jerk limits by saikishor · Pull Request #83 · ros/urdfdom_headers · GitHub

Once these changes are merged, the next step would be integrating these extended joint limits into the ros2_control ecosystem. This would allow controllers to automatically enforce these constraints, ensuring safer and more precise command execution—without requiring users to manually implement workarounds to respect hardware limits.

We’d love to hear the community’s thoughts on this proposal. Do you see value in adding acceleration and jerk limits to URDF? Are there any potential challenges or alternative approaches we should consider?

A related discussion can be found here: Allow for More Complex Joints in URDF

Looking forward to your feedback!

[traversaro]

Replying from Allow for more complex joints in URDF :

I’m not sure if there would be binary incompatibility, as most of the structs are header based and mostly most packages are based on only one of those libraries and I think it should be fine.

Sorry for going a bit technically, but ABI stability/compatibility is a bit tricky. Even if a structure is defined in an header-only library, it can still influence the ABI of another downstream library. In the specific case, in PR Extend JointLimits class to include acceleration, deceleration and jerk limits by saikishor · Pull Request #83 · ros/urdfdom_headers · GitHub you are changing the ABI of the urdf::JointLimit class, that indirectly changes the ABI of the urdf::ModelInterface class, that is used in the non-header-only public method exportURDF of liburdfdom_model.so:

(urdfdom) traversaro@IITBMP014LW012:~/pixiws/urdfdom/.pixi/envs/default/lib$ nm -s -C liburdfdom_model.so | grep " T " | grep "exportURDF"
000000000000ae70 T urdf::exportURDF(urdf::ModelInterface const&)
000000000000ae80 T urdf::exportURDF(std::shared_ptr<urdf::ModelInterface>&)

So by changing the ABI of the header-only urdfdom_headers’s urdf::JointLimits, you are effectively changing the ABI of the non-header-only urdfdom’s urdf::exportURDF.

In a nutshell, it may be just easier to ensure that ROS 2 installation does not install two different version of urdfdom to be safe. Based on rosdep System Dependency: liburdfdom-dev, rosdep System Dependency: liburdfdom-tools and rosdep System Dependency: liburdfdom-headers-dev , I guess the ROS 2 packages that should be migrated from using the system urdfdom to use the ROS urdfdom:

• pinocchio
• gz_dartsim_vendor
• sick_safetyscanners2
• ur_description
• ur_simulation_gz
• sdformat_urdf

Once that is done, it may still be possible for users to mix system urdfdom and ros package urdfdom if they manually install a system apt package that depends on urdfdom (as it happens with other packages that are both provided by the system packages and ROS 2 packages, see for example Conflict between DART library and Gazebo · Issue #724 · gazebosim/gz-physics · GitHub), but at least this will not happen if one just installs ROS packages

@saikishor

Are there any potential challenges or alternative approaches we should consider?

I know that the current URDF spec is a bit in transition https://github.com/ros/urdfdom/pull/183 (mostly due to me that I need to wrap up the PR, my bad :] ). Anyhow, could it make sense to try to formalize/document a bit what these new URDF values represent, just with a short description of what they should represent, if they are supported for all joint types and the units used to represent that? You can take an example the existing spec for limits available at urdf/XML/joint - ROS Wiki .

In the past I experience problems in teams as these limits had different interpretation among the team members. For example, for position one some considered them as “hardware” hard limits (i.e. where the joint physical stop is present, if any) while other considers them as “software” limits (i.e. the value at which the software clips or limits desired position values), so it would be a good idea to try to be less ambigous, at least for new attributes.

In the past the concept of urdf (file format) version was added in Add in support for a version tag. by clalancette · Pull Request #133 · ros/urdfdom · GitHub, this is not strictly related to this proposal, but I guess that once a new release of the urdf (format) is done, it could make sense to mark it as 1.1 given that this is a back-compatible new feature?

Instead, given that there are two officially supported URDF parsers in ROS, one is urdfdom, while another is urdf_parser_py, do you plan to open a PR to update this also in GitHub - ros/urdf_parser_py: Standalone URDF parser for Python. ?

[saikishor]

@traversaro

Sorry for going a bit technically, but ABI stability/compatibility is a bit tricky. Even if a structure is defined in an header-only library, it can still influence the ABI of another downstream library. In the specific case, in PR Extend JointLimits class to include acceleration, deceleration and jerk limits by saikishor · Pull Request #83 · ros/urdfdom_headers · GitHub you are changing the ABI of the urdf::JointLimit class, that indirectly changes the ABI of the urdf::ModelInterface class, that is used in the non-header-only public method exportURDF of liburdfdom_model.so:

@traversaro Thank you for bringing this up. AFAIK, I don’t think it affects the urdf::ModelInterface, I could be wrong

The urdf::JointLimits class is a part of the urdf::Joint class, but it is included as a pointer instead of an object itself directly. Additionally, this urdf::Joint class is also used as a pointer within the urdf::ModelInterface. For this reason, I think it shouldn’t be an issue. What do you think?

@traversaro

I guess the ROS 2 packages that should be migrated from using the system urdfdom to use the ROS urdfdom:

I see only pinocchio, gz_dartsim_vendor and sdformat_urdf from the ROS 2 packages side. The good thing is if we do it now, we have the Kilted for the everyone to migrate and we have things properly sorted out for ROS 2 L as well as next Ubuntu LTS releases.

@traversaro

I know that the current URDF spec is a bit in transition https://github.com/ros/urdfdom/pull/183 (mostly due to me that I need to wrap up the PR, my bad :] ). Anyhow, could it make sense to try to formalize/document a bit what these new URDF values represent, just with a short description of what they should represent,

Nice, it would be great if you can finish this specification part that you started and I could extend it for the new attributes once it is merged,

@traversaro

In the past I experience problems in teams as these limits had different interpretation among the team members.

I always considered them as the hardware hard limits, and use these limits for the last layer of protection, if the user surpasses and send a command to the hardware that is completely outside the physical limits of the hardware.

@traversaro

this is not strictly related to this proposal, but I guess that once a new release of the urdf (format) is done, it could make sense to mark it as 1.1 given that this is a back-compatible new feature?

Make sense, that’s a good idea, we can do that

@traversaro

given that there are two officially supported URDF parsers in ROS, one is urdfdom, while another is urdf_parser_py, do you plan to open a PR to update this

Yes. I’ve a plan to update this part as well. I wanted to open this discussion before starting any further work.

[saikishor]

Hello Community!

If you have something to say on this topic, please post your thoughts or comments in this thread.

Thank you!