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.

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –


  • Kabir, i agree that as long as aliasing effects are no issue anymore the only important factor is latency. However, latency can me easily measured. Have you any idea of the latency of your bus Venkat? 

    And lets not forget the cost issue neither.

  • Hello,

    well from the  control engineering side speaking, faster sample rate does not automatically mean more stability. 

    If you goal is to get a Control System which is able to follow your commands more quickly (which I assume is what you are trying to achieve, because "stability" can also mean that you want your quadrocopter to be able to handle external disturbances like wind better), then it might be worthwile to either tune your PID gains better, or settle for another Control-structure entirely.

    For example, the guys from ETH (in just one of their videos) dont achieve their good performance because they sample crazy fast (although I believe they use a stm32 microcontroller at 200Hz), but rather because they employ very well laid out controllers.

    Infact there is a discrete control theorem which states that in order to capture all relevant information of a system with discrete sampling, you only have to sample twice as fast (Nyquist Shannon sampling theorem) as its fastest frequency. As you quadrocopter can only rotate as fast as its fastest eigenfrequency, this would mean that depending on your frame a maximum of 100Hz sampling time would be sufficient. Therefore sampling, and controlling your Quad faster would not help, as you quad cannot move faster then its eigenfrequency (which again, depends on your frame, motors etc.). This is actually also exercised in real flying systems, like the eurofighter (which has a sample frequency of around 150hz).

    I guess what I want to point out, is that if you want to have faster responding quadrocopter, it will not suffice to just "do stuff faster", because your quadrocopter cannot physically turn faster then its system limits, but rather to spend time on implementing better control loops and identifying your Quad model (therefore System identification). Getting a better understanding how your copter reacts to inputs, will impact your flight performance more then increasing your control loop frequency. Because if you have a good Mathematical Model, you can lay out your gains better (for example with an LQR controller),

    Of course this is only my Oppinion.

    Best regards,


    • I agree Philippe.  This is why, as Kabir says, Hz is like Megapixels.  An over-reliance on one single variable, while everything else is ignored.

      • Developer
        And if it comes to better hardware with isolated processing, we're already doing that today. The Snapdragon Flight for example has a multicore Krait applications processor and a Hexagon DSP at 800mhz running a RTOS and the timing critical flight stack. With a direct digital link to the ESCs, we're already achieving very low latencies.

        As such, I honestly don't really see the case for your autopilot, and why it would outperform a modern, well-architected system like PX4. Quite definitely, you should reconsider your 'everyone else is wrong' stance.
        • The whole idea of a multi-threaded FC would be to have the main loop do its job, and then you can add more and more processing on the other cores. You can add more sensors, image analysis etc that all use CPU, and then update the values in shared memory (or have the main thread pull them).

          The advntage would not be better latency, but would make it easier to add lots of new stuff to adjust behaviour. So we would get new functionality at minimum risk. It would be nice if I could just add sensor X, and put plugin X onto the FC, and it would work. Like I add kernel modules to Linux to get the hardware support. Then some other code to read the sensor and modify flight using an API. Anti-collision should be high priority, but works at a higher abstraction level than microadjusting attitude.

          • What is the effect, when a multi threaded , mult core processor, get blocked one of it's threads/cores ?
            I'm not a specialist here, but running a multicore processor in a computer, I notice, if one app hangs, the other cores tend to 'freeze' as well, being less.
            Still eating 100%+ of it's total capacity.
            Thus far, I'm 100% in for the idea from muavdrones, to really work with physically different processors..
            As I'm using linux as well, isn't it so, that sometimes you load an extra kernel module, that tends to freeze the rest as well ?
            What i notice on a lot of these autopilots is, that their I/O capabilty is mostly limiting, except maybe when using I2C bus ?
            I was just looking a bit, there is one board offering 36 servos out, with a 100Hz update rate..
            Pasting in some specs..

            • 9 DoF digital Inertial Measurement Unit , 1200 degrees/s maximum
            • Internal 3-axis magnetometer
            • Dual processor for
              • Sophisticated sensor fusion (IMU, Magnetometer, GPS, Altimeter, Airspeed etc)
              • Flight management and communication (Control or Navigation algorithms, Payload management, Communications, etc)
            • Altimeter sensor (Absolute pressure), 0 - 15000 m
            • Airspeed sensor (Dynamic pressure), 0 - 250 knots
            • GPS, NMEA and Raw Format, Update rate 5 Hz
            • 4x analog ports (12 bits)
            • 8x digital IO ports
            • 2x I2C bus
            • 1x SPI bus
            • 1x CAN bus
            • 3x serial port for payloads
            • 1x serial port for external/internal data modem
            • 12 directly connectable servos
            • Up to 36 connectable servos with an external boards
            • Up to 100 Hz servo update rate
            • Input voltage ranging from 7.5V to 28V

            Where I notice : DOUBLE Processor, yet gps update at 5hz ?

            Counting in anti collision, object/face recognicion, .... and so on, isn't it indeed no better, to put most important funcionality completely apart, with it's own memory, so no matter what, it keeps functional, ( that could be 4 subprocessors )  and one 32/64 bit a la AMD turion ( known to consume not to much) , or/and a gpu, like the Nvidea board you can get these days ?

            Where subprocessors keep at flight control, the main processor all kind of fancy things, and the GPU all video/anti collision/ face recognition

            my two cents...

            • Developer

              There is no free lunch.

              Parallelism/multi-threading/multiple psychical units are great for tasks that can be split into many smaller independent tasks. But when the next computation is depended on data or results from the previous one, then you just get a lot of overhead in the form of complexity and latency.

              So splitting a task into separate physical computing units, only helps if each unit can work independently.  But in the case of autopilots in requires most units to work as a whole. The IMU/AHRS can't do the next iteration before it has fresh sensor data, the control outputs can't change before the latest IMU solution has updated the PID's and so on. So if one unit dies, the rest of the system most likely no longer has data to make reasonable decisions.

              On top of this there is also inherent latency added by the data communication needed between the units, and in ensuring there are no dead-locks or communication failures.

              What I do agree to, is that splitting the autopilot into separate logical task makes a lot of sense. But this is mostly for convenience (makes it easier to understand), flexibility and faster porting to new hardware. And this is what the ArduPilot HAL aims to do.

              And there is no technical reason to prevent different parts of the HAL to be executed on separate hardware units, but I fail to see the benefits. Adding more hardware does not automatically translate into something faster or safer.

              • Hello John,

                Well, maybe you could speed up the communication  with the sensors with an interface, that keeps giving the same value until the sensor changes?
                That way the processor doesn't has to wait, and can keep working in sync, with almost zero waitstates.
                For delays between different processors, you could set up the same infrastructure, like it is used  in computers, like north/southbridge, pci or whatever ports?
                If you set up each processor with it's own memory, then the possibility on bottlenecks and errors is more secured.
                In each most significant processor, you could set up extra code, for when one fails, the other can safe the day, being rudimentary.
                Heck, if you would like to work 100% secure, you could make a setup threefold, which solves the prob with sensor defects.
                The GOOD thing with multi processors, where some work dedicated, and are not to be 'touched', with other programming, makes them inherent safer.

                With what is growing these days, and more and more functionality is added, you can't keep working with one, or even more microprocessors, and it wouldn't be a bad thing, to start thinking to even add a CPU and GPU to the mix, ofcourse, for those that want to do more.
                Follow modes, object , envirionment , face recognicion, radar/sonar , I guess this goes far beyond the capacity of these microprocessors, while they still keep being perfect for the emu / autopilot, if kept on minimum two micro's.

                To answer on your 'deadlock' or communication error, couldn't one of the two micros not bringing back the bird, being the one with the sensor feed, doing it full auto, to a given coordinate, easier for a x-rotor then a plane, but ok, and the other still be flown without correction being easier for an airplane then a xrotor.

                At least one sure benefit I guess, it'll free up more memory ?

                Don't be offended, if I misuse terminology, or miss the ball somewhere, I'm not a programmer, nor hardware specialist.

                But I've clearly seen the difference between single and multiprocessor servers, and while my multicore sometimes has one core blocked, the other tend to freeze more or less as well, while with the multiprocessor, one can hang, the other keeps doing it's job.

                I also see, all more professional boards tend to work with multiprocessors as well, and a guy, who made some stuff in 2002, tended to jump to the same conclusion, that the micro was enough loaden with sensors, and ran also in memory issues, and has put a normal processor, to handle the other tasks.
                He worked with qnx I guess

                And yes, there's never a free lunch

                And don't get me wrong, I still think arduino is awsome

          • Developer
            Multi threaded FCs are nothing new. APM is sort of multi threaded in portions, and PX4 is fully modular, with each module (estimator, controller, sensor drivers, etc.) being a separate process which is connected by a very fast publish/subscribe bus.
            Its already easy to add features. You can just add a module and start them, even in flight. Not a problem at all.
          • Anti-collision for beginners is the hype of the moment, so it would be nice to have it implemented as soon as possible. It seems that the Intel Realsense module for the Yuneec Typhoon H will be sold separately, as an upgrade for 99 usd. I think it is just plugged in a usb socket on the underside of the craft. Maybe using the same module is the fastest way to implement anti-collision.

This reply was deleted.


DIY Robocars via Twitter
DIY Robocars via Twitter
DIY Robocars via Twitter
May 13
DIY Robocars via Twitter
RT @f1tenth: Say hi to our newest #F1TENTH creation for @ieee_ras_icra next week in Philly. It’s going to be huge! 😎 🔥 @AutowareFdn @PennEn…
May 13
DIY Robocars via Twitter
May 11
DIY Robocars via Twitter
May 8
DIY Robocars via Twitter
RT @SmallpixelCar: Noticed my car zigzagged in last run. It turned out to be the grass stuck in the wheel and made the odometry less accura…
May 8
DIY Robocars via Twitter
RT @SmallpixelCar: Test my car. RTK GPS worked great. Thanks @emlid for their support. https://t.co/EkQ6qmjmWR
May 8
DIY Drones via Twitter
RT @chr1sa: @kane That's @diydrones circa 2009. Still have a box of those Canon cameras that we used to strap into planes, just like this.…
May 3
DIY Robocars via Twitter
RT @chr1sa: Our next @diyrobocars race is going to be outside at a real RC racetrack in Fremont on May 28. Fully autonomous racing, head-to…
Apr 30
DIY Robocars via Twitter
RT @f1tenth: Our Spring 2022 F1TENTH course @PennEngineers is coming to an end with a head-to-head race as a big finale. So proud of our st…
Apr 26
DIY Robocars via Twitter
RT @DanielChiaJH: I wrote a thing! Throughout the development of my @diyrobocars car I've been using @foxglovedev Studio to visualize and d…
Apr 23
DIY Robocars via Twitter
RT @SmallpixelCar: My new car for high speed. Low body, everything ( @NVIDIAEmbedded Jetson Xavier NX, @emlid RTK GPS, IMC) under the deck…
Apr 23
DIY Robocars via Twitter
Apr 21
DIY Robocars via Twitter
RT @f1tenth: F1TENTH Race training setup @PennEngineers for our upcoming ICRA2022 @ieee_ras_icra competition. @OpenRoboticsOrg @IndyAChalle…
Apr 21
DIY Robocars via Twitter
RT @fatcatFABLAB: Proud to be hosting a restarted DIY Robocars NYC Meetup April 26. Come by if you want to talk about and race self-driving…
Apr 17