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
float64 x float64 y float64 theta
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
I’ve also been introducing a bunch of new repos/interfaces recently (
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
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)
- 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
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.