Home > Arduino, Balanduino, Bluetooth, Guides, TKJ Electronics > Full size DIY Balancing Robot

Full size DIY Balancing Robot

It has been quite a while since my last blog post, but I am finally ready to reveal what I have been working on the last months. Ever since I made my first balancing robot: http://blog.tkjelectronics.dk/2012/03/the-balancing-robot/ and the Balanduino I wanted to build myself a full size version which I would be able to ride just like a regular Segway.

Finally I decided to make one together with a good friend of mine Mads Friis Bornebusch in a course at my university DTU (Danish Technical University/Technical University of Denmark).

Video demonstration

Mechanical construction
The main frame is an aluminium checker plate that is 500x360x7mm which the motors are bolted onto. This width was chosen, so it would be able to go through a normal door opening. The motors used are two MY1020Z 500W, 24V, 12.6Nm brushed DC motors.

I ordered them from Germany, as I needed them right away, but you should be able to get them much cheaper by ordering them directly from China.

Below is an image of the aluminium checker plate after we have drilled the holes for the 8mm steel bolts. Note that these are countersunk, so they are flush with the surface. I would recommend using lock nuts to ensure that the bolts will stay in place – you can also use Loctite instead.

Aluminium checker plate - ready to mount the motors

Aluminium checker plate – ready to mount the motors

Motor with hub

Motor with hub



Countersunk bolt

Countersunk bolt

Motor bolted onto frame

Motor bolted onto frame


After that we drilled four countersunk 10mm holes. These are used to bolt two SKF Y bearings to the middle of the frame. Inside these are mounted a 300mm ½″ steel water pipe with some custom made fittings for the 25mm bearing.

Custom fitting on the pipe

Custom fitting on the pipe

Finished assembly

Finished assembly


In one end is mounted a 10kΩ potentiometer which is used to tell the position of the steering rod. It is mounted to a hole in the endcap secured using some epoxy. The potentiometer is then bolted to a square aluminum bracket secured to the main frame using screw holes we made.
In the other end is mounted a 90° bracket – note that we have welded a solid iron rod inside the rod, at the bracket, as it broke off during testing. All pipes are just ½″ steel water pipe that you should be able to get at your local hardware store.

Potentiometer for steering mechanism

Potentiometer for steering mechanism

90° bracket

90° bracket



Mounted to the other end of the 90° bracket is the steering rod. This is 1050mm long with a T-bracket in the other end. Two 180mm pieces with an endcap are then used as the handlebar. I decided to put some tape used for bicycles around the handlebars to give them a more comfortable grip.

Two springs from an old washing machine are connected from the edge of the frame to 230mm up on the steering rod. This ensures that the steering rod will always center itself. The hose clamps are there to ensure that both are equally tight.

Spring mechanism

Spring mechanism

On the handlebar is also a deadman button which is connected to the reset pin on the motor drivers. This needs to be held in while riding it and will prevent the motors from turning if it is released.

Deadman button

Deadman button

In order to mount the wheels onto the motors we made a custom motor hub.
A 3D-rendering of the motor hub can be seen below (not supported on mobile devices and some browsers). Note that the cylinder going out from the hub is meant to add support, as it will fit around the motor shaft. We did this as we were worried that the load might damage the gearing inside the motors.

The 3D-drawings are available at the Github repository.

Finished motor hub

Finished motor hub

The electronics

The heart of the main board is a 16MHz Arduino Pro Mini running at 5V it reads a MPU-6050, 3-axis accelerometer and gyroscope in order to estimate the angle. This is done by reading the accelerometer and gyroscope at 500Hz. The measurements are then fusioned together using the Kalman filter I wrote some time ago.
It then uses the angle as an input to a manually tuned PID-controller which will output the PWM value needed to keep the robot balanced.

A Bluetooth SPP module is connected to the microcontroller as well. This allows it to communicate with an Android phone via Bluetooth using an application I have written.

Two inputs on a LM324 operational amplifier is used as a buffer. This buffers the signal coming from the deadman switch. This is needed as there is a 20kΩ pull-up resistor on each of the motor drivers reset inputs. The diode D1 is there to ensure that the microcontroller will never be able to drive the signal going to the reset pins on the motor drivers high.
Furthermore one input is also used to buffer the voltage measurement read from the batteries.

One input is used as a inverted amplifier in order to amplify the signal coming from the potentiometer connected to the steering mechanism. The 10kΩ potentiometer is used to adjust the output until it is roughly 2.5V.

A buzzer is also connected. This is used for basic feedback, as it will beep when the robot is turned on and will be turned on in case the battery voltage gets too low.

Headers for signal going to the two motor drives are also available.

Main board schematic

Main board schematic


Below is a picture of the finished PCB. Note that the MPU-6050 is mounted using some double sticky foam – this is to reduce vibrations.
The final PCB can be found at the following link: https://github.com/Lauszus/BalancingRobotFullSize/tree/master/PCB.

Etched PCB

Etched PCB

Main board almost done

Main board almost done


In order to control the two motors you will need two high power motor drivers. We decided use the Pololu High-Power Motor Driver 24V/23A. Each motor driver is rated at 23A continuous current without a heatsink. We have mounted heat sinks on the motor drivers to ensure that they can handle the current, as the motors have a peak current of 26.7A according to its specification. In this setup the motor drivers does not even get hot.

Motor driver front

Motor driver front

Motor driver back

Motor driver back


In order to control the motors you simply apply a PWM signal to PWMH and control the direction using the DIR input. This allows you to easily control the motors with only two pins. Note that PWML is not used in the final setup. Furthermore the motor driver has two “Fault flag indicators” labeled FF1 and FF2. These will be drive high in case of a fault. The motor driver can be reset by driving the RESET pin low – this is done if the deadman button is released.
Finally it also features a current sense output. The current sensor is powered by soldering a jumper on the PCB – more information can be found at the product page.

I decided to use this motor driver, as I can control it directly using the I/O on the microcontroller instead of using a serial interface which is also used on some motor drivers. I did not want to use this, as the serial communication is slow compared to just controlling it directly using the pins on the microcontroller.

Also note that the microcontroller and motor driver are both grounded via the same battery. If you intend to power the microcontroller from a separate battery. You will need to solder a wire to GND as well.

Below is a picture of the motor drivers before and after we mounted the heatsink. Note that we cut away the heat shrink at the MOSFETs and applied some cooling paste before mounting the heatsink to the motor drives using some long bolts.

Motor drivers

Motor drivers

Motor driver with heatsink

Motor driver with heatsink


To power everything we decided to use three 6S LiPo 3000mAh batteries in parallel giving a total capacity of 9000mAh.
I have not actually made an endurance test, but they seem to last a pretty long time – it lasted from 10am to 4pm at a conference with only two batteries.

As the maximum voltage of the LiPo batteries is 25.2V (4.2V per cell) you can not simply connect the batteries directly to the VIN/RAW pin on the Arduino Pro Mini. Instead we are using a LM2596 step down switch mode regulator in order to step down the voltage to 8V. This is then stepped down by a 7805 5V linear regulator which is located on the main PCB.

It is very important that all you apply a good amount of solder to all your connections, so they can handle the high power needed. Below is a picture of the custom parallel cable I made. This was done by first applying solder to a 10AWG wire. Three 12AWG wires were then soldered to one end and a wire was wrapped around them in order to keep them in place. The same thing was then done for the other side. Finally a wire was wrapped around the entire joint and solder was applied. This will require a good soldering iron and a large tip in order to reflow the entire soldering joint.

Before connectors and heat shrink

Before connectors and heat shrink

Finished battery cable

Finished battery cable


Below is a picture of the three batteries connected to the parallel cable I made. The three female XT60 connectors are connect to the two motor drivers and the last one is connect to the LM2596 switch mode regulator.

Batteries with parallel cable

Batteries with parallel cable

The finished PCB is then mounted inside a electronic enclosure on the bottomside of the robot. It is mounted using double sided sticky foam in order to reduce the vibrations to the MPU-6050.

Electronics mounted inside enclosure

Electronics mounted inside enclosure


Robot bottom side

Robot bottom side


Robot overview

Robot overview

Me driving the robot

Me driving the robot


The code

Flowchart of the code

Flowchart of the code

The code was inspired by the Balanduino code: https://github.com/tkjelectronics/Balanduino and the basic structure is basically the same. It is written in C/C++ using some libraries and functions from the Arduino platform – these are the Wire (I2C) library and the timekeeping functions millis and micros.

A flowchart of the main loop of the code can be seen to the right.

At first the microcontroller is powered on by connecting the battery to the LM2596 regulator. Then it initializes an input which makes it able to read the current status of the deadman button. After that it sets the pin connected to the buzzer to output and reads the different values from the EEPROM including PID-values, Kalman values etc. If it detects that the EEPROM values should be restored (if the structure of the values have changed due to a value being added or removed to the configuration struct) it will turn on the buzzer for 1 second and proceed afterwards.
The next step is to initialize the UART (Universal asynchronous receiver/transmitter) at 57600 baud rate, the pins connected to the motor drivers and configure the MPU-6050 at a sample rate of 500Hz and set the accelerometer ±2g and the gyroscope range to ±250deg/s. It then calibrates the steering and finally turns on the buzzer for 100ms and initializes the timers it uses for timekeeping.

Now the main loop is running. As it can be seen on the flowchart it will run forever until power is removed. The first step is to check if any of the diagnostic pins on the motor driver are high, this means that there is some kind of fault. If that is the case it will turn on the buzzer to alert the user that something is wrong. The next is to check if any new IMU data is available. The MPU-6050 is configured so it will hold its INT pin high if there are new measurements available.
If there is no new data from the IMU it will check if any data is available at the serial port. This is used to configure PID-values, Kalman values, the amount of turning etc.
If new measurements are available it will read the sensors and calculate the angle using the Kalman filter. Then it reads the steering input from the potentiometer and checks if the robot is upright and the deadman button is pressed. If that is not the case it either means that the robot has fallen over or the user has let go of the button. In this case it will turn off the motors. If not it will calculate new PWM-values for the motors using a PID-controller.

To turn the robot a value is simply added to one motor’s PWM value and subtracted from the other. This value depends on the value read from the potentiometer connected to the steering rod. The specific code can be found inside PID.cpp.

Finally the battery voltage is checked. If the battery is too low it will start the buzzer. After this final step it will go back to the start of the loop.

One key difference between this hardware and the Balanduino is that there is no encoders on the full size version, so it is actually not possible for it to balance on its own.
This also makes it harder to estimate the speed of the robot. This is instead estimated by integrating the PWM value. This is used to tilt the robot backwards as the speed increases to prevent it from falling over.

To control the robot you simply lean forward/backward which will make the robot start to travel in the given direction. You tilt the steering rod to either side in order to turn. The full source code is available at Github: https://github.com/Lauszus/BalancingRobotFullSize.


Android application

In order to easily tune the PID-values and get data from the robot I wrote an Android application.

Below is a picture showing an overview of the Android application.

At the first screen the user is able to see the current draw of the motors, the turning value, battery level, run time and finally the PWM-value on a custom speedometer.

The next screen allows the user to adjust the PID-values, target angle and adjust how fast the robot should be able to turn.

The third screen shows the current position on a map. The position is obtained using the built-in GPS module on the Android device.

The fourth and final screen shows a graph of the current angle calculated using the accelerometer, gyroscope and the angle estimated using the Kalman filter. It also allows the users to adjust the Kalman filter coefficients.

The communication between the microcontroller and Android application is done via Bluetooth. In order to make sure that the data is parsed properly a protocol for this was implemented. It consist of a constant string header, then one byte to indicate the command and then one byte indicating the length of the data to follow. After the data there is a simple checksum. This checksum is calculated by taking XOR of each byte in the message excluding the header. The full serial protocol can be seen in the source codes: Protocol.cpp, BluetoothChatService.java and BluetoothProtocol.java

The phone is mounted on a smartphone dock that is simply zip tied to the steering rod.

Application screenshots

Application screenshots


Further documentation

Part of the assignment was to write a very brief six pages paper. The paper can be found at the following link: GRP12_AUT2_Two_wheeled_robot.pdf. I would really recommend you read through it if you are new to the concept of balancing robots as it explains the basic of how two wheeled balancing robot works and some of the theory behind it.

Furthermore we also did a presentation. A link to the poster is available as well: POSTER_GRP12_AUT2_Two_wheeled_robot.pdf

Future improvements
The final product turned out just as we planned, but there is still room for some improvements that we left out due to time constraints.

First of is to replace the current tires, as they are made of solid rubber. I believe it would help replacing these with some pneumatic tires instead in order to reduce vibrations on rough terrain.

Furthermore I would like to mount some encoders, so it would be able to balance on its own. This would allow me to remote control it! This would also allow me to measure the speed of the robot precisely instead of just integrating the PWM-value. Which should make it travel a bit smoother.

If I had to built it again I would consider making a slot for the steering rod, so it did not land on it if the robot fall over. It would also be nice if I could take the steering arm off in order to ease transportation.

I have also considered replacing the deadman switch with some kind of weight enabled mechanism, so you did not have to hold in the deadman button while riding it.

An obvious improvement would also be to upgrade the motors as they are not nearly as powerful as the ones on the Segway – these are 1500W each. This would enable it to handle rough terrain better and allow it to go faster. I would like to try some hub brushless motors so the ride could be as smooth as possible.

Finally I still need to mount the batteries and motor drivers inside some enclosures in order to protect them from water and physical damage.


If you got any questions or comments. Please do not hesitate to leave them below. Also if you want a picture of some details on the robot just tell and I will upload it!

Part list

Update 9. Juni 2015
I would also recommend the following motor driver as well: 30A 5-25V Single Brushed DC Motor Driver.

  1. Willie
    August 19th, 2015 at 05:31 | #1

    I have it connected the way the schematic shows. I have it plugged directly into the board as you did on yours. I even tried a second MPU-6050 in case it was faulty but it still has the same problem. I tried a second arduino pro mini I had sitting around, still same problem. I tried switching the address as you said in your last response, still the same problem. Any other ideas? Thanks

  2. August 19th, 2015 at 12:34 | #2

    @Willie
    Could you try to run the code found here: http://playground.arduino.cc/Main/I2cScanner?

  3. Willie
    August 20th, 2015 at 05:37 | #3

    I ran the code and the serial monitor just keeps saying:

    Scanning…
    No I2C devices found

    Just an fyi, also put the arduino and mpu6050 on a breadboard to test it by themselves together without the rest of the circuit, but I still got the same result. So then I tried my second arduino pro mini and the other mpu6050 and still, the same result (in circuit or on breadboard). Do you think my MPU-6050′s could be defective or something, they were both bought at the same time?

  4. August 20th, 2015 at 09:17 | #4

    @Willie
    How have you connect the MPU-6050? It sounds like you haven’t wired it correctly.

  5. Willie
    August 21st, 2015 at 04:25 | #5

    So, while I can’t say yet if it operates completely properly yet(because I haven’t got any of the electronics mounted, and I haven’t made the vertical bar), I can say it works, it beeps, the wheels spun, for the short time I was shorting the deadman wires together. :)

    Now to explain what I had been doing wrong the whole time, and it does relate to my wiring as you thought in your last response to me. While breadboarding I had been connecting the SDA and SCL wires to pins 8 and 9 on the arduino, because in the schematic I saw them in the bottom left corner of the arduino board, it never crossed my mind to count how many pins were on each side of the board(physically and by the schematic). Then I found 4 holes in my Arduino that I never put pins in, cause the board never came with pins to do those holes, just pins for the two sides. So i just thought they were for something else that didn’t matter to me. Then i looked the main board and there were 4 holes in the same spot that I didn’t put headers on because I didn’t know I needed those. So after a little more soldering and taking I2CScanner off and putting the normal code back on, and it fired right up.

    It might be a few more weeks or so before I finish building it, but when I do, I’ll email you some pictures of it, because I designed it little differently than yours and I thought you might want to see it.

    But seriously, thanks for all the help Kristian, I know you didn’t have to help me, but you went out of your way to help, and it’s definitely appreciated. Thanks man

  6. August 21st, 2015 at 14:44 | #6

    @Willie
    Good to hear you got it working! Looking forward to seeing the pictures :)

    You’re very welcome. It’s nice to see other people find what I do useful!

  7. Willie
    August 22nd, 2015 at 02:16 | #7

    Ok, I hooked it up for a little bit today, I had someone hold it in the air while I tilted the board around(which isn’t currently mounted, I’m still try to figure out what kind of way I’m going to enclose my electronics). Upon powering it up, both motors immediately spun in the same direction to make it go forward if I remember correctly. So I tried to tilt the board some to slow them down and then reverse direction, but it was unresponsive, it just kept trying to go forward no matter what I did. After about 10 seconds of running, I heard a loud pop (like a firecracker) and then saw fire. One of the big black transistors on one of the motor drivers had fried and it was on fire for a few seconds. At that time one motor stopped, and the other was still spinning, so I disconnected the battery to kill the whole thing. Any idea what might have caused that? I’ll be looking over it more in depth sometime to see if there were any shorts in the wiring of that driver. But I don’t believe there are because I hot glued the driver wires after soldering them to help prevent shorting.

  8. August 22nd, 2015 at 15:25 | #8

    @Willie
    Have you mounted a heatsink? I have attached a heatsink to both my motor drivers. Alternatively you can use the following motor driver: http://www.robotshop.com/eu/en/30a-5-25v-single-brushed-dc-motor-driver.html which works quite well.

  9. Willie
    August 26th, 2015 at 18:40 | #9

    How exactly are those other ones wired, do they use less wires or more or the same. I see where to wire the main power and the motors you use the screw terminals, but where do all the signal wires get soldered to? Do you use the white connector? Or is any soldering done by the two test buttons? Thanks

  10. August 26th, 2015 at 22:16 | #10

    @Willie
    You connect three pins: GND, DIR and PWM and yes you use the white connector. Also consult the user manual: http://www.robotshop.com/media/files/pdf/md30cusersmanual.pdf.

    Since it do not have diagnostic wires and current sense functionality you can just leave them out.

  11. August 27th, 2015 at 18:45 | #11

    I had the same problem with burning transistors. You have to avoid turning on 500W motors without temporary construction that let stand wheels on ground. I think that in this situation (maybe I’m wrong) big current are floating across transistor and it causes fire. When wheels are on ground robot start balancing and everything is OK. Also for test you can connect little 24V motors to test without burning risk or reduce voltage to 12V.

    Have you got any troubles with chainging parameters in android app? When I’m trying to change something (with estabilished BT connection) by sliders, aplication are closing.

    Also my balancing robot doesn’t react on steering potentiometer.

Comment pages
1 2 4546
  1. No trackbacks yet.