Segway Replication
Project Background
My first introduction to the realm of mechatronic systems occurred in 2008 when I saw a Segway for the first time. Up until that point, I was only familiar with passive balancing systems which rely on gravity to keep them oriented a certain way, and I was blown away by the concept of a feedback device capable of balancing itself in real time. One of the first things that I did after finding out about Segways was write an essay for my English class at the time which covered the inner-workings and applications of Segways. I learned of the 6-gyroscope array used in conjunction with at least two accelerometers to provide the Segway with sensory information, how they communicate data to the Segway’s mainboard to be interpreted, and how the Segway responds with motor signals to those sensor inputs to keep the Segway balanced.
I was 12 years old when I became aware of the Segway, which left me far out of range of the funding necessary to purchase one for myself. It isn’t really a toy designed for kids to play around with, though in my opinion it isn’t all that practical either with its low top speed of ten miles per hour and the danger that it adds to transportation. The cheapest model that I could find was still an unattainable 5000 dollars. At that point, I decided that no matter how long it took me to complete, I wanted to design, program and construct my own Segway.
Over the course of the next two years, I combined scrap materials with a few items purchased online for the construction aspect of my Segway and attempted multiple methods of programming the feedback loop that would keep it balanced. I used Lego Mindstorms as my microcontroller and interface between the Segway motors and sensors. This ended up bringing me close to the control system that I needed to keep my Segway balanced, but I was unable to get it to work at that age, and still had too much to learn about mechatronic systems before I stood a chance against the Segway’s complexity.
Now, with my college education, I believe that I could program and build a working Segway using much more respectable manufacturing techniques than the ones that I attempted to use when I was 12. Though I failed to produce a working model the first time around, I am armed with the knowledge that acquired from my failures and my education and will definitely see this project through, though I will definitely be starting again from scratch.
Detailed Description
I began my Segway project with extremely simple and low-quality materials. At the age of 12, all that I had available to use was scrap wood, wood screws and junk materials from a few gutted Razer motor scooters. I made a few drawings detailing my idea of a final product using the materials that I had, which was quite simple in the beginning, but I slowly built upon it as I acquired more materials. The very first iteration of my Segway project was largely held together with Gorilla glue and steel hanger strap. I had high-power signals running up the handlebar shaft to normally-open switches located in each handle which I had originally intended to use for directly driving the motors. The wires remained on the final model that I ended up with but served no purpose once I discovered the mechanism behind Segway acceleration and turning.
The Segway’s self-balancing act makes corrections to the structure’s orientation whenever the user leans in a direction, and those corrections cause the Segway to accelerate in the leaned direction, both transporting the user and preventing the Segway from tipping over. Needless to say, it was dangerous to have 24-volt high-current connections running through the handlebars even in 12-gauge coated speaker wire, but that was the idea that I came up with at the time. Now, if I wished to send a signal from the handles to the mainboard at the base, I would run low-power wires up the length and read the wire signals as inputs using a microcontroller, then control relays or transistors to output high-power signals safely.
I had no idea how to drive motors at variable speeds when I began this project, which is definitely necessary for seamless balancing, so I only had them set up to be completely on or completely off. I knew that changing the voltage input would influence motor speed, but I didn’t know that it would also largely influence the torque output, nor was I familiar with any device that I could use to adjust the input voltage anyway. I am now well aware of pulse-width-modulating electrical signals, especially those powering motors, at high frequencies to effectively control rotor speed. PWM wastes far less energy than using systems of resistors to regulate voltage for speed control and produces significantly higher torque for the same output speed as such a resistor system would achieve.
Motors are also designed to operate with specific voltage inputs, so if I had gone through with voltage-controlling my motors, they would have easily stalled entirely at low voltages, even under no load. The drive system itself consisted of independently controlled brushed motors that I had salvaged from broken motor scooters. Each, in the final version, was rated for a 200-watt output, with rotor speeds of around 3000 rpm, but I originally had mismatched motors, one of which provided far less than a 200-watt output. I opted to also salvage the sprockets used in the motor scooters which would, when chained together, impose a speed reduction of 5:1, giving the wheels a no-load rotation rate of 600 rpm.
The maximum speed that the Segway could reach with the 1-foot diameter wheels that I eventually installed, under no load, would be 21.4 miles per hour with the motors capping at 3000 rpm. Before I acquired those wheels, again limited mostly to the scraps that I had laying around, I first tried to use the wheels that had been salvaged from the broken scooters. At the time, my understanding of motors was extremely limited, so my first attempt involved directly mounting the six-inch-diameter wheels onto the rotors. I tested this once, but the motors were not designed to handle the direct load and couldn’t rotate at any significant speed, pulling extremely high currents and ultimately causing the wires to overheat and generating sparks at a bad connection point which lit the tape that I covered the connection with on fire. I used electrical tape from then on and was sure to connect my wires more reliably.
I scrapped the first design because of how unreliable it was and moved to a much more sturdy version using real fasteners and more evenly-matched motors. The best way that I could think to mount my wheels was to construct a U-shaped structure on the top of my baseboard from angle iron and drill coaxial half-inch holes through both sides of each U-section. I ordered a few wheels on eBay which had half-inch-bore bearings and paired them with half-inch bolts fed through the holes that I had drilled in the angle iron.
In order to keep the handle vertically oriented but also allow it to swivel, I purchased a few large springs at a nearby hardware store and screwed them into the frame, then attached them near the bottom of the handle shaft, which on my newer version of the Segway had been set up to swivel at its base on a bearing. With the springs in place holding the handle in the upright position, it was then possible to add a system that would read the rotation of the handle away from its normal vertically oriented position and translate it into motor commands to turn the Segway.
I mounted the now power-matched motors to the bottom of the baseboard, strapped a few lead acid batteries between them and installed a dead-man-switch and a kickstand, and I was ready to begin programming an interface to balance and turn the Segway. I turned to my uncle since I had no prior experience with coding devices to perform actions in the real world; I had only worked with Visual Basic and entirely virtual actions at that point. He did some research and asked around at work, then he concluded that for my skillset and applications, the best route for me to follow was to use the Lego Mindstorms electronics kit as the “brains” of my Segway.
The kit was fairly expensive for someone my age, and I couldn’t afford it at the time, but I received it as a gift soon after. I learned that since the kit did not include a gyroscope sensor, I would have to purchase one separately online, so I researched on the Mindstorms site to see what kind of sensors were available. I was happy to see that they had a proprietary gyroscope ready to interface with the Mindstorms Brick which houses the system’s microcontroller, so I purchased one.
After messing with the software for a few hours, I had coded up a system that sent signals to a Mindstorms motor proportional to the rotation of the gyroscope away from its starting position, a rudimentary approximation of the real system that would be needed to balance a Segway. I built a structure with the motors from the kit that emulated a miniature Segway to see if the system that I had made could balance, but the relationships between the measurements taken by the gyroscope and motor movements were more complex than I had expected, and it did not function as intended.
One of the main problems that arose from my choice to use Mindstorms was in the structure of the IDE that came with the Mindstorms kit. While easy to understand and learn to use because of its icon-based interface, it only contained necessary basic functions written for a shallow range of tasks, and I could not troubleshoot by creating sophisticated mechanisms, nor could I take advantage of the system’s full potential speed. As such, it was difficult to specialize certain tasks when everything had to be done using their inefficient, slow prebuilt functions. There were limits coded into the functions setting the rate at which data could be collected, processed, and then a reply sent out that could otherwise be well exceeded in simpler languages and without the coded limitations. I was unable to prepare any code using this interface that could provide the data-rates necessary to make my system as responsive as it would need to be in order to remain balanced.
My FTC robotics team used Mindstorms to control our robot and found the same limitations of speed both in using the free Mindstorms software and when we attempted to use Labview. The final code was just too inefficient to respond to the control requests that the robot was given seamlessly and in real time, which in my Segway would have been catastrophic. We found a solution in the programming language Robot C for our robot, which was more of a bare-metal language, interacting with components in the simplest and quickest way. I took that to mean that Robot C would also work for my Segway, so I uploaded the necessary firmware onto my unit and started researching a bit into coding a gyroscope-based feedback loop.
At the time that I was doing this coding I was only 14, and had never even heard of derivatives, so I was truly stuck until I was better educated. I successfully found multiple sets of code written in Robot C by others that I tested on my own unit which were capable of balancing my Lego structure using the kit motors and wheels, but I was unable to learn much from this code, much less manipulate it for my own needs. One such version operated according to input signals from the gyroscope sensor as I had intended, which brought me very close to the type of code that I was looking to create myself.
Before I found that gyroscope-based version, however, I was surprised to find a version coded to stay balanced by reading changes in light intensity below the unit to one side, most likely using the rate of change of the reflected light’s intensity. A light sensor with a built-in red light was propped to the “front” of the unit which, when placed on a flat surface, would report a decreasing level of light intensity when the unit tipped back and an increasing level when it tipped forward due to the reflection of the red light bouncing back. I was impressed not by the practicality of the applications used in this version but by the fact that it actually worked, and the ingenuity that led to the ideas used in the build.
While based on these working models I can conclude that the Mindstorms NXT, with its gyroscope, angle sensing and motor actuator peripherals, would have been able to run my Segway, I have since found much simpler and more suitable solutions. I am proficient now with Arduino coding, and I can think of simple ways to code a Segway-balancing control system within Arduino or similar microcontrollers, with faster read-write rates and many more far cheaper open-source peripherals to choose from. When I have the space, the time and more real manufacturing tools available such as a lathe and mill, I will return to this project.
I plan for my next attempt to entirely model the system first in CAD, which I did not have available to me when I was 12, before beginning to construct the machine, and to use real, rigid, respectable components like aluminum, steel and machine screws in place of the wood and wood screws that I used in my first attempt. I approached this project with scrap and repurposed materials the first time around, choosing Lead acid batteries, old pipes, tape and motors from broken motor scooters. My improved version will use new components such as high-energy-density lithium-ion-polymer batteries, specialized hobbyist brushless motors in place of the Razer brushed scooter motors that I had before, and precision machined aluminum framing. I am excited to finally do some real work on this project now that I am sure that it’s something I can accomplish with the tools that I will soon have at my disposal.