Miniature Self-Balancing Robot (completed)

1/13/15

With RPI's machining facilities inaccessible to me over winter break, I decided to pursue a new project to keep boredom at bay. My custom 3d printer project is still back at school awaiting parts that I will install when I return, and the third revision of the mechEtroller motor controller is awaiting new PCBs. So what to make that's cheap, interesting, requires no machining, and can be done in a few weeks?

It turns out that my answer was a tiny robot. Similar to the full sized Segway-like electric scooter I build in high school, I wanted to make a inverted pendulum bot. This time, however, with some differences:

• Small enough to fit in a (largish) pocket
• Properly coded and tuned PD control loop (the big scooter required some balancing skill on the part of the driver)
• Polished and professional looking electrical design (No vecro'ed Arduino Uno and rat's nest of jumper wires)
• Robust chassis that can take the inevitable repeated falls
• 30 minutes of run time, and integrated lipo battery charging
• Wireless control and telemetry

I thought long and hard about encoding the drive motors, but ultimately decided against it, as it would raise the cost and size of the build. I'm also looking into doing some extensive work with encoded motors in a much more ambitious future project. I began with the motors, as they would be the biggest determiners of the chassis footprint. I could have certainly gone smaller with my selection, but I wanted a gearmotor for the speed reduction and torque. A non-geared option struck me as being much harder to control and more prone to stalling when traversing obstacles (not that it's much of a concern either way). I ended up choosing the 50:1 micro geared motor from The Robot Marketplace, and picked up a set of matching 32 mm Pololu wheels to go with them. Now I had some dimensions to work with, so I CADed the motors and wheels and began sketching a chassis outline. With a good handle on the scale I was dealing with, I settled on 3d printed Nylon as my chassis material of choice. With the 3d print services from Shapeways,com, the Nylon (their "flexible and strong" material) was inexpensive and elastic enough to resist shattering. 3d printing also allowed me to design pretty much any shape and contour I liked (barring any thin geometry), which was a nice change from designing for manual mill or lathe work.

The upper half of the chassis was going to be designed around the PCB, so I switched gears and begin researching components. Optimization was of less priority than ease of integration and support documentation, so I focused on parts that were more well known. The venerable ATmega 328 processor was an easy choice (although I want to branch out more in the future). Wireless communication was also kept simple with an Xbee module header. The gyroscope and accelerometer were a little bit trickier. While I tried to find some hand-solderable surface mount components on DigiKey, it appears that the smartphone industry has hyper miniaturized the modern versions of these parts. Options which did not require reflow were generally highly specialized or highly expensive (or more likely both). So I retreated back to Sparkfun and settled on their 6 dof IMU, which kept everything  a lot simpler. This will be attached with a soldered header on the PCB, which actually helps save a little space. I also included an 5v to 3,3v I2C converter chip in the design (because the IMU ran on 3.3v), which I later determined was unnecessary. While I was ordering from Sparkfun, I selected two of their 1000mAh single cell batteries (3.7 volts per cell). In my testing of the motors, they appear to draw around .25 amps at 7.4 volts when changing direction after freewheeling, and can apparently reach around 1.6 at full stall. Given that the robot should only utilize a small fraction of the total torque, and that amperage is proportional to torque, I expect that it will easily exceed 30 minutes of run time. For driving the motors, I selected an integrated dual H-bridge chip with lots of support documentation from around the internet, the TB6612FNG, from Toshiba. While the control scheme seems a little input heavy, the operation of the chip is relatively simple and robust. It can handle 1.2 amps continuous and 3.2 peak, which is perfect. Last but not least was the charging support for the batteries. I found the MCP7384 line of dual cell charge controllers, which promises to do everything I need and much more. I've never spent much time looking at charge profiles for lithium polymer batteries before, but the datasheet for this was eye opening. I have never attempted to use a chip like this before, so there is a good chance my implementation may not work. Once all of the components were put into the schematic, I began the process of laying out the board:

The silkscreen rectangle at the bottom of the board illustrates the outline of there the IMU will sit. This board was also my first time integrating JST connectors, which I like a lot, The trick is to cut off the connector retaining nubs on the male plug if you ever plan on removing it. Finally, there was a lot of empty space going to waste underneath the Xbee, so I put some slightly over the top diodes for the motor controllers beneath there. Now that the board was done and sent to fabrication at OSHPark, I could finalize the mechanical side. I directly exported the Eagle board outline to a .dxf, which was opened in Solidworks and converted to a 2d sketch.This gave me the final dimensions needed to complete the chassis. 

I had a couple schools of thought on how to tackle the chassis design. In a strange departure from the Formula Hybrid car chassis and virtually every other electric vehicle I've built, weight really wasn't much of a concern here. I didn't need to design a nodal space frame or trussed structure for something this small. I played around with the idea of making a completely enclosed shell for a while, with a design similar to that used in plastic injection. While it would keep dirt and water out, it would make debugging more miserable and be more expensive to print. Given that the operating environment would primarily be on a desktop, an open design would work just fine. So I ultimately focused on making a structure that was easy to mount to, rigid, and capable of protecting components in case of a fall. An extruded I-beam shape was the natural result, with the batteries on one side of the web, and the PCB on the other. The extrusion was terminated with wheel hubs which continued down to support the motors at the bottom.

Mounting standoffs were printed in to the PCB's exact dimensions, and a slot was cut out of one of the chassis sizes to access the charging port. The motor compartment at the bottom was slotted for dubious cooling purposes, but otherwise dimensioned exactly to the gearmotor size for a tight fit. While keeping the center of mass farther from the axis of rotation makes balancing easier, this also impacted the overall size of the chassis. While it isn't visible in this picture, there are slight slots cut into the other size to help hold the batteries.

Here is the full assembly, complete with guesstimated wheels because Pololu didn't feel like giving more than 3 dimensions. I sent all the orders out, and waited 2-3 weeks for all the parts to arrive. The chassis came before the PCB, and the quality was fantastic. I would definitely use Shapeways again for prototypes. While RPI has commercial grade 3d printers and there are a smattering of hobby grade printers among the student body (soon to be joined by mine), it's hard to get parts printed in anything but ABS or PLA, and the quality is highly variable (in the case of the hobby printers). I got the blue polished option, which erases most of the interface lines between the plastic layers and leaves the part with a nice, almost sand blasted matte finish.

Nailed the fit

The PCB arrived shortly after, and was immediately soldered:

Shown here without the Xbee or IMU

The Arduino bootloader burned correctly the first time, and well as the power regulation and the battery inputs. When I went to solder the I2C voltage converter, though, I found the first problem. Apparently the chip footprint I used on the PCB was vastly larger than the actual chip size. After more research, the internet consensus seemed to be that a voltage converter wasn't necessary with this sensor, so I bridged the correct pins with fine strands of copper wire. Next up I tested the IMU sensor but not before accidentally connecting it backwards. Note to self: always indicate the orientation on the PCB. While I was eventually able to talk to the IMU over I2C, the acceleration outputs I was getting were highly inaccurate and jumping all over the place, I strongly suspect that the reversed connections damaged it the first time, so I have a new one being shipped now. With the IMU out of commission for the moment, I moved onto the motor controller. While the motors were originally intended to be bolted in from the front of the gearbox, I learned when they arrived that these holes were thru drilled instead of tapped. The only real way to mount these seems to be tiny screws or an external holder. Given the tightness of the fit already, I just used some JB weld around the bottom of the motor cans to mount them permanently I soldered the motor leads, loaded some sample code, and to my surprise:

It worked the first time. Now hopeful that I would not need a new board revision, I soldered the Xbee headers in, finishing the board. This is where the robot sits at the moment. Assuming the new IMU arrives this week, it should be optimistically possible to get a proof of concept working in the near future. Stay tuned for more updates coming in the next few days.

1/17/15

My miniature balancing robot is up and balancing! The new IMU sensor board implementation was easy and painless, and now I'm in the long (and probably never ending) of playing around with P, I, and D coefficients for the control loop. I've achieved balancing on carpets and temporary balance on hard surfaces so far. The small wheels, short distance between axis of rotation and center of mass, and poor vibration isolation of the IMU is making more optimized balance very difficult. Any proportional gain high enough to keep the bot upright on a hard surface is enough to generate high frequency oscillations that I can't easily address. Thus far, I've experimented with low-pass filtering the derivative output and filtering of the total output with little benefit. I've also attempted mapping the proportional gain exponentially to allow for higher gains at the extremes without jittering at low angles, but without much success. Next up, I may try optimizing the program to eliminate trig through a lookup table and certain floating point operations to speed it up. Problems aside, I am very pleased with how well the first iteration has worked!: