Arduino Helicopter

The Arduino is a very simple micro-controller to interface to, and i have managed to pick up a unit and have been having fun ever since. I have gotten the idea to build a micro-controller based CCPM helicopter such that it would be interfaced via a computer. This would allow features such as auto-leveling to take place, but not taking out the fun of being a helicopter model pilot. It should also then provide novice pilots or experienced programmers a chance to control a complex heli-model, and at the same time provide the fun that RC Heli flying provides.

Personally, this also combines my wish of being able to create a computer controlled vehicle and fly a helicopter at the same time. i do know that there are many projects out there that attempts this, but i would just like to take this opportunity to learn about the Arduino as well.

I’m open for being advised on such a project and comments on endevour. Please email me at copperblue >at< fastmail >dot< fm. NOTE: Apologies if the video quality is crappy, but i only have an iPhone.

First attempt at interfacing servos with arduino
Promising results in creating a simple servo sweeping Sketch (or program)

Simple interfacing with Accelerometer ADXL330
Have accelerometer produce visible output via Servos

Simple interface to try provide auto-leveling in theory to a helicopter frame
Introduced codes to include some amount of manual control on top of auto-leveling

In the last few days, i decided that the mini heli frame was good enough for simple prototyping but wasn’t good enough for the long run. So i went out and got myself some Heli parts from
After some discussion, i was convinced that if the micro-controller was going to control the heli, with the right program, the heli would also auto-level on its own and still fly like a 4 channel helicopter. It was at this point that i changed the frame to a CCPM Heli
Ported the code from a 4 Channel to a 6 Channel Heli

I started noticing servo problems such as different turn rates and different angular velocities.
Changed all swashplate servos to be of the same type.
Also started to look for Gyros for tail rotor control and battery voltage control

Having implemented the Tail rotor movements based on a dual Axis Gyro (IDG1215) proceeded to wonder why most implementation use both a gyro as well as an accelerometer
Found a few good references on differences between Gyros and Accelerometers
Investigated simulated lateral vibration on my existing implementation only to realize that the Ailerons on the heli is over responding to the vibration even in theory. Proceeded to think seriously about mixing the extra Gyro axis into the Ailerons as input.
Investigated on the Kalman Filter only to realize that i don’t understand the maths well enough. Used my own method of mixing and averaging the Gyro and accelerometer data instead.
Completely re-wrote the CCPM heli code to better accommodate all the recent changes and made the code more modular so that it can be changed more easily.
Discovered that properly measuring the angular velocity of the gyro can result in better vibration reaction while maintaining good tilt sensing.
Soldered the entire circuitry on a proto-shied for better connections

Used angular velocity to calculate the angle of the tail rotor and thus controlling the servo. Resulted in finer measurements of rotor control.
Did some more manual vibration test. Note that since i only have a 2 axis gyro, i didn’t have enough to mix the elevator with a gyro as well. However, this exclusion serves as a verification if gyro mixing is indeed important.


From some normal compensation to a PID library as suggested by Managed to get the servo movements better controlled in manual modeling but somehow still resulted in displacement errors. Managed to get in contact to someone in NUS (from this group to re-live my memory of Control Theory, and gave some insight on how to troubleshoot and tune the PIDs. Would have been promising but pity it can’t go any further than just some short question of advice. But still good info and a fruitful short discussion.

From the PID manual adjustments, now i at least know that i have a choice of PID or PD. Of course, if the 1deg error is acceptable, i would prefer to go for PID.

Also wrote a short graphical output Quartz Composer for plotting the serial data provided by the Arduino. However, it seems that the data rate isn’t smooth enough to get really smooth output for graph. but good thing is that i can now see how the PID affects the movement of the servos.

Also changed an important aspect whereby the original codes read the sensors and immediately offset the servos by the read amount. In the PID control method, the orientation of the helicopter is now feed to the PID and the PID automatically controls the servos for a level helicopter.

Am now looking for a cheap tripod stand to fix the helicopter to, so that a test flight can be done without the helicopter actually flying. Will resume all this once i return from Japan with a fresh mind.

Back from Japan! But have been extremely busy with work and haven’t even ordered the second Gyro for the elevator yet. Finally managed to make some progress on the tripod heli mount so that it would be safer to test the servo motion of the heli in a real operation situation. This is especially through in a One-Man-Operation. 😛

Maybe i can attach the rotor and apply PID on that before i make the order for the gyro… hum….

Finally managed to get some stuff done. Things really did slow down a fair bit since the last Razor 6DOF ( didn’t work out so well. and the IDG1215 ( Gyro was faulty. The unsoldering and testing apparently caused a fair bit of damage to the other components and i wasn’t very sure about the reliability of the chips on the original Arduino shield anymore. While purchasing a new shield would be cheap, the damage to the other parts would be costly.

But good things nonetheless, the vendor that i purchased the IMU and the Dual axis gyro from verified that my chips where faulty and replaced them. This took quite a while, but i suppose it was worth the wait. Both the IMU and the Gyro came back working well and i finally did a test run on the IMU and the values and the stability was finally in the acceptable range. The drift was indeed quite good being less than 1 degree for every 15 minutes.

Another good thing that came out of the wait was that i went to the USA, and i found a Circuit Writer and Sealer Pen from FRYs. The result is a beautifully clean Arduino Shield with circuits drawn on. On top of that, i choose NOT to solder the IMU on the ProtoShield? and used the Circuit Writer Ink to fill in the contacts between the board and the chip mount. This would hopefully make the connections work but at the same time, make the IMU easy to remove if i was to move on to a smaller Arduino board. I have some pictures of this work posted in the gallery.

Due to RSI, my right and left wrist are also hurting, which gave me time to re-think how to write the code for the IMU. From previous experimentations, i have already found out that i am going to use a Orientation Detection strategy followed by a PID control to the servo output. So i proceeded to think about how i could accurately obtain the orientation of the IMU.

A good thing about the 6DOF IMU is that it has everything that i need on it. This means no messy wiring. This made it easy for me to plot some graphs on the IMU’s varying output given the degree of tilt. This and some excel magic managed to provide me with a very close fit equation such that for a given value, i can immediately obtain the degree of tilt. I have attached my excel spreadsheet as an example of what i did. Having this equation also means less mess on the code. Using a simple 8 value averaging method to build a software LPF, coupled with the equation obtained, i could immediately obtain the orientation of the IMU from its given position.

The last thing i have to handle would be consideration for vibrations in the heli. In stability, the gyros in all directions should not be moving, and i used this as one of the criteria to know if the heli was rolling in any direction. Couple this with the accelerometer outputs, i am hoping that it is sufficient to pinpoint the orientation of the helicopter well. Approximately 1-2 degrees of Accelerometer output is also tolerated if varying from stability.

At this point, on desk test, the method and value seems accurate in response to orientation changes. The only errors are that if the accelerometer approaches 90 degrees in the X-Y direction, the equations and the electrical values can’t seem to match up and measure the 90 degrees change in orientation. i’m not too fussed up by this as if the helicopter is tilting that much, it would have probably crashed…. and i’m not making a system capable of inverted flight…. not yet anyway.

At this moment, i’m still doing some more test on this few new strategies, but things seems to be looking up.

Next up will be writing the output for the Tail rotor and mapping the orientation outputs into usable PID inputs.