Build your own TurtleBot3 backbone

Implement the fantastic robotic packages offered by the TurtleBot3 robot on a budget without sacrificing features and performances.

Public Chat
Similar projects worth following
Turtlebot3 is the perfect platform to deep into robotics and AI through.
I propose you to build the TB3 backbone on a budget: replacing expensive Dynamixel servomotors and OpenCR board by cheaper components compatible with all ROS TurtleBot3 packages.

NB: github link to be added soon

Why this project ?

It makes no doubt that ROS (Robot Operating System) is the most common framework for robotics. It offers a powerful middleware for interconnecting sensors and actuators with already packaged drivers and state-of-the-art algorithms (SLAM, vision based algos, IA, control...) also already packaged by the huge open source community.

Among the countless robotics projects based on ROS, one of them shine by its number of features and its rich documentation and tutorials: the famous TurtleBot3. Its open source hardware with modular mechanics is the base for variety of robot's type: 2 Wheel-Drive, 4WD, 6WD, omnidirectional wheels, embedded robotic arm:

NB: Altough this project is oriented on turtlebot's like robot, those features could be used for any robotics platform of your mind

Current Architecture

Hardware components on the Waffle TB3 and Burger TB3 (2WD) are listed above:

  • Propulsion Motors: Dynamixel XM430 servomotor (expensive). Dynamixel servomotors are high quality and performance servomotors, offering advanced features like torque, rate and position control with a complete SDK. All hose features are not needed and came at a price.
  • Microcontroller running low level task: OpenCR board based on Cortex M7 (expensive). This board delivers power for all components, it integrates an IMU sensor, different communication and I/O ports
  • Single Board Computer (SBC) running high level task: RaspberryPi (affordable)
  • Sensors: lidar, cameras (affordable)


This project aims at replacing expensive hardware components with cheaper ones, while keeping software compatibility. Thus Dynamixel servos with OpenCR board will be respectively replaced by brushed DC motors with Arduino Due (based on Cortex M3). The microcontroller firmware will be adapted to match modified hardware.


In this section, I will update the developing state of features covered by Dynamixel+OpenCR converted into BrushedDC+Due.

  • Motor control: convert velocity commands received from SBC into wheel rates (kinematic model), estimate wheel rate with sensors, perform wheel rate control, distribute power to motors [WIP]
  • Odometry publishing: compute odometry from encoders used for localization [DONE]
  • IMU publishing: compute unbiased gyro rates and accelerations along with attitude used for localization (current TB3's implementation use biased values) [WIP]
  • Robot state publishing: several states indicating battery voltage level, hardware faults [TBD]

Those features constitute the core of the robot and could be seen as turtle's backbone.

Project organization

For this project, i decided to follow an iterative approach: build and develop from lower to higher components while trying to validate each performance individually. Some important points regarding this project:

  • this project focuses on TurtleBot3 "backbone" but came in parallel with the design of a complete "TurtleBot3 like" robot (not covered here)
  • each feature involves both hardware and software development that will be covered in logs
  • to facilitate hardware integration, electronics will be simple and based on existing boards (regulators, H bridges, IMU, current sensors...), even if ideally a complete PCB should be designed

  • IMU processing [WIP]

    matop08/12/2019 at 17:38 0 comments

    Hardware integration

    IMU used for this project is the MiniIMU-vX from Pololu, it incorporates several chips that offers 9 degrees of freedom, allowing a complete attitude estimation.

    • LXXX
    • LXXX

    In order to passively filter noise from mechanical structure especially from motors, the IMU should be soft mounted. It is also possible to use integrated filters provided by the chip, all information regarding available filtering frequency and settings are available in the datasheets.

    For this application, I chose ODR + frequency [TBD]

    Attitude algorithm

    The algorithm used on the OpenCR firmware is the Madgwick complementary filter. This filter produces good results regarding advanced sensor fusion algorithms (like Kalman filters), and is able to produce complete orientation (yaw, pitch and roll), when using magnetometer (it is not the case on the current OpenCR firmware).

    I also use this algorithm for this projects with some improvements:

    • include magnetometer measurements
    • allow varying time processing
    • compute on-line gyrometers biases
    • sensors calibration

    Sensors calibration


    An automatic bias computing is performed at firmware startup, no immobility check are done doing this process, so robot should absolutely be kept static during this period!

    Biases evolve in regard of temperature and mechanical stress on the board, although their computing during robot operation is not mandatory.


    Madgwick filter uses accelerometer to compute gyroscopes biases. In details, each time acceleration norm equals to gravity (the robot's speed regarding terrestrial reference frame is constant), so if accelerometer have biases this condition never appends and gyroscope estimated rates diverge from real rates.

    The selected method is the 6-point tumble sensor calibration, which use a quite simple sensor model, with scale factor, cross-coupling and offsets. All details can be found on this document from STMicroelectronics.

    This calibration must be done after fixing the IMU on its support, because fixing it causes mechanical stress on the PCB which must be calibrated. Its not mandatory to realize systematically this calibration at startup, calibration data could be stored in memory.


    The selected method consists in measuring scale factors and offsets which  correspond to hard iron distortions. More details and code are available at this really well made github page from kriswiner.

    This calibration must be done after fixing the IMU on its support and after inserting it inside the robot frame because all magnetic components such as metallic frame or other electronics components could modify the sensor behavior (hard iron). As for magnetometers, this calibration could be done not systematically.

  • Motor speed control [WIP]

    matop08/11/2019 at 19:54 0 comments

    Wheel speed estimation

    Each hall encoder produces nb_{rising edges} logical rising edges per motor rotation (due to multiple magnetization points on encoder ring).

    Speed estimation relies on counting the number of logical rising edges nb_{encoder ticks} during an known time interval dt for a single sensor.

    Wheel speed is then estimate with the following relation

    At low speed, the signal is noisy and filtering is applied. The filter consists in a running average with higher weight on the last value. Some tuning on filter size and weights might be needed.

    Wheel direction estimation

    In order to estimate direction, during each rising edges of sensor A, the logical state of sensor B is read. Then a logical state is associated with a direction.

    This method is quite robust but sometimes presents glitches which are removed using a median filter.

    Control strategy

    Linear and angular reference velocity in the robot frame are converted into left and right wheel reference speed using differential drive kinematics model.

    Then a PID controller tends to make estimate speed converge to reference speed for each motor. PID's output is not directly PWM value but PWM rate.

    Controller tuning

    Tuning controllers could be painful and require basic understanding on effects of each Proportional, Integral and Derivative terms. To accurately tune your controller you will need to log several debug variables while playing a step reference input.

    The ROS package called plotjuggler offers a complete UI for real-time visualization and logging of topics values. Simply publish debug topics with interesting values.


    1. Set I=0 and D=0, progressively increase P until motor get a response with a "important" overshoot (more than 50% of a step respons. Debug variables: reference speed, estimated speed, PWM rate, PWM value
    2. Motor response time could be long, to reduce this increase progressively D value. Be aware that this term tends to amplify noise. Debug variables: reference speed, estimated speed, PWM rate, PWM value, PWM rate from Derivative term
    3. At this point, PWM value might vary a lot, try to smooth it by adding Integral term

    Control and estimation loop frequency

    This section presents some 'businesse rules' that will help you to tune your controller loop and filters.

    The controller frequency should be at least twice higher than your robot dynamics bandwidth (around 5Hz for turtlebot-like robot), so running that loop at 50Hz should be able to produce a good stability and rapidity control.

    The speed wheel estimation frequency should not exceed twice the minimal desired speed. From the equation given at Wheel speed estimation, it is possible to calculate the corresponding frequency.

    About filter: note that delay is your worst enemy, it reduces rapidity and stability. So the more you filter raw encoders value, the more you add delay into control.

  • Hardware selection

    matop08/11/2019 at 16:45 0 comments


    • expected linear speed for a 40mm wheeled robot -> [10mm/s; 1m/s]
    • transformed into wheel rotational speed -> [XXRPM; XXRPM]

    To match spec, we need to paid attention motor's type. For our application, three type of motor would have been OK to replace Dynamixel servo: stepper motor, brushless motor or DC geared motor. Similarly, several angular position sensors would have fit our needs:

    • Quadrature Hall Sensors, they produce analog signal proportional to magnetic field
    • 1 or more Logical Hall Sensors (at least 2 are needed to estimate direction). They produce a logical high state when sensors reach magnetic threshold corresponding to a locally magnetized area on the ring
    • Magnetic encoders
    • Optical encoders

    In order to keep costs as low as possible, widely available DC geared motors with 2 logical hall sensors are used for this project.

    Motor and Encoder sizing


    • max speed: RPM
    • voltage: 6V
    • torque: largely enough
    • reduction gear: 1:850

    NB: the reduction factor must be quite important, because angular position resolution depends on this value, enabling low rate control.

    Motor piloting board

    To power motors the popular double H-bridge L298N board is selected. Documentation an tutorial for this board are widely available on the web.

    This board only support up to 2A per channel while our motors could demand up to XXA. In order to use safely this board, current needs to be monitored.

    Current sensing

    As detailed above, sensors will be used to monitor current and prevent overcharge on L298N. I choose the CJMCU-758 with ACS758LCB-050B-PFF-T that allows bidirectional current measurements.

View all 3 project logs

Enjoy this project?



Peabody1929 wrote 4 days ago point

It would be great to see pictures of the assembly process.  They would help me build one.

  Are you sure? yes | no

matop wrote 7 hours ago point

Thanks for your interest in this project, I planned to add pictures in a future log.

Don't hesitate to ask for more details

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates