|
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.
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. Fortunately, I didn't
have to make a tiny ceramic tuning fork on a tiny pottery wheel. They
are a standard electronic product called a piezoelectric rate gyro.
They're 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.
See the video
[2.2 MB]
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.
|