Robot projects and interesting tid-bits

I like showing my kids that we can build fun stuff with what we have on hand.  So while we had to purchase most of the items (everything except for the frame sadly), we could still build the frame out of items we had on hand, or easily obtainable from the local hardware store.

As crazy is it may sound, I just happened to have two carbon fiber rods, these were left over from my triathlon days (A carbon fiber aerobar set that I installed on my tri-bike came with both curved and straight bars.  I used the curved  bars on the bike and the straight ones ended up in my collection of robot/maker parts).   They were the right size for what I had in mind and would require no cutting.

PVC body with carbonfiber arms

PVC body with carbonfiber arms

The main fuselage then became a left over section of 1.5″ PVC tubing (painted black of course).  The arms were simply wedged through holes drilled in the fuselage secured with red vinyl tape.  The idea is that the pieces would be allowed to flex during a hard crash and there wouldn’t be any screws, or glue to cause unnecessary damage (bend, don’t break).

To mount the motors, we used pipe anchors.  They are placed over more tape, which holds nice and snug.

Motor mounts using pipe hangers and wood



Motor mounts using pipe hangers and wood

Word of caution! We received two sets of screws with our motors for mounting. DON’T USE THE LONG SCREWS unless you absolutely have to. There is no stop to prevent the screws from touching the coils inside the motor. So if you crank down on them, chances are you’re cranking right through the motor and you’ll have to replace it. That was an expensive lesson for us!

The motors are three wire (brushless motors which require their own speed controller) and to make swapping of components easier are fitted with bullet connectors.  To solder the connectors on we created a jig.  If you have to do more than one motor it’s worth the effort!


Drones (quad copters specifically) are pretty cool – and it turns out they are insanely easy to build and fairly easy to fly. Just do a quick look on youtube and you will find countless examples. Custom builds, like just about any hobby level electric remote control vehicle, require the following:

  • Radio Transmitter (your controller)
  • Radio Receiver (usually included with your controller)
  • Battery
  • Battery Charger
  • Motor (4x for quad copters)
  • Speed Controller (4x for quad copters)
  • Propellers (4x for quad copters)
  • Fuselage (frame/body)

Quad copters require one additional item that airplanes and gliders don’t specifically require

  • Autopilot : This is an intelligent device chalked full of sensors (typically an internal compass, tilt sensors, barometer, voltage sensors, and some have built in GPS or input dedicated for an external GPS)  The main purpose of the autopilot is to keep the quad copter level and mix the motor speeds based on the input from the controller.

The logic diagram for your typical quad copter looks like this:

Logic Diagram for quad copter


The quad copter could be flown with a 4 channel radio, but most autopilots have flight modes, and those modes require additional channels.  We choose to use a six channel transmitter/receiver.  The logic lines coming from the radio to the autopilot are:

  1. Throttle (speed of motors / climb rate)
  2. yaw (spin left/right)
  3. pitch (tilt nose up/down)
  4. roll (tilt left/right)
  5. Switch 1 (used for flight mode selection)
  6. Switch 2 (used for flight mode selection)

On our system the GPS is external, so we modeled it here as a logic input.  What’s important to really grasp is that the receiver is not controlling the motors and really neither is the autopilot.  The human pilot tells the transmitter, the transmitter tells the receiver, the receiver tells autopilot, the autopilot tells the speed controllers, and the speed controllers tell the motors.  To spell it out even more:

  • The human pilot wants the drone to fly forward, so he pushes the pitch and throttle sticks forward on the transmitter
  • The receiver relays that channel 1 and 3 have new settings to the autopilot
  • The autopilot knows that channel 3 is the pitch, and it has increased and consequently tells the front two speed controllers to spin the motors at a lower % than the rear motors until the angle of attack matches the desired pitch based on the pilots input
  • The autopilot know that channel 1 is the throttle, and it has increased and consequently tells all 4 motors to increase in speed – but will do so while monitoring and maintaining pitch – so even if the throttle is maxed out, because the pitch control is forward, the autopilot will not allow the front two motors to spin at full speed – at least not until the proper angle of attack is reached.

Meshing the tracking with robot controls was pretty straight forward. We used the database as a message queue, essentially we would update the database to indicate where the camera should be pointed based on image tracking. The position checking would read the new values from the database and correct the movement path. Made for fluid movement as the head tilt/pan was always in motion. For small movements it would move slowly for larger movements it would move faster, always in an acceleration arch that removed any jerkiness. We completed this several years ago, but never posted the video… this is Half Built after all :)

I finally finished my port of the E1 object tracking from OpenCV (CV2) / Python 2.7 to OpenCV / Python 2.6. I had to do this because Beagleboard doesn’t have a readily available Python 2.7 package (at least not with Angstrom), and I didn’t realize that OpenCV (CV2) required Python 2.7 until after I developed the original code on my laptop.

This was a bit of pain because there are not many examples. If your platform supports Python 2.7, use OpenCV CV2! There are a lot of examples and it’s all object oriented. It’s so much more enjoyable to work with.

I made a quick and dirty web GUI so that I can adjust the HSV values in real-time. It works pretty well.

Tracking objects by HSV colors.

I also built a quick-and-dirty web interface to control the servos. The big motivator here was I replaced the original side-to-side movement with a pan-tilt configuration.

Unfortunately when used together, the board gets reset…. Still trying to figure out why…

One of the take-a-ways from last year’s Maker Faire was that having multiple battery packs and no overall power switches were problematic and actually dangerous.

As we were setting up our booth my boy took to hooking the batteries up to the robot. Somehow there was a short, followed by sparks and smoke. The battery was toast and the boy ended up with a small burn on his finger. It was at that moment that I knew a formal power system would be built before any further “playing” with the robot.

My requirements were simple.

  • I wanted one source. I didn’t want one battery to run the servos and a different battery (or 2 as was the case) to run the motors.
  • It had to be regulated for running the computer and all peripherals.
  • Each sub system could be switched off
  • It needed one main power switch AND an emergency cut off

In researching for ideas I came across the idea of using step-down voltage regulators running in parallel off of a large battery bank. This makes it easy to add power capacity as needed. I would carve off 5v for BeagleBoard, 5-6v for the servos (and controller), and 7v to each motor.

I used these 3amp Buck Converters for the BeagleBoard
DC-DC 3A Buck Converter Adjustable Step-Down Power Supply Module LM2596S

I used these 5amp Buck Converters for the each of the the remaining sub-systems (servos, left motor, right motor)
DC-DC Step Down Adjustable Power Supply Module Converter DC 0.8V-24V 5A Max - DSN5000

For power switches I couldn’t resist lighted rocker switches (just for the bling) and of course the emergency switch had to be a mushroom button.

I had envisioned the switches running horizontal across the shoulders of the back of the robot, but the boy over-ruled me with a vertical design (which looks great and works better). We used a corrugated plastic sign trimmed down to the proper dimensions and spray painted white. additionally it was re-inforced with white duck-tape (so the painting ended up not being all that necessary).

On paper this all seemed great and was easy to layout in a crisp design:
E1 Component Diagram

The reality of the wiring was pretty messy
Back of Power Panel

Labels make for a polished look.
Adding Labels

And it works!
Main Power OnPower On and Regulated

I put together a fun script which isolates colors using HSV filtering and then finds the largest “blob”, which is presumably an object that should be tracked. It then finds the center of the “blob” draws a target indicator on it, along with the X,Y coordinates.

The result is surprising good object tracking with minimal code. I have yet to port it over to the BeagleBoard because I wrote the script taking advantage of OpenCV’s “CV2″ library which requires Python 2.7. Unfortunately Only 2.6 is available via packages for the BeagleBoard and I have had little success in getting 2.7 to cross-compile. So I’m in the middle of porting the code to use only the core “CV” functions.

Here is the results of the object tracking (running on my Windows laptop):

Ultimately the E1 will be controlled by a beagle board computer. To accomplish this I bought a Torobot 24-servo controller board, but had a really hard time getting an easy-to-use API to interface it. I tried pyUSB to no avail.

Finally I found that the Torobot USB board could be communicated with through an Arduino serial driver. Conveniently this is available through opkg:

opkg install kernel-module-cdc-acm

When the board is plugged in, it comes up as


From here you can simply echo commands to the device.

echo "#8P1500T100" > /dev/ttyACM0

This basically says “set servo 8 to position 1500 with speed 100″. Doesn’t get much simpler than that!