Go Down

Topic: Arduino Helicopter Autopilot (Read 25010 times) previous topic - next topic


Another thing I should probably add at this point is that I will be making changes to the library for reading the PPM - It seems that there are enough occurrences of noise in the right time frame to trigger false positive signal identification, this only happens occasionally, but it is enough for it to throw off the values horrendously when it does happen, and at present that causes an offset on all the channels of a random amount.

I think I'll make it wait for a considerable number of frame periods within the right time scale before it allows any data into the code, at present this is done by counting 30x consecutive ok status reports and then allowing data through. However - somehow this still occasionally causes an odd erroneous positive identification...??

Watch out for an altered version of the library soon. I'll post here when it's working.

GPS on it's way very soon - I've been thinking about that one a lot.

Anyhow - back to the code.


Hello again,

I've just fixed some daft errors in the gyro and radio control code, it should now behave more sensibly.

The Z axis gyro uses a really ugly hack to make the kalman filter work without an angular input - but it works remarkably well. I'll look into getting a compass or using the heading from GPS - this will make the rotational readings much more accurate, and a heading would make position hold even more usable. I hope to make the new kalman code soon - it's going to be one big filter rather than one per axis - this will hopefully have more resistance to noise from other axes and should run faster too.

Alpha3 has been updated with these changes - anyone experiencing difficulties with RC or gyros should grab a new copy from my site.



Subscripted  :)

With respect to the PPM noise, maybe you can try to add a limit for a maximum amount an axis can change between PPM frames. Since it is unlikely for any axis to change say >25% in 20ms (unless you have super fast commands).

I donno, just thinking...




Welcome aboard zitron, I have a feeling that I'll be doing just that - also making it lock on more securely to the tracking of the framing period, and checking whether the number of pulses in any frame is consistent with the rest.

I'm also going to add a 100nF cap to gnd on the output of my RC receiver to aid the noise rejection.

All the best!



Feb 09, 2009, 04:50 pm Last Edit: Feb 09, 2009, 04:51 pm by edsimmons Reason: 1
Hello everyone!

I've made further progress with the helicopter code, and the processing sketch. Linear correction will be integrated into the next version release.

I now have video working under linux, the display is now a video overlay. Also the display has been re-arranged considerably to include an artificial horizon (which is very accurate) and some pretty little piecharts to illustrate the throttle and tail rotor pitch.


The Xbox 360 controller integration is going well - this will be included in the next release.

Thanks again to everyone who is testing the code for me - it's certainly speeding the process up.

Ed   :D


Hello Ed,

great project! PCM was mentioned a few times the thread and I'm wondering if there is code for Futaba's PCM?



The PCM is a standard across manufacturers, as the servo pulses are derived directly from the baseband PCM. All you need to do is locate the PCM pulses in your receiver and make a connection to it > pin 8 arduino.

Mem's library (servo decode) will have you up and running in no time.

I've had some major luck with new filtering for the gyros and accels, I can sense a rotation of less than a degree accurately and use the feedback to smooth movements. Also I've achieved a filter system to detect linear, tilt compensated accelerations without the gravity component. All of this means the helicopter should be flying very steadily very soon.

All the best!


The PCM is a standard across manufacturers, as the servo pulses are derived directly from the baseband PCM. All you need to do is locate the PCM pulses in your receiver and make a connection to it > pin 8 arduino.

Ed, arnewbie is referring to PCM (Pulse Code Modulation), not PPM (Pulse Position Modulation). PCM is an encoding method where the actual digital values are sent as a serial stream.  Unlike PPM it is not standardized and it needs a lot more work to decode.  


Does anyone of you know at what voltage level the ppm pulses are? Is it the same for all radio manufacturers?



My bad re: PPM vs. PCM - oops

Yeah - my receiver  has the pulses at about 4 volts, plenty enough for the microcontroller to go digital high. It should be roughly the supply voltage of the receiver in most cases.

Hope that helps,


Oops, my bad. I thought you were using the PPM stream coming from the buddy port.


Apr 17, 2009, 04:43 pm Last Edit: Apr 17, 2009, 04:44 pm by halley Reason: 1
It's been quiet on the thread a bit.  I just put in an order for a collective-pitch heli, and I expect it'll take some time for me to learn it (since I've not flown a CP before).

I was wondering if there's more room to minimize the size and weight here.  Either by making a "stickduino shield" or just going straight for an Atmel on a heli-oriented board.  And adding an air-pressure altimeter seems like a no-brainer, except helis are low-altitude and I'm not sure how accurate the devices are when near the ground.

It seems like the ultimate aim is to let a program dictate higher-level commands to the heli, like "lift off gently," "climb to 30 meters," "turn to heading 270," and maybe even patterns like "zoom forward and tilt up into a stall-left turn."  While flying manually is a great amusement for some, I can see this as being more task-oriented for serious applications, UAV style.

Adding a couple generic "accessory activation" pins would be interesting as well.  Nerf launchers, cargo winch drivers, cargo jettison, camera triggers, laser or light effects, ...


what do you use for wireless communication?


Hi everyone!

Sorry for the complete lack of news for a while. I've been working on GPS, camera and compass functions.

The 168 arduino is being pushed to the limits with the IMU and correction code alone, so some changes to the hardware have been made.

There will be a major release in the near future. There are new versions of the code for the 328p and Sanguino to allow for more than just IMU and correction functions.

I will post here when the release is made, there will also be a hardware release soon, once it's finalised.

Wireless serial is handled by a UM96 from sparkfun, although I'm tempted to move onto trying wifi using something like a fonera on the heli.

All the functionality of the system is being tailored towards minimal human input - GPS waypointing is improving etc. I will have to come up with a method of giving really simple commands 'live' but otherwise I think it's fulfilling most of the questions people have asked.

All the best!


hi my friends,
[ch305] need some idea about driving the dc motor with arduino board.

firstly [ch305] detect the tilt angle and I want the produce PWM signal to drive the motors with l293d, but my system likes a teeterboard for ex for negative tilt [ch305] drive the one motor and for positive tilt [ch305] drive the other one, just [ch305] want to stablize the platform thanks for your helps...

Go Up