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
| Segway | My Scooter |
| Motors | Brushless servo motors with neodymium magnets. "The highest-power motors for their size and weight ever put into mass production". | Conventional DC motors with gearbox, widely used in powered wheelchairs. $286 each from National Power Chair or from Robot MarketPlace. |
| Gearbox | "Like a precision Swiss watch". Engineers designed the "meshes in the gearbox to produce sound exactly two musical octaves apart." | Part of the wheelchair motor above. When going up a ramp, they sound kind of like the starter motor on my old Dodge Dart. Rrrrr-rrrr-rrrr-rrrr. |
| Batteries | 2, 60-cell custom-designed NiMH packs producing 72 volts. "the highest power of any currently available chemistry". | 20, 6-cell NiMH packs made for RC cars. They have "IDEAL SOLUTION FOR RC TOY" printed on them.$15 each from Powerizer. |
| Wheels | Wheels are "sophisticated engineering-grade thermoplastic." Tires by Michelin, with a "unique tread compound (a silica-based compound instead of traditional carbon-based materials)". | Wheels are stamped steel. I think they're made for utility trailers. Tires made by Cheng Shin tire works. They make startlingly loud squelching sounds on tile floors. Tire and wheel are $79 each from NPC, and hubs are $20 each. |
| Controller | "Sophisticated controller boards from Delphi Electronics" with "Texas Instruments digital signal processor, monitoring the entire Segway HT system and checking 100 times per second." | An 8-bit microcontroller from Atmel, running code written in C using floating point arithmetic. It sends speed control commands out the serial port at 9600 baud in ASCII to the motor driver. $10 from Digikey. |
| Motor Driver | "a set of 12 high-power, high-voltage field-effect transistors (FETs)". | The controller has 16 MOSFETs and can handle way more current than my batteries can supply. Made by RoboteQ, it's $485 from Robot MarketPlace. It's a popular part for use in Battlebots. |
| Gyroscope | "packed with five solid-state, vibrating-ring, angular-rate sensors" | One ceramic rate gyro, of the same kind that's in your camcorder (to detect your hand jiggling and stabilize the video) or RC helicopter (to stabilize the tail), and a 2-axis accelerometer to correct for drift. $149 from Rotomotion complete with the Atmel microcontroller. |
| Structure | Plastic and aluminum in smooth swooping shapes. "Chassis withstands 7 tons of force." | Two pieces of aluminum plate with holes drilled in them, and a standard aluminum extrusion for the handle. |
| Safety features | Everything is dual redundant. For example, "in the unlikely event of a battery failure, the system is designed to use the second battery to operate the machine and allow it to continue balancing until it is brought to a safe stop." | There is no redundancy or backup system. It is not even robustly made. Loose wires literally dangle out the bottom. In the fairly likely event of the software crashing, a wire coming loose, a component failing, or the batteries running low, the wheels will stop and the entire kinetic energy of the system will be used to accelerate my head toward the ground. |
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.) This is pretty darn important, and you should think about it very 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.
Another caveat: I am not a lawyer, but beware that the Segway folks have a US patent on the whole idea of a balancing scooter. Note that this is not a set of instructions for building one, it's just notes on how I built mine. I built this one for my own amusement and to satisfy my personal curiosity about how balancing scooters worked, but in the US building such a thing with any kind of commercial motive without a license from the patent holders could get you in legal trouble.
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 an Astroflight model 112 charger, which delivers 5 amps charge current at the 40 volt charging voltage.
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 from
Atmel. 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 & 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:
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
I like to use the scooter to go for coffee, but it's very hard to hold onto a cup of coffee and ride it at the same time. It needed a cupholder. I tried a very simple design, basically some cable ties on the main bar, but it didn't work well. I lost about 3/4" of coffee in 1/2 mile and got coffee spatters all over my pants. But, the great thing about publishing your experiments is that you get lots of minds thinking about the problem and one of them will probably suggest the right answer. Bob Beichner, from the physics department at North Carolina State University, wrote:
...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.
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 & 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.
The first generation of PolyBot has the basic ideas shared in all the generations of repeated modules being about 5 cm on a side. The modules are built up from simple hobby RC servos, power and computation are supplied offboard. The modules are manually screwed together, so they do not self-reconfigure. The G1 modules showed the first instance of simple reconfiguration for locomotion in 1997. This design has been made available to other researchers, most notably the NASA snakebot (so far). 
This module was made to be a testbed for adding sensors and for testing the functionality of various configurations. Although it is not self-reconfigurable, it is very easy to manually reconfigure with a simple push and a twist. These modules do have a simple 8-bit processor and batteries on board. 
This version was built after the second and third generations and took the learning from building the G2 and G3 versions further. It is more reliable than the G2 and G3 versions, and more robust and scalable than any of the other G1 versions. This comes primarily from using more robust servos with more reliable output stages and using a higher voltage power bus. The increased robustness was demonstrated at an IROS03 tutorial putting the modules in the clumsy hands of robotics researchers. 
This generation of PolyBot includes onboard computing (Power PC 555) as well as the ability to reconfigure automatically via shape memory alloy actuated latches. Docking of the chains is aided by infrared emitters and detectors. The black cylinder sticking out of the module is the motor. The motor with gearbox is about 5 times stronger than the G1 modules. 
