Self Balancing Robot
A two wheeled Segway-like balancing robot with a $15 budget.
This project was built for an intro to engineering course. The rules were to build an arduino based 'robot' in 2 weeks with a cost of under $15 that 'moves.' The complexity and task of each robot was completely up to the students.
The robot should perform as follows:
Self correct in real time
Of course, the robot must also follow the project rules. It must cost less than $15 (not including the arduino and servo motors). The whole project must be completed within two weeks, and will be presented to the student body after the deadline.
From a small list of 'robots' I could created, I chose the most unfamiliar project. Having built plenty of simple robots with legos in elementary school and middle school, as well as very complex robots in High School, I wanted a challenge. The projects that I considered are as follows :
Popcorn/ball catapult (with rubber bands and automatic reloading)
Line Follower (uses a light sensor to follow a line - this was something my junior high school robotics team did with simple visual block based programming in the LEGO Mindstorms NXT 2.0 software.
2 axis arm with a pen programmed to write or draw.
Self balancing Segway-like bot
The challenge that I saw was in the programming. A mechanical body would not be too difficult to create; the real balancing comes from the sensor input and controlled motor output. I chose to do this coding without any research of existing self balancing code. This was so that I could explore, discover, and learn the system, the programming language, and the balancing code for myself, as this was my first time learning how to code in the Arduino IDE language. I would have to experiment with different control schemes to optimize balancing.
I tested several iterations of wheel size and center of gravity. I quickly found that the servos were not fast enough to respond to quickly developing error (unbalance). I iterated wheel size and discovered that the only way to get the right response speed with the motors provided was to use larger wheels. I ended up laser cutting 12" wheels in the SCU maker lab for this robot. I also added a counterbalance to the bottom to move the center of gravity slightly lower (but still above the axis of the wheels). This helped to reduce the inherent instability of the system.
The physical robot consisted of an old airpods box mounted to two servo motors with hot glue and the arduino powered by a 9V battery that was taped onto the side. The MPU 6050 gryo+accelerometer sensor was held in place with the stiffness of the solid core wires that were bent into the pin holes (due to the lack of a soldering iron). Wheels were initially 1" diameter RC car wheels, and where quickly upgraded to 3", then 8" foam boad wheels, then 12" laser cut wheels.
Testing and Tuning
I tuned the gain constant through an iterative process, which involved a lot of trial and error. I found that the stability of the hard wheel on carpert required different constants. The carpet was more stable, so I inverted the surface that the soft/deforming material was on in order to use it on hard flooring, such as concrete or wood. Using a roll of toilet paper that I folded several times over itself, I taped the soft surface to the outside rim of the wooden wheels. This enabled better stability on hard surfaces, and constituted the final design change of the robot.
Afterwards, I researched self balancing arduino robots and discovered that youtube quickly found a similar bot. I noticed some interesting differences between the two. The biggest difference was the motor power. The second biggest difference was the code, which was from a gitbub library derived from "MultiWii 23" firmware which "was the culmination of years of break-thru drone autopilot 'pilot feel' development" for quadcopter control during flight," from Carbonbird's professional team.
Overall, given the time constraints of this project, I am proud of the control system and robot that I developed. If I were to continue development of this project, I would definitely experiment with smaller wheels and faster/more powerful motors, and a more powerful battery. The servos provided for the class were not ideal for the drive train. I would also further develop the control system to minimize the time to recovery and distance travelled during recovery. This would likely involve more research in feedback control systems (that I did not have as a freshman in college).
After having taken a course in feedback control systems, I decided to update this page with some insight I've gained. In hindsight, I essentially created and developed a P only control loop, feeding a gain times the difference between the set position and the actual position, where position was the gryo sensor feedback. If I were to re-do this project now, I would likley start by researching and experiementing with inverted pendulum control systems, which will likely involve a PID loop, rather than a simple P loop. This might also involve modeling the system with a transfer function that models robot position rather than robot angle, as well as tuning system constants such that its gains minimize rise time and steady state error.