Expected behaviour when cmd_vel == 0

edit

For all robots I've worked with, wrote my own hw interfaces for or have used hw interfaces of others with, cmd_vel was always used to dictate the state in which the system should be (ie: messages encode the desired state or set point). For those robots a command of 0 m/s meant: motors powered, but not rotating.

This has made sense to me, as by convention cmd_vel carries setpoints in the form of geometry_msgs/Twist, which contains the following comment:

This expresses velocity in free space broken into its linear and angular parts.

So, Twists sent to a mobile base platform encode a body relative set of linear and angular velocities. These are then typically mapped onto joint space velocities for wheels in case of a wheeled mobile base such that 'the robot' (or mobile base) attains the desired attitude.

Following this, a Twist carrying only zeroes would encode for a 0 m/s linear and 0 rad/s angular state in the body local reference frame, or in other words: a non-moving robot.

Your other option (unpowered or backdrivable actuators) would lead to a non-zero state in case of "coast[ing] downhill" (as the encoders, which will probably be present to support velocity control, will register a non-zero displacement). That would lead to a velocity error, which a controller would probably try to rectify (by breaking or applying a corrective velocity).

Edit: I don't believe there is a REP that documents or standardises this particular aspect (as in: in a robot-agnostic manner), but there is REP 119: Specification for TurtleBot Compatible Platforms, which in the section called TurtleBot Node Core API writes:

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.

which seems to confirm my experience and intuition.

As almost all use of cmd_vel seems to follow this convention (as authors of early nodes looked to existing implementations to match their own against, and TurtleBot and PR2 were the most prominent ones), I believe only your second alternative would be the correct one.

Edit 2: there is also REP 147: A Standard interface for Aerial Vehicles, which doesn't directly deal with cmd_vel or its semantics, but discusses something similar in the Rate Interface section:

The command is a body relative set of accelerations in linear and angular space.

Note that this talks about 'accelerations', but the idea and use is similar to cmd_vel and velocities for wheeled robots.