Twenty years ago, just after the dot com meltdown, I was working as a consultant and had lots of free time on my hands. I started indulging in my hobby of building robots, and subsequently met up with other like-minded people at the Silicon Valley Home Brew Robotics Club. One of the first people I met at the club was Bob Allen, an electronics engineer who had a machine shop in his garage and could make amazing mechanical things.

Bob had built some combat robots in the past, and we were both excited about working together on more interesting and complicated robotic projects where we could use all three robotics disciplines: mechanical, electrical, and software engineering. Back then, my mechanical engineering skills were severely lacking. Robot-suitable mechanical parts were hard to come by, but combat robot parts were more readily available due to their popularity on TV at the time.

I had a pile of these parts and was eager to put something together. I remember one afternoon going over to Bob’s house to discuss the possibility of doing a collaborative robot project using this parts pile. His first comment was, “are you crazy? You’re going to destroy your house if you build it with that stuff!” He then showed me a video of a robot that could balance on two wheels, and I thought it was amazing. Plus, it was small and probably wouldn’t destroy my house. Bob and I wondered if we could build something similar. It couldn’t be that hard, right?

Months later, in 2002, Bob and I finally had a set of electronics put together, with the right motors figured out, and we were ready to take a crack at making it balance and drive around. Then came the hard part. Building the robot was one thing, but the software challenge of making it autonomously balance on two wheels was monumental. I think it took a good three months just to get it to not fall over, and many more months to make it drive around. The first robot was named “Bender” after the lovable beer-drinking robot from Futurama. It fell down so much that it made sense to name it after a robot that was drinking all the time.

Bender the Balancing Robot, built in 2002.OLogic

I didn’t know much about control theory when I started this project, but I learned fast. A balancing robot is essentially an upside-down implementation of the classic inverted pendulum problem. I learned the hard way making a balancing robot that works well requires the following items:

• High-torque geared motors with encoder feedback
• An IMU (a combination of a gyro, accelerometer, and compass)
• A microcontroller-sized CPU

The big software challenge for a balancing robot is that you need a control loop where you read the IMU, remove all the drift and bias, and then move the wheels of the robot in the correct direction to keep them underneath the robot so it doesn’t fall down. It turns out that the speed of this control loop is not terribly critical. On all my early attempts, about 30 Hz was enough to keep the robot stable. It still sounds pretty easy as I am describing it, but once you dig into the details, it gets tricky. In 2021, the IMU units you could buy off the shelf were pretty inexpensive and reliable. In 2002, this was not the case, and I had to roll my own by taking each sensor separately and fusing them together in software.

I bought a new two axis accelerometer, but it was pretty noisy, and had linearization issues. What this means is if you tip the accelerometer on its edge, and slowly rotate it through 360 degrees, you should be able to draw a perfect circle from the data coming out. The data from this accelerometer looked more like a garden squash than a circle. Then, I found some gyros at a surplus electronics warehouse—single axis piezoelectric devices originally made for camcorders and computer mice. They were not widely used, but for some reason the surplus store had a big box of them.

The gyro is the most important measurement device that you use for keeping the robot upright. It gives you the rate of rotational acceleration as the robot starts to fall. The problem is, if you just put a gyro on a non-moving surface, like a desk and start taking readings from it, the zero point will slowly start to drift. Compensating for this drift is the hard part: how can you measure a sensor when zero is constantly moving?

The answer lies in an algorithm from statistics and control called a Kalman filter. You take your sensor measurements, run them through a Kalman Filter, and you can produce estimates of where you think the true measurement actually is. My math skills were pretty rusty from college, and when I dug into how to implement one of these, I really had to go back to basics and learn what to do. It took quite a bit of work to get to the point where I could build a simple Kalman filter algorithm that I could use to fuse together my janky gyro and accelerometer. But once I had it working, I could see on the bench that when my little IMU board was not actually moving, the output of my filter would stay stable, and when it was moving, the measurements would even move in the correct direction!

Flexo, built in 2003.OLogic

Next, I needed a control theory method to keep the robot balanced. There are many different ways to go, but I wanted something simple. My brain hurt after figuring out the whole Kalman filter thing, so I went with the simplest solution, which is a proportional–integral–derivative (PID) controller. It turns out that a PID controller all by itself is usually just barely capable of keeping the robot balanced, but it doesn’t necessarily deal with all the problems of driving around, carrying an offset load, or all the issues related to bumping into something. I learned I had to add lots of extra terms and software filters to my PID equations, but I began to achieve great results.

It was finally time to make a smaller, improved version of Bender that could do more things. One thing I learned from all my work was that bigger balancing robots are usually easier—since they move slower, the control system doesn’t need to be as exacting in making minor corrections. But making a really tiny balancing robot becomes harder and harder the smaller you go. In the TV show Futurama, Bender has a brother named Flexo. So, it made sense to name the new robot after him.

Since I now had a PID algorithm good enough to do things like balance a robot with an offset load on top of it and drive up and down ramps, I could easily mount a moving, pan-tilt-camera rig to the top without any fear of the motion of the camera knocking the robot over. I used a color tracking camera tuned to track the color red, so that if you put a red object in front of the robot, it would try to move towards you. Once it got close enough, it would just stand there and stare at you. We took Flexo to the Homebrew Robotics Club once he was working, and there was a kid there wearing a red sweatshirt the robot really took a liking to!

Once we knew how to do the basics, we built an off-road version of Flexo called Big Red, and another version called Fat Albert that could get up on its own from laying on the floor.

Fat Albert had a unique mechanism and software implementation that allowed for transitioning from the floor to standing and then back to the floor again. We applied for multiple patents on the whole setup and have kept them active over the years, but we still haven’t figured out what to do with them—if you have an idea, let me know!

Bob thought we might be able to find some companies who might be interested in paying for our expertise in developing these kinds of balancing robots. We bought a booth at the first RoboNexus trade show held in San Jose in 2004. On the first day, we were standing in our booth with Flexo showing off his balancing act, and who should come down the aisle riding a Segway, but Dean Kaman himself. He rode up, and stopped for a moment, and said jokingly, “Wow! Look at that! I have never seen anything like that!”

On the second day, we met a bunch of enthusiastic engineers from Hasbro. They were looking for more interesting robotic toys they could add to their line, as well as some help with more advanced sensors in toy development. We were invited out to Hasbro corporate headquarters in Rhode Island to give a presentation to the engineering team about what we could do. Bob asked if we needed to prepare a formal presentation, but Hasbro told us to just show up and bring some robots. When we arrived, we were shuttled into an enormous conference room that looked like it could seat 100 people, and there were 20 people sitting in there waiting to hear the presentation that we didn’t have! We thought we’d completely blown it, but we just turned on the robots and Bob started talking. Soon, the crowd warmed up, got out of their seats, and started coming to look at the robots up close, and it all worked out after that. Bob and I started a robotics consultancy called OLogic Inc. in 2005 with Hasbro as our first customer.

Ted Larson at Hasbro HQ in Rhode Island.OLogic

Hasbro thought that our balancing robot idea could become a great consumer product, so they made the investment to start turning Flexo into something that could be sold as a toy. The first step was to get rid of the surplus parts and integrate consumer-grade components and motors. There were two robots made: one was a full 3D printed prototype that was fragile as glass, and the other was just the drive system with our existing electronics mounted on it.

On left, a prototype drive train for AMP. On right, the first AMP prototype, called Glass Man, built in 2006.OLogic

We broke both of these prototypes more times than I can remember. Every time it broke, I would call up Bob, and he would come over and we would figure out a clever way to glue it back together. After tons of trial and error we eventually had something that worked, and then it was time to make the real product. After a few trips to China and meeting some fantastic manufacturing experts, and a bunch more work on our part, we finally had the real product ready to go.

The product was to be named A.M.P., for “Automated Music Personality,” or AMPbot for short. It was a balancing robot, but it also had a pretty sweet boom-box inside it, so it was a mobile speaker system too. It came with software so it could dance along to the music being played.

At this point it was 2008, and AMPbot was scheduled for release in early 2009, but that was not to be. The financial crisis of 2008 changed the priorities for all the toy companies, and after only about a dozen pre-production prototypes were made, AMPbot was cancelled by Hasbro.

By 2010, we were wishing there were ways we could revive the AMPbot project. We got permission from Hasbro to take it to market on our own if we could find enough investment to make it happen. We reinvigorated the stock of limited prototypes we had built, and took AMPbot to the Demo Conference in 2010 and tried to launch it as its own project. We found lots of robot enthusiasts who wanted him in their homes. I mean, who doesn’t want a cool music playing robot?

What happens when you leave AMP’s alone overnight in the office.OLogic

We attended multiple trade shows to attempt to find interest for making AMP. Here I am describing AMP at CES in 2012:

To keep OLogic going while we tried to figure out how to get AMP out the door, we spent our time picking up robotics consulting jobs. We were able to get a one-off project to build some little balancing Android Robots for Google, and tour them around to events like Google IO, Google Sandbox, and Google Zeitgeist in London. Bob and I had lots of fun—it felt like a travelling circus, bringing our robots to all of these events.

Balancing Android robots built for Google.OLogic

Concepts for a variety of different balancing robots.OLogic

There is both a happy and sad ending to this story about balancing robots. I made many friends along the way and started a cool robotics consultancy that is thriving today, but it seems that AMPbot was never meant to be. Bob Allen has since retired from OLogic, but he can still be seen now and then at a Home Brew Robotics Club meeting, as his love of robots lives on. The prototypes of AMPbot still adorn our lobby at OLogic, but we have since moved on to other projects, and for now my balancing robot saga is over.

Ted Larson is CEO and Co-Founder of OLogic, Inc., an embedded systems research and development company with a focus on robotic applications and technologies. Ted has over 30 years of experience designing and building commercial software applications. His current interest areas are robotics, artificial intelligence, and embedded systems in consumer and professional electronic devices.