# Is there a REP or standard for the /cmd_vel topic?

Is there anything that says "Thou shalt only use geometry_msgs/Twist on the /cmd_vel topic"?

Is there anything that says how a robot might indicate, "I have 2 wheels and can only move in the X direction or rotate about the Z axis"?

What should a robot do if it is commanded to move in the Y or Z axis and it is not capable of doing so? Should it halt and catch fire? Should it silently ignore such commands?

Oh yeah, how about some way to indicate "If you ask me to go 3e8 m/s, I'm not going to be able to achieve that. The best I can do is 1e-2 m/s, and that's only on a good day".

Thanks.

--wpd

edit retag close merge delete

Related discussion on ROS Discourse which seems to raise the same/similar points: Is “Twist” (still) a good velocity command interface (especially about the lack of a "return channel" in this interface).

And a related Q&A: #q332587 (which references the same REP).

( 2020-06-03 02:20:37 -0500 )edit

Sort by » oldest newest most voted
Is there anything that says "Thou shalt only use geometry_msgs/Twist on the /cmd_vel topic"?


You can always do whatever you want, but you are clearly aware of the general convention around this so its good to follow it when you can and it makes sense to. No, there isn't an REP specifically listing cmd_vel as the "official" base driver topic, its just a sane default we typically use, similar to camera_info and image for working with camera streams. There are tools like image transport that will help you if you do it that way, but you don't have to.

What should a robot do if it is commanded to move in the Y or Z axis and it is not capable of doing so? Should it halt and catch fire? Should it silently ignore such commands?


That's up to your application and needs. If you have an omni robot, then Y could be a real command so you don't want to ignore it. If Differential, then its obviously bogus and you could either silently fail or throw something and both would be reasonable in context. If you're in control of your trajectory planners, you shouldn't have a situation ever with an invalid twist.

Oh yeah, how about some way to indicate "If you ask me to go 3e8 m/s, I'm not going to be able to achieve that. The best I can do is 1e-2 m/s, and that's only on a good day".


Lookup various forms of the velocity smoother package, that should be what you want.

more

I do agree with most of what you write though.

( 2020-06-03 02:51:08 -0500 )edit

That's not really an REP on using cmd_vel, that's a description of the TB mechanism including other stuff and not generalized for "thou shall...". I don't think that's the intent of the standard to be interpreted that way.

( 2020-06-03 09:08:49 -0500 )edit

Technically you're correct.

However it's the only official documentation about cmd_vel afaict.

I don't think that's the intent of the standard to be interpreted that way.

I don't completely understand this part of your comment. Interpreted how?

Even though REP-119 is not specifically about cmd_vel, it does give information on how that topic should be used, which is what a REP about it would also do.

( 2020-06-03 09:14:06 -0500 )edit

That REP is just an explanation of the TB topic / node structure, I don’t think that any particular element from it should be selectively pulled out and thought of as the “right way” to do things or quoting that REP as a standard for how to do things. The scope of the REP is pretty clear and its not written to be a “thou shalt...” in any of the elements of it.

( 2020-06-03 09:38:31 -0500 )edit

I don’t think that any particular element from it should be selectively pulled out and thought of as the “right way” to do things or quoting that REP as a standard for how to do things

again, technically correct.

However, I don't believe it's a stretch to assume many implementations of base drivers since that time have either been modelled on the TB implementation or the PR2's (which essentially uses the same semantics).

If that's the case, we're not selectively lifting anything here: that has already been done by the authors of those drivers. We're referring to the parts of the REP which relate to the behaviour (and sometimes implementation) of the driver on which many others are modelled.

The scope of the REP is pretty clear and its not written to be a “thou shalt...” in any of the elements of it ...

(more)
( 2020-06-03 10:14:08 -0500 )edit

For the TB, I think we’re both on the same page

( 2020-06-03 12:11:55 -0500 )edit

Edit: I only now realised you tagged this with ros2.

The REP referred to in my answer was written almost 10 years ago -- so no ROS 2 -- but it's fairly ROS-version (or even: ROS) agnostic, so I feel it's still relevant.

As I wrote at the end of my original answer: I would still support a new REP which lifts the relevant pieces about cmd_vel from REP-119 and gives it its own document. It would still not need to target any specific ROS version though.

Is there anything that says "Thou shalt only use geometry_msgs/Twist on the /cmd_vel topic"? [..] I feel like I read a REP about this once before, but all I'm seeing today is REP-103.

While it's not strictly about cmd_vel itself (and it doesn't use the wording you used ;) ), there is a REP which describes part of the behaviour of the ubiquitous cmd_vel topic/interface: REP-119: Specification for TurtleBot Compatible Platforms:

Level 1

TurtleBot Node Core API

• Subscribed Topics

• cmd_vel (geometry_msgs/Twist):

The desired velocity of the robot. The type of this message is determined by the drive_mode parameter. Default is geometry_msgs/Twist.

[..]

Level 2

Software Requiremets

• The base moves based on geometry_msgs/Twist [10] on the "cmd_vel" topic

If the base is not holonomic, only the components of the command which are achievable should be executed.

This REP also claims dependency on REP-103: Standard Units of Measure and Coordinate Conventions which (should) immediately fixe(s) cmd_vel to only accept Twists with SI units for all the fields (so no "unit scale" values, as some drivers actually do), establishes the use of a right-handed coordinate system for the base and the interpretation of Twists, and a dependency on REP-105: Coordinate Frames for Mobile Platforms, which establishes standardised frames (names and semantics) for such mobile platforms.

The REP even includes some minimal mention of "command timeout" functionality:

Expected Parameters

• ~cmd_vel_timeout (double, default: 0.6)

If a new command isn't received within this many seconds, the base is stopped.

Quite a few drivers still do not have this.

As is clear from the excerpt however, this is only a very minimal specification of the syntax and semantics of cmd_vel (so it doesn't address all of the questions you raised), but there is some specification and it seems to have been fairly successful.

Not many drivers claim to comply with REP-119 though, as, as @stevemacenski writes, most developers mimic existing interfaces and their implementations, or simply reuse libraries which "force" them to comply, so you can expect fairly similar behaviour between different implementations. As the Turtlebot provided a pretty good example (or generalisation actually) of what it means for a robot to have a mobile base, many early ROS users started copying it (without being aware of the REP most likely).

Is there anything that says how a robot might indicate, "I have 2 wheels and can only move in the X direction or rotate about the Z axis"?

What ...

more

Thanks. I missed REP-119. I am aware that there are "general conventions" about this, but thought it would make sense to ask the question anyway (perhaps with a little bit of dramatic emphasis). I only tagged this as ros2 because I had to give it some tag. I'm terrible with tags :-)

( 2020-06-03 07:38:23 -0500 )edit

I've deselected my answer as the answer, as technically, REP-119 does not just standardise the semantics of /cmd_vel, but of the TurtleBot stack (back in 2011).

The semantics and intended way for /cmd_vel to work, as well as the message type the topic should carry (ie: geometry_msgs/Twist) are documented in it, but the OP's question was: "is there a REP for the cmd_vel topic", and that is not the case (afaict).

As @stevemacenski's answer below is more correct in this sense, I've marked his as the answer to the question raised by the OP.

@wpd: if you don't agree, please comment.

( 2020-06-03 11:06:08 -0500 )edit

PS: I still believe REP-119 provides the best description of the semantics of the topic, and the intended operation of nodes which subscribe to it though.

The fact that there are many other aspects of a specific ROS stack documented by that REP does not reduce the value of the parts about /cmd_vel as far as I'm concerned.

( 2020-06-03 11:07:23 -0500 )edit

Given that my original question was a thinly veiled version of "I think I recall reading REP-119 once (perhaps 11 years ago), but don't recall where or when... can anybody help me out?", I think that both of your answers address my immediate need. And this discussion as a whole appears to highlight a need (or at least a desire) for some standardization in this area.

I am happy with both answers, and appreciate the discussion that this has generated.

--wpd

( 2020-06-03 13:28:05 -0500 )edit