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.
There are still limitations of the hardware that the FC is sending commands to. Ex. current ESC's based on PWM need to be replaced.
Then there is the frame design, motors, props.....many variables.
I've had this Y6 for about 1 1/2 years. I took a video of it the other day because someone at another forum said Arducopter isn't stable in high winds. With this copter I don't worry with 30 mph winds. How stable does it really need to be?
FYI, about the separation of attitude controller (the core functionality of a FC) from the rest, I asked a related question about a year ago:
The most important advantages concerning that point in my humble opinion would be interoperability, performance, increased code stability and easier maintenance.
Yes , all of the above , i have experienced it in real time , if fact due to the system while testing i have had crashes(due to improper algos's) but never fly away's , even while navigation is turned on.
Additionally, i have created an additional module for data logging , something like a black box recorder with a update rate of 50Hz (for real time analysis). http://www.muav.in/motherboard_zuppa_klik.php (the add on module supports SDK based camera trigger).
Finally, just to add to the point you have made , It is also very easy to build apps on these type of system architecture directly via an interface .(refer to my reply to Lazer Developers , it has a java app for RP2).
FYI , i will be releasing all the APP libs open source , after i manage to get in a few more features.
The problem I see with this architecture is that the bus is a bottleneck ( The part labelled control network seems to be modelled as a bus) Is there any reason for the actuators to be connected to the sensors or the video controller? It is very inefficient and performance slows as more devices are connected and the poor old bus slows down
I decided to go with a star network as described here.
My main reason was that I wanted to put more intelligence in the wings themselves.. sensors servos and RC in the wings rather than the fuselage, without having a large number of connections.
Doing things in parallel does in fact happen on currrent systems. Your gyro accel magnetometer and baro may all have processors on board. If you can isolate processes that are independent that is a great thing. In fact removing unnecessary coupling is a good goal in any system. The downside of doing it in non reconfigurable hardware is inflexibility.
The advantage of doing it in software ( or reconfigurable hardware) is freedom to make fundamental changes on the same hardware.
Personally I wouldnt bother with an 8 bit processor any more though. You can get cheaper 32 bit processors with more ram more rom and much better and more numerous peripherals. They will also handle an RTOS :)
He's been band.
Sound like you would like the Parallax Propeller microcontroller design with 8 cores, ring buss communications and shared memory.
But alas the traditional event driven approach is much more efficient and responsive then pulling a loop as fast as possible.
I like the approach used in APM, with a series of small tasks of known maximum duration which are called at a configurable rate each.
Regarding the option discussed in this thread, it's presented as two advantages :
- speed of control loop execution
- one CPU is critical for plane safety, the other not
But for the second point I'd say that the second CPU is as critical as the first one, as it manages the GPS and waypoint management : if it has any bug in its code it can result as well in crash or fly-away.
I thought it important to clarify the intention of this thread as I see a few comments on processors/controllers like 8bit , 32 bit etc .
My architecture is not restricted to 8 bit in fact I have applied it for an automobile R & D project where I have used the 328 along with an M3 and an M4 on the parallel BUS .
By this thread I am looking at stimulating thoughts on :
In short the need to relook AP/FC architecture with an eye on the future when drones should be used like a PC or a smart phones of today.
As for the interesting posts by Dan Wilson ,John Arne & Ben will get back with a detailed reply over the weekend for sure after the current rush on some deadlines at work are dealt with .
You made an excellent choice for the CPU. Very reliable indeed. Limited resources leads to efficient code and that leads to fast code ;) I have a bunch of frames waiting for you. Quad's, tricopter, hexa's. I used to help beta testing version 3.2 with Randy. I also helped with the development of the micro VRbrain by Roberto. I found a nasty PPM bug in the first hardware revision. Also looking forward to help with your project. I share your enthusiasm for this project as i am convinced that this is the way forward for flight controllers. ;)
Current architecture of drone autopilots is wrong , Drone hardware architecture needs to be completely re-engineered.
That's quite the bold statement.
All the high level app logic on the 3DR solo is happening on the onboard linux computer. The DJI Phantom 4 is handling the vision processing, for example, in a separate module http://www.movidius.com/solutions/vision-processing-unit. What you are saying is that the app needs to be separated from the control system for the autopilot holds true he how the current market is handling that.
The problem is that at the granularity you are proposing you lose the flexibility. This is the flexibility that has helped the industry get to where is has today. Also if you scale up to 32Bit processors, you start adding extra cost, than using a integrated multi-core solution.
You maybe able to create a distributed processor architecture, but will it really be any better than running processes in parallel in threads and cores on today modern processors? With extra board dimensions and interconnects, will it be more reliable? The architecture will have bus bandwidth communication problems. And as another poster put it, t's 'improved' architecture with diminishing returns.
The current autopilots are isolated control modules and the addition of companion computers they are app expandable. I really don't see anything new here.
You propose an interesting solution to the problem, with the usual pros and cons to the design. In the end it's a just a different approach and does not negate or deem the current approach should be thrown away as wrong.
I look forward to reading about your progress as you develop your system further.
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 ?