I know this statement will raise the question who is this guy coming and telling us that current day autopilots are all wrong. Well I have been flying RC Planes from the age of 10 and have been using autopilots from the early Ardupilot of 2009 -2010 vintage till the more recent ones from 3DR, DJI, Feiyutech including their cheap clones over the last 5-6 years. I have been coding from the age of 15 and am now 21 years old.
Based on my experience with this wide range of autopilots I have come to the conclusion that hardware of majority of autopilots are adapted from the world of data based computing made for processing huge chunks of predefined data and giving a appropriate notification or display. In the case of data based computing inputs are got from low response data source like Ethernet/internet or some sensor network, this data is processed and outputs are either notifications or a display and in a few cases some very slow speed controls. Nothing where high speed control of a dynamic object is involved even on a single axis.
Hence the question : are these processors/hardware made for controlling a dynamic moving object with freedom across 3 axis’s like a drone??
After using all types of available autopilots I realized that the fundamentals of drone control at its core requires the following steps to be done repeatedly as fast as possible
1. reading sensor values and conveying them to the controller/processor
2. filtering these sensor values
3. pushing the filtered values into a PID loop
4. transferring control commands to the actuators for immediate action.
This cycle needs to be repeated over and over again the faster the better . This is what determines the stability of the drone the higher the cycle time the higher the stability .So what is needed in the case of drones is a continuous high speed input –output action reaction control system. I realized that drone control is not so much about data crunching as about speed of the control cycle.
If the use of drones has to grow developers have to be given freedom to code for their applications without compromising this core control cycle. In the case of drones a developers code resulting in a system hang will result in catastrophic outcomes like either crashs or fly aways, both which have been regularly reported in current autopilots. Achieving high control cycle speeds & isolating the flight controls is not possible with the current architecture of sequential processing, hence the future of drones is limited by the architecture of
currently available autopilots.
So unless a new thought process emerges drone use cannot grow exponentially. What is needed is a motherboard that it radically different from anything available today.
I have been working on this for a while now and my first hand experience is that the moment I shifted my focus to achieving higher speed control loops with my self designed autopilot the level of stability and performance I have been able to get are awesome even in very high costal wind speeds on a small 250 mm racer. I achieved this with the most primitive of micro controller used in the first ardupilot the ATMEGA 328. Things got even better when I replaced the MPU 6050. IMU with the MPU 9250.
With my custom made Distributed Parallel Control Computing Bus I have been able to achieve Altitude hold with a total drift accuracy of less than 1 meter and a very accurate heading hold as well as GPS navigation on the 250 mm racer. All I did was to add another ATMEGA 328 in parallel to the first one to add on features.
Thanks to this I am able to completely isolate the core flight control loop from the APP development coding there by the drone is never compromised by faulty APP development coding.
Distributed parallel control computing I have found from my own experience is an architecture that really has the potential to create exponential growth in drone applications. I would be interested to know of any other ways by which others are trying to address this core unique control processing requirements of drones.
For anybody that thinks 'speed' is needed to make a stable flight control system. Check out this drone controller.
This baby ran at a whopping 2mhz, and was pretty successful in keeping the lunar module 'stable'.
Today's flight controllers are 'Rube Goldberg' machines in comparison. When you have less to work with, you do more work to make it simple. If NASA can fly to the moon and back with such a simple device, what is all this discussion about quad-core-giga-bit-parallel-processing-nonsense about?
It's actually like we went to the moon with something less than a $25 arduino. No need for a rube-goldberg machine.
ZUPPA Autopilots are available here http://www.zuppa.io/#buykitnow for Testing .
ZAIP SDK will also be released shortly by which one could interface any SOC or Our break out boards .
Data Sheet attached .
Added Flyer of The Autopilot
Here's a screen shot of the GCS that comes as a standard download with the ZUPPA Autopilots .
Link to a video of testing the accuracy of the GCS ( https://youtu.be/9oJ9qCoXRpI ) .
I prefer testing GCS and GPS on ground Vehicles as any inaccuracies are immediately visible .
Here's the link to get the GCS software and details for connections :
Video to set up the autopilot and the GCS :
I see your points and concur. My AttoPilot (2007 Beta testing, sales 2008-2011) used the 8-core Propeller 32 bit IC. The IMU version 3.0 used 2 Propeller IC (16 cores). Focus was on fast optimized loops running on their own physical cores, with sparse pushing/pulling a few 32 bit datum with the central hub RAM. About half the cores ran code written in SPIN, the other half coded in assembly.
Great to see you here again, Dean!
I think modern architectures do get to the same place, albeit via different means. All the modern boards (Intel, Qualcomm, DJI, 3DR Solo) use two physical processor stacks, one microcontroller-based for for basic control that's highly optimized for fast, consistent loops, and the other one a much beefier Linux-based computer for higher-level control such as vision, sense and avoid, data processing and comms. There have been efforts to do it all in threads or processes on one board, such as the Navio2 on RaspberryPi, and that does work. But the trend in the industry is to keep the "flight controller" and the "app processor" as separate computers, each optimized for their own task.
How an autopilot flies almost matters not a jot, they all get the job done well these days. How the system talks to integrated apps that get work done is more important. Just yesterday I was trying a couple of new mapping apps that. One required SRT files from DJI craft so the developer is not even bothering at the moment to think about other platforms. Drone Deploy, Mapper and PIX4D mapper all work out of the box with DJI systems. I'm trying to say getting your system integrated into work apps will be more important than how elegantly it flies for commercial success.
I do look forward to more efficient aircraft flight with proper finesse in the aerodynamics dept. Not just relying on over powered bully boy tactics ;-) As always with these things perhaps a better way is just around the corner.
Attopilot was years ahead of the crowd and had functions only just arriving on the current crop of controllers.