Miniature Balancing Robot: first test

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!:

New Project: Miniature Self-Stabilizing Robot

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.

Return of MechEtroller, revisions 1 and 2!

Way back in the warmer days of September, I posted the creation and almost immediate destruction  of my first brushed motor controller, MechEtroller. While the result was unsurprising given my limited experience in power electronics and PCB design, I'm won't let this project die with only one failure. I'm a huge advocate of learning by doing, and each MOSFET detonation is another valuable piece of education in how not to electronics! So the adventures of a MechE student attempting to build a robust, compact motor controller continues.

 Not long after the voltage regulator smoke cleared, I embarked on the revisions to solve the grounding issues that plagued the first version.

If only it happened this quickly in real life

No new features were added in this iteration, only an attempt to resolve the problems I identified last time and some rerouting. I also took the more intelligent approach of soldering this board in bite sized pieces, moving in the order of voltage regulation, logic control, and MOSFET control. Almost immediately, I identified a new problem. I had apparently foolishly assumed that just because both regulators were from the same company and had the same footprint, that the pin breakout would match. This meant that the 12 volt regulator was out of commission, so I bypassed it by jumping the pins with a small strand of copper. This was less catastrophic that it sounds, because the 5 volt regulator could handle up to 12 volts, and that was the exact voltage needed for the gate drivers. So, with the board now connected to a carefully dialed in variable power supply, I continued onto the ATmega 328 microcontroller and peripherals. The power LED was still giving the all clear, indicating that there were not immediate shorts, so I went ahead and burned the Arduino bootloader onto the chip through an ICSP pogo pin programmer...

...and it started right up, blinking the status LED just like it should. Neat! I took the opportunity to test the FTDI header breakout and confirmed that the test program uploaded successfully. With the simple stuff finally working, I moved onto the FETs and gate drivers. I send a 5 volt signal to the gate pin on the driver and measured the output. The multimeter read 0 volts. Back to the datasheet. Further investigation revealed that the XREF pin of the FAN3111 driver had been mistakenly tied to ground rather than logic voltage. Whoops. Another lesson to read the documentation carefully and not submit PCB designs at 2 in the morning. I spent a little more time chasing down another strange problem involving voltage leaking across a MOSFET, but after examination and input from some friends, concluded it was a result of not cleaning the flux from soldering. 

Excited by how much closer revision 1 had gotten me, I decided to get a little more ambitious. I was dissatisfied by the FETs I was using, now firmly convinced that their tiny size was just too limiting of thermal dissipation. The pitch spacing on the pins was also a concern, just inviting a tiny metal shaving or solder blob to lodge between and ruin a lot of work. I also wanted to include a current sensor, so it could begin making intelligent power control decisions. I settled on the IRLS3036 for the FETS, due to their relatively cheap cost, acceptable Vgs vs Rds relation, and hefty D2Pak footprint. This footprint also gives me the ability to easily upgrade to better components when the detonation danger level has dropped. I chose the ACS712 hall effect current sensor because it was the cheapest component that could measure up to 30 amps (a somewhat arbitrary design requirement that I decided on when starting the project).

The increased footprint of the FETs is pretty obvious right away. You can also make out the current sensor pads to the left of the battery voltage plated hole. Populating the board was uneventful with the exception of a tiny solder bridge from one of the gate drivers shorting to a ground via. Once fixed, power regulation and the microcontroller operated normally.

Now uglier and covered in sawdust

Before soldering the FETs, I ran through each of the gate drivers, checking to see that they outputted the 12 volts being supplied to the gate pin when driven logic high. Everything checked out, so I added in the MOSFETs. Immediately there was a problem. Everything powered on fine for about a second before the microcontroller began switching the outputs. Then, a brief current spike would occur and everything would reset and repeat the process. I tried to track the source of the shorting in numerous ways, before finally deciding to just allow the board to draw more current and seeing what got hot the fastest. The board sustained about three seconds on an electric drill battery before smoking in multiple areas, but it was enough time to see the issue. Somehow, certain MOSFETs were conducting even when their gate pins were low. The only way I could imaging that happening would be voltage spikes over 60 volts (impossible), or that the current was flowing source to drain. I checked the eagle schematic and confirmed my suspicions. In my eagerness to copy and paste the new FETs into the schematic, I had accidentally flipped the position of two of them. Another facepalm moment, but another opportunity to add more functionality in the next revision...