ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A answers.ros.org

# Twist message working & ackermann type conversion

I am familiar with ROS and the concept of twist message. Recently, i used the teb_local_planner concept to convert the conventional twist messages into the ackermann type and thus,the designed steering based worked well.

But now, i want to understand the actual working of how the twist causes movement of the wheels,even in case of conventional differential based bots. When i use any twist message, ex: rostopic pub /catvehicle/cmd_vel geometry_msgs/Twist -r 8 -- '[2.0, 0.0, 0.0]' '[0.0, 0.0, -1.8]' , then what are the internal operations going on which results in movement of the bot?

Is there any specific package used in the launch file of the bot which links this twist based velocity commands into encoder values?

Also, changing this twist message into ackermann type involves any new set of internal operation to drive the wheels?

Regards

edit retag close merge delete

Sort by » oldest newest most voted

Every robot is going to have a unique way of handling the conversion from Twist message into motor commands. It depends on the geometry of the robot, the motor controllers, what feedback is available, what type of motor is involved, the existence of APIs, etc. So it is difficult to give a general answer for how to do this.

For wheeled robots, likely the biggest thing that is needed is an understanding of the kinematics of the robot. For a differential drive robot (like a TurtleBot), if we have a desired forward and angular body velocity (the data contained in the Twist), there is a unique mapping that tells us what translational velocities each of our wheels needs (assuming we know how far apart the wheels are). Then if we also know the diameter of the wheels, we can uniquely calculate a desired angular velocity for the motor. This information can then be passed onto a motor controller in some fashion.

Let's look at the TurtleBot as an example:

• This callback is the callback that actually listens to the Twist message on the cmd_veltopic. They convert the data in the twist into a tuple representing the translational velocity of each wheel that gets stored as self.req_cmd_vel
• Then at the very end of the TurtlebotNode.spin method they call self.drive_cmd with this tuple of wheel velocities.
• Because we are in "twist control mode", the self.drive_cmd actually calls the Turtlebot.direct_drive method defined in the create_driver script. This method transmits a command to the robot base over a UART connection using PySerial. The protocol for this communication was originally defined by iRobot.

If you are interested in studying the kinematics of mobile robots, I'd recommend looking at Siegwart's Introduction to Autonomous Mobile Robots. Section 3.2 of Correll's Introduction to Autonomous Robots (available as a pdf) has a good walkthrough of diff drive robots and car-like steered robots.

more

Thank you for such a great and explanatory reply. The book you mentioned has a perfect summary of what the ackermann steering involves.

( 2017-05-04 03:33:01 -0600 )edit

If i need to start learning CAN Interfacing and need to implement them with the steering model, do you suggest me to work on the controller packages as well,or will working only with kinematics of the steering model will do my job of linking with CAN?

( 2017-05-04 03:55:34 -0600 )edit

I'm not really sure what your application is, but fundamentally, CAN is just a communication protocol. If you are using CAN, my guess is that is because you have motor controllers that use CAN. You need to write a ROS node that converts Twists to motor velocities and then sends them over the CAN bus

( 2017-05-04 10:50:08 -0600 )edit