Here is a picture of my quadcopter in its current setup.
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:
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:
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:
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:
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.
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 :)
ok - it compiles - now it misses some usb declarations of vatriables.
def. time to go to bed :)
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 ..
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 ?
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).
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...
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 :)
Ok perfect for the other member of VR this is the link where you can found the source code :
So when i start to try it i will a lot of questions for you :)
© 2023 Created by Roberto Navoni. Powered by
You need to be a member of FOXTEAM UAV CLAN to add comments!
Join FOXTEAM UAV CLAN