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
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,
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.
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..
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.
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
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.
-
2
-
3
-
4
-
5
-
6
of 10 Next