Current architecture of drone autopilots is wrong , Drone hardware architecture needs to be completely re-engineered.

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.

Views: 12215

Reply to This

Replies to This Discussion

Thanks! Luci is quite a bit more compact than those other solutions, not to mention WiFi and Bluetooth built in, which is very convenient instead of Ethernet. 

And yeah it's not exactly the same, but many of the things he listed is something that a linux level processor could do vs another set of dedicated MCUs. Also those kind of MCU's are being used in mobile phones now similarly to how it was proposed, in fact the Edison has a dedicated MCU component just as a "sensor coprocessor".

It seems, muavdrones is blocked here ?

oh yes, Y6 for some reason seem to be very stable in high winds... I remember the day I've maidened my first Y6 (7kg) wind started building up right when I got into the field so strong that I was seriously debating myself weather I should call it off....  the moment it took off I immediately understood that is was the most stable platform I've ever flown. (flight controller is AUAV-X2)  

and it still my workhorse.

later in the evening this picture was taken:

He's is not blocked. Just hasn't replied for awhile for a while.


From what I read :

muavdrones, you discarded the real-time OSes by merely having had a bad experience with FreeRTOS and semaphore overheat? There have been decades of research in RTOSes, multithreading is then unworthy? I do not get it. There are tens of RTOSes. Xenomai a adds a Linux micro-kernel extension and, pipelining sensitive and non-sensitive real-time calls differently, achieves <50µs at cyclic test on a Raspberry Pi (2 i guess). Do not you think you need to reconsider the option? I am genuinely asking since you know a lot more than me on this.

As per the architecture you proposed : can you go with me in the future? We are in 2022. Laser range finders have went through huge progress : they can now get 2Gb/s data streams at 360° both in horizontal and vertical field of view. You can map the entire surroundings within each sampling. Small "slamming" quadcopters autonomously determine agressive manoeuvres to go through tight spaces that cannot be reached with normal hover "in real-time" ( first vid there Will serial communication prove to not be a bottleneck, when your kinematic core will need to be constantly updated, with what you call environmental sensors ( often referred to, in the academic papers, as exteroceptive/exproprioceptive sensors)?

About RTOSes you can also think of Arinc653 for manned aviation...

he cannot login anymore directly, but has to use a proxy

That has nothing to do with this DIYDrones website. It might that he's ISP in India have problems to connect NING network where this website is located. 

I just checked his account and there are no any blockages assigned to his account.

Hope that network issues will be solved soon for him. In meanwhile if proxy works, then he can use proxy to access :)


I think a processor that can detect when it is in error is the best next step.    Software and control algorithms are not the weak link.  They are tested in development and even further in aircraft flight tests.  The APM development system tests the code with a processor simulator combined with a flight simulator. 

However, any hardware single string processing can still make an error and not detect it.  It is not that we need multiple processors to run the algorithms faster.   What we need are processors that can detect when they have made an error, so that the micro-kernel can go back an rerun that control step and get it right.   Failing that safe themselves.

Texas Instruments makes a line of ARM processors called safety processors that detect when they have made a processing error and generate a hardware interrupt.    My favorite, the Hercules TMS570 processors runs fairly efficiently at 150MHz and has error detection and correction on all internal memory and registers.   The TMS570 lock step dual Arm Core detects processing errors clock cycle by clock cycle.    The real plus of this safety processor is that nuttX is already running on it.

The next big thing will be the APM autopilot code running on this safety processor.   The Pixhawk "Hercules" :-)

Sounds great but if your project is closed source then it doesn't belong here and your post becomes and advert for your product. If it is open source then please provide links to the code and hardware specs. Thanks.

Is this really only a place for open source contributions to drone development? While it should be encouraged, it shouldn't be discouraged to keep some things private. 

In 2008/2009, I designed one of my first flight controllers. The controller used three CPUs (I'll post the schematic someday), and it was a failure. The main reason for failure was the complexity added my using multiple CPUs.

A homogenous system with a single CPU is much more efficient. It is true that the hobby drone flight controllers are pushing it. The flight controller should only perform flight control tasks; nothing else. We have seen that manufacturers are heading in this direction with auxiliary computers managing non-flight related tasks. 

In other words, what you are suggesting is not at all new. Been there, done that...Even so while today's microcontroller can easily handle the basic flight control tasks AND non-flight related tasks, it is more reliable from both a software and hardware standpoint to not have the processing tightly coupled.

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service