"Straddle Crane" Self-Balancing Robot

I am aiming to create a new self-balancing robot that can drive around an object, pick it up, carry it and offload it.

Public Chat
Similar projects worth following
I wanted to do something practical, challenging and educational for my final year univertsity project. I didn't know a huge amount about the practical side of control engineering or electronics but I was inspired by what other hakers/makers have managed on youtube etc with this type of robot. During my background research phase, I noticed was that many of the self-balancing robots do not fulfill a practical purpose; they are just cool. So I am aiming to adapt existing open-source projects and make a self balancing crane style robot. The project was started in September 2018 and aims to be complete by April 2019. Currently working on getting this page up to date with control script files, circuit diagrams, photos and videos...

Please scroll down to see the project log to see my latest progress. I will provide links to testing videos there.

The concept drawing of the robot is the best explaination of what I am trying to build, and why I have called it "Straddle Crane"...

There are 4 key deliverables of this project:

  1. Build a robot capable of balancing (no position control or crane mechanism)
  2. Develop prototype to be able to move around based on smartphone communication
  3. Add crane mechanism to robot chassis so that the unloaded crane boom can move and the robot remains balanced
  4. Develop lifting sequence and successfully pick an object up whilst remaining balanced

I currently have a prototype that is almost capable of the 1st aim. Here's the link to videos of my intial testing:

Google Photos folder

As you may can see by some of the videos, the control system needs a bit of development. A common problem is that the robot falls when it reaches equilibrium.


Circuit diagram for those of you who use Fritzing.

fzz - 19.94 kB - 03/02/2019 at 11:50



Circuit diagram for those of you who don't use Fritzing.

Portable Network Graphics (PNG) - 246.47 kB - 03/02/2019 at 11:49


  • 1 × Arduino Nano R3 Develoment board & microcontroller that can be plugged into breadboard; this runs the control script that balances the robot.
  • 2 × NEMA 17 Stepper Motor Bipolar stepper motor and has a 1.8° step angle (200 steps/revolution). Each of the robot wheels will be powered independently by these motors.
  • 2 × A4988 Stepper Motor Driver (in breakout-board) The drivers used to control the stepper motors; one per motor.
  • 1 × MPU-6050 6 Axis Gyro + Accelerometer (in breakout-board) The robot's sensor that is used to report the tilt angle.
  • 1 × HC-06 Bluetooth Serial Pass-through Module Used to communicate with Android smartphone.

View all 9 components

  • Translation Control First Attempt 13.03.2019

    Ben Peters7 days ago 0 comments

    After yesterday's attempt at adding steering to the robot resulted in some instability ( probably due to the added computational power of having seperate throttling variables). I decided to revert to the previous code and add only forwards and backwards control to see how this affected the stability.

    I have solved my logistic problem by adding a string harness for the robot to my wired controller (you can sort of see it in the above picture), check out the videos to see how much easier it is making the testing; no more need for a friend chasing the robot around. The robot moves forwards or backwards by tilting itself into the direction it needs to travel. The results were very promising. Please see this video link.

    The robot can drive in both directions but drives slowly in the direction against the way it tends to drift and slightly too fast in the other direction. I am fairly confident now that the robot will operate as intended when I sort these sensor issues out! Today I also conducted some more rigorous testing on the robot and have a good amount of data with repeats that I will analyse in the hope of sorting these issues out. I will post any significant progress on here.

  • First Steering Tests 12.03.2019

    Ben Peters03/12/2019 at 19:41 0 comments

    Today I modified the code to give the robot some steering capability. This meant creating separate throttling variables for each motor whereas previously I had just one variable that controlled both motors simultaneously. Now when the joystick is pushed left or right the code adds to the left and subtracts from the right motor's PID value to result in different throttling between motors.

    The robot can now steer but is much less reliable! Strangely, the robot has become less stable as a result of me adding this capability; it is nowhere near as stable as before with the same PID values. I am not sure why the tuning should be different but I suppose I have essentially doubled the computation needed in the subroutine than controls the motors. I have had some attempts at tuning with varied success. It is not being told to move forwards by the way, this is still an effect of drift I think. Please check out the videos below...


    P.S. the robot has become a bit of a logistical challenge to test, I think you'll find these amusing :)

  • Joystick Built

    Ben Peters03/11/2019 at 11:12 0 comments

    Just a short post to say that I have made a joystick holder (with approximately 1m of cable) now and this week I will be working on:

    1) getting the robot turning

    2) getting the robot moving backwards and forwards

  • Ready to add controller 08.03.2019

    Ben Peters03/08/2019 at 18:57 0 comments

    The robot suffered a fall at the start of this week that hindered my progress somewhat. Upon falling over, all components operating directly from the battery voltage got fried; my Arduino Nano clone, and two stepper drivers. Check out the picture below that shows the Nano's burnt out voltage regulator...

    I had to acquire replacement parts which took some time. In the mean time I set about adding the capability of the robot to measure its own battery voltage so that I would be warned if the LiPo battery was dangerously low in remaining charge (I should have done this a while ago). It now gives a warning by turning a red LED on, and its readings were verified using the serial monitor and a voltage meter. You will see the circuit changes and code updates in the near future when I upload the revised code and circuit diagram.

    With the replacement of the components and some adjustment of the code, my robot is now fairly successful and I am ready to add a controller and make the robot steer around. Please see the link below for the test that verifies that I am ready to move on to control :)


    I was going to use a Bluetooth and a custom built android app to control the robot (and still intend to eventually). However, at first I will use a wired joystick module to see if I can just get the robot to responding to inputs (lessening the amount of variables that could cause failure). Today I have started by making long jump wires:

    P.s. there is still a drift issue as you can see the robot constantly moving away from its starting position, I am hoping I will still be able to control the robot with reasonable accuracy despite this issue. Any advice here would be very useful (see previous log for more detailed explanation).

  • Gyro Drift Data 02.03.2019

    Ben Peters03/04/2019 at 00:05 0 comments

    In an attempt to understand the issue of the robot constantly moving away from its start position, data from previous tests was plotted.

    This first plot showed that the sensor thought the angle was drifting away from equilibrium; this explained why the robot kept moving in the same direction and the slope downwards explained the acceleration. Next it was decided to see how the PID error value was changing:

    The above plot revealed more evidence for gyro drift. We can see the system error is desired (mean of approx 0) yet the sesnor thinks the angle of the robot is slowly decreasing over time; this is causing movement acceleration away from the starting position to keep itself "balanced". Next it was decided to test the MPU6050 readings outide of a balancing test:

    Three tests were conducted each of about 3 minutes duration. 1) sensor was left undisturbed, 2) sensor was given a quick shake then left undistrubed, 3) sensor was randomly disturbed for 3 minutes by hand then placed level again. The results verified the gyro dirft and also showed that the drift is worsened by constant excitation.

    Ther current dirft compensation strategy is to determine a set of calibration constants that are determined using an average drift over 500 loops calculated during the robots start up procedure, these constants are then subtracted from the gyros raw values for every program loop. The above results show that this method is not working very well. Two options were considered: 1) calculating the average drift over more loops (1000 loops perhaps) 2) deploying a more intelligent (dynamic) drift compensation technique that could recognise false readings and adapt its influence accordingly.

    It would be great to get in touch with someone who has worked with gyro drift in the past.

  • Adding New Calibration Procedure and Off Switch 01.03.2019

    Ben Peters03/02/2019 at 11:41 0 comments

    Following the resolution of the rotating issue, I set about making some changes to the robot:

    • Replacing the velcro with double sided tape to rigidly fix the breadboard (and accelerometer) to the robot chassis.
    • Glueing the frame components together (previously just slotted); improving the rigidity of the frame and the wheel axes alignment.
    • Adding a switch to the circuit to prevent me having to unplug the battery every time.

    After making these changes I conducted more testing with a friend and saw the following results:

    • The new calibration procedure worked well and the robot started trying to balance when it was lifted to the equilibrium position; the initial attempt looked very promising, much like the oscillatory behaviour you would expect from a poorly tuned PID controller.
    • The robot balanced but constantly drifted forwards; routinely travelling about 5m (until we had to stop it due to a lack of space)
    • The stepper drivers were getting very hot and this seemed to cause the performance of the robot to suffer; missed steps from the stepper motors etc.
    • With a low value for the Integral gain, the robot performed how you would expect with a badly tuned PID loop. The robot is extremely sensitive to integral gain. Making this a little higher resulted in the robot balancing for longer but always dirfting.
    • Data was taken during balancing tests to try to discern any control/sensor issues (analysis to follow soon).


    In conclusion, the robot still seemed to exhibit behaviour that was not solvable by simple PID tuning. Specifically the drifting and sudden falling in some cases give the impression there are some electronic issues. The drivers getting very hot seems to be a big problem. The next test that will be done is to try using some NEMA 17 stepper motors with a lesser current rating in an attempt to reduce the load on the drivers.

  • Solved Rotating Issue 28.03.2019

    Ben Peters03/01/2019 at 16:32 0 comments

    Following the conclusions from Wednesday's testing, I switched out my older stepper drivers for some new higher quality units. 

    • Initially the robot suffered from rotating but that was quickly solved by setting the current higher using the potentiometer.
    • Once set to maximum current, the rotating issue was solved and resulted in better overall perfromance with no adjustment of PID values (see link below). However, the stepper drivers were getting very hot quickly so testing was only done for short periods of time with cooling breaks inbetween.
    • The breadboard was velcoed onto the robot frame and filming in slowmotion revelaed that there was some play between the breadboard and the robot that was lilkely to harm the gyro readings (see link below).
    • The conclusion was to fix the breadboard rigidly to the frame to mitigate these vibrations.

    Please see this link for videos of the above testing: VIDEOS

  • Troubleshooting Attempts (Link to videos in text)

    Ben Peters02/28/2019 at 11:48 0 comments

    Prior to this testing the robot perfromcance can be summarised: robot could balance for a maximum of about 20 seconds but was very inconsitent, the robot ususally failed because it started to rotate (nothing in the code was telling it to rotate), sometimes the robot would stay at top dead centre then just appear to give up; ie it was not just an issue of a poorly tuned PID controller, there was some undesired behaviour occuring. The code conducted a calibration sequence whilst supporting the robot vertically and would just start trying to balance once the callibration sequence was complete.

    Conducted a few hours of testing and adjusting in an attempt to get the robot balancing. I tested in the iForge makerspace using a string harness (to stop the robot falling over) and logging some of the values to the sensor and control values to the serial monitor. Summary follows:

    • Added code to allow the calibration sequence to run whilst the robot is on its side then when picked up the robot will start balancing if the accelerometer detects that the robot is upright (see the linked project YARB to understand what I mean). I managed to implement this but there were problems when the robot actually started balancing where the robot accelerated very agressively immediately and became unstable. Investigation through the Serial Monitor revealed that this new calibration procedure resulted in an inaccurate gyro angle (+4 degrees). For the time being I have disabled these lines of code and reverted to the start up procedure described above.
    • Power source was increased from 11.4v to a 15.5v LiPo. This was done in attempt to increase the torque delivered by the motors incase this was the reason for the robot "giving up" (not having the required torque and therefore stalling).
    • Following the power increase I tried to tune the PID values again to some success. The best balancing time was around 30 seconds but the robot suffered from the same problems of rotating. The motors were definitely delivering more torque so the robot failed less frequently due to "giving up" somewhat confirmed my suspicions of a lack of torque.
    • A second attempt to prevent the robot "giving up" was setting a limit on the lowest permitted motor speed (other than when at top dead centre) because the robot always seemed to fall when the serial monitor reported a sudden very low motor speed. The effect of adding this meant that the robot consitently failed due to rotation. Thus the rest of the testing was trying to figure out why the robot kept rotating.
    • When the robot rotated, it seemed that one motor simply stopped driving momentarily. It was observed that this was consitently the same motor failing.
    • The testing concluded by observing what the rotation was when the stepper motor drivers were swapped. The robot rotated the opposite way and it was deemed that one of the stepper motor drivers was not behaving as desired. The next step will be to replace both drivers with new, higher quality units and hopefully this will solve the rotating problem.

    Please see a selection of the testing videos using this link, notably showing the robot rotating then failing.

View all 8 project logs

Enjoy this project?



Alexander wrote 03/09/2019 at 17:26 point

Awesome project! 

I have a few suggestions. If you find the stepper drivers are getting hot, you could heatsink them, or many stepper drivers will allow external FETs to be used. This would allow significantly more current while spreading the heat load out. Looking at the A4988 datasheet, it looks like using external FETs wouldn't be too difficult.

Also, gyro drift is very common. It is usually characterised in the datasheet. Using the accelerometer data in tandem with the gyro is a good way to improve the drift - if the gyro is changing but the accelerometer isn't showing movement, then you can assume it's drift. This is what "sensor fusion" is all about. Elecia White's book Making Embedded Systems touches on this subject, if I remember correctly. There are many libraries out there for sensor fusion but depending on your timeframe, you can always try writing it yourself! It's a bit of math, but nothing too difficult.

If you have any problems, feel free to message me! I'd be happy to help.


  Are you sure? yes | no

Alexander wrote 03/10/2019 at 05:35 point

Just checked out the videos -- you can definitely hear an unhappy stepper driver -- glad to hear changing it fixed the issue!

  Are you sure? yes | no

Ben Peters wrote 03/11/2019 at 11:04 point

Thanks for checking them out Alexander. Just to clarify, on the latest video (8th March) could you notice any unhappy driver sounds? I switched to lower current stepper motors for that video and everything seems to be okay now...

  Are you sure? yes | no

Alexander wrote 03/11/2019 at 14:00 point

@Ben Peters No, it was one of the older videos. Sounds good in the newer ones!

  Are you sure? yes | no

Dusan Petrovic wrote 03/08/2019 at 16:15 point

Love your project, very cool.

  Are you sure? yes | no

Ben Peters wrote 03/08/2019 at 18:59 point

Thanks, much appreciated! Hopefully some manoeuvrability of the robot is coming next week.

  Are you sure? yes | no

Ayush wrote 02/27/2019 at 05:03 point

Can u please give the links of the videos in which u made it. 

  Are you sure? yes | no

Ben Peters wrote 03/01/2019 at 14:13 point

Hi Ayush, please see the links to the videos in my project log.

  Are you sure? yes | no

Sophi Kravitz wrote 02/21/2019 at 15:08 point

Hi Ben, Can you repost the link to the videos? It didn't work for me. Cool concept!

  Are you sure? yes | no

Ben Peters wrote 02/22/2019 at 08:56 point

Thanks Sophi. Yes sure I will work on that today, did it say you didn't have access or did the link just not take you anywhere?

  Are you sure? yes | no

Sophi Kravitz wrote 02/22/2019 at 13:09 point

Hi Ben! I get a 404 with the Google photos link above. Excited to see!

  Are you sure? yes | no

Ben Peters wrote 02/23/2019 at 15:05 point

Sophi, I have updated the link. Please let me know if you can access it now. The current videos are very early test videos from the end of last year. I will be uploading more soon.

  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