ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

geometry_msgs::Twist references (navigation stack / ros_control)

asked 2014-10-29 11:21:21 -0500

arennuit gravatar image

updated 2014-10-29 11:21:47 -0500

Hi all,

I am currently putting in place a mecanum_drive_controller for ros_control (it transforms a desired twist into corresponding wheels velocities and computes the odometry out of the wheels encoders). This is all fine and working as expected.

Now I have a bit of an uncertainty about what to expect as input (desired twist) and what to provide as output (actual twist computed for the odometry). This is especially important as I expect to be "ros compliant" and integrate with the navigation stack and other standard packages.

So, say I have a mobile robot which is rigidly attached a frame m, of origin Om. I also have a frame odom which is used as a reference. So what I believe is that the input twist provided on topic /base_controller/cmd_vel should the twist of desired Om, seen as belonging to m, in its movement with respect to odom and expressed in the odom basis. This is the desired twist.

The observed twist provided as output should be the same (not the values obviously ;)): twist of observed Om, seen as belonging to m, in its movement with respect to odom and expressed in the odom basis.

Can you confirm?



edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2014-10-29 12:24:39 -0500

dornhege gravatar image

I'm getting confused with all the frames, so let me make it simple.

Twist is usually send without a frame_id, so you (the controller) defines, where the axes lie in your robot. The convention is that x points forward, y to the left and z upwards. Usually the base_link or base_footprint frames are aligned like this. A twist with positive linear.x thus drives forward, positive linear.y left, etc. This given twist is always relative to the current robot, i.e. linear.x always drives forward, nevermind any odometry information (this is stateless).

I would interpret the odometry message's twist in the same way, i.e. linear.x is the observed forward velocity at this moment, indenpendent of any odometry frame.

The odometry pose however usually is the accumulated pose of the robot's base frame in the /odom frame.

edit flag offensive delete link more


Ha! If linear.x and y are relative to the robot, then it means the twists are body velocities. My gut feeling was wrong then. This fully answers my question, thanks!

arennuit gravatar image arennuit  ( 2014-10-29 12:44:16 -0500 )edit

Actually that makes things easier for me as I had already coded my controller this way ;) Thanks again.

arennuit gravatar image arennuit  ( 2014-10-29 12:45:37 -0500 )edit

Question Tools

1 follower


Asked: 2014-10-29 11:21:21 -0500

Seen: 706 times

Last updated: Oct 29 '14