Two wheels are more than you need! See my self-balancing electric unicycle. Also see Version 2 of the scooter.

Short MPEG Video [1.0 MB]

Self-balancing scooters, like the Segway™ are often thought to be technological miracles, but it is not actually very hard to build one. I built the one described here in about a week using off-the-shelf parts. I spent another week tweaking the high-speed stability, improving the steering control, and writing about it.

Although the Segway has several exotic components, mine is built from common low-tech parts like wheelchair motors and RC car batteries. The parts, even at small quantity retail prices, cost less than half of a genuine Segway. It also doesn't need complex or high-performance software. The first version was written in Python and used serial ports to talk to the gyroscope and motor controller. The current software, now in C running in an onboard 8-bit microcontroller, is only 500 lines of code.

Riding the scooter is definitely fun. Things I like about it are:

• It's easy, when riding down the street, to stop and chat. Somehow on a bicycle or a regular scooter, it's a huge nuisance to stop. But on this scooter, it seems very natural to pull up and chat while standing on it.
• It's pretty easy to drive around inside the office. The low-speed maneuverability makes it easy to go through doors.

Things I don't like are:

• It's fairly tiring to ride. Standing still on a hard, bouncing platform makes my feet tired. Not as bad as rollerblading, but a somewhat similar feeling. The body is really evolved to be in constant motion, and the combination of static posture (even more static than standing normally, since you try to keep your weight centered) and being jolted by bumps is probably bad for your spine.
• I feel like a total techno-dweeb riding it around. It just screams "Silicon Valley nerd," even more than having 3 cellphones and a PDA strapped to your belt. OK, I am in fact a Silicon Valley nerd, but I don't want everyone to know it.
• I get stopped every few blocks by someone ask about how it works. I don't mind telling people about it, but it does take an awfully long time to get to the coffee shop and back in the morning. And I can't quite drink a cup of coffee on it while moving at any speed, so the net result is that I arrive back at the office, 30 minutes later than if I'd just walked, with a cold coffee. A small sacrifice for Science.
• Its speed and terrain handling is an uncomfortable middle ground between walking and bicycling. When walking, I usually go in pretty straight lines, over grass and curbs. Biking is fast enough that I don't mind going around on the road. But the scooter is neither fast enough to make going the long way round feel right, nor maneuverable enough to go up and down a lot of curbs.
• It's not relaxing and conducive to having deep thoughts the way walking is. Riding it is fun but tense.

Rolls Royce vs Model T

The Segway is made with quite high-quality, high-tech, and expensive components. Overall, the components I used are a lot lower-tech and cheaper than the ones in the Segway. Yet, mine seems to ride just fine. It suggests that there's room for a Henry Ford of balancing scooters to develop and sell a low-cost everyman's version. Here's a quick comparison. Quotes below are from segway.com.

Despite being able to build my own, I'm still impressed with the Segway™ and with the courage it takes to bring such a product to market. Like with cars, it's pretty easy to put together a motor and wheels and make it go. But building a safe, comfortable vehicle is a serious effort.

Warning

There is one very important difference between what can be built as an experiment and the commercial Segway: The commercial one has a lot of safety features, redundancy and fool-proofing. Mine has none whatsoever (Well, it does have a kill switch so it doesn't go zooming away if I fall off, and it does shut down if it finds itself tipped more than 45 degrees.) Those details are kind of important, and you should think about them carefully before considering building such a thing yourself. With a scooter like this, if it stops working for any reason (software crash, hardware failure, low battery) you will fall, hard, and probably on your face. Imagine zipping along at 10 MPH, and suddenly the platform you're standing on stops dead. Oh, and there's a T-bar in front of you to trip you up if you start to run. So you really shouldn't try to replicate this experiment, and I can't be responsible for what happens if you read this and try to build something.

A scooter that you ride on is not the best place to learn how to build a two-wheeled balancing device. Getting them working properly is quite subtle, so you should really start with atwo-wheeled balancing robot and then scale up. See my notes on safety if you're considering trying to build something.

Construction

The mechanical construction is incredibly simple. Just a plate to stand on bolted to the tops of the motors, a support across the bottom, and a handle. Hanging from the foot plate are two pieces of hand-bent sheet metal to support the batteries. The batteries are just taped and cable-tied to the sheet metal.

Mechanically it's much simpler than any other kind of vehicle. With only two wheels side-by-side, there is very little structure. With no steering it doesn't need complicated pivots and linkages. It is literally just two motors bolted to a frame and a stick to hold.

The electronics and footrest all fit entirely within the 14" wheel diameter. Without the handle, it can roll end over end. But the ground clearance is pretty small. I should go up to 16" wheels, hopefully a bit lighter than the big tires I've got now. Currently it weighs about 90 lbs with its full load of batteries. The wheels alone must account for 20 lbs of this.

Dashboard

The dashboard is an electronics chassis box with knobs for steering and balance feedback loop gain. This shows the early version of the dead man's switch, which really is not adequate. I found this out when I fell off, but the wire pulled apart instead of yanking out the connector. When it pulled apart, the exposed strands ended up touching to complete the circuit and keep it going. Fortunately, a safety feature in the software shut it down before it ran over my head.

Power

The motors I used are made for wheelchairs where they are driven from a 24 volt battery. I want a little more speed, so I drive them from 36 volts. My wheels are also a bit larger than the wheelchair's. It should reach 15 MPH flat out. I got 36 volts by putting 5 standard 7.2 volt RC car battery packs in series. The batteries are rated for 30 amps discharge and I wanted over 100, so I put 4 strings of 5 in parallel for a total of 20 packs or 120 cells.

There is a a complication with multiple NiMH batteries in parallel. You want to avoid current flowing between them when their voltages are a bit different. So there is a bridge rectifier for every pair of batteries, with both + and - terminals connected to the motor driver. That way the voltage on the 4 strings of batteries can differ by up to 1.5 volts without current flowing.

The batteries can be disconnected by the 4-way connector for safety, and for charging. I use anAstroflight model 112 charger, which delivers 5 amps charge current at the 40 volt charging voltage. See schematic diagram.

The system pumps energy back into the batteries when it's decelerating or doing downhill. I had worried about the frequent current reversals harming the batteries, but I'm assured by a number of people who've had experience doing this with NiMH batteries that it works well. There might be some extreme case, like starting at the top of Pike's Peak and riding all the way down, where it could overcharge and destroy the batteries.

Balance and Control

Balancing is easy. Just keep the wheels under the center of gravity. It's just like when you pick up a stick and balance it resting on the palm of your hand.

Actually, there are some complications. You don't know where the center of gravity is. You don't know exactly which way up is. And you may not be able to move the wheels fast enough to keep under it.

I discuss knowing which way is up under "Gyroscope" below, but for now assume it's known. Technically what it knows is the angle between the scooter's chassis and the direction of gravity. And instead of keeping the wheels below the center of gravity, it keeps the stick vertical (ie, the angle equal to zero.)

With the stick vertical, if you stand in just the right position, the center of gravity will be right over the wheels and the scooter will be stable. But if you lean forward, the center of gravity will be in front of the wheels and the scooter will start tipping forward. The computer senses this and moves the wheels to keep the stick vertical. But by then it has fallen some more, and it needs to move the wheels faster.

The net result is that when you lean forward, the scooter accelerates forward and when you lean back it accelerates back. It's surprisingly intuitive. Most people find they can control it within seconds of getting on it. If you're used to riding busses or subways, you're used to leaning forward when the bus is about to accelerate. Well, this scooter follows your lean instead of you having to follow it.

There is another complication. What happens if you keep leaning forward until the scooter is going so fast that the wheels can't keep up? It has to change the tilt of the scooter so instead of keeping the bar vertical, it tilts back. The bar is at waist level, so it pushes you back until the center of gravity is no longer in front of the wheels and it stops accelerating. If you lean farther forward it keeps tilting back in order to keep the speed down. In order to be able to tilt the scooter back it needs to speed up the wheels and get them out in front, so the speed limiter needs to kick in before the motors are maxed out. I currently have the limit set to 50% of maximum speed.

Keeping the Stick Vertical

Keeping the stick vertical is easy. If it tilts forward, it runs the wheels forward until the bottom of the stick is under the top.

Here too there are complications. It has to move the wheels just the right amount forward. Too much and it'll have to move them back, then forth, until the thing is bucking widly. This is pretty much the default thing that happens until you get it tuned just right.

It needs to know both the angle of the stick and how fast it's changing. Knowing how fast it's changing lets it slow down before it overshoots the mark. Technically this is known as a PD loop. The amount of drive it sends to the wheels is proportional (P) to the error in angle, and also to the derivative (D) of the error.

I mentioned above that when it's going too fast it needs to tilt the stick back. This is tricky to do, because in order to tilt back it needs to accelerate the wheels forward to get them a few inches out in front. It then seems like it's going even faster, and it tries to tilt even farther back. This is called "positive feedback" and it's a recipe for uncontrollable oscillation. Making this stable was the trickiest part of the whole project, and the fact that it can only be tested at high speed resulted in several moments of terror and a few bruises before I got it right.

Wheels and Steering

Steering is done by making one wheel go faster than the other. Because all the mass is centered between the wheels, it can spin around quite quickly.

When not moving, maximum turning corresponds to having one wheel at about 10% forward and the other at 10% reverse. This spins it around pretty fast. You wouldn't want to turn this fast at high speed because it would tip sideways, so it reduces the maximum turning speed as the forward speed increases.

The wheels have 0.5 degrees of toe-in, meaning that they are both angled slightly inwards. The front wheels of most cars have a similar amount of toe-in. Pneumatic tires are inherently flexible sideways, and it makes it more stable to have them always flexed slightly. I don't know if 0.5 degrees is the right amount and I haven't tested any alternatives. But the steering is quite stable despite not having any active correction in software.

Putting it all together

What takes many paragraphs to explain is surprisingly simple to code. Here is the basic pseudocode of the balance algorithm, complete with the numbers which made my scooter feel stable and responsive.

Inputs

angle, angle_rate: the tilt angle of the scooter in radians and its derivative in radians/sec
steer_knob: the reading from the steering knob, between -1 and +1.

Balance

balance_torque = 5.0 * (angle - rest_angle) + 0.4 * angle_rate

Limit top speed by tilting back

overspeed = max(0, cur_speed - 0.5)
if (overspeed > 0) {
  overspeed_integral = min(0.4, overspeed_integral + min(0.2, overspeed+0.05) * dt)
}
else {
  overspeed_integral = max(0, overspeed_integral - 0.04*dt)
}
rest_angle = 0.4*overspeed + 0.7*overspeed_integral

Steer. Decrease steering rate at high speed

steer_cmd = 0.07/(0.3+abs(cur_speed)) * steer_knob

Track current speed

cur_speed += 1.2 * balance_torque * dt

Differential steering

left_motor_pwm = balance_torque + cur_speed + steer_cmd
right_motor_pwm = balance_torque + cur_speed - steer_cmd

Outputs

left_motor_pwm and right_motor_pwm directly set the duty cycle of the pulse width modulator for the wheel controller, and range from -1 to +1 (+1 is 100% forward, -1 is 100% reverse.)

Gyroscope

In order to keep the handle vertical, it needs to know which way is up. Humans, other mammals, and even lobsters have a nifty little sensor in the inner ear which does this, and it's possible to do something similar mechanically. The simplest way to know which way is up is with a pendulum. A pendulum at rest points down.

Unfortunately, the scooter is not at rest. If it's accelerating forwards a pendulum will swing backwards. It may also get swinging back and forth. It needs a much more stable notion of up.

A gyroscope made from a spinning wheel is the classical solution to keeping a vertical reference. They are still used in airplanes to remind pilots which way is up when they're in the clouds. But having an actual spinning flywheel is clumsy. They take time to spin up, they need expensive precision bearings and lubrication and use a lot of power, and occasionally the flywheel explodes (they have to spin pretty fast) and sends little bits of shrapnel into the rest of the system.

Although it's hard to visualize, it turns out that if you have a tuning fork vibrating and rotate it, it will cause a measurable vibration in the perpendicular direction. By measuring the vibration you can tell which way it is rotating and how fast. The scooter uses a very small ceramic tuning fork in just this way. They are a standard electronic product called a piezoelectric rate gyro, used in handheld camcorders to detect your hand jiggling and subtract out the motion from the picture to make it stable. One of the first successful applications of nanotechnology, they're a vital enabling technology for TV shows like C.O.P.S.

Unfortunately, these rate gyros are not perfect. They tend to report a small rate of rotation even when they're perfectly still. And if the balancing software integrates this small rate for long enough, it'll think it has rotated a lot. So it needs to compensate for that, and it does it with a pendulum. While a pendulum may swing around and wobble back and forth in the short term, the long-term average of its position is straight down.

Again, it doesn't use an actual pendulum. It uses a "micromachined silicon accelerometer", a silicon chip with a sort of diving board etched into it. This diving board bends a tiny amount in the direction of gravity, and some electronics detect how much it bends. With two of these arranged perpendicular to each other, it can compute the angle of gravity by computing the arctangent of the ratio of the bending measurements. And unlike a pendulum they don't get swinging around.

So now it has to combine the short-term reading of the rate gyro and the long-term reading of the pendulum. There is a theoretically optimal way to combine these pieces of information into a good estimate of actual tilt angle. This is called a Kalman filter. Such a filter was a good place to start, but I found I got better results with a hand-tuned feedback loop.

Sound complicated? It's not as bad as it sounds. In fact, the whole code, including stuff to read ADCs and manage serial communication is about 500 lines.

Microcontrollers

All the software needs somewhere to run. Not so long ago this task would have required more computer than you could lift, but now it runs in a tiny chip costing $10. The one I used is fromAtmel. They're fast and very easy to write software for; I wrote the code in C using floating point arithmetic and trigonometric functions, and it has plenty of speed for this kind of application.

The Atmel chip I'm using has built in analog data converters to interface with the gyroscopes and steering controls so it's a nearly complete solution. There are only about 5 chips in the whole scooter.

Motor driver

The software needs to exert precise control over the speed and torque of the motors. Under worst-case conditions, like going fast up a steep ramp, the motors need to work very hard to keep up and can consume a tremendous amount of power doing so, as much as 5000 watts.

The torque generated by the motor is directly related to the current flowing through the motor. The current is controlled by alternately switching the motor across the full battery voltage, then short circuiting it. If it did this slowly it would do just what you'd think: alternate full speed, then full stop. But it alternates very fast, about 4000 times per second, and this produces a smooth output from the motor. If it spends 37% of the time with the motor connected to the battery, the motor runs about 37% of full speed.

The scooter uses a device made by RoboteQ to switch all this power around. It's a popular unit among Battlebot builders since it's small and handles a lot of power. It receives commands from the microcontroller over a serial port, such as "left motor 37% forward, right motor 35% forward" (but in a compact binary format) and it gives the motors that much power. This command would correspond to going about 5 mph in a gentle right turn.

Limits

In theory, balancing is quite simple. Just keep the support under the center of gravity. Where it gets complicated is in handing the limitations of the motor & battery system. The simple control strategy may require much more power than the motors and battery can deliver. If it lets the scooter get into a situation where the wheels can't keep up with the center of gravity, the rider will be thrown.

If you're going fast and then run into something like a ramp or speed bump, it may require a lot of power for a short time to keep the wheels going up the ramp. As batteries get low and motors get warm, the amount of available power goes down. It's hard to predict exactly when it doesn't have enough to run safely. There's certainly a large gap between when it couldn't handle hitting a speed bump at 10 MPH and when the batteries actually run down.

I plan to experiment with using a bank of capacitors to provide enough short-term oomph to handle hitting a major bump at high speed. It's much easier to calculate the amount of energy needed to handle a bump safely than the maximum speed for a given battery condition. It just needs enough to get the wheels out ahead of the center of gravity, so it can slow down. My back-of-the-envelope calculations suggest about 2500 Joules delivered in 0.5 seconds. The new carbon aerogel ultracapacitors (not to be confused with mere supercapacitors) can store this much power in small 4" x 4" x 2" package costing about $250.

Or, I could just stick a wheel in front of it. But that would seem like something of a compromise.

Performance and Testing

When I first built this, I had never been on a Segway or even seen one close up. You'd think with all my geeky friends I'd know someone with one, but I didn't. I tuned the system according to how I thought it should work. A few days after I put up this page, I got to try a genuine Segway and I realized two things: it felt better to have a stiffer feedback loop so the handle didn't move back and forth so much, and that it should limit maximum speed by tilting back. I changed both, and it feels much better now. These videos are from the original version:

Current Problems

These are the things that are currently bad about my prototype.

• The ground clearance is very low. Even large acorns get stuck under it. Using larger wheels is one solution, and I think with more clever mounting of batteries I could get them at least 1.5" higher. If I make the wheels much larger, I'll want to find a way of getting the foot plate below the center of the wheel since I'm already 8" off the ground.
• It should detect when I've stepped off it, so it doesn't simply zoom away with no rider. My big worry is that I'll shift my feet around and it will erroneously detect me having stepped off. At high speed, this could be Really Bad.
• It really should give some indication of battery charge, other than by falling over when it gets too low. The voltage of NiMH batteries isn't a good indication of charge, so there's no easy way to do it.
• It doesn't detect when the wheels are off the ground or slipping. Once when leading it down a curb, I got it twisted a bit and it hung up on the battery supports. With the wheels free, they started spinning very quickly and it gave a huge lurch when it got back on the ground. I don't know what the general solution is. Probably it should limit the speed to 1 MPH when the rider is off.

Things Learned

• You don't need high-tech low-inertia motors for adequate responsiveness. Regular old copper-wound motors work pretty well even though they have a lot of rotating mass that acts like a flywheel. This might actually help with handling a bump, as the inertia helps keep the wheels spinning up the incline.
• You don't need low-backlash gearboxes either. The conventional non-precision spur gear units give about 1/8" backlash at the wheel diameter. You can feel a tiny clunk sometimes when the torque reverses, but it's hardly noticeable. They do make some gear whirring noise which is noticeable indoors. It'd probably be quieter if they weren't bolted to a big aluminum sounding board.
• I didn't need any feedback in yaw (left-right steering) to keep it heading straight. I just give equal motor drive voltages, and it keeps nice and straight even on slopes or going over bumps.

Future Work

Things I'd like to try, if I had more time:

• I can take both hands off the control bar and control with my feet, at least at low speeds. Handy when going through doors. I wonder if I could learn to control it without a handlebar at all. Perhaps with some sort of ski boots and bindings for greater control.
• Put the vertical handle bar off to the side, instead of in front, and hold it with one hand.
• Make wacky new vehicles on the same principle. Why not go for coffee in a miniature dragster, doing a wheelie all the way? Or in a greco-roman chariot, without the horses? You could also make improbably tall vehicles, like a phone booth that zoomed around upright.
• Take a regular 3-wheeled "mobility scooter," and make it do wheelies all the time. You might even be able to use its original motor driver, and just add a gyroscope and feedback controller. Seeing one of those 3-wheeled scooters, normally associated with geriatric mall cruisers, doing a wheelie would really surprise people. And if it fell, you'd at least have a wheel to land on.
• The ideal vehicle might be something that rides like a motorized recumbent 3-wheeled bike on roads, but tilts back to balance on sidewalks. You'd have to get off to change modes.
• Build one with a small gas engine and generator instead of batteries to power the electric motors. It'd probably need a substantial capacitor bank to smooth out the power demand. The engine and alternator might even be lighter than the batteries, and it'd have tremendous range. It might go faster too.
• Build a balancing scooter without any batteries at all, but instead control the braking force on the wheels to keep it balanced. It would only work going down a hill. You could use the same motors and dump their power into a bank of big resistors. Mountain boarders might dig this.
• Build a real experimental platform with 20 or so knobs to control each of the feedback parameters. It's very interesting to adjust a parameter and feel the difference in real time under your feet. It'd need to have some fail-safe scheme for returning to a reasonable set of parameters if the user adjusts them too far.

Links

Ben Smither's self-balancing one-wheeled scooter.

nBot, a 2-wheel balancing robot. A much better place to start if you want to build something that balances. Good collection of links.

Ted Larson's balancing robot. Mesmerizing to watch.

LegWay, a balancing robot made from Lego.

A Japanese version of the Segway. Smaller and more fuel-efficient.

Equibot, a balancing robot without gyroscopes. Probably the easiest and lowest-cost balancing machine you can build if you want to build something. The disadvantage is that it only works on flat floors.

A simple and elegant experiment in dynamic balance

Francisco Lobo built a balancing robot using similar technology.

Some students in British Columbia built one. Their report includes working code and schematics.

The Brilliant Pebbles project has a useful wiki for programming Atmel microcontrollers.

Bay Area Segway Enthusiasts Group, who let me try a genuine Segway.

Steve Wozniak's Segway Page.

The Robot Marketplace sells most of the parts I used; they also sell higher quality battery packs.

Ugh. You knew it had to happen.

Maddox has an even simpler idea for making your own.

A FIRST robotics team built a balancing scooter in 2002.

Segway LLC.

Self-balancing Skateboard by the UBC Electric Bike Club.