This latest project is the longest and most complicated so far.  Over the last several months I’ve been working to put together a Segway-like self-balancing scooter, aka the “Halfway”.  Many people have written up and posted similar projects online.  Google “DIY self balancing scooter” to see some examples.  Other people’s work provided a lot of inspiration and help during the design and execution of the Halfway scooter.  If you’d like to see how it turned out, skip to the end of this blog post for a video of the Halfway in action.

This particular project was appealing to me because it utilized elements from my earlier blog posts, such as obtaining angle data from an IMU and integrating a Wii nunchuck with an Arduino.  I also got to learn some new skills, including welding metal, CAD with Google Sketchup and programming with PID control loops.

The Disclaimer:

Riding a two-wheeled self-balancing scooter is an easy way to get injured.  One of the co-owners of the Segway company died by driving his off a cliff.  A homemade version of a Segway lacks the redundancies, careful testing and built-in safety mechanisms of the real thing.  If you decide to utilize any of the information in this blog post in building your own scooter, I am not responsible for the outcome.  Please keep safety strongly in mind in the design, building and especially the testing of any motorized project that you intend to ride.

The Principle:

Self-balancing Segway type scooters are not as complicated as they initially seem.  When I first saw one, I thought they had gyroscopic stabilizers to help maintain balance in an upright position.  In fact, the only gyroscopes needed are tiny ones in the IMU (Inertial Measurement Unit) that help detect the orientation and tilt of the scooter.  A self-balancing scooter is basically a classical inverted pendulum.  The scooter works by simply running its wheels quickly enough in the correct direction to stay upright.  If the scooter leans forward or backwards, it will drive in the direction it is leaning until it returns to a vertical alignment.  The wheel speed is determined by how far the scooter is tilting, how rapidly the scooter’s angle changes, and how far and for how long the scooter has been tilted away from vertical.

The Research:

There is a lot of information about building a self-balancing scooter or robot on the Internet.  Some of the more useful sites I found:

• http://www.instructables.com/id/Easy-build-self-balancing-skateboardrobotsegway-/  – My primary inspiration for this project was a well-documented Instructable on creating a self-balancing skateboard by XenonJohn.
• http://www.instructables.com/id/Rideable-Segway-Clone-Low-Cost-and-Easy-Build/ – This Instructable came out when I was mostly done with the Halfway, but it is an incredibly thorough overview of building a DIY Segway, along with a comprehensive instruction video on YouTube.
• https://sites.google.com/site/onewheeledselfbalancing/Home/links-to-other-self-balancing-projects – A meta list of other self-balancing projects.
• http://www.tlb.org/#scooter – Trevor Blackwell’s well-worded description of building and driving a DIY Segway.

The Components:

There are any number of different design choices when building a self-balancing scooter.  You can choose chain drive, direct drive or motorized hub wheel/motor combinations.  Wood, metal (or combined) chassis.  Digital or analog IMU (Inertial Measurement Unit).  Tilt handle, joystick or lean steering.  The list goes on.  The choices I made were based primarily on availability, ease of use, then on cost.  Here are the principal components I ordered online:

• Motors:  Razor e300 24 Volt, 280 Watt Scooter Motors – Cheap, reasonably powerful, and easily available on eBay.  These motors included an 11-tooth #25 chain sprocket, so this determined the size chain and wheel sprockets needed.  In the end, I’m not sure if they provided quite as much power as I’d like.
• Wheels: 9″ x 3.5″ rear wheel with fixed sprocket – I wanted these to be as large as possible for a smoother ride, but also had to make sure the sprocket was attached directly to the wheel hub (not to a freewheel) so that the wheel could turn both forwards and backwards by changing the direction of the tension in the chain.  I also purchased the corresponding axle and spacers to help keep the wheel sprocket aligned directly underneath the motor gear.
• Batteries:  12V, 7Ah, Sealed Lead Acid Batteries.  Heavy but cheaper than the alternatives.  I had planned to put two of these in series to run the 24V motors, but inadvertently ordered four batteries instead of two.  I decided to add the additional two batteries in parallel for a longer driving time.
• Micro Controller:  Arduino Uno – The right combination of low cost, speed, multiple I/O pins and flexibility.
• Inertial Measurement Unit:  GY-521 – An easy choice, as these are cheap (under $6 on Amazon), have 6 degrees of freedom from a 3-axis MEMS gyroscope and a 3-axis MEMS accelerometer, and I’ve had experience using them in past projects.
• Motor Controller:  Sabertooth 2×25 – At $125, the most expensive single component of this project, but essential to drive such powerful motors and easy to use with an Arduino.  Accidentally frying one of these taught me to be VERY careful about the polarity of the battery connections.
• Steering Joystick/Deadman Switch:  Wii Nunchuck – I had one lying around the house, along with a WiiChuck breakout board to help connect it to an Arduino.  I had used a Wii Nunchuck to control servo rotation in a previous project, so I already knew how to use one of these for steering.
• #25 Bicycle Chain and connecting links – Purchased from a bicycle store.  I also had to purchase a chain breaker tool to cut the chain in the right place.  The connecting links allowed me to connect the chain up into a loop of just the right length.

The Chassis:

Frame:  Homemade from steel tubing, angle bracket and wood.  Steel made the frame strong but quite heavy.

In designing the chassis, I was mostly concerned with sturdiness – the motors, batteries and wheels are heavy and the motors produce a lot of torque.  I wanted the frame to hold them securely in place.  I also considered the best way to keep appropriate tension in the chain drive. Suspending the motors directly over the wheels with metal bolts allowed me to adjust the chain tension by tightening or loosening the nuts.  I can add or remove washers to adjust the distance between the motors and the wheels.

I designed the basic chassis in Google Sketchup, to be welded from 1″ steel tubing.  Modeling the chassis online was absolutely essential to getting the right configuration.  I wanted as close a distance as possible between the motors and the wheels to minimize the effects of slack in the chain.  I also needed to make sure the axle supports (made from steel angle bracket) were close enough to hold the axles, but far enough apart to leave room for the wheels. Before starting the construction, I took a terrific class at Moltenmetalworks in Los Angeles specifically to learn welding and basic metalworking techniques.  Once I had a feel for the basics, I was then able to go back to Moltenmetalworks’ open lab time and use the MIG welders and other metalworking tools they had in their shop to construct much of the frame. After the basic frame was welded together, I added a number of parts held on by 3/8″ metal bolts, including four pieces of steel angle bracket below the frame to support the axles and another two pieces of angle bracket along the sides to support the platform the driver stands on.  I cut 3/8″ threaded rod into 6″ lengths and used that to suspend another two angle brackets which support a wooden platform below the frame.  This created a center compartment to hold the batteries and electronics.  The four lead-acid batteries take up much of the room in the center compartment, which makes for a tight fit for the electronics. If I did this project again, I’d create a roomier compartment for the batteries and electronics. The motors are mounted on sturdy wooden boards, reinforced by thin steel sheet, and the boards are bolted to the top of the frame.  This allows the distance between the motors and wheels to be adjusted by adding or taking away washers on these bolts between the frame and the wooden boards (see picture above).

Handles:  It is very helpful for the driver to have something to hold onto for balance when riding a self-balancing scooter. Most DIY Segway scooter designs seem to have a center handle for support.  Often this handle can pivot to the left and right to provide steering.  In the case of the Halfway, the easiest and cheapest approach was to bolt handles directly to the frame.  I chose wood to keep the weight down, as the Halfway was getting very heavy by this point.  Steering is accomplished through the joystick on a Wii Nunchuck, which is currently duck taped to the handle.  A more stable attachment method is planned for sometime in the future.

The Electronics/Power:

Basic electronics setup:  An Arduino Uno provdes the brains for the Halfway.  For inputs, the Uno gets orientation data from the GY-521 IMU and steering and control data from the Wii nunchuck.  The “Z” button on the nunchuck acts as a deadman switch.  The motors will only turn on and remain on if the user is holding down the “Z” button (this is coded in the software).  For debugging and information purposes, the Uno can send output through a JY-MCU Bluetooth board, as well as to a 2×16 LCD display.  In addition, the Uno controls three LED lights.  One indicates whether the scooter is “balanced” (within 4 degrees of vertical), another indicates whether the rider is holding down the deadman switch on the Wii nun-chuck.  The third indicates whether the Bluetooth board is powered on.  The Uno sends data to a Sabertooth 25 Amp motor controller to specify the power to and direction of the motors. The power to the motors is provided by four 12V 7mAh lead acid batteries connected first in series, then parallel for a net output of 24 Volts.  Most of the electronics fit in the center compartment under the platform the rider stands on.  However, it was a tight fit.  Some of the components, on/off switches as well as outputs such as the LEDs and LCD display are housed in a control panel made out of a 6″x4″ project box.

Power supply issues:  I initially attempted to power the Arduino Uno off of the lead acid batteries using a 9V voltage regulator.  This was the most common configuration I’ve seen in designs that were published online.  Other designs ran the Arduino off of the 5V regulated output from the Sabertooth controller, but I wasn’t convinced that the 5V was a large enough of an input to power the Uno.  Attempting to power the Uno from the lead-acid batteries was problematic for me.  I found that the GY-521 would give accurate data about the Halfway’s tilt angle until I turned on the motors, at which point the GY-521 data became unreliable.  I assume that large power pulls from the motors were causing fluctuations in the rest of the circuit.  I tried adding different values of capacitors in series with the voltage regulator to smooth out any voltage fluctuations in the electronics, but still couldn’t get consistent readings from the GY-521 with the motors on.

I eventually decided that a workable, though more complicated solution to powering the electronics was to use an optoisolator to separate the motor power from the power to the other electronic components.  You can see the optoisolator in the close up picture of the electronics in the main compartment.  I brought in a battery pack containing 8 AA batteries totaling 12 Volts to power the Arduino. I connected a 5V voltage regulator to the 12 Volt battery pack to provide power to the Bluetooth board and the 2×16 LCD display.  All other electronic components were powered directly from the Arduino.  l then connected the output of the Arduino to the low voltage side of the optoisolator and the Sabertooth to the high voltage side.  This made the wiring a bit more complicated, but completely solved the problems with corrupted GY-521 data.  The downside of this setup is that now I have to make sure that two different sets of batteries (the lead acid batteries and the AA battery pack) are sufficiently charged to run the Halfway.  To make sure the communication between the Uno and the Sabertooth wasn’t too fast for the optoisolator, I set the baud rate on the Sabertooth to 9600 baud using the dip switches (see below).

Sabertooth Configuration:

The Sabertooth motor controller is communicating with the Arduino in Simplified Serial Mode at 9600 baud, configured with dip switches on top of the board.  PAY CLOSE ATTENTION when the Sabertooth Manual says to be very careful to connect the the battery to the controller with the correct polarity.  I found that the Halfway’s metal frame made it very easy to short the power to the Sabertooth by simply holding a wire carelessly.  It was a very expensive lesson.  The Sabertooth itself is extremely easy to control with an Arduino, and comes with its own Arduino libraries.

Control Box:

The control box rests on top of one of the motor supports and contains the on/off switches for the JY-MCU bluetooth module and Arduino power supply as well as 2×16 LCD display for debugging purposes.  I also put the 8 “AA” battery power supply in this box because it was the only place it fit.

Software Design:

There were two principal algorithms utilized in the Arduino software.  The first, the Complementary Filter, was used to take the raw data from the GY-521 IMU and use it to determine the scooter’s current tilt angle.  The second, the PID control algorithm, computes what power the motors need to keep the scooter balanced, as a function of the current tilt angle, rate of tilt, and accumulated errors.

Complementary Filter:  A previous blog post discusses using a complementary filter to combine raw gyroscope and accelerometer data from an IMU to obtain accurate orientation information.  For the Halfway, I only needed to know the pitch angle of the scooter (its deviation from vertical), so I didn’t bother to calculate yaw or roll.  I used a modified version of the code from the previously mentioned post to do the calculations.

PID Algorithm: PID stands for “Proportional, Integral, Derivative”, and its output is a function of the computed error in a system.  The error in this setup is how far the scooter is tilted away from the desired vertical (designated 0 degrees).  An excellent, intuitive description of the PID algorithm can be found in this blog post about using PID to create a line following algorithm for LEGO Mindstorms.  The output of the PID algorithm is simply a value to send to the motor controllers which determines the speed and directions of the motors.  Fortunately for me, Brett Beauregard has written a nice, robust PID library for Arduino, along with a detailed explanation of how it works.  To use this library, one has only to specify the values of the constants of proportionality for the proportional (Kp), integral (Ki) and derivative (Kd) components of the output.  As it turns out, finding Kp, Ki and Kd is not trivial, and there’s been a lot of trial and error to find values that seem to work.  I’m still not sure they are the optimal values.  It’s fairly obvious when you supply the wrong K values.  If they’re too large the scooter starts to oscillate violently, and if they’re too small, the scooter won’t right itself quickly enough and falls over.  However, it’s not nearly as clear when one is converging on the optimal values, as the K value data space has a lot of local minima.  The values currently in use came from a combination of guesswork and trial and error, but there are known PID tuning algorithms that may be used in a project like this as well.

Safety Features:  The following safety precautions were written into the code:

• Deadman switch on the Wii nunchuck.  When the driver lets go of the “Z” button on the Wii controller for more than 300 milliseconds, the motors will shut off.  This way if the driver falls off, the scooter will not run them over (as long as they are not still holding on to the deadman switch!)
• If the motors are off, the scooter must be moved into an almost vertical position for them to engage again.  Since the power to the motors is proportional to the tilt angle, we don’t want the scooter to start off with a large initial speed.  Starting out close to the vertical guarantees that the initial speed will be small.
• The engines will shut off if the scooter tips too far over.  If the tilt angle gets too large, the scooter has probably fallen over, and should be turned off.

Steering:  The Halfway has differential drive steering, meaning it turns by creating a velocity differential between its two wheels.  The driver can turn by moving the joystick in the Wii nunchuck to the right or left.  Data from the Wii Nunchuck is obtained by the Arduino using the WiiChuck library.  The software determines how far the joystick is tilted to the right or the left, and creates a steering value based on whether the joystick is tilted a lot or a little.  This steering value is added to one wheel, and subtracted from another.  If the scooter is not moving forwards or backwards at the time, it will turn in place.

The Results:

The video below shows that the Halfway works and is a lot of fun to drive.  Two of my boys volunteered to be the test pilots.  A few quirks still remain to be ironed out, however.

• The Halfway works well on flat ground, but tends to twist sideways on uneven surfaces, especially on hills.  Ideally, I would like to fix this by obtaining yaw data (rotation around the vertical axis) from the IMU and correcting the turning by counter steering when the Halfway is turning without being steered.
• The wheels stick easily on small obstacles, like stones or branches. Again this may be solvable by using an IMU to get Yaw data, and increasing power to the stuck wheel if the Halfway starts to turn without being steered.
• The Wii nunchuck is difficult to hold on to for long time periods.  A different steering design would be better for future versions.
• The gear ratio specified by the motors and wheels (55:11 = 5:1) does not produce as much torque as I would like.  I think that the Halfway would drive better with a higher torque, lower speed gear ratio.
• I’d like to use a more methodical system to optimize Kp, Ki and Kd in the PID Algorithm.

The Future:

My son and I obtained a used electric wheelchair for $50 on Craigslist.  We’re going to strip it down for the motors and wheels, and use them to build a direct-drive version of the Halfway this summer.  We should be able to utilize some of the lessons learned in this project.  I hope that the direct drive motors will provide more torque to the scooter for a better ride over rough areas, and that the build will go faster the second time around.  If all goes well, by the end of the summer we’ll be driving our Halfways together!