I’m currently using two (or more…) computers onboard my drones, one computer is in charge of stabilisation and control of the vehicle (g.n.C) while the other handles the guidance and navigation part (G.N.c), in this post I’ll define and will give a short explanation of my flight stack.
G.N.C. is is a branch of engineering dealing with the design of systems to control the movement of vehicles, especially, automobiles, ships, aircraft, and spacecraft. At this moment my main focus is aircraft, and in more particular sense, multirotors. In many cases these functions can be performed by trained humans, pilots… however, because of the speed and complexity of flight dynamics of multirotors, human reaction time is too slow to control this movement, or even impossible to control 4 actuators in order to make a quadcopter fly. Therefore, systems are used for such control. Even in cases where humans can perform these functions, it is often the case that GNC systems provide benefits such as alleviating operator work load, smoothing turbulence, energy savings, etc. In addition, sophisticated applications of GNC enable automatic or remote control.
To handle the stabilisation and control of the vehicle I use off-the-shelf flight controllers, and I use several of them Multiwii (several models), APM, PX4, Pixhawk, CC3D among others. The ones I tend to use harder are the Multiwii boards and the Pixhawk.
You might be asking yourself which multiwii board I use?? and the answer is simple, whichever. I wrote a python module that talks the multiwii serial protocol (pyMultiwii) and thats how I communicate with that flight controller. So, any flight controller board that uses the multiwii firmware or that it equipped with MSP (multiwii serial protocol) is going to work with my module. I have tested my module on the next multiwii boards:
- MultiWii AOI v1 and v2
- MultiWii lite v1
- MultiWii SE v2
- MultiWii 328p
- Afro Naze32
- Naze32 (complete)
The new trend among flight controllers is to use 32bit microprocessors (usually at 72mhz…), and the new MultiWii’s are 32bit versions with similar sensors as the old ones, of course the firmware is different, and the vehicle attitude control is much more smoother in comparison with the 8bit boards, due to faster processing and the use of better precision (float or double) on the calculations. A very noticeable performance occurred after using the new board version, the position controllers performed 70% better after having a faster inner loop (attitude stabilisation).
And between those new flight controllers, there is two “similar” firmwares, baseflight and cleanflight. I will not go into detail about this situation. Currently I’m using baseflight, although I have reports from other people that my module also works with cleanflight.
The pixhawk is a flight controller designed by ETH Zurich which started with the development of the PX4 autopilot and then to its new form know as pixhawk, it supports several flight stacks, the most popular/most used is the 3DRobotics (APM Flight Stack), which is right now the second largest consumer drone company in the world. The other flight stack is the “PX4 Flight Stack”.
On the hardware side, it uses a 32 bit processor clocking at 168mhz and two IMU’s instead of just one to provide redundancy to the system. I will not go to much into detail about this.
Being an open source open hardware project, several “versions” of the pixhawk have already appeared on the market, also several chinese clones… I have tested several versions of the pixhawk, among this ones:
- PX4 (original)
- 3DR Pixhawk
- Pixhawk (HobbyKing clone)
- Pixhawk Lite
Although the chinese clones are far more cheap to get than an original version, I personally recommend to use the original ones, this ones have being more tested and go through more strict quality control methods and therefore must likely less to fail. And when you’re flying over the Atlantic… you want something that will NOT fail.
There are several alternatives to talk to this flight controller. And either the PX4 and APM flight stack, both talk “mavlink” which is a protocol for communicating with small unmanned vehicle. It is designed as a header-only message marshaling library. Its being adopted by several other flight controllers, its was done by Lorenz Meier… and you guess correctly, from ETH Zurich.
As I was saying, there is two ways of talking to the FC, one is using the 3DR option called “DroneKit”, I have use it to make several examples, it has its limitations and its practicalities.
The other one is to use ROS.
If I have enough time I’ll make a post describing both options.
So, after introducing the flight controllers (the ones that are in charge of the “inner loop” or the stability of the aircraft), I’ll proceed to discuss a bit about the companion computers.
This depends entirely of the target mission you want to accomplish, in my case, I’m developing position controllers for multirotors… I have to mention that we can actually just use the FC to develop position controllers… but is a bit more complicated to modify tons of code on the firmware of either naze’s of the PX4/APM flight stack rather than separating the “outer loop” to be executed on another computer. That’s where the companion computers come into action. Also is better if you separate computers so that you can have a bit more of robustness, if the companion computer crash, the FC is still able to keep stabilising the vehicle and (with properly tuned failsafes) probably land the vehicle or disengage it.
There is a boom of linux credit-card size computers nowadays that we can make use as companion computers. Personally I like to use Raspberry Pi’s, due to its simplicity, robustness and low price. And now with the new Pi Zero, the things get very very small and light.
Companion computers I have used on my vehicles:
- Raspberry Pi B+
- Raspberry Pi 2
- Odroid U3
I have had accidents with the RPI’s and those small computers are really sturdy. The RPI 2 is great when you want to run some computer vision algorithms and then command the vehicle to do certain commands. But having a RPI B+ (if you have one laying around) it work great.
Right now I have two exact same vehicles with naze32’s and RPI B+ doing position controls, and they work quite alright.
So, whats the big deal having another computer on board? well… you have more computer power, you can do more complex stuff or you can interconnect more devices to the vehicle or even turn the vehicle into a IoT device.
In my most simple case I used it to get readings from the ground station which can contain, motion capture data, joystick commands or even calculated control commands.
In the case of the naze32 I just simple connect a usb short cable to the rpi and to the board. In the case of the pixhawk there is two ways of connect it, one using the rpi onboard serial interface or to use a FTDI cable/board to make them talk together. I have tested almost all connections possible.
I designed and 3D printed a small base that is bolted to the rpi and holds either the naze32 or a pixhawk. It makes everything tidier and works alright. I’ll upload it to Thingiverse and share it as well.
7 thoughts on “Flight Stack”
I read your this post as well post about Dronekit – SITL.
I am working on similar flight stack, I am pretty much new to all these things,
so could you write a post (or email) explaining about how to setup communication between Flight Controller –> Companion Computer (macOS/ Ubuntu) (with Dronekit+Mavlink on it) –> GCS (mission planner UDP)