The Balancing Robot

Now avaliable as a kit
A balancing robot kit is now avaliable via Kickstarter: Check out the blog post as well:

Hello everybody
I have for a long time wanted to build a remote controllable balancing robot aka Segway – that’s was actually the main reason why I created the PS3 Bluetooth Library both for Arduino and the FEZ Devices. It has been a long time since the sneak peak and the performance has been improved a lot since then. The original one had a FEZ Rhino as the main processor, but I discovered that it was not fast enough to read the encoders, as it is not running embedded code. Also I was already using more than 10ms per loop, which I used as a fixed time loop, so I decided to step up a notch and go for a much more powerful device: the mbed microcontroller, which is an ARM Cortex-M3 running 96MHz.

It might have been possible with just a normal Arduino (NB: I have now ported the code to Arduino, see update for the code), but I didn’t want the speed of the processor to be an issue, so I decided to go for the mbed. The robot also features an Arduino Duemilanove with a USB Host Shield on top running a sketch based on my PS3 Bluetooth Library. The mbed board actually has USB Host functionality, but I decided not to port the PS3 Bluetooth Library as my original thought were to use an Arduino Due, but as you might know it hasn’t been released yet, despite the Arduino team announced, that it would be released by the end of 2011. But as soon as it is released I think I will port the code to it instead.

Video Demonstration
Here is a short video demonstration of the robot and me explaining some of the concepts of the design and how it works:

The Hardware
Here are some pictures of the robot:

Here is a list of all the hardware I used:

I also used:

The robot itself is made of three pieces of 215x75x7.5mm MDF wood and four threaded rods. The distance between the plates is 7cm at the bottom and 7.5 at the top. In total the robot is 27cm high including the battery.
See the 3D model for more information.

3D Model
I have created a 3D model in Autodesk Inventor with true dimensions, this will hopefully inspire other people for there robot design. All files can be found at github.
The 3D model can also be viewed at the following site:

Check out these rendered images of the robot:

The Code
All the code and 3D model can be found at our github. Here is a list of hyperlinks for all the repositories:

Also check out the wiki.

I have now ported the code to Arduino. The code can be found at github:

I have thought about how I could improve the performance of the robot. First of all I could try to use an accelerometer with a smaller resolution, as the one I got is a ±3g and ±1.5g would be sufficient for my needs. Also my gyro got a resolution of ±300 deg/s and I have seen people use gyro with a resolution as low as ±50 deg/s.

Another aspect would to use belts to minimize backlash, instead of connecting the wheels directly to the motors – a bit like this one.

Also I don’t compensate for the battery level in the code – so it behaves differently depending on the battery level.

Overall I am really happy about the end result – it balances pretty well and the remote control works perfect!

It has been a really good learning experience for me and a really fun project to do, but also very time-consuming – I have spend many nights tweaking the PID values and adjusting tiny bits of the code before I accomplished the end result.

The next step would to build a full size one, but I don’t know if I will do it the near future – but hopefully some day :)

That’s all for now. Hope you like my robot. Feel free to post a comment below and I will answer as quickly as possible.

  1. June 17th, 2016 at 13:06 | #1

    You should simply just subtract the turning value from one motor and add it to the other, as it is done here:

    Can you upload a video of it, then I will take a look :)

  2. Jean Khoury
    June 18th, 2016 at 19:04 | #2

    @Kristian Sloth Lauszus

    Hey Kristian,
    Before recording a video, I wanted to know if it’s necessary to use a motor encoder? I’m using an arduino motor shield instead of a motor driver too.

  3. June 19th, 2016 at 09:10 | #3

    @Jean Khoury
    Yes I would differently recommend using encoders!

  4. Jean Khoury
    June 19th, 2016 at 21:08 | #4

    @Kristian Sloth Lauszus

    Ok then that’s my starting point. I’ve done a little research about rotary encoders, and all I got is that it gives us the speed of the wheels with its direction, but I didn’t find any related arduino libraries or how to get the informations, codings, anything in general.

  5. Jean Khoury
    June 21st, 2016 at 15:10 | #5

    @Kristian Sloth Lauszus

    Hello again Krisitan,
    So I managed to stabilize it with some oscillations of course due to not using encoders for the moment, however I’m trying now to make the robot move forward/backward. I’ve tried adjusting the PID’s setpoint but due to the current parameters it falls almost instantly. How did you manage to do it?

  6. June 24th, 2016 at 09:08 | #6

    @Jean Khoury
    Please read the following page:

    Also take a look at the Balanduino code:

    Can you record a video of it and upload it somewhere, then I will have a look.

  7. Jean Khoury
    June 29th, 2016 at 14:59 | #7

    @Kristian Sloth Lauszus

    Hello Kristian,
    Sorry for too many questions 😀
    So I re-arranged my PID parameters, and managed to move the robot forward ( had to add some I for a faster respond). it’s not perfect however due of course to not using an encoder.
    I found an arduino encoder, the KY 040, I managed to read the data ( value between 0 and 255) but the link you gave me did not help much, the code didn’t work for me.
    my question now is how to calculate the wheel speed ( to have it as an input for speed control pid and get as an output the angle that will be used as a setpoint for the balancing pid).
    since speed = d position/d time, I thought of fixing d position as the distance between two clicks, but I don’t even know how to do that, am I even thinking correctly?

  8. Jean Khoury
    June 29th, 2016 at 18:24 | #8

    @Kristian Sloth Lauszus

    So I took some time to think about it, here’s what I got.
    the encoder gives 20 ppr, which means 18 degrees per tick. ( that’s a shity resolution to me !)
    pi->180 degrees, which means 18 degrees -> pi/10.
    so the distance between two consecutive ticks would be d position = pi/10 * diameter of the wheel. I only need to calculate d time between the two ticks using millis and voila.
    What do you think? Or maybe enlighten me with the way you did it 😀

  9. Pat
    June 30th, 2016 at 19:48 | #9

    @Kristian Sloth Lauszus

    Thank you again Kristian, as i am already using the latest version of your Balanduino code it was my understanding that the bot should turn as good as it goes forward and backwards without needing to adjust the code. Could it be a Bluetooth speed issue with the dongle

  10. August 7th, 2016 at 17:10 | #10

    @Jean Khoury
    I would use a encoder with higher resolution.

    It actually turns quicker than it can move forward and backward.

Comment pages
1 11 12 13 2196
  1. No trackbacks yet.