Ros_control ABI breakage in Melodic 2020-02

General
1

The latest release of ros_control in Melodic introduced some ABI-breaking changes.
Please make sure to update all dependant packages and forks when updating your ros_control packages in ROS Melodic.
We are sorry for the inconvenience.

Should you encounter actual bugs as a result of this, please open an issue with a description and let’s work through it.

Ref:


2 Likes
2

I may just be a cranky engineer, but dare I suggest that the ABI breakage IS the actual bug? I was under the impression this is why we had the policy of breaking changes being okay between distros, not within them. While I appreciate the post notifying us of it, I personally would rather see this fixed and owned as a mistake as opposed to telling users to deal with it.

From the issue:

While the option of targeting Noetic for it was there, we opted for Melodic to deploy this functionality earlier

That attitude will bite us as a community in the long run, in my opinion. Maybe even in the short run. Companies (and academia) use and rely on the software we as a community write. Throwing breakage at them will at best lead to frustration, perhaps a fork (I know of companies that maintain their own ROS distros for exactly this reason), and at worst a departure from the userbase. This type of thing can make the whole ecosystem look immature.

2 Likes
3

More details on what the improvements were and how to update, please :+1:

4

I was under the impression this is why we had the policy of breaking changes being okay between distros , not within them.

ABIs should only be expected to be stable for packages with versions greater than 1.0; see REP 9 and the Stack Version Policy; ros_control is only at 0.16.0. Even then, case-by-case changes are allowed for serious bug fixes.

5

Nit, but REP-9 is not an active REP, it’s status is Withdrawn (here).

6

Oops, that’s true. Do you know if there’s any newer guidance on compatibility-breaking changes? That was the only one I knew about.

7

I’m not aware of any (active) REPs or similar statements about ABI compatibility or guidance on how to deal with potentially breaking changes right now.

General best practices apply I would say (ie: Semver and all it implies), with the annoyance that many packages in ROS (1 and probably 2) never really leave the 0.x minor.

Two related bits of info:

  • REP-149 does extend the version element in manifest format 3 packages with a compatibility attribute, which should allow one to (from here):

    Specify[ing] the version up to which the package is compatible with, i.e. always pick the oldest compatible version. If not set, the same value as specified in the version tag is assumed.

    “Compatibility” in this context guarantees that downstream packages built against the older version will continue to work with a newer version without the need to be rebuilt. This includes but is not limited to ABI compatibility. Changes in other parts of a package (CMake, Python, etc.) could also require downstream packages to be rebuilt and therefore not qualify as “compatible”.

  • candidate REP-2004: Package Quality Categories (ros-infrastructure/rep#218), which could potentially enforce semver. It’s up for discussion at the moment though.

8

That REP does mention ABI stability within a ROS release, but semver doesn’t actually say anything about ABI compatibility. It only describes how the version number should change as the code does. Whether or not you choose to break the API or ABI and when, is not specified.

9

Fair enough, but in my experience one goes with the other.

That’s why I mentioned it.

10

They’re definitely related, but I think this is a common misconception people have, that one implies the other, which isn’t true in my experience.

If we said “you can adjust minor or patch according to semver within a ROS release”, that says nothing about ABI stability.

Imagine there’s a class with a bug in it, and you fix the bug by changing logic that exist in the .cpp file, but also you add a bool to the class declaration in the .hpp to keep track of some state. This would fix the bug and according to semver would not break API and therefore could be a patch version update only, but it would still break ABI because the size of the class changed. Now you might be able to fix the same bug without adding a member to the class in the .hpp file, and that would be the same fix, but without breaking ABI. As far as semver is concerned they’re both patch version changes and are otherwise equivalent, it doesn’t care if it is ABI stable or not.

11

The big ABI-breaking changes are:

  1. Adding two new optional datatypes to Joint/ActuatorStateHandles, and their associated transmissions. absolute_position and torque_sensor are meant to augment the existing trifecta of pos/vel/eff by providing additional sensor feedback. Note that they are not present in the Joint/ActuatorCommandHandles, and thus are not “commandable.” They are meant only for feedback.

  2. Adding JointModeInterface for switching joints between different control modes. This offers more tools and flexibility for handling switching modes, since currently mode switches are hard-coded into the RobotHW (prepareSwitch and doSwitch) and initiated by stopping & starting the desired controllers. This new interface will allow for plugins to handle the switching logic. (These plugins are still called controllers, but have a very different purpose than existing controllers). It also may be useful for enhancements such as e-stop, homing, better error handling in the case of mode switch failures, etc.

Neither of these have much documentation yet, unfortunately.

The PR with these changes, ros-controls/ros_control#395: