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.
Replies
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.
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.
There is a guy here using 3 atmega328 for his FC
https://www.youtube.com/watch?v=9KYkznAas7Q
regards
Andy
Thanks Andy , proves the concept works well .
Venkat
@Joseph Owens
Bang On you have understood the concept perfectly
Thanks to you and for the benefit of the other forum members the concept is as below:
“ The proposed architecture of parallel processing mimics the body .
We all have two ways of responding to external information :
a) Reflex response to sensory information : which are fast instantaneous reactions to sensory information , not much thought or processing goes into these actions
b) Thought out response to sensory information : we assimilate the information understand it and respond after processing the information.
Core 1 ( KCU ) in my architecture works like a) above as far as responses to sensory information is concerned as it deals with the effect of ambient conditions on the drone along 3 axis like a reflex at high speed responses .
Core 2 ( IHOU ) is like b) : It handles the higher level processing like navigation , APP expansion etc . this processor need not necessarily by ATMEGA 328 it could be any processor like M3 , M4 depending on the requirement of the application.
As things progress yes , the architecture will get more specific for applications as it does in nature by evolution of the drone space.
Joseph thanks once again:)
I trust a lot in your forward thinking idea. Keep me updated!
Sure will please ping me at venkat@muav.in
Venkat
I'd like to ask a general question : if you're looking for high speed control loop, which would basically do some sensor filtering, PID regulators and generate servo signals, wouldn't a low cost DSP be a good choice in place of the atmega328 ? The point is that they are optimized from a hardware perspective to execute extremely fast the operations needed for digital filtering. Maybe the atmega is sufficient for this task, but why not use a specialized DSP ?
@Ben
-
3
-
4
-
5
-
6
-
7
of 10 Next