Best Microcontroller to build a drone

Which one is the best microcontroller to build a drone,  Arduino, Raspberry Pi, or another one?

Important abbreviations before reading this article

Attitude Heading and Reference Systems better known as (AHRS)

Inertial Measurement Unit (IMU)

You definitely need a microcontroller, a microcontroller is different from a computing system like the Raspberry Pi in latency and timing. The Raspberry Pi runs Linux, which like most multitasking OSs has task polling/switching (IRQ0) -interrupt request- every 10ms. the sensible implication of this is often that if at some point the Raspberry Pi must do something aside from fly the quadcopter (like service OS-operating system level tasks), your control code goes to “blackout” for a minimum of 10ms. (Though it’s true that you simply can tweak the kernel to scale back the task poll time).

Normally this is often fine since the quadcopter mechanical latency is slower than 10ms, BUT this is often getting to screw together with your AHRS loops if you do not buffer the IMU data, and your PID (proportional integral derivative control) loops if you do not catch up on it.

In simple terms – the Raspberry Pi is running an OS, which is doing a bunch of OS-like things within the background, like flushing buffers, and system logs, and stuff like that. this stuff happens periodically and can interrupt your code. With the normal software, you do not notice this interruption because it’s happening at a timescale much less than a person can tell. However, with a quadcopter, there are processes that should not be interrupted (like the part that collects IMU data). you do not have much control over this interruption (because a multi-tasking OS is meant like this), then the sole thanks to using a Raspberry Pi to fly a quadcopter is to create hardware buffers into the IMU module, and write code to catch up on non-updating PID output (if you do not you’ll destabilize the craft because your gains would be wrong).

On the other hand, microcontrollers either run a real-time operating system (RTOS) or some low-level interrupt-driven code that guarantees low-latency operation on the critical parts of the code.

If you would like the processing power of the Raspberry Pi, what you ought to do is have a microcontroller affect low-level and low-latency tasks like interfacing with an IMU, and running the PID and output loops. Then slave the microcontroller to the Raspberry Pi, and leave the high-level navigation and communications code to the Raspberry Pi.

In the past, that is what we’ve done. an inexpensive microcontroller deals with IMU, PID, and manual flight controls, and runs a rudimentary quaternion-based AHRS with simple filtering for stabilization; then, a lightweight 1GHz quad-core ARM computer running Linux deals with GPS autopilot and communications, also as a more powerful AHRS with ETFs. The microcontroller’s AHRS is fast but less accurate and drifts over time, while the computer’s AHRS is slow (higher latency) but more accurate. So we combine the simplest of both worlds by having the microcontroller control the quadcopter, and therefore the ARM computer periodically sends it AHRS corrections to stay it trimmed and accurate.