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
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 .
Venkat
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.
@Bill Bonney
Thanks for you reply and appreciation.
Current autopilots do not have separate H/W core whose only purpose is to do one specific control , So the actual Kinematic control , gps math etc. are computed on a single core .
What I am doing is like developing a distributed organisation , I have X amount of work , Instead of getting one highly paid and smart employee to do this work , I get 5 average and cheap employees , break the work X into 5 different tasks A,B,C,D,E .
Each employee is trained to only do his task repeatedly , so his focus is to Complete the task in hand with full attention , hence Emp1 completes task A , emp2 completes task B , emp3 task C so on n so forth , The time taken by each to do it will is much shorter than the project as a whole , Since the focus is only on one task that perfection with which it is done is better , and none of the employees are over worked hence they will not fail to show up or quit. Basically , apply this to computing you will understand what I am trying to build , with Multiple low cost reliable chipset , I can do complex tasks by distributing and isolating their processing and do it repeatedly and reliably.
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.
Bill has a point there.
That is: these are both different approaches, with differing sets of design goals/strategies, priorities, and audiences, complementing each other by adding choice and leading to more new ideas. So neither idea has to be wrong, in the same way that Linux can't be called a bad/wrong design from a Windows point of view and vice versa.
So perhaps and hopefully it was a clumsy choice of title, but humbly calling it a 'a new or alternate approach to hw architecture' or something like that would've been a better choice imho, as there's no point in risking inadvertently offending others who're doing a fantastic job at their set of goals.
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.
@John Arne Birkeland
The Parallax processor has a similar architecture to the NVIDIA K1 with 256 cores.
They are a good choice for making an autopilot , But then again you will never have total isolation is processes , Why ? its pretty simple the Cores that many companies advertise eg: SnapDragon S4 Quad core processor , actually don’t have isolated cores , the cores which are advertised are basically separate ALU’s which have Separated reference Instruction sets . How , it works is that the instruction’s in the instruction registers are popped at a single time onto two or more ALU’s , so in one clock cycle we can execute 2 or more instructions , but the H/W resources are the same memory is also shared , the H/W multiplexer for output is same , in some cases they go the extra step of adding two NMInterrupts of each sub module , like the intel ATOM , so h/w and resources is accessed in real time after ALU is computed and not is a buffered fashion.
What I am talking about id multicore , h/w layers totally isolated control computing environment , where tasks are separated in terms of H/W resource , Instruction registers , ALU , memory and FLASH.
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.
“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.”
Precisely , that why it should be isolated and source not left for any one to code , Efficiency makes a lot of difference while coding a GPS navigation block mine occupies about 12Kb of physical memory space on chip (coded in C++ so portable to any embedded system with GCC) , maximum use of Unary operators and step wise formula implementation in stead of block based formula implementation:
Eg :
If We want to compute :
F(y)=x*sin(y*M_PI)+z*tan(y*M_PI); where x,y is of int16_t type
Instead of one block , I write:
Q(y)=(float)((float)x)*sin(((float)y)*M_PI));
S(y)= (float)((float)z)*tan(((float)y)*M_PI));
F(y)=Q(y)+S(y);
By doing this I can give explicit type conversion , re use the function Q(y) and debug each step while implementing to ensure efficiency , consistency and reliability
Now , I give an interface with a specified instruction set to build apps in a SDK, like in my previous replies , by this access to core variables(like angleToTarget) from interface is not there for app developer , hence unless app developer code an app to fly away there would not be a fly away ;-) . Even if any app is executed or not the efficiency , performance and reliability will remain same (no dependencies on any additional apps or user code).
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:
http://diydrones.com/forum/topics/why-no-physically-separate-multic...
The most important advantages concerning that point in my humble opinion would be interoperability, performance, increased code stability and easier maintenance.
-
4
-
5
-
6
-
7
-
8
of 10 Next