Self Balancing Robot Uses Cascading PID Algorithms

At this point we’re beginning to think that building a self-balancing robot is one of the rights of passage alongside blinking some LEDs and writing Hello World on an LCD screen. We’re not saying it’s easy to pull off a build like this one. But the project makes you learn a lot about a wide range of topics, and really pushes your skills to the next level. This latest offering comes from [Sebastian Nilsson]. He used three different microcontrollers to get the two-wheeler to stand on its own.

He used our favorite quick-fabrication materials of threaded rod and acrylic. The body is much taller than what we’re used to seeing and to help guard against the inevitable fall he used some foam packing material to protect the top level. Three different Arduino boards are working together. One monitors the speed and direction of each wheel. Another monitors the IMU board for position and motion feedback, and the final board combines data from the others and takes care of the balancing. Two PID algorithms provide predictive correction, first by analyzing the wheel motion, then feeding that data into the second which uses the IMU feedback. It balances very well, and can even be jostled without falling. See for yourself in the clip after the break.

24 thoughts on “Self Balancing Robot Uses Cascading PID Algorithms

  1. It’s pretty cool, but I am not sure what the point of having a 2 wheeled balancing robot is for. You could just add a 3rd swivel wheel somewhere and it wouldn’t need to self balance. Awesome build and work, just not sure what a 2 wheeled robot is useful for (except for maybe a bike configuration).

    1. If you bump this it’ll stay up. If you bump a 3/4 wheel, it has no way to keep itself upright.

      Imagine a toolbox, drink table, etc that follows you – that won’t fall over if it bumps into something.

      That said, those designs would require additional engineering to be useable/functional.

      1. Maybe a 4 (or more) wheeled platform with swiveling wheels that have a lot of negative camber? Perhaps (if the wheels are mounted on legs) the legs themselves could come out at an angle.

        Don’t get me wrong, I just have yet to see a really solid implementation of this idea. For the immediate time being, even if a half-decent self-balancing robot can be made, the next table that follows you is still more likely to use “dumb” wheels.

        The problem is the extra weight. The motors would have to be stronger, and the feedback loop would have to be quicker. It’s not as simple as just putting a large flat surface on top of one of these. Even the placement of your tools/drink will affect the balance of the robot. It’d be very annoying to have this whole surface available to you, but only feel safe putting things in the middle.

    1. The response time of a physical PID controller is much faster than the response time of microcontroller PID algorithm. A physical PID controller operates in real time, while a microcontroller PID algorithm can only operate at a fraction of the clock speed of the micro.

      For example, the Arduinos used were likely running at 16MHz. If there was a “PID” instruction in the micro’s instruction set, the best response time you could hope for is 62.5ns. You really have to assume that there will be a couple hundred instructions, at least that perform a PID function. So we can probably assume that it’ll take ~6us to respond to any change.

      Keep in mind that this is each cycle the “PID” controller tries to match the input.

      It’s safe to say that you can expect some wobbling.

      ;tldr
      Real life is faster and more responsive than emulation.

      1. But even if the table was moving/tilting at 10 meters per second (30ft) it would only move a 0.6 mm (0.02″) in the 6 uS your example mentioned.

        Definitely worse than a purely analogue solution, but I would assume that the lag caused by having motors with not infinite torque would dwarf that small delay.

  2. In a lot of ways it is a right of passage. It is sort of the traditional introduction to signal and control processing problem. It is an interesting system because it is an inherently unstable system. Similar rights of passage are thermostats and the like, but honestly… The inverted pendulum is much more interesting, especially as a robot.

  3. Androbot simply used angled wheels, no fancy stuff required to make their TOPO bots stay upright on two wheels.

    They did bob back and forth a bit and any more than a slight incline was a challenge.

    Combine current self balancing tech with TOPO’s drive system and you’d have a self balancing robot that won’t fall down even if it loses power.

  4. “rites of passage” ???

    you make the rest of us feel untalented and unknowledgeable lol

    maybe we can all agree that its _any_ PID that is the rite of passage!
    no matter if its uC “software PID control loop” or
    just plain circuits done the real way (edit: instantaneous way)

  5. These sort of designs could be implemented in aids for people with no legs, Imagine that, I see it happening in the future.
    Anyone could produce it, I don’t see why they don’t.

  6. Hi, nice robot. I also build one using a single pid controller and it is stable but there is still room for improvement. I would just like to know some more about your cascaded pid controller. How did you implement it and what variables is being controlled by it? Thanks

    Lezard

Leave a Reply to LezardCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.