General System Design

Some general decisions needed to be made about the overall design before trying to do much. Overall various websites seem to suggest buying robot kits, quality parts, and never trying to build your own servomotor controller. We'll be ignoring all that advice, especially the part about not being able to just use scrap, random parts, and glue to build a decent robot. All these sections will be covered in more detail later, with circuit diagrams and firmware.

Power:

A small DC-DC converter module is 5$ and can power the robot from either a Lead-Acid electric bike battery, LiPo batteries, or really anything. It's small and cheap and works great:

Before anyone rips into lead acid batteries, keep in mind that run-down lead-acid batteries are far too valuable to go to waste here. They are recycled and resold, so you trade your old ones+money for new ones. Lithium battery technology is also uncommon here beyond cellphones/laptops.

A 2200mAH, 11.1v LiPo battery should power it for 5-7 hours of constant use.

Movement:

By using a mix of servos modified for continuous rotation and unmodified servos, we get reasonable movement. It's not high power, but all runs off 5v, meaning all systems run off a unified 5v. They don't require a H-bridge or special circuit protection. Plastic gear servos are also 2$ each, metal gear ones are about 7$. I figured dual continuous rotation plastic gear ones are OK for movement:

 ...and a metal gear one for steering. I don't recognize the brand... as far as I can tell it's a mainland knockoff of a Hong Kong copy of a cheap servo. If your software has any hunting problems, it will grind back and forth, generating enough heat to melt and catch on fire.

As another added benefit, this design means basic movement only requires 2 servo control signals. Currently, movement works but needs improvement.

Chassis:

The alpha version will use carbon fiber bolted to more carbon fiber, because I randomly saw a piece lying around a store. Future revisions will use copper clad board because it's way cheaper, easier to work with, and reasonably strong and lightweight.

The two drive wheels that power the robot forward/reverse are aluminium model aircraft wheels, but any reasonably wheel-like object will do. If traction is bad, sand it and coat with silicone sealant.

The steering is a bit more complex. Basically, it's a servo that pokes through a hole in the chassis, and is stuck to a modified office chair wheel. This actually works surprisingly ok for a first try, although there's a lot of room for improvement here. Some sort of rack-pinion steering with 2 front wheels would probably be better.

I'll note here that I'm terrible at mechanical stuff, but I refuse to re-purpose a toy car because I won't get any better that way, and the design will be difficult to reproduce.

Servomotor controller:

Completely custom and hand soldered to perfboard. It's based on the common ATMega16 MCU, because I can buy that here and it's quite powerful, and adding a MAX232 makes serial communications trivial:

Right now the firmware works, but only handles 2 servomotor control lines. It could handle way more (and motors and sensors/lasers), but there's no point in coding that now because I'm not sure what I'll add or to what MCU pins.

Firmware is coded in assembly: What is power without control?

An Arduino would work at extra cost and you can probably copy paste something from somewhere... What is power or control without understanding?

I've provided the working firmware (Github) with commented code, but I'll devote a nice long post to explaining it section by section.

Processing:

I chose the beaglebone black because it runs ubuntu/debian headless well, and has more processing power than a raspberry pi. I felt this was worth the small difference in price.

The raspberry pi is a great machine and it would also work well for this application. If you already have one, go ahead and use it instead.

Control:

At first this will be just web2py accessing the device's serial port, so a few buttons on a web server control movement. It's OK for testing. The app is called CITEC because I was in the Bangkok hackerspace when I wrote the code this is based on. I also wrote code to control it using Minecraft+ standard mods, which also works, but it's not so great for testing so I'll demo that another day. On a 'practical' note, Dwarf fortress control might also be nice.

It's tethered by ethernet now, but wifi will come later. 4g is also an option, but we'll see how the budget goes.

Later, a USB game controller will be connected to a client application written in pygame, and the robot will be treated as a python remote object through Pyro. A server app will run on the beaglebone and use pyserial to interface with the servomotor controller.

Some audiovisual feedback will be added, probably with ffmpeg streaming server somehow. The current webcam works.

That's about it. Should be decent. Will make an OK telepresence bot if I raise the webcam and mount it on a servo actuated gimbal to avoid making yet another cat simulator.