ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

ROS Teleop package


Hi everyone,

I am making my own robot (quite similar to Turtlebot in terms of components) and I am working on a P controller to make my robot go straight forward: both motors should have the same velocity, regardless the surface differences in each wheel and the unbalances of the robot itself. The controller is implemented on an Arduino board.

So I wonder, how does the Turtlebot go straight? There must be some kind of control made! Is the code on the Opencr (the “Arduino” that serves as motor controller) open source? When you run the Teleop package in the Turtlebot, you just move it and it works, but… is there any way to research what is happening in a lower level?

Thank you



I believe that the answer that you are looking for is in this code:
A Turtlebot2 has a base called Kobuki. Such base is where the controller is located.

I did not really check it properly, but I am pretty sure that the specific code that you can use as a reference is there. Check the following files: include/kobuki_driver/modules/diff_drive.hpp and src/driver/diff_drive.cpp

If you have problems with the controller, send me a private message :wink:



I think he was talking about the Turtlebot 3 (he mentioned the OpenOCR board).

I might be wrong because I have never used a Turtlebot 3 but the fact that it goes straight might come from the fact that the motors used are Dynamixel servos. These motors already integrate a controller (PID like). So as the 2 wheels are supposed to turn at the same speed, the robot gave more chances to go straight.


Well, in any case, he is not using a Turtlebot 2 or 3. He is developing his own controller with an Arduino board… The easiest way of doing it is to count the ticks on the odometry ( If you actuate over the motor to make the number of ticks on the left wheel equal to the ones on the right wheel your robot will “go straight*”.

If you have servo motors, control the speed is just give them the correct input. But if you pay attention to the differences on the odometry your system will be more robust.
If you do not have servo motors, you will need the odometry to close the speed loop on the controller. But again, pay attention to the differential odometry will increase your performance.

*I said “go straight” because this system is easy, but far away from being perfect. Imagine that the weight of your robot is unbalanced to the left side. If you have soft wheels, the one on the left will deform more than the one of the right. Thus his radius will be smaller, and each tick of the odometry will be a movement slightly smaller on that wheel. After some distance, you will see your robot slightly turning.


You can check out Linorobot’s implementation:

The idea is to have a PID controller for each motor to maintain the required speed defined by Teleop package or Navigation Stack. This requires:

PID SETPOINT : The converted required speed (geometry_msgs/Twist) from m/s and/or rad/s to RPM (Rev Per Min). The kinematics library does the conversion for you, just pass the required velocities and it will return the required RPM for each motor.

PID FEEDBACK : Calculated motor RPM based on the wheel encoder’s ticks per rev over time.

The PID’s output is then used to determine the PWM value required to drive the motor.

Do this in a loop and you get a controller.