Category Archives: RC Heli


November Update

I guess I don’t have a complete blog entry to write on any one thing.. but there are several unrelated things that I feel like writing down. I recently joined Twitter, but I must suck at using it because none of these things ended up there.


Tragic. Introspective. Complicated. This isn’t really a place where I would feel it appropriate to go into detail, but it would be unjust to omit given that the other things here are significantly less important.


I don’t have a huge amount of flying time on it yet, but I’ve been enjoying the Blade mSR so far. I’ve been flying it mostly in smallish spaces, so I haven’t had the guts to really see how maneuverable it is- but I’m impressed with its stability and responsiveness so far. Also, either I’m a totally awesome pilot, or (more likely) it’s actually pretty easy to fly.


I haven’t had much time to work on the DSi lately. I’ve let Bushing borrow my hardware, and he’s been working on producing a small quantity of additional RAM tracing/injecting setups. This isn’t the kind of thing we can make many of (I estimate it takes about 6 hours to solder one together) but it’d be helpful for the community if more than one of these rigs existed in the world.


What time I have spent on DSi-related stuff has been on Temporal Hex Dump. It’s actually coming along okay- I took a bit of a development detour to improve it’s Mac OS support after I bought a MacBook Pro… but the next step is to add the part of it that is actually a hex dump. So far, it has the timeline navigation widget and a correlated list of memory transactions:

Temporal Hex Dump

Robot Odyssey

So, way back in April, I posted the first screenshots of Robot Odyssey on the Nintendo DS. This was I guess what I’d call a “binary port”. It runs the original Robot Odyssey binaries, via static binary translation, and with many modifications and UI enhancements to adapt the game for the DS console.

I never got around to posting pictures, but I actually did make significantly more progress on this project before getting distracted. I ended up implementing a pretty sophisticated system for patching the game and dynamically manipulating its world state, as well as “forking” additional copies of the running game very quickly for the purposes of having those forked-off copies render additional sprites. What is this good for? Well, I could have the game proper running on the DS’s top screen, while the bottom screen shows status icons for each robot, where the icons accurately depict the state of the robot’s bumpers and thrusters, and even what item the robot is holding at the time. I also had a mostly complete game load/save UI implemented, including a live preview that shows you where you saved while picking a game to load. My next step was going to be a UI for editing circuits inside your robots using the stylus.

Anyway, I know I’m being cruel by describing all these great features and not posting a video or a ROM image. Sorry. I promise I’ll make a video one of these days when I have a bit more time. As for a ROM image, right now the best I have is the source code for a tool which will generate a ROM given the original Robot Odyssey files. You can get the source with:

svn co

To compile it, you’ll need devkitARM and Python. You’ll also need to put your original Robot Odyssey files (the DOS version, not Apple!) in the “original” directory in the source tree. You can leave them in a zip file, or strewn about the directory in random places. The translator knows what files it needs, and it will find them by SHA-1 hash.

I give no guarantees as to the current state of the source tree- I haven’t worked on it in a few months, and I think I last left it in a state where loading and saving were partially but not usably done. If you aren’t a developer, the source tree isn’t likely to be useful to you yet.

Homework assignment: If anyone in the audience wants to see this Robot Odyssey DS port turn into a real homebrew ROM image that anyone can download without compiling it themselves, we need to have redistribution approval from the game’s current copyright holders. Problem is, I have no idea who that is. I did email Warren Robinett about this project a while back, but he couldn’t tell me who currently owned the copyright. Following the trail of acquisitions, I think it might be owned by Houghton Mifflin Harcourt. Yeah, the textbook company. I did email them about the Robot Odyssey copyright multiple times, but I never got a reply. So, what now?

One approach is always to release it then look for the return address on the cease & desist letter. But, in all seriousness, I would like to be able to release a legal port of a classic game which the current copyright holder clearly has no commercial interest in. It seems like there should be some way to do this.

Lipo Woes

I was hoping to dust off my Blade CX2 this afternoon and get some flying in. It’s been many months since I’ve flown, and that’s really a shame.

So I take my two 800 mA 2S packs out of the liposack in the garage, and they’re both pretty swollen. One of them is still at nearly full charge (about 3.5 volts per cell), the other has one cell at 0V and one at 2.5V. Looks like no flying today… and best of all, now I get to figure out how to dispose of these things.

This really seems like something that should be on Wikipedia, or at least Snopes. The lazywebs give me all sorts of conflicting information: some people claim you should discharge the cells with a resistor or light bulb then throw them in the trash, some people say you absolutely must not discharge damaged cells, and to put them in salt water instead.. but then it seems that the salt water is more of an urban legend, and really just turns out to be a rather ineffective way to discharge the cells. The salt water won’t get into the cells themselves unless you puncture the casing (which seems like a really bad idea) and it just eats away the battery’s terminals, making them impossible to discharge properly.

For now I’m following the approach that makes the most sense to me: put the cells outdoors in a fire-resistant bag, and discharge them to zero with a 100 ohm resistor across each cell. Supposedly they’ll be inert at zero volts, and I can take them to the recycling center or throw them in a dumpster or something.

Is there an obvious resource on Lipo disposal that Google is just failing to find? This really seems like a great example of the internet at its least helpful- dozens of “authoritative” answers out there, all different.

Anyway, I guess my CX2 is still out of commission for a little while. I just ordered some replacement batteries, and that seemed like as good an excuse as any to also buy a Blade mSR. One of my coworkers has been raving about his, and it seems like a good second heli to learn 🙂


R/C helicopter lights, Revision A.5

Atmel is going to personally revoke my electrical engineering license if they ever find out what’s in that yellow heat-shrink blob, but I now have a shiny new 5 gram version of my helicopter light kit =D

This version has all the same remote-control dimming and strobe capabilities of the heavier Revision A. The only practical drawback is that it isn’t quite as bright.


Hardware sketch: R/C helicopter light kit

As great as it is to finish a professional-looking hardware project with optimum component choices and full design documentation, I love the feeling of sketching in hardware (or as I’ve called it in the past, improvisational electrical engineering). Despite all the faults and rough edges in today’s development tools, we do live in a world now where it’s easy turn an idea into a working prototype with very little time and money.

Flying in the dark

Yesterday’s hardware sketch was a light system for my helicopter, an E-Flite Blade CX2. I wanted:

  • A way to fly at night. Real navigation lights would be nice, but for starters I just want the whole helicopter body to glow.
  • A way to take off and land safely. I’ve flown with only a body light before, and it’s really hard to land when you don’t know quite where the ground is.
  • A bright strobe, for extra visibility and attention.
  • A way to control the lights remotely, using the extra servo channel on the Blade CX2’s radio.

My finished prototype takes the form of a small circuit board that attaches under the canopy with velcro. That board holds the light control electronics, plus a bright white searchlight. It connects to the radio (for power and control) and to the internally-mounted body lights. The body lights are just bare LEDs attached to the inside of the tail and canopy with velcro. One white LED in the tail, one red and one yellow LED in the canopy.

Both sets of lights have full brightness control using a single knob on the BCX2’s transmitter. At the knob’s minimum setting, all lights are off. As you turn it up, first the body lights fade on. Next, the searchlight fades on. Just before hitting the maximum setting, all the lights are on at full brightness. If you turn the knob farther, to its maximum, the searchlight goes into strobe mode.

There are some rough edges, but it works remarkably well for such a simple design. The total weight is about 15 grams. It’s heavier than I’d like, but it doesn’t effect flight performance much. I’d still like some orientation lights mounted on the skids or the sides of the control PCB, but the body light is pretty easy to fly by. The searchlight is incredibly visible at maximum brightness. Even from an altitude of 50 feet or so, the light casts a bright spot on the ground.

Technical details

Skip this section unless you’re a huge dork 😉

The light controller uses an Atmel ATtiny85 microcontroller (kind of overkill) and a pair of NPN Darlington transistors to drive the LEDs. The microcontroller’s firmware is quite simple. An assembly-language loop times the pulses coming in from the radio, then the firmware decides on a corresponding lighting mode and sets up the AVR’s hardware PWM peripheral accordingly.

This hardware sketch was built with whatever parts I had handy. The LEDs are low-tech by today’s standards, the microcontroller was kind of overkill, and MOSFETs would have been better than the Darlington transistors. If I were building a second revision of this, I’d make a few improvements:

  • All surface-mount parts and a PCB, to decrease size and weight.
  • Use a single 1-watt Luxeon LED instead of an array of cheapo white LEDs.
  • To drive the Luxeon LED, I’ll probably want a simple buck converter.
  • Logarithmic LED brightness control, rather than linear.
  • Side-emitting navigation lights, mounted directly on the main PCB.
  • Optimize the firmware for low-power operation when the lights are off. Right now it costs about 8mA to run the AVR in its pulse-detecting loop at 8 MHz.
  • Start mass-producing and selling these 😉 It’s much better than any commercial light kit I’ve seen for the Blade CX2, and the parts are quite cheap.


I’ve been remiss in my duty as blogger extroardinaire. A new hobby, and I haven’t yet informed the world!

For the past couple months, I’ve been fascinated by R/C helicopters. As far as I can tell, this all started when I was at Fry’s drooling over the Lego Mindstorms in the toy aisle. The abundance of toy helicopters caught my eye. I didn’t buy one right then, but the thought was planted in my mind.

I have been exposed to a lot of aerospace-related enthusiasm over the years. My dad works in aerospace, Jen has been squeeing about anything that flies for as long as I’ve known her, and then there was that whole Space Grant thing I did in college… Anyway, despite all of that I never really took the time to fly anything myself.

Within a few days, I walked out with a $25 infrared microhelicopter: a cheap clone of the Silverlit Picoo Z. This is a really fun little toy, and it was an instant hit at work. After I flew mine around the office a bit, at least three coworkers ended up buying one. It’s a lot of fun for the price, but it’s frustrating if you’re expecting to have a reasonable amount of flight control. There are only two low-resolution channels, and it’s pretty unstable.

Following in footsteps of one of my coworkers, I graduated from the Microgear helicopter to an E-flite Blade CX2. This is a really great helicopter for the price. Stable, maneuverable, upgradable, and ready-to-fly with a good supply of spare parts for about $250. This was Paul’s birthday present to me 🙂

I’ve been having a lot of fun with this. It’s very easy to fly indoors, and with a little practice it’s flyable in low winds. I usually fly it in the
apartment’s courtyard, though it’s insanely fun to fly around the new buildings at work.

Things that interest me about model helicopters:

  • Aerobatics. I’m working on flying smoother and faster figure-eights on the BCX2, and I often run into the limits of the heli’s design when turning sharp corners. I’m curious what it’s like to fly a more capable heli like the Blade CP Pro or the Align T-Rex.
  • Airborne nerf gun!
  • A homebrew light kit for flying at night, perhaps with navigation lights plus a variable-power spotlight.
  • Aerial photography. This interests me a lot, actually. The OpenSourceQuadroCopter or a similar quad-rotor design seems to be a better bet for stability, but I’ve been experimenting to see what’s possible with the Blade CX2.
  • First Person View (FPV) flight. I’ve done some experiments with mounting a small wireless security camera on my Blade CX2, but some folks out there really know how to do this right. Some of those videos are very impressive.
  • Tune-ups. Crashes suck, but the mechanic in me loves tinkering with small electro-mechanical parts.

Besides the little security camera, I’ve been experimenting with taking video from the Blade CX2 using a Flip Video camera. These are little solid-state camcorders that can hold an hour of TV-quality video. I stripped down a Flip Video camera to just a bare PCB and lens (without LCD) to reduce weight and power consumption. The board is conformal-coated in Acrylic to add a little bit of protection from the elements, especially electrostatic discharge. The whole camera is about 25 grams, and it can be powered via an extra +5V input on the proprietary connector. I run it from one of the extra servo connectors on the BCX2’s 4-in-1 control unit. (If you try this yourself, it’s important to use the same +5V input. The battery power input is designed for 3V only, and the +5V input on the USB port will put the camera into downloading mode.)

The only problem this leaves is how to mount the camera to the helicopter. My BCX2’s lower rotor is quite steady, but the upper rotor is a bit wobbly. The vibration is significantly less if you’ve just replaced both the inner and outer shafts, but even after a lot of mechanical tweaking I couldn’t get my heli running smoothly enough that a camera velcro’ed to the body would give me a clear picture. I ran experiments with a few different mounting systems. The one that seemed to perform the best was based on a rubber-band suspension (to isolate the camera from high-frequency vibration) plus a bit of foam to damp out oscillations in the rubber bands. I also coiled the camera’s power cord, to minimize the amount of vibration it would transmit. The prototype looks kind of silly, but it’s a significant improvement over mounting the camera directly.

The heli’s CG is quite good in this configuration. The servos and the battery holder are reversed, so the camera on the “front” of the heli is actually where the tail would normally mount. Its weight is counterbalanced by the 4-in-1 control unit on the opposite side. The heli has less rotational inertia than it would normally, but I compensate for that by decreasing the gyro gain. It doesn’t fly as well as a stock BCX2 flies, but a stable hover is still possible. Flight times are also quite good. I can get about 8 minutes of video+flight on a charge. It weighs nearly the same as the stock BCX2 body pieces, so most of the overhead is probably electrical. Without the LCD, the camera draws around 350 mA while recording.

None of the videos I’ve recorded so far are terribly impressive. This is the unedited footage from one test run. Individual frames from the image are quite clear, but the residual low-frequency vibration is causing some really strange wobbling in the picture. I saw this behaviour for the first time when I tested the camera outdoors.

(The video on YouTube, in case your RSS aggregator strips out <embed>s.)