ARM based quadcopter

12232296268?profile=original

Here is a picture of my quadcopter in its current setup.

Hi,

I just signed up for an account on this page. Roberto has asked me to write a bit about my quadcopter project and perhaps help out with some of the ChibiOS related aspects of his MP32 project. I have written about this on DIYDrones in the past, but I will try and highlight some of the main aspects here.

The hardware setup is as follows:

  • Homemade aluminium frame consisting of u-channels and a CF base plate with bent wire hangers as landing gear
  • Alpha 370 size motors (HobbyPartz), bolted directly to the frame
  • Salvaged 6dof sensor board from a Walkera XUFO 5 (4?) OR homemade sensor board made of unsoldered HobbyKing HBK401(sp?) gyros and a Sparkfun 3-axis accelerometer
  • 2-axis magnetometer (I know, 3 axes would make my life a little easier)
  • Maxbotix sonar range finder for low-altitude hold
  • Locosys LS20031 GPS or DIYDrones Mediatek GPS
  • Modified ADNS2620 optical mouse sensor for low-altitude position-hold
  • 72Mhz RC gear (Futaba TX, generic RX)
  • XBee telemetry downlink
  • Oh, yes: taped on keychain-camera for onboard video ;-)

The electronics setup consists of an ETT STM32 stamp module (Futurlec) which runs custom flight software written in C. The board contains an ARM Cortex M3 microcontroller with 64K of RAM and 512K of flash rom. The board itself runs at 3.3V, but the inputs are 5V tolerant. Here is a picture of the chaotic electronics setup:

12232296661?profile=original

The flight software makes use of ChibiOS for setting up the hardware and implementing multithreaded control and navigation tasks. In particular, the current version runs 4 threads concurrently:

  • A high priority thread which runs the main loop generating the attitude estimates from gyro, accelerometer and magnetometer readings and generates the PID controls. The inner loop runs at ~400Hz - this is with a 2ms sleep cycle included (i.e. it could run at most @500Hz)
  • A lower priority task which reads and parses GPS data (NMEA for the Locosys GPS, binary for the Mediatek unit) and generates high level navigational commands for the main loop
  • A lower priority task which reads serial data from my custom-built mouse-sensor optical flow detector - this also generates navigational commands for the main loop
  • A lower priority task that reads pressure data from an I2C based BMP085 barometric pressure sensor

The attitude estimation is done using quaternions and a DCM-like algorithm for drift compensation (it is not exactly DCM  - there is no cosine matrix with the quaternion approach; the underlying idea for drift compensation is similar, however). Other things that happen concurrently (in a preemptive sense) with the 4 threads above, but which are not implemented as ChibiOS threads, are:

  • Gyros, accelerometers and magnetometer are sampled via the ARM's ADC circuitry. The readings are filled into a circular buffer via DMA (this is easy to set up with ChibiOS) and averaged over in the main loop as a crude low-pass filter
  • The RC receiver pulses are read via pin-change interrupts to measure the PWM pulse lengths (I am using a bit of a hack here by reading 6 channels with only 4 pins - this relies on the fact that the pulses of most RC receivers are spaced concurrently in time, so one can infer every other pulse, e.g. number 2,  by looking at the end of, e.g. pulse 1 and the beginning of pulse 3)
  • The sonar readings are also read as PWM via a pin-change interrupt.
  • The PWM outputs for the 4 motors are hardware-generated (the ARM core can generate up to 4 independent PWM outputs per timer) - this is also set up via ChibiOS.

The way in which the 3 navigational threads communicate with the main loop thread is rather crude at the moment by setting global variables for pitch and roll of the quad. Most of this code is more of proof-of-concept quality rather than trying to make a generic code framework. The code itself is developed under Linux using a gcc cross-compiler toolchain compiled from sources. I also wrote a very simple graphical ground station software in Perl/Tk which displays a 3D model of the quadcopter and some other debugging info. The telemetry link at this point is a downlink only, in order to change anything the quadcopter has to be plugged in and a new firmware has to be uploaded.

Here is a video of the quad flying, demonstrating the position-hold capability via the mouse optical-flow sensor:

 

Anyways, that's all for now, let me know if you have any thoughts/questions.

Marko

E-mail me when people leave their comments –

You need to be a member of FOXTEAM UAV CLAN to add comments!

Join FOXTEAM UAV CLAN

Comments

  • Invoking: ARM Sourcery Windows GNU Create Flash Image
    arm-none-eabi-objcopy -O ihex MP32XDuino.elf "MP32XDuino.hex"
    Finished building: MP32XDuino.hex

    Invoking: ARM Sourcery Windows GNU Create Listing
    arm-none-eabi-objdump -h -S MP32XDuino.elf >"MP32XDuino.lst"
    Finished building: MP32XDuino.lst

    Invoking: ARM Sourcery Windows GNU Print Size
    arm-none-eabi-size --format=berkeley MP32XDuino.elf
    text data bss dec hex filename
    155676 1712 5136 162524 27adc MP32XDuino.elf

     

    now it is time to write the test cases

    can i create a branch and let others do the testing :)

    robert

  • ok - it compiles - now it misses some usb declarations of vatriables.

    def. time to go to bed :)

  • ciao roberto,

    i am trying to compile with xduino.

    but i get compile issues - the compiler is unable to locate include files.

    strange - because it happens only for a few files ...

    it's too late - need to trake a few hours sleep :)

    xduino is pretty old - and does not match with the latest firmware lib from stm.

    but it is much cleaner when compared with leaf labs ..

    regards robert

  • Hi Robert,

    my idea is to port the library on chibios not on standard STM lib , because i prefer to use ChiBiOS all , and working on HAL for porting the code on different platform ... I spoke with Giovanni about this approach and he told me that STM library is not write soo good ...

    I used libmaple as starting point because it yet implemented the basic arduino functionality in wirish lib , so is possible to use other framework called xduino that use stm lib , are you check it ?

     

  • before i forget - huts of for getting the copter in the air!
  • hi - me again,

    i spend some time to separate the dfu functionality from the leaflabs bootloader.

    that is a big hack - and i stopped doing so because of the messy stuff.

     

    when working with a cortext device i'd like to build the sw around the cmsis library and drivers because this will be supplied by the silicon manufacturer.

    and those leaflabs guys just reinvented the wheel ... making it extremly hard to move forward when new cortex devices are introduced with slightly small changes ...

     

    maybe we should address the question to the redfox (how difficult it is to split the functionality on top of the mp32).

    regards

    robert

     

  • Hi Robert,

    I don't disagree - the code could be made a lot more modular and readable. Besides that, the mechanism by which the various threads 'communicate' with each other is certainly a little hackish.

    I am not yet that familiar with the MP32 hardware, so I cannot judge how hard it is to port.

    I am not quite sure I understand your MIT alumni remarks...

    Marko

  • hi marko de kleine berkenbusch,

    filemanagement is easy - just one file :O

    that might be split into smaller parts.

    how difficult will it be to move to the mp32?

    at least a start ... i am somewhat surprised about those mit alumni students from the mit.

    creating a mess is easy ...

    i should prob. take a picture of what is in front of me :)

    regards

    robert

  • Ok perfect for the other member of VR this is the link where you can found the source code :

    http://code.google.com/p/multipilot32/source/browse/#svn%2Fbranches...

    So when i start to try it i will a lot of questions for you :)

    Best

    Roberto

  • There are some minor changes compared to the version I sent to you a few weeks ago (mainly a motor arming mechanism). I plan to sync up the repo with my changes in the future, but I am not working on it very actively at the moment.
This reply was deleted.

Blog Topics by Tags

Monthly Archives