Goals:

The uBristleBot was originally created for the original Square Inch Contest, but due to various reasons, wasn't completed by the deadline. Nevertheless, I saw the project through and was quite pleased with the result.

I wanted to make a feature-dense 1"x1" PCB, wondering just how much (or little) was needed to make a tiny, adorable robot.

Finally, as with many of my projects, I wanted to stretch the bounds of what I was possible, learning about and using the BLE protocol, using a different... way... to program, and how to write an Android App.

Design Choices:

BLE Chip: BLE121LR-A (Silicon Labs/BlueGiga)

This was the heart of the project, and a large draw as to what I wanted to try and learn. BlueGiga (aquired by Silicon Labs), created something called BGScript to program and configure their modules without needing to know about things like compilers, and interrupts. Since my knowledge with BLE was limited, I gave it a shot with the hope that using it would speed up development.

It was... ok.

Buck/Boost Converter: LM3668 (TI)

Ever since TI's WebBench came out, TI is the first place I go for power regulators. Simply pop in my input range and output range, decide what to optimize for, and DING, here's a list of schematics, BoMs, and layouts that would best fit your constraints.

I didn't worry too much about efficiency, since I wanted to keep part count and layout footprint to a minimum.

Motors: 304-103 (Precision Micro Drives)

Arguably the other heart of the project, I didn't want to use any motors I could find. I knew SMT motors existed, and I wanted to put them on the board. I've had too many experiences with small wires fraying or shorting that I wanted to keep that future problem at bay.

Finding a supplier for them though was not easy. I finally settled on PrecisionMicroDevices, primarily because along with a selection of motors, they also came with datasheets, and specs. They weren't exactly cheap, but for the peace of mind they (mostly) provided, they were worth the cost.

Motor PSU (2.7v): TPS727XX (TI)

Again, TI WebBench. Motors needed 2.7v at most.

LiPo Charger: MCP7383X (Maxim IC)

It worked with the Sparkfun breakout board and was already small, so I didn't see why it shouldn't work for me.

It did. Never had a single issue.

Passives:

0402's. QFNs. No leads. No through-hole parts. This was the challenge. It was hard, but I'm so glad it all worked out. Not sure it would have been possible with slightly larger components.


Lessons Learned:

It worked! The PCB took two revisions, I was able to use pogo pins to successfully create a separate programming board, LiPo charging was wonderful to have built into the board, and the App (mostly) worked.

However, there were a couple of things that could have been improved:

- Motor orientation. The uBristleBot had a tendancy to turn right much easier than left. It turns out that because the brushed motors were so small and weak, there was a noticable power reduction when the left motor would rotate against the internal brushes. One possible improvement would be to flip the left motor along the X axis, so that it spins in the same direction as the left, but still makes the bot turn the right direction.

- BLE is not the right protocol for this. It worked, but trying to drive several of the little ones at once was difficult since the connection would often have to retry transmit attempts. Maybe the chipsets in phones and/or modules available have improved, and maybe it's time for another go at it, but I'd take a good look at something else (low throughput, high resiliancy, maybe something in the Sub GHz bands?) before using BLE again.

- I missed lower-level peripheral control. The software used to control the BLE module was OK, but it felt too limiting at times. This could be because I was already used to programming embedded firmware, but I digress.

- PCB success! It's always a good sign when I successfully make and hand-assemble a dense PCB. Without fire.

- Android is... interesting. It's nice that there's effectively no barrier to entry, but iirc, there's so many different ways to do certain things, while other things need to be done in a very specific way. Would still do again.

(Possible) Future Improvements:

I'm not planning on reviving this project any time soon (unless maybe we do a Cubic Centimeter Competition? C^3 sounds enticing). However, I do like to float what-ifs every once in a while:

- Sub GHz. Maybe even RC receivers? I'd like to use something that 1) isn't fighting for nearly as much spectrum, and 2) has a much higher RF receive sensitivity to make dropouts much less common.
Of course, the problem with this then becomes how to control the thing...

- Moar motors! When the steering problem was discovered, one of the "solutions" was to simply add two more motors, effectively making the legs of an 'H'. It's not like space is a luxury or anything.

- Different motor config all together? Imagine something like a kiwi or holonomic drive. It hasn't been done, but that's not to say it's impossible...

- Proper software. The firmware ended up being trivial to "write" once I was familiar with it, but I missed having the lower-level peripheral control that allowed me to do more creative things. Because of the motor imbalance, I couldn't simply tell the robot to move in a direction. The best control that I could achive was tank style controls, which was annoying. I like to think that having much finer control over the FW would have helped.

- Add an IMU. Nothing says keep-it-simple like an IMU.
But really, adding am IMU would enable the use of closed-loop control, such that directionality would be considerably easier. There's just the issue of space...

Disclaimer:

This project is quite old (~3 yrs). Please don't expect any of the URLs to still work. Everything should be self-contained within the GitHub repos.