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