Updates on the Software - Waging war with interrupt priorities

Much has been done now and after a few long days I have finally got interrupt driven measurements from the sensors to work. Because I want the abstract level of the code to be high there was a lot to fix to get it to work and be "invisible" to the user, but now it works very well.

This is how it is done/implemented:

1. First the sensor sends out an "Data Ready" signal, however this is not on the I2C-bus (MPU6050 or HMC5883L, the barometer does not have an data ready pin).
2. The interrupt is generated and an Binary Semaphore (in FreeRTOS) is set so the task that reads can be unblocked.
3. The task will try to take the I2C-bus by checking the I2C-mutex, if the bus is occupied it will wait, else it will tell the I2C to get the data requested using interrupt driven transfers. When it is done the I2C will execute an Callback-function that will set the I2C-mutex as free again and tell the OS to start using the data.
4. Now the task will wait for the next "Data Ready" interrupt.
   

This guarantees that there will be no collisions on the buss and it is easy to add mote functionality depending on where you want things to happen. 

    The biggest problem when trying to do this was when FreeRTOS always got stuck on a function called "vListInsert", this was tracked down to be a problem in the priority of my interrupts. The interrupts must have a lower logical interrupt priority (higher numerical value) than a define in FreeRTOS, else the thread safe API functions could not be called safely. The USB was given a priority of 5 and the I2C was given a priority of 6 (higher value is lower priority), but then the I2C stopped working. I then found out that the ISR (Interrupt Service Routine) of the USB was taking to long to execute and therefore "breaking" I2C packages when preempting it, this was as simple as swapping their priority. Now all other interrupts must have a priority of 7 - 15 for not to interfere with the I2C and the USB and FreeRTOS has 0-4.

Test print of a Quadrotor

I've been playing around a little with the idea of printing a Quadrotor frame. So I was browsing around on Thingiverse when I stumbled upon this design: http://www.thingiverse.com/thing:34552. I used that as a basis for my own design but changed a few things. I made the spacer from the arms a separate part, this because I didn't have long enough screws so I embedded a M3 spacer inside it so I could screw it from both sides. Also I changed so it could take the motor I have been thinking of using, made it higher to fit a battery in between the plates and added small feet.

And some pictures!

Concept design 

Test with one boom

Test with one boom 

Zoomed on the split spacer with an M3 hex-spacer inside

My 3D printer is alive!

The last couple of weeks I've been building a 3D printer in order to build cases and frames for my PCB. It's coming along really nicely so soon I can start printing frames.

It's an MendelMax 1.5 printer with an QU-BD extruder. Some modifications have been made to the extruder because the original tensioner for the filament was really bad, it had no margin for error in the filament. We made it spring loaded plus a bearing to make it slide better and with less resistance.

Entire assembly 

Where the bearing pushes on the filament

Video when printing a few parts at 50-70mm/s

Preliminary design for a Config software

In order to make it easier to configure the system a simple configuration software has been designed. This is the first preliminary design so it will be subjected to change as the project goes on.

It has functionality to:

• Talk with the bootloader for firmware download
• Set gains and limits in the regulator (this is going to change a lot, some changes has already been made to the regulator)
• Calibrate the input signals to their specific function (Analog, On/Off, 3-state)
• Set the mixing of control signals for different frames, select mixers from a few different presets and the PPM update frequency

Some pictures:

More info: Hardware/Software

Here are some specifications for the hardware and software. This is valid for rev. 2.2. Later revisions  might have small changes.

HW Specs:

• ARM Cortex-M4F STM32F405 CPU w/ FPU and DSP @ 168MHz
• MPU-6050 accelerometer/gyroscope
• HMC5883L magnetometer
• MS5611-01BA01 pressure sensor
• 8 PWM outputs (50/400Hz)
• 4 expansion connectors (3 UARTs & 1 CAN)
• 6 slot RC input connector with support for (C)PPM up to 8 channels in and signal strength

SW Specs:

• Runs FreeRTOS (with FPU support) with an Hardware Abstraction Layer on top for fast application development
• USB Bootloader - no need for an external programmer!
• Quaternion based Uncented/Extended Kalman Filter provides attitude and position estimation
• "Control signal to Motor"-mixing for different types of frames
• Flight control: Rate mode, Attitude mode and more to come as deveopment proceedes

USB serial driver working!

Finally I got the USB serial driver to work! After a whole lot of testing on the STM32F4-Discovery I managed to port the code to my application. Now this can be used to communicate with the chip and work as a down-link for the bootloader.

First test one Discovery-board:

Final result (Swedish):

First post: Some old info about box and PCB soldering

As this is the first post some old information is added to start of with. More info on recent updates will come soon.

A friend of mine used his 3D printer to test making a case for the board, it turned out really well and will help protect the board.

First version of a box for the PCB

Here are some pictures of the soldering of a board. However this is an old version of the board. The new version has a few updates in order to make it easier to solder and so a new case could be used (some components were to close to the edge of the board).

 Bottom

Top