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: 12201

Reply to This

Replies to This Discussion

Essentially you are arguing that e.g 4 processors connected externally on a bus are better than 4 cores connected internally on the silicon. 

Nobodies saying isolated processes that are independent and run in parallel are not a good thing.

You just need to look at the history of the transputer and you will see that a lot of what was learnt about parallel (concurrent) programming has been adopted internally on modern processors. https://en.wikipedia.org/wiki/Transputer#Legacy

I personally don't think you have something that adds anything we are not already using. or cannot be achieved on a multicore processor like the ARM Cortex M4 with dual or quad cores. Or even with a realtime OS

The challenge is in the implementation on either system to avoid pitfalls in concurrent programming.

The only thing that is probably known, is that the cost and reliability of a system externally connected on a bus will be more expensive and less reliable. Just look at how micro controllers are much more cost effective and reliable than separate processor, memory, GPIO connected systems. 

Good luck with your design, it will be interesting to see how well you succeed in your aims. It's not a wrong solution, just a different one. And it doesn't indicate how it's currently being done in the industry as wrong, it actually supports it a valid approach.

What we need is a multi-core, multi threaded CPU, like current heap of cheap ARM quad and octocore. Have the flight control kernel loop bound to one CPU instance, and then leave the rest for all the other processing.

But it could also be done by creating timer interrupt based time slices, prioritizing the core thread.

This is the way things are going.

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,

Phil

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.

Indeed. As someone also brought up sensor aliasing effects, if you consider the PX4 flight stack, sensor polling is at 2khz to mitigate effects of coning, etc. Running control loops at that rate is just a waste of processing though.

The only advantage of higher Hz loops would be to reduce latency, and any modern flightstack has that part well sorted. I've seen quite a few racer pilots say that a faster control loop works better (because the Internet said so) but this is not true. Even the OneShot ESCs don't really help because they're running faster, it is just that thanks to the lower pulse widths, they reduce *control latency*.

The point im trying to make being, Hz does not give you much, but reducing latency does, especially with an optimal software architecture combined with hard timing hardware. Unfortunately 3 AVRs don't get you there at all. The latency in the intra processor link alone can kill performance.

I agree with Philippe - especially as he points out, that a quadrotor can only rotate as fast as its eigenfrequency. With physics and dynamics kicking in, your propellers can only go at around 120 Hz even with the world's best ESCs. The limits on the system dynamics are something you cannot simply ignore and say that faster loops equals better control.

As Phil said, a better system modelling method, and integrating the dynamics model of your system into the controllers makes much more sense. Model predictive control, or even LQR/LQG (considering that the system is well modelled) will give you tangible performance improvements. Again, not something you can do with 3 AVRs.

Even estimator improvements will give you better results than just faster loops. I've been working on integration of system dynamics model into an vision-based multi sensor estimator for better dead reckoning and sensor offset estimation, and the results are quite satisfying.
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.

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.

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.

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.

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.

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...

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.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service