Proposal to Extend `JointLimits` in URDF

[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.