Quadrocopter - asking for practical solutions...

28 Jul 2010 . Edited: 07 Apr 2011


I am working in small R&D based company making specialised microlithography equipment.

As hobby trying to make my completely own quadrocopter full-featured project.

Quite new to embedded devices.

My targets:

1. Substituting the bunch of old microelectronics and complicated stepper controller by one (preferably) modern uC board, completely under our control.

Needed: MicroStepping motor control in closed loop with QEI linear encoder, communication with PC,

2. Quadrocopter - using Chrobotics AHRS and mbed board want to make full controller.


a) reading the signal from RC receiver

b) reading attitude from AHRS, i future also GPS position,

c) processing by mbed or similar device (have also FEZ domino and mini)

d) writing to motor controllers (servo standard signal).

I have already found here a lot of information, but would be very grateful for some indication (links?)

- communication with PC easiest way from our own application written in Borland C++

- Reading signal (either servo PWM outputs or whole PPM frames) from RC transmitter

Have a look at Paparazzi their autopilot:


Should not be hard to use some of the software - and it is a much beter starting point that the arduino code from an aerospace perspective.


29 Jul 2010

Many thanks - I'll definitely check it!


01 Aug 2010

I've look there, downloaded source and will look for interesting details to use.

But, what I found is quite in contradiction to mbed philosophy ;)  - this is a piece of really hard, very serious development work, which may  be the basis for serious professional projects, incl. military.

My aim, however is quite different - I want to learn as much as I can myself (even though 47 old student sounds a little bit funny) and create a project to highest possible extend myself.

So, I want to found out some necessary pieces (like RC signal decoding) in Paparazzi work and do AMAP myself - in fact I highly prefer to write my own soft than to break through others work...

I hope, that I may expect some support from your side - as I see this forum as probably most responsive uC forum I have found, I hope that my often stupid questions will sometime get answered :)



01 Aug 2010

Hi Pawel,

Someone was asking about reading from an R/C receiver before, and in that thread I remembered I posted an example of how you might write a PwmIn class i.e. something that gives you the period and pulsewidth of an incoming signal. See:

Not sure if this is useful, but might help out towards your excellent goal!


03 Aug 2010

Many thanks !

I would like to read whole PPM frame (all PWM signals in one sequence) as it comes into just one pin, but your code is really helpful, especially to get some of the interrupts philosophy (new to me so far...). I think to start with reading single PWMs and after having some experience, modify the function to read whole frame...

24 Aug 2010

Parrot's code is open source too:


27 Aug 2010


Have a look at AeroQuad, ArduCopter, ArduPilot / DIYDrones, and of course the multirotor helicopter forum in www.rcgroups.com. Everything you need can be found in those sources.

01 Sep 2010

Many thanks !  I've looked at some of above sites and still trying to find the simplest starting approach instead of complex, multiplatform and very dificult to read programs...

I've bought chrobotics sensor board (AHRS style) which takes almost all sensors processing out of my head, and I want to use it "as is" at least for start.

So now my tasks for the very beginning are:

1. Read the RC receiver signals,

2. Read the orientation from Chrobotics AHRS,

3. Combine 1+2 into  set of 4 engines driving PWM signals.

The result shall be stable quadrocopter easy to operate by everybody..

Then I want to add GPS and barometric sensor for altitude and make a drone to serve as my summerhouse guard adding some powerful LEDs and loudspeaker as main determent tools ;)

But, I realise that it is not a short way, even though I hope to receive even more shortcuts here...

01 Sep 2010

I-ve had a look at that board in the past. I hope it outputs the info at a sufficient rate to be usable. For a multikopter you do want sensor data at a rate of 500Hz or so to allow drving the motors at 300-500Hz. Downside of such a fully integrated solution for the sensors might be less ability to control type and level of sensor filtering and adjustment.

With respect to your Rcvr integration, and motor output, you might still want to look at e.g. the AaroQuad/ArduCopter who have a nice little ATMega based 8ch to PPM converter (avoids the need for surgery on the receiver with FM receivers which generally do have PPM on board, and solves the problem of integrating some of the 2.4GHz systems, some of which do not have PPM on board), and also in the AeroQuad forum (and in one or two threads in RcGroups.com under multirotor helis) at the discussion about using a simplified serial interface for control of the motors, as is also strongly supported by the ArmOKopter group in Germany. That serial interface could take different forms:

-- modifying commercial ESCs: for a number of them this only requires reflashing with modified firmware (see the ArmOKopter site),

- creating a simple serial to 1, 4 or 8 channel PPM converter and using simple commercial PPM ESCs which can accept higher frame rates (up to 450Hz). Quite a number of newer low cost ESCs can accept this. A 2nd version of this same interface could also be used for driving e.g. camera mount and control servos. To allow maximum easy of integration even into existing multikopters, I-ll most likely program this to listen to both the simple serial interface and the I2C interface and accept the first which sends valid data as the one is should listen to for the remainder of the session. This way people can also use it on multikopters with I2C motor control to switch to unconverted ESCs.

The simplified serial interface that I-m proposing would slightly reduce your throttle range to allow us use of the top 16 values to be used as sync bytes / addresses, would run at 115200kb and would use different message formats depending upon the sensors or ESCs attached. The message formats would be optimized for speed / bandwidth. It would allow telemetry data to be returned. Besides having 8 data and 8 setup/control addresses, each device / channel on an intermediate device would have a subnumber which initially will range from 1 to 8 (0 being reserved for a call to all devices on the same address), but this could be expanded to allow for more subdevices or channels although even with only 8 subnumbers you would in theory be able to allow 64 devices to be attached to the same serial bus (even if this might need some buffering / pull up/down resistors on the bus to keep the singal good and not overload any ports).

I2C modification of ESCs has been used quite a lot in multikopters but has two serious drawbacks:

- very few I2C ESCs are available, and conversion of commercial ESCs requires quite significant microsurgery and reprogramming with failure rates of the conversion ranging from 1 to 50%.

- a failing device can block the I2C bus and if that happens when flying, all ESCs will stop and the landing tends to be "a bit too fast" so to speak

Both the above downsides could be avoided with use of the simple serial interface while still reducing the need for the main processor to waste lots of time and pins generating separate PPM output signals at high frame rates.

I2C would remain of use for e.g. non-critical sensors or devices of which the chance of failure / blocking of the bus is extremely remote. This approach to developing serial "black boxes" of which multiple can use the same bus, of course would fit very well with the mbed and central processor with its 2 I2C, 3 (4) serial and 2 SPI interfaces (although of course 2 of the I2C and serial interfaces overlap and 1 serial and 1 SPI interface partially overlap. But with 1 SPI, 1 I2C and 2 serial ports availablefor interfacing over serial channels, you still have quite a lot of capability for serial channels. E.g. 1 serial mainly output channel for ESCs and servos, 1 serial mainly input channel for receiver, GPS and sensor data, I2C for additional sensors, SPI for the occassional sensor which requires that and the ability to use the mbed as programmer for other devices, while of course the USB remains the interface to the "groundstation".

Regarding the difficult to read source code, the UAVX uses more or less standard GNU C with only some hardware (PIC processor) based extensions. The Arduino's of course use the more extensive language simplifications offered by the Arduino libraries. Those are not identical to the ones offered by the mbed environment. E.g. I don't find it all that difficult to convert code for an Arduino to the mbed environment. Most of the algorithms have little to do with the hardware and if you understand what the hardware relarted code is suppoed to do you can generally reuse the algorithms. Of course you can choose to use the CooCox environment (essentially the Code Sourcery GNU C++ toolchain + Ecliplse + CMSIS libraries for the LPC1768 hardware, or cook your own environment based on e.g. Yagarto + Eclipse + CMSIS). That does offer the advantage of still using a standard hardware library but be able to develop offline or with others using SVN or GIT.

You've probably caught on to the fact that I-ve also started developing a flight controler using the mbed taking the UAVX code --and I have no PIC experience but can understand the quite well after a bit of reading-- as a starting point but inserting a lot of my own ideas and wishes straight off which does mean a very massive rewrite straight off .... ;=))

01 Sep 2010 . Edited: 01 Sep 2010


Many thanks for tons of usefull knowledge - I'll have to find time to look through it on details !

As an indication - chrobotics newer sensor board deliver signal either at fixed 400Hz rate or on demand, so I assume it is sufficient for the task.

Your proposal of simple serial sounds very interesting, so does PPM converter idea - I will study both and most likely implement in my solution.

Now, I am about to look at ArmOKopter and start working...


It's in German :(   Anyway, I'll check all english part and try to find most interesting parts - maybe you could provide links to most important threads ?

01 Sep 2010

If you go to www.rcgroups.com in the Multirotor helicopters forum you will find a sticky at the top which has a tremendous ammount of links to multikopter related info.

Re the german parts of the ArmOKopter forum, Google can help translate. And as you've find there are quite some English parts. If there are parts that seem particularly useful but the Google translation doesn't help, just let me know and I-ll do some rough translation (within reason).

01 Sep 2010

ok, thanks!

Now, I need some time to organise everything inside my soul ;)

02 Sep 2010

Your soul, and concience, should be always be clean. Just organise it in your mind ;=))

Just did one of the quickest "does this board read this sensor tests" ever with an IR distance sensor. Really straightforward connectiona and analogpin in. Of coarse working out the curve for exact calculation of distance will take a bit. Have you seen the "let's play ping pong with a multikopter" video on the ArduCopter page ?

02 Sep 2010

But this board (CHR-6dm) does not have IR sensor on board... Just set of accels, gyros and magnetometer. I am just checking everythink before using their interface program to check the board sensors reading..

08 Apr 2011

Reading a lot in the meantime, gaining some practical experience with one of leading solution - mikrokopter.de (finally "Gone with the wind" - as you can read in mikrokopter.us forum)and looking at Arducopter project, I decided to go with own solution = mbed + chr6dm. After reading some topics here ("software interrupts" and some more about PPM, PWM reading + IMU reading and analysing) I would like to ask for some suggestions, how to best proceed with following:

  • 1 reading up to 6 RC inputs in PWM mode (0,5 - 1,5 ms pulse with 20ms period, every signal on separate pin and usually, but not always with different timing),
  • 2 reading serial data stream (40-60 bytes packets with 100-300Hz frequency, 115kbauds speed),
  • 3 recalculating both to have desired powers of 4, 6 (now) or up to 12 (in some future) speed controllers (ESC)
  • 4 sending that to - again PWM outputs.

For the beginning (up to 6 PWM controllers) it looks like mbed is sufficient to take and send all signal in parallel without the need for additional hardware (like suggested by Artur above). For the beginning I want to make it flying within as simple hardware setup as possible. Now, for software - as I don't feel comfortable with interrupt right now and hate to dig into bigger libraries (RTOS et c.), I would prefer to organise all soft within one main loop with min 100Hz repetition. Do you think it is possible ? (at least partially...) If not please suggest, how to organise interrupts to avoid problems with relatively long readings of serial packets (2) and often reading of (1). (3) and (4) will obviously go to main loop. What I mostly worry about are mistakes of reading 1 or 2 due to mutual interrupting and I hope experts here simply know how to arrange it best way...

08 Apr 2011

I was trying to interface the chr6dm to the mbed, but the chr6dm got damaged probably from ESD. Caleb from ch robotics is awesome, he offered to fix it for free or I could pay the difference and upgrade to the new UM6. I got the UM6 it comes in a plastic case, and most impressive is that it is quaternion based which removes the singularity at 90 degrees. I've written the interface between the UM6 and the mbed, but it needs some work before it's publishable.

I'm working on an autonomous parafoil with the mbed. I'm using two DNT900 1 watt RF modems to communicate between a PC running LabView and the mbed. I'm going to do the PID controller in LabView and just send the winch servo commands to the mbed.

23 Dec 2011

Hi. How did you get the CHR6DM to communicate with the MBED? I understand it has UART, does that mean you can use regular serial communication with it? Also does the CHR6DM give you actual angles for each axis? Thanks for your help.