Discussion: Standardizing ROS Interfaces

General
1

Here’s a philosophical discussion I’ve been thinking about frequently lately. There’s a spectrum, between two separate ideas about ROS Interfaces (messages/services/etc):

  • There should be MANY ROS Interface types that should each be used in as specific contexts
  • There should be ROS Interfaces that are general enough to be used in MANY contexts

My personal opinion is that the ROS community / ROS maintainers have skewed too much toward the first point.

Last year, I tweeted a list of provocative ROS topics, including “Should std_msgs exist?” This is an old debate that keeps popping up. The core idea is that a service like GetFloat shouldn’t exist because it’s unclear what the float is. A temperature in Celsius? Fahrenheit? The number of casualties? The flip side is that you can use the name of the interface to specify the semantics. You’re not naming the method GetFloat, you’re naming the method /get_temperature and the return type is a float.

I think that the interfaces should be as general as possible but not too general. For example, much of my navigation code uses nav_2d_msgs, which centers around geometry_msgs/Pose2D:

float64 x
float64 y
float64 theta

instead of geometry_msgs/Pose (like the standard navigation stack does).

geometry_msgs/Point position
    float64 x
    float64 y
    float64 z
geometry_msgs/Quaternion orientation
    float64 x
    float64 y
    float64 z
    float64 w

Pose2D is less general, but the ROS 1 Nav Stack didn’t support moving in the Z direction or 3D orientations. It made the code a lot cleaner in a lot of places to not have to constantly convert to and from quaternions.

However, a decision was made a few years ago to deprecate Pose2D in the latest ROS 2 distros. Simple std_msgs are also being deprecated, like Float32.

I’ve also been introducing a bunch of new repos/interfaces recently (social_nav_msgs, polygon_msgs, kinematics_msgs*, benchmark_msgs*, collision_msgs*). I am not trying to introduce new standards to force upon people, but trying to make them available for people who do want to use them. The generality of the names is two-fold.

  • If they do become standards, then it’s clear that they are not meant to be used with a specific package/ROS organization.
  • They are invitations to collaborate and add more interfaces to the ecosystem. For collision_msgs, right now there’s no standard, between gazebo_msgs/ContactState.msg and moveit_msgs/CollisionObject.msg, Those are two very different contexts, but I think the community would benefit if there was some common structure between them and the types weren’t namespaced behind the specific projects (Gazebo and MoveIt)

However, I’ve gotten pushback on the packages with stars above that were thought to be too general. I’ve renamed some of them, because of valid points deriving from the Naming REP

  • The interface names should be “specific enough” to identify what the package does (but also not overly verbose)
  • The interfaces are not “community-approved” (so far I’m the only one using them) and putting them in the ROS Distro gives them a community-approved smell.
  • Similarly, the interfaces have not gone through the REP process to gain community support (see REP-138 on laser conventions, or REP-147 on drone conventions)
  • The general package names are not anywhere near “complete”, i.e. there’s not a drop-in replacement for CollisionObject yet.

And I get it. I don’t want to “squat” on an overly generic name just to control it. However, I ultimately feel that it makes sense to do this in a “bottom-up” sort of way (rather than top down via REP), and that is more in line with the open source ethos. Put it out there and see if anyone uses it, and how they use it.

To go back to the original philosophical question, I think that these interfaces should be out there for use in multiple contexts because 1) it’s less work for the next developer who wants something similar 2) the centralization means that only one version has to be maintained.

I’m curious what more people think. Consider the discussion opened.

I’ll end with a favorite joke of mine, which is that there are only two hard problems in computer science: cache invalidation, naming things and off-by-one errors.

2 Likes
2

I’m all in favour of generic interfaces, but there’s one advantage of more specialised message definitions that names-of-topics can’t achieve: type safety. And with type safety comes introspection and machine reasoning and verification of node graphs and node compatibility.

Why is that important/desirable? If my temperate sensor node publishes std_msgs/Float32, and another accepts std_msgs/Float32 but controls the gas throttle of a car, I can now use the temperature of my morning coffee to control the forward velocity of my car, and it’s unlikely such a connection would be flagged as suspicious by analysis tools (despite the fact there is no sensible conversion between degree Celsius and m/s).

Tools like ipa320/ros-model and HAROS can do amazing things (like generating an (almost) complete ROS application or answer questions about whether a node in your graph would cause a bottleneck for other downstream nodes given a specific event occurring upstream), but they have the greatest difficulty extracting that information from existing applications. The more generic the message definitions, the harder this sort of work becomes.

(I guess this is partly what has been described as “clear semantics” for ROS APIs in the past: the ‘ability’ to determine whether some connections make sense – or would even work – based on message types. I’d just like to not leave it to humans only)

1 Like
3

Thanks for kicking this great topic off.

I agree with you I’d be glad to see some more standard messages.

Recently, I had a discussion involving naming REP in a rosdistro PR, and we’ve concluded a few things:

  • even if you’re sure your package is super generic etc., as long as it’s just you using it, it should get an org prefix (unless special conditions are met, e.g. the package implements a well known algorithm and anybody else would produce a very similar thing if you told him create a package with this name)
  • after that, you can promote it and convince other people to start using it (which might be a bit harder because of the org prefix, because I generally feel there is a subjective (probably irrational) obstacle for people to start using org-prefixed packages; however, with only message definitions, it might be easier)
  • when your package becomes famous, you can remove the org prefix (this is even the suggested approach in the naming REP). However, this hits one of the big problems in package.xml format and support for ROS messages in client libraries - they don’t support renaming packages. So I think this is one direction of development which could greatly help to resolve your concerns - make the path of org-prefixed packages into non-prefixed ones seamless.
  • what might be a great addition to help this process would be to create a Google Form (or another similar tool) in which users of your package could voluntarily register their github/discourse handles, so that you could reach to them and ask for feedback when going in the org-prefix removal phase.

As a big (and painful) example of semantics in topic names (which should also raise a flag in any system analysis tool, but currently can’t) is std_msgs/Image and its transport companions. These messages e.g. do not contain the information whether the image has been rectified. And there’s no way to figure that out except for searching for _rect in the topic name and hoping your user did not use some other name. So any code just cannot subscribe via a image_transport/CameraSubscriber and get the 3D rays corresponding to image pixels. Because it doesn’t know whether the distortion described in CameraInfo has already been removed or not.

4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.