Control board and firmware architecture

First thing first, all my boards and all of my code are for Microchip PIC 16-bit microprocessors. Sorry, Atmel AVR and Arduino fans, you would not find much of interest here, except, maybe, something related to sensors or PID controller L

Why PIC? I simply got used to it – I started working on the flight controller idea about 10 years ago and somebody in my flight club recommended PIC, so I started with PIC MCUs, got quite comfortable with them and they are fully capable of addressing all of my needs. If you are interested in some of my previous iterations, check the Project History page.

I definitely do not imply that one architecture is better than the other – if you would like to see a great comparison of Microchip PIC and Atmel AVR MCUs, check the link http://www.eevblog.com/2010/02/22/eevblog-63-microchip-pic-vs-atmel-avr/ and if you have a strong preference and would like to get into arguments, please argue with the author of that post. I am impartial J

Now that we are over the MCU hurdle, let’s talk about the code. Code is developed using Microchip’s MPLab-X IDE and XC16 compiler – both products are freely available from www.microchip.com (the free version of XC16 compiler does not perform optimization of code beyond the basics). I work on Windows platform, so if you are a MAC or LINUX user (MPLab-X and XC16 available for all platforms) and would like to compile my code on your machine you may have to replace all “\” with “/” in all of the #include directives and in directory references in the Project Properties in MPLab-X.

Now, about the code itself – ALL of my communication libraries (UART, I2C, SPI, PWM for motor control, RC Receiver communication, etc.) are interrupt-based! There is no time lost on waiting in my control loop as all the communication with sensors and other peripheral devices happens in parallel with the computations in the Interrupt routines (ICRs). This leaves me a lot of time for calculations, so I use floating-point arithmetic for all calculations without the need to resort to time saving tricks like doing calculations using fixed-point or Q.15 or Q.31 arithmetic with subsequent normalization. I can also freely use trigonometric function and matrix operations without any concern to how much time they use! 

Time savings produced by implementing asynchronous IO are so high that without any special optimization my control loop on the Version 2 board (previous generation using 40 MHz PIC24HJ MCU), which implements self-stabilization, course lock, battery management, etc., runs at 400 Hz. I actually had to insert additional wait into the control loop to bring it down to 100 Hz because my data logger (the “black box” in aviation terminology) could not keep up with the data stream!

So, even if you are not an enthusiast of flight and do not care about the multicopters, you still may find some interesting code snippets in this blog. For example, my I2C library allows for multiple slave devices on the same bus; respective control programs may acquire bus for exclusive use in the asynchronous mode by implementing interrupt callbacks. More about this in the I2C section later.

Another interesting feature of the Version 3 design is that the board uses two MPU-6050 6-DOF (3-axis gyro and 3-axis accelerometer) sensors. Sensors are oriented at 45 degrees to each other – +/- 22.5 degree in reference to the X-axis of the board. Thus, the Roll and Pitch calculations are based upon fusion of four measurements from each sensor; Yaw and vertical acceleration are calculated based upon the average of the measurements from both sensors. Sensors are physically located roughly symmetrically around the center of the board, but quite apart from each other. My expectations are that this design will reduce sensitivity of attitude calculations to vibration, which is a serious issue for multi- and helicopters. However, whether these expectations will materialize or I just wasted a perfectly usable second sensor – we will see when we get there.

Now it is probably the right time to have a look at the board, which we will do in the next post.