Instead of using a microcontroller based board, such as an Arduino, etc., for a flight controller, how about using a Pi based solution?
The are a number of options which use the Pi:
- The NAVIO2, made by EMlid, is outrageously expensive, costing around £150+. Put that against a ArduPlot (APM) which is around £20.
- Navio2 or The Raspberry Pi Flight Controller
- The Drone Pi uses a MultiWii.
- PXFmini controller sits on a Pi Zero, made by Erle. PXFmini ($69) – There is also the Erle-Brain2, which powers the Erle-copter, Erle-Hexacopter, Erle- Rover and Erle-Spider.
- Only using the Pi, no APM, Wii or other flight controller, is the Quadcopter+Raspberry Pi = PiCopter
– 4x Robbe Roxxy 2827/34 Brushless Motor
– 4x BL-Ctrl V1.2 (http://mikrokopter.de/ucwiki/en/BL-Ctrl_V1.2)
– Raspberry Pi
– Arduino+RFM12 for Radio transmission over ttyUSB0
-MPU6050 Motion Sensor (Gyro+Acc)
-3-Axis Digital Compass HMC5883L (not in use)
-ublox5 GPS (not in use)
-WiFi Dongle to ssh into the RPi (I tried to use it for Radio control but that do not work very good)
Overall, I would say it’s perfectly feasible, a great prototyping choice, but a rather mediocre choice for a longterm product. There are countless benefits to prototyping with inexpensive commodity hardware such as the RPi. The RPi is reasonably light (certainly light enough for a quad that’s probably carrying a camera that is far heavier) and reasonably compact. You probably won’t be able to find a better cheap, reasonably well-supported, and available platform with similar features. However, it is far from ideal for a few reasons.
The main issue you will encounter is that the RPi is a single computer at heart. This means that if you are going to use it for controlling your motors, it will be timesharing between all of the other various software programs that your flight control board must run such as navigation algorithms, communications, and any mission-specific computation for sensors.
In order for that to work, it would be mandatory to be using a realtime kernel, which does exist for RPi. Most flight control boards split the work into at least two physical processors. One that reads sensor values, integrates the result, computer error, and then computes commands… and only those tasks. That processor, typically referred to as a “controller” because it implements a control loop, has a very high performance requirement. The faster it can execute, the more stable your platform will be because of [math goes here]. The reason a realtime kernel is necessary is that if the kernel decided to allocate time to other processes instead of the controllers, it would randomly fail to recompute the command values for some set of your motors. That would be like randomly turning off your controllers for an arbitrary amount of time. Think of it like when Windows/MacOS randomly pauses and does something you don’t understand, sometimes with a spinning mouse icon. You really don’t want that when the processor is responsible for keeping the aircraft in the air. While it’s possible to write your software and configure your kernel in a way that wouldn’t have this issue, it would be very challenging to do correctly. To avoid this challenge, the controllers are usually split off into another dedicated processor that accepts goals from a main processor. This means the dedicated controller processor only needs to do four things: accept commands from the main processor (probably over a serial link), read from sensors, multiply and add, and write out commands.
Splitting the work would leave a main processor, which is concerned with navigation and very high level commands to figure out the goals that the controllers should be aiming for. This is where a Raspberry Pi would be a perfectly adequate choice. Since it doesn’t matter if the higher level control logic takes on the order of a second to recompute, it’s far less crucial that it be a high performance piece of hardware. Since this is where you want to be able to rapidly iterate and test, using a developer-friendly environment with a monitor output, such as an RPi is a great choice.
Once the prototyping stage is over, the value of the RPI largely goes away. At that point, you would want to transfer your code onto a much more compact board for space, weight, and boot-speed. I would suggest looking at something like a Teensy. While Arduinos are popular, you will quickly discover you need more memory for your programs than the 32k typically provided on the smaller Arduino boards. By the time you import a few sensor libraries, you will hit 32k, and it’s a waste of your time to be playing stupid compiler tricks to get it to fit into the 32k limit.
If you wanted to strike a balance, you could always make your own very compact board with two Teensy boards. One would be dedicated to the control loops, and one would deal with everything else. This would preserve the commodity hardware benefit of the RPi, while giving you a more reliable setup. You would lose the ability to do arbitrary things in a Linux environment, and monitor output from the boards. You may or may not care.
I believe that a Raspberry Pi usually runs with a general purpose OS (various Linux distributions).
The Pi is more of a product to provide full blown computer capability…and not so much for low-level hacking.
If you want to play around with general purpose programming using Linux…the Pi is a good choice (the Beagle Board is another.)The Pi does have general IO ports, SPI bus, I2c bus, and UART.
These are communication methods need to talk to servos, esc throttle controls, barometer, gyros, accelerometer, and GPS.
The big hurdle in using a Pi for this low level control, is that you are relying on Linux to provide a working API, and to correctly interface to all these sensor type chips.
Does Linux have this capability?
I wouldn’t bet on it.
Another problem in using a general purpose OS, is that it introduces all sorts of unwanted latency.
And if the OS is buggy, or if it doesn’t provide the functionality you want…you’re out of luck.
That is, unless you want to modify the Linux OS itself, to fix it, or make it do something that you want it to do.
Now your FCB software project has become 100times more complex.
Real-time OS’s are also an option, but I’d even avoid using these…it’s just another layer to debug, and try and wrap your head around.
So typically, flight control software is written directly “to the silicon” itself…with no intervening OS.
You need to be able to compile the software into a hex file that can be flashed directly into the microcontroller’s program flash memory.
Does a Pi let you dispense with an OS?
The answer to that question is complicated by the fact that the Pi uses a Broadcom chip.
Broadcom chips are really a one off, in that they don’t provide datasheets that are available to the general public.
The Broadcom sales model is to sell millions of the these chips to a very limited number of large cell phone vendors.
I think the Raspberry Pi people originally chose Broadcom because they wanted to concentrate on education…and less on hacking.
They were primarily shooting for a price target, and Broadcom may have been the only choice to fill the niche.
It may have saved $5-10, but it was not a great decision for those who want to develop software at the lower firmware level.
For programming at this level, you need microcontrollers that provide complete access to Datasheets that fully document all the available peripherals and control register settings.
It’s literally impossible to create FCB software without availability to this documentation.
Obviously this documentation was provided the Pi developers so they could port the supported Linux distributions to this chip.
That doesn’t mean that a hacker can get ahold of these documents in order to modify the Linux, or learn the secrets of writing, compiling, and flashing programs to the bare silicon.
Every other generic board I can think of uses microcontrollers that are fully documented.
Just go out to the vendor’s site and download the free PDF files.
For all these reasons, I’d say the Raspberry Pi is the worst of all the options for developing a flight control board.
Much better general purpose boards are available, such as Beagle boards, the TI Discovery boards, or the various Arduino type boards.
Many of the open source Flight Control Project firmware will run, not only on the customized flight control board hardware…but the firmware will also run on the more generic breakout boards that have the same chipsets.
Here are some links that also address your Raspberry Pi as Flight Control Board question:
Here is somebody who has used a Pi:
Here’s a Raspberry Pi shield that is a flight control board.
Although some of these links look promising…I still think a Pi as a FCB is like forcing a square peg into a round hole.