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.
Good luck with your project Venkat :)
Long live the Kahlman filter as a "very advanced SLAM algorithm", and advanced architectures where "even if the esc’s output Control doesn’t change every cycle , the motor Command changes based on PID and its previous OP". Also UARTs implementing the new Distributed Parallel Control Computing Bus.
And the Turing test.
This sounds a lot like our thinking when we developed Luci. The idea was to offload a lot of the higher level, "non-essential" components to the Intel Edison copilot (while also enabling WiFi, bluetooth, more sensors, more IO's, etc.) and leave the flight core to manage the flight. This also means that development is taking place on a Linux system, which is a lot faster and easier to develop on.
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
FYI the graphite in the $2 pencil poses a danger of shorting out electronics. Everyone uses the space pen.
more info please, does it support more then the intel Edison ?
The Edison is built into the board for compactness. However our software (Dronesmith Link, Dronesmith Suite) runs on any linux capable drone platform (i.e. Solo, Phantom) or companion computer with a little bit of hardware config. We are developing more accessory/daughter boards that can bring on more powerful co-pilots as well that can focus on certain heavy calc processes like sense and avoid and object recognition. If you want more info, you can hop on our community slack channel.
@greg: you proposal is the same as PXF Cape for BBB, the NAVIO for RPi, PXF Mini for the RPi etc...
Not really the same as this proposal to use multiple microcontrollers for each fntion of the autopilot
Look like an interesting project for those wishing to use an Intel Edison. Nice.