INTRODUCTION
This is a work in progress............
BEWARE: Once you start out doing this it becomes addictive: either the thing balances or it doesn't. An all or nothing situation. There is a temptation to work and work until you can get it to balance. When it does it is very elegant and almost feels alive, when it doesn't it is just an annoying lump of metal.
Many of those who have built segway clones and self balancing robots do appear to be experienced programmers and possibly already in the IT industry. I am approaching this from another angle having maintained classic cars, being familiar with car electrics and hobby electronic projects. The last time I wrote any computer code was in "BASIC" for my Sinclair computer aged 14 years.
Basics of the design
From all my reading of the work of others, the general idea is this:
1) A gyroscope (solid state) decides if the board is tipping (falling over) and speeds up the motor to bring the board back into balance beneath you.
2) The more you are tipping the faster it tries to do this PLUS the faster you are tipping the faster it tries to do this.
3) The problem is the gyro can “drift” with time, but on the other hand it has fast response and is quite immune to vibration. To overcome this drift we utilise a small part of the signal from an accelerometer with each “loop” of the control software. The accelerometer is good because it does not drift and knows which way is “up”, however is quite influenced by any vibration. By adding in a small part of the signal each time, we are in effect looking at the average reading over time so random vibration errors should tend to cancel out. See my links page for info on theory of self balancing systems.
4) Hardware: Lead-acid batteries. Because they are cheap and can deliver large current in small bursts if needed – and this is needed because although you need very little power to roll along a level surface, you need a big reservoir of “spare” motor power for the board to bring itself back beneath your centre of gravity if you start to tip over.
5) ATMega 32 microcontroller on a small development board from a robot webstore.
6) 4 potentiometers give manual control of 4 of the constants in the computer balance algorithm. These were initially in a hand-held controller and the idea was to “tune” the balance algorithm while standing on the board rather than changing values in the code each time. When optimum settings were found I could then convert the values found this way into the actual computer code. These analogue hardware “tricks” will hopefully allow me to keep my code relatively straightforward as I am on a rapid coding learning curve.
7) Widest Go-Kart rear wheel available (18cm wide), Go-Kart shortened rear axle, Go-Kart bearings, sprocket carrier, sprocket, chain. 420W electric motor with small drive sprocket.
8) Motor controller is the “OSMC” from the USA used by some others and developed for large combat robots.
9) Chassis sides are made from laser cut steel sheet.
Cardboard mockup to get dimensions correct. Start with wheel, then look at motor. Allow some side to side movement of motor (slotted bolt holes) to get tension on chain exactly right. "Kick ups" each end allow board to be shorter as electronics boxes go inside these, also allows you to theoretically go up hills with board tilted forwards to make it go up the hill, without front end hitting the ground. Small wheels from a skateboard mounted at each end semi-recessed limited damage early on during development process! Later on I removed these as not that useful.
I have used aluminium alloy between the two steel side plates to reduce weight a little. One side is riveted to the steel panel while the other side panel will be held on by lots of small bolts. This allows the bolted side panel to be taken off to assemble the axle, wheel and bearings more easily. As you can see I have several sizes of sprocket for the main wheel. For initial tests I have chosen to use a very large sprocket which will give me a slow top speed but much more torque at the wheel for getting up hills. I have made one design mistake here. There is no way I can inflate the tyre without removing one side of the chassis!
I have tried to create bulkheads where feasible and box sections to give strength. It would be nice to think I have created something as elegant as the monocoque frame of a 1960's Formula 1 racing car but in truth it is not quite as good as that!
To stop drilling holes through alloy and then having the bit go straight into electronics I made a handy safety device clamped to the drill bit made from the brass insert from a wire connection block.
I trimmed excess alloy from the motor to get it to fit within the 10cm deep chassis rails.Original plan was to have 2 batteries side by side and micro in a box at far end. However with this setup it is much heavier on the motor side. I have therefore moved one battery out to far end where control box would have been. Not quite as neat and tidy but better for weight distribution. Also you can see there is just enough space to fit a third battery if I want to go to 36 Volts later on (which would probably even up the weight as well).
Bearings are for 30mm tubular axle from rear of a Go-kart.
Solid steel axle at moment, very heavy, may replace with aluminium at a later date as part of a weight reduction exercise.
Wiring tidied up behind alloy channel sections as they run from one side to the other. I do not want the wheel to rub through the wiring insulation causing a disaster. Ribbon cable was difficult to route along the side of the machine and has been well wrapped in plastic tubing where it enters through holes in the frame to stop any chance of it chafing against metal edges.
After destroying my gyro by accidentally putting 12V through it, I have used an opto-isolator board from Quasar Electronics to use my logic outputs to control a 12V buzzer (>70% duty cycle warning) and some 12V LED warning lamps (low battery warning. These completely isolate the logic outputs of the microprocessor from the switched 12V items. This may seem excessive but blowing up gyros is a very expensive thing to do.
More developments October 2008:
All plug connections, especially to microcontroller board, that can be have now been soldered to increase overall reliability.
Warning system via optoisolator for low battery and excess speed also involved even more wires to/from microcontroller box. Too much spaghetti making things unreliable. Have removed all these circuits for now, trying to simplify things. This has freed up some space in the casing too (thinking of fitting an LED headlight in front end for example). I may just mount a bar of LED's on one end of board to indicate battery status, using a little off the shelf kit for this.
I decided at that time to have a compromise manual control system. I discovered that when the values for the 4 variables on the potentiometers were put into the algorithm as code, the whole machine felt much "tighter" to ride. Also having 4 potentiometers like this means there are a very large number of wires running into and out of the microcontroller box - plenty to go wrong.
Consequently I decided to use a small hand controller with a button that killed the motor if not pressed at all times, plus I included one single control for overall gain so this could be adjusted when riding. The other variables were included in the code.
617 Squadron Lancasters with dambuster bombs. It reminded me of these when viewed from the side.
