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
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
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)
Motor (4x for quad copters)
Speed Controller (4x for quad copters)
Propellers (4x for quad copters)
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:
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:
Throttle (speed of motors / climb rate)
yaw (spin left/right)
pitch (tilt nose up/down)
roll (tilt left/right)
Switch 1 (used for flight mode selection)
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.
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
I used these 5amp Buck Converters for the each of the the remaining sub-systems (servos, left motor, right motor)
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:
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!
With a home cooked meal in me, a great night’s sleep, and having enjoyed time with my family (sister Kathy, brother in law Jeff, brother Chips, sister in law Lynn, niece Samantha, and nephew Michael) I was able to convince Jeff to do Section 11 with me. Without the weight of my luggage the riding was much more enjoyable.
Jeff did the first 12 miles with me
The bike handled a bit more spirited without all the weight
It was some of the best single track (roller coaster smooth) of the trip
With plenty of great views
I left Jeff with the truck at mile 12 and continued to finish the rest of the segment.
It was great riding. At one point I heard a thrashing sound…looked back and saw the tail of a bear running down the side of the mountain. This gave me a huge adrenaline boost and rode fast to make the distance between us as great as possible.
In these trees a bear lurks….
The trail finished up with a 781ft drop in 1.5 miles. Here’s a video of it:
My phone charge cables broke in Breck, and as such had limited juice left for pictures and tracking. Which was sad because going up to and over Searle and Kokomo Pass was fantastic. The ride down was a bit sketchy…but not as bad as coming off of 10-Mile.
I passed this neat 11 foot waterfall, and as I did Chrissy, a CT racer caught up with me. I had a 3 mile and 1/2 hour head start on her…and she had done in 2 days what I had done in 6. Her first day had been 90 miles.
We rode together for a bit. She stopped for lunch while I kept going for Tennessee Pass. She caught up with me at the top. She (thankfully) goated me into doing the next two miles of trail. I stopped to shuffle my water from my secondary store to my camel-pack. I thanked her for letting me ride with her and wished her good luck on her Time Trial.
With rain and cold keeping over the area, highway 24 was not the zooming downhill I was expecting. I limped into leadville and fiqured I had done enough. There was no way for me to get to BV in time to see my brother in the AM, so I called my sister and she picked me up.