Short MPEG Video [1.0 MB]

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.

• 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

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 a two-wheeled balancing robot and then scale up. See my notes on safety if you're considering trying to build something.

Construction

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

Power

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 an Astroflight 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

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

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

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

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

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

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 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

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

I'll try to get some videos of the current performance up soon. It still doesn't quite match the Segway in two respects. First, my gyroscope drifts a bit especially when accelerating hard or going up a ramp, so the handle position wanders around a bit. This is tiring on the arms, and makes it harder to limit top speed. Second, my balance feedback loop isn't quite as stiff as the Segway's, so it still feels a bit mushy. I can't make it any stiffer without getting oscillations. It may need a higher-performance gyroscope, but I think the main difference is that the Segway's wheels have a large moment of inertia which allows it to apply a reaction torque to the chassis. My wheels are smaller and have most of the mass in the center, so it only gets reaction torque between the ground and the mass of the scooter body. The soft rubber tire adds a large spring between the wheel and the ground, and the mass of the scooter is not very stiff either since the batteries flop around.

The Segway is also bigger, stronger, lighter, and has more ground clearance and battery power. But I still like mine pretty well.

Cupholder

...all you have to do is make a little "hammock." Take a large drink coaster or other disk and drill three small holes near the rim, 120 degrees apart so they are equal distances apart. Run a string through the holes and tie together a foot or so (the distance depends on the size of your cup and the coaster diameter) above the center of the coaster. Support the hammock from the knot where the strings come together by hanging it on a hook or something. As long as the coaster doesn't bump into anything (it has to be able to swing freely) it is pretty hard to spill anything, regardless of how you move around the knot. You can even spin the thing in a big vertical circle so the cup is sometimes upside down, and nothing comes out. (Hopefully you won't do that with your scooter!)

Sure, I thought, in theory. I think I saw that demo in Physics 101 too. But it can't possibly work in practice, with 3D wobbling, swerving and bumping. With no damping, the cup will swing around wildly. But, I tried it anyway. Instead of the plate Bob suggested, I used a large cup that a normal coffee cup will fit into. As well as keeping it from sliding off when it's jiggling up and down, it should also help keep the coffee warm in the fast-moving air. As a worst case test, I just filled it with water and put no lid on.

The first version used a string about 30" long. It worked as long as the cup didn't bump into anything, but the string was so long that it was hard to avoid hitting obstacles or the scooter itself. For version 2 I shortened the system to about 14" including the cup and hung it about 15" out in front of the handlebars. It swung around crazily, but didn't spill. It's quite amusing to watch: it looks wildly improbable and out of control.

See the video [2.2 MB]

Current Problems

• 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

• 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 & 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