2 Wheel Android Weight Controlled Robot

This robot toy is like a Segway, except it is naturally self balancing. The operational principle for movement is similar to the Sphero toy, minus the outside ball part and gyro. It is stable because the center of gravity is lower than the wheel center. It is able to move because the motors move the center of gravity (influenced mainly by the battery pack position); the wheels just follow the center of gravity. The maximum driving force is related to the center of gravity mass times the distance from the center of rotation (with the mass being 90 degrees to the ground). Therefore, bigger wheels are required to allow clearance for the mass, in order to keep the overall weight of the robot low while maximizing the driving force. I used foam core to increase the diameter of the stock wheels by hot gluing 7-1/2" diameter rings of foam core to the existing wheels. Since there is no gyro to limit the center of gravity location, the robot operator needs to get used to the maximum acceleration rate possible- if the speed is just cranked up to maximum from a standing start, all that will happen is the motors and battery will rotate in a blur, and the wheels remain stationary. A moderated acceleration rate will result in the battery pack moving noticeably forward (or back) and smooth acceleration. Very fast speeds are possible with a fresh battery pack.

Inexpensive toy hobby motors with wheels are used in lieu of my first design idea of using miniature gearmotors , because it is much easier to find the toy gearmotors, plus they have an axle on both sides. The spare axle allows an extension shaft to be installed between the motors to help strengthen the structure (since I used thin foam core at the bottom between the motors). Since the motors will be going different speeds, I had to attach them in the center with bearings to allow this movement. This center bearing allows keeping the shafts in line and prevents the motors from bending inward towards each other.

2 ea. toy hobby gearmotors with wheels Motor and Wheel

2 ea. (8 spare) Miniature deep groove ball bearing 625ZZ 5*16*5 mm Ball Bearings

1 ea. 21/32" brass tubing for holding bearings, hobby store, K+S #8144

1 ea. 1/4" brass tubing for axle spacer, hobby store, K+S #8131

1 ea., 7/32" wood dowel axle, hobby store

1 ea. 3/16" foam core sheet, hobby store

4 ea. miniature screws and nuts to hold axle spacer and motor shaft to axle, hobby store

1 ea. 4 AA cell battery holder Battery Holder

1 ea. HC-05 Bluetooth with carrier board and regulator Bluetooth Module

1 ea. Arduino Pro Mini (jumper for 5v output) Pro Mini

1 ea. TB6612 dual motor driver, Motor Driver

1 ea. Arduino IDE (free) Arduino IDE

1 ea. FTDI serial converter USB to TTL FTDI adapter

1 ea. Smartphone app Android joystick control app

1 ea. misc. tools- hot melt glue gun, drill, soldering iron and solder, wire.

Start by making the center support bearing. I just pushed 2 of the bearings into a 1" section of 21/32" brass tube (tight fit, use a hammer and piece of wood on both sides of the bearing/tube). I used a tubing cutter to cut the tube, but that made an ugly, ragged cut. A pair of Wiss M5 tin snips enabled me to cut off the ragged part, leaving a nice edge. With a bit of sandpaper, no sharp edges. The wood axle fits snugly into the bearing on each side, leaving most of the interior of the brass tube empty- another 2 bearings could have inserted and would have made a slightly sturdier assembly, but I don't think it matters that much.

A 1-1/2" section of 1/4" brass tube on each side of the center bearing fits over the wood axle and over the nylon motor axle. Two miniature nuts and bolts are installed into holes drilled through the tube/nylon axle and through the tube/wood axle. The wood axle required 3 layers of Scotch tape to build up the axle diameter to fit snugly into the 1/4" tube.

The wheel diameter was increased by using foam core inserts hot glued to the original tires. Draw 4 ea. 7-1/2" circles O.D. and a 2-5/8" I.D. with a compass on the foam core. Probably it would work as well with only 1 foam core insert per wheel, but 2 per wheel looks better. Or use 1/2" thick foam core (but harder to keep the cut perpendicular through the greater thickness, and increases the chances of gouging out foam). In any case, use 3 or 4 sharp Exacto blades in the cutting process, or the foam or paper backing will tear out. Drill a hole in scrap wood to fit the protruding hub of the plastic wheel so the wheel can lay flat on the wood. Then put the foam cutout over the wheel (foam core resting on wood block too) and tack 4 spots of hot glue between the tire and foam core from the top. Center foam core as close as possible before the glue hardens. Turn the wheel over when the glue is hard, and glue all around the tire/ foam core, being careful not to put too much glue on the sides of the tire, as it may hit the motor when installed. When hardened, find some scrap 1/2" spacers (1/2" foam core works) and place atop the wheel, then place the second foam core cutout on the wheel, resting on the spacers. Center and hot glue the foam core cutout to the tire. Remove the spacers when glue hardens. Repeat with the other wheel and foam core inserts.

Cut a 1" wide rectangular strip of foam core to attach to the bottom of the motors, long enough to allow the motors to be perpendicular to it with the center support bearing and axle spacers in place between the two motors. Cut a 3/8" relief hole in each side of the strip so the protruding motor shafts at the bottom of the motor won't rub on the foam core. With the wheels off, and center bearing axle/ spacer connected to both motors, hot glue the bottom of the motors to the strip while keeping the center bearing axle/ spacer connected as squarely and evenly aligned as possible while the glue dries. Glue the battery holder to the bottom of the strip.

You should test the HC-05 Bluetooth module to verify the baud rate matches your sketch, and to change the module name to something more recognizable than "HC-05" when it appears on your Android phone's Bluetooth scan. Start by hooking up your FTDI USB/TTL adapter (set to 5 volts) Vcc to Vcc of HC-05, Ground to Ground, Tx of FTDI to Rx of HC-05, and Rx of FTDI to Tx of HC-05. Note the led on the HC-05 flashes quickly, meaning it is in advertising mode. Push and hold the small push button on the module while simultaneously removing then restoring power to the module to get it into programming mode- the led will flash slowly, and you can release the push button. Open Realterm terminal program, Port Tab, select 38400 baud, select the port you are using from the drop down menu, and click the change button, followed by left clicking the mouse in the upper top of the terminal screen to begin. Then select the Send Tab, type AT in the send box, check the two boxes +CR and +LF, and click the "send ascii" button. An "OK response should appear in the terminal window. You can set the baud rate to whatever works for you, for example AT+UART=115200,1,0 for 115200,N,8,1. You can run the robot with as low as 9600 baud, but if you want to send information back from the robot (like battery voltage), you need a faster baud rate like 115200, since the program normally handles 4 bytes at a time (Serial.available() == 4) but the battery monitoring function puts out 14 bytes, thus the serial receive buffer must be clear of the 4 byte information before the program can send the 14 bytes back. If you then type AT+UART? it should repeat the new values. Same for the name, send AT+NAME=xxYYZZ and AT+NAME? to verify. See HC-05 manual . AT+ROLE? should give OK+ROLE:0 indicating a slave device. For other projects, you can create a direct link between two HC-05 modules, one as master (Role:1) and one as slave (ROLE:0), but in this project we are using the Android device as the master Bluetooth device.

I chose to use the Pro Mini and the TB6612 motor driver because of the much smaller size compared to an Arduino Uno and a motor shield. The smaller boards can just be hot glued to the motor for a clean installation. Solder a 6 pin female header to the Pro Mini to make a secure connection with the FTDI adapter pins for programming, and it also allows a removable serial connection (TX and RX wires only) from the HC-05 Bluetooth module. The Bluetooth module would otherwise interfere with the FTDI program download, so the header / connector assures there is never a conflict. Another way to avoid a Bluetooth conflict would be to use software serial for the Bluetooth, but software serial interrupts will mess up the millis() function used in the program.

A 4 AA battery cell holder is located at the bottom of the robot to minimize weight. The battery holder is hot glued on, strengthening the strip of foam core chassis. You could use a larger battery pack, maybe 6 AA cells, just increase the dimensions and wheel clearance as necessary. If you use a different battery voltage and also want battery monitoring, adjust the resistor values according to the original source, and change step size in the program. Note I used the internal 1.1 volt reference when calculating resistor and step sizes instead of the usual 5 volt reference because the 6 volt battery is more likely to dip below 5 volts, thus the lower reference.

The joystick program was designed for 1 motor and 1 steering servo, but his L293 library offered other modes, like 2 wheel and 4 wheel modes. The L293 library is in the first download at the bottom of the original source, Car_With_Sensors_Continuous.zip (7k). I changed the program from 1 motor and 1 servo to 2 motors and no servos, by using a formula to proportionally drive the wheel speed based on the angle information sent by the app. I included a doughnut function for fun, it causes the robot to spin in place either left or right depending on whether the "A" or "B" button is activated. The robot should be going at a relatively slow pace; hit the A or B button- then increase the speed. The thing goes so fast it is a blur! If leds were added to the robot (already in the program), it would make a great nighttime display.

This is a fun project. I was not sure how well the robot would respond with only a change in the center of gravity, but it turns out it has plenty of torque as long as the operator doesn't allow the battery pack to get past 90 degrees to the ground. That actually makes it more fun, due to the challenge of getting a maximum acceleration rate- but slow acceleration and fast speed over time is easy to achieve. Similarly, rapid stopping rates must be thought out, as just letting the robot stop by letting off of the controls may result in the motor and battery spinning with the wheels. Never operate this toy where others could be injured because it couldn't stop in time.

Possible improvements would be to include a gyro and accelerometer to limit the maximum center of gravity position. An easy improvement would be front and back lights, a horn, and even a pan/tilt for a camera or sensor, because those functions are already implemented in code, just add the wiring and external devices. Since it can send back additional analog readings from the robot, sensors for smoke or gasses could be added, or an additional battery pack voltage could be monitored. A rechargeable battery pack would be another improvement. All the improvements come at a cost; I wanted to get maximum fun for minimum cost, and I succeeded in that.

I thought of a follow on project for a bigger, human supporting vehicle like the hoverboard, but without the gyro and center swivel. That would make it even harder (or impossible?) to control, but also more fun. The idea would be to have a platform that attaches a chair to sit/recline on equipped with left and right heel and toe pressure sensors for speed and direction control. It would have wheels big enough in diameter to allow the center of gravity to be lower than the axle location. A user would flex the ankles to control the forward/back motor speed (actually controlling platform center of gravity position). It might be possible to control it in a stable manner, a bit like a person can ride a bicycle without gyroscope stabilization; and, like a bike, training wheels could be added front and back, limiting the platform movement to a safe amount. The motors would not have to have as much torque as a Segway, because the platform would be naturally stable; no energy would be wasted constantly balancing weight centered above the center of gravity, thus greater range and speed could be achieved. The lower reclining seating position would also be more aerodynamic, resulting in more range and speed than a person standing upright in the wind on a Segway.