Switch from Twist to TwistStamped for cmd_vel

[SteveMacenski]

Right now we use Twist which contains no time based information. This may be important for detecting old or out of order messages in async applications.

A survey should be conducted for supporting this across the navigation ecosystem to support:

• Navigation
• RL
• turtlebot drivers
• gazebo
• other common robot drivers
• rviz (?)

In the mean-time, may be worth having a deprecation warning in navigation controllers for the meantime to let users know its coming. It would be ideal to have most mainstream drivers support this before too many people are ported over and stuck into it.

Maybe rename to cmd_vel_stamped?

[Timple]

Copy-paste from discourse, probably better to have the discussion here:

How does twist_stamped help? It can be stamped upon generation, but maybe the navigation algorithm took very (unexpectedly) long and is thus based on old sensor information.
Or the message never arrives and you cannot check it’s timestamp -> you need a timeout detection mechanism on the receiving side to be safe.

Which problem does the stamped message tackle which cannot be caught with a timeout detection?

[SteveMacenski]

It can be stamped upon generation

Yes, so you know exactly when that command is supposed to be executed.

maybe the navigation algorithm took very (unexpectedly) long

That's an unrelated issue.

Or the message never arrives and you cannot check it’s timestamp

Sure, but when the new message comes and using timing relative to that. If you get an old message instead, you definitely don't want to arbitrarily execute it.

Timeout detection should already be in your system, frankly. But just because you receive a message in a given time window, does not guarantee that it was generated in that time window, or that they're in order, or that they're still valid. You need some knowledge of timing for that.

[Timple]

The inorder part is a good point. And indeed an inorder can messup another timeout system which is unaware of that. 👍

[Rayman]

Nice, I would like this switch to TwistStamped.

On our robots we always publish a TwistStamped in tandem with twist. For rosbag this is nice, but also when viewing a rqt_graph of the cmd_vel. If you have a stamp you have nice smooth graph, even though you could be on a wifi connection for example.

[SteveMacenski]

We will discuss this more after the Foxy release, we don't want to break anything before an LTS or make things harder for other parts of the ecosystem.

In the meantime, it would be helpful to compile a list of places that need to be updated to support this off hand I can think of:

• DWB
• TEB
• pure pursuit
• Spin and backup recovery
• Gazebo/ignition plugins, probably
• open-source robot drivers (kobuki, turtlebot3, create, rover, ?? [not sure how many other vendors even have a ros2 driver yet])

Please add more to this list if you know of anything!

[Rayman]

• robot_localization
• teleop_twist_joy
• teleop_twist_keyboard
• twist_mux
• yocs_velocity_smoother

[SteveMacenski]

This should be started after the Foxy release in a few weeks

[SteveMacenski]

CC @tfoote @Karsten1987 - maybe worth a conversation to divide and conquer for this in Galactic?

[Karsten1987]

CC @bmagyar fyi.

[tfoote]

@SteveMacenski the big thing that I wanted to bring up is that the Header on a Twist is not enough information to allow us to transform it directly there. If I remember correctly there's actually 3 reference frames that need to be captured. I'm going to need to dig through my notes. you can do things like require messages published assume that one or more of those frames are coincident. But that's not always intuitive. I'm going to have to dig deeper to find notes on this. But before we do a mass migration to a TwistStamped we should make sure that it's adaquately complete.