Drone hardware architecture needs to be completely re-engineered

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. Om sree sainathayanamaha

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 .

Yeah thats really impressive article.
Parallel computing technique is already used in APM which has mega2560 and couple of mega32 for computing.
Parallel computing has its own advantages of doing more number of things at one time.
Anyway nice one.

I'm no coder, but have a bit of experience working with the Pixhawk, and the curiosity.

Could you put up a thread detailing what you've done? It would be a great read, and would add value to the forum.

That is indeed a thought in an alternative direction. There are a few different problems as I see that need to be debated and treated independently

1. The sequential process - These crafts work on feedback loops, so at the moment, this is the most plausible solution, unless we have some AI built on something like a SyNAPSE system that can be used to predict https://en.wikipedia.org/wiki/SyNAPSE

2. Speed of the loop - Yes the faster it is, the better it is. If one processor cant handle it, get a coprocessor that one can offload to. That is how we came to multicore processors today. . 80286 used to have a math coprocessor. Every computing device we have today is stuck in a while loop, the faster the while loop executes an iteration, the better the result seems to be. a.k.a processing resolution.

3. Separation of concerns and processing priority - This is most easily dealt with the current systems using interrupts. Atmega has a few. but interrupts is the most reliable way of preemptive processing with processor based design available today. There could be alternative solutions using FPGAs to process sensor inputs, filtration, PID, locomotion, execution within hardware, and on separate subsystems, leading to a tighter firm realtime system that will process even if there is a hangup

@muavdrones,
A quote from your post.
"This is what determines the stability of the drone the higher the cycle time the higher the stability ."
Did you mean "the lower the cycle time...?

I'm just nit picking. You're probably right about your basic premise.
Regards.

@muavdrones, I think you are still in APM/Phantom 2 Age, All the circuits after that are too advanced than you mentioned. Please take time to inspect Pix4 / Pixhawk hardware,

Just "32bit STM32F427 Cortex M4" is far better than 4 x atmega 2560 parellel and with "32 bit STM32F103" as a co processor for failsafe, also the pix not only use Invensense MPU 6050 but also a combination of ST Micro L3GD20H  & LSM303D to be safe and precision measurement.


Also forgot to add "The Fly Away/ Crash age is over", Did you heard any fly away / crash because of Flight control(Pixhawk / Naza / Phantom 3) failure in this last 6 months? If anything happened like that then I can surely say that should be a motor / esc / wiring / cheap clones / pilot errors, that cant be controlled by a better Autopilot Coding or Processing power of FC  

@akhilzid ,

Your post clearly indicates your lack of understanding between products and the technology that goes into creating them . Throwing in a few processors names is not an indicator of technology . Technology is independent of processors and controllers .

The technology I have created has been used with a range of processors including M3 & M4 on a serious  automobile R & D project on which I am already working with a listed company in that space .

We have been associated with RC India and autopilots from the founding stage SO I HAVE BEEN USING AUTOPILOTS FOR AGES ,

Get one thing not all people talk out of their hat , everything I say has proof and reason with data and stack traces along with vdo's , I have over 10 years of flying experience and over 5 years of coding , I am a core java architecture coder , I have taken up large projects with Listed automobile companies for autonomous cars and my technology is evaluated by UAV experts from TIFAC ( DST ).


Lets look at what you are saying the STMICRO L3GD20H and LSM303D have separated axis dual precision magnetometers , hence the DCM state matrix is complex on APM (in simple terms the magnetometers position is offset as compared to ACCEL n GYRO so when you perform fusion you need to take into account the lateral displacement as a sin n cos eqn. Now look at the most advance IMU MPU9250 , the Mag's location is offset by 0.001mm on a silicon wafer level as compared to accel's hence with a basic ellipse -> circle normalizer and vector maths I can compensate it , plus please check out sensitivity , and mag tolerance of MPU9250 its is WAY higher than STM counterpart .
PS : MPU9250-MIL is used by NASA for their redundant IMU's. If you want to go into further details with mathematical eqn. and quadratic algorithms I can go into that but am not going into it as you are talking of products and not core technology .

I guess as for the others who have posted here appear to have interest and understanding of technology , here is a technology oriented discussion going on DIY drones on this very subject that would surely help you to understand that I am not criticizing products like PIXHAWK ( diy drones is the home of pixhawk ) and NAZA but trying to stimulate a discussion at an Global level on AP architecture :

http://diydrones.com/forum/topics/current-architecture-of-drone-autopilots-is-wrong-drone-hardware

I don't want to repeat so placing the link here for those interested .

Video of my same board on multiple copters with easy fly :

@akhilzid : FYI check out the DIY drones  link to first of all understand what I am talking about with  knowledgeable members on DIY drones  who have termed my creation of my own autopilot as an achievement in itself and appreciated the out of the box architecture   .

I am sure this will also help you understand that for once an Indian ( me ) is trying to lead thoughts on the future direction of drone technology which is being appreciated with  an open mind by those members who had a hand in creating APM and Pix hawk.

I want you people to work hard and hard to withstand tough competition of NAZA ,APM.
I think you should have a website not the one which has now. Its doesn't have good options to buy.
We want a website where we can buy ZUPPA and try them.

MPU9250 = MPU6500(is a low power version of MPU6050) + AK8963



Also refer these links
http://diydrones.com/profiles/blogs/auav-x1-a-new-vision-of-the-px4-autopilot
http://www.rcgroups.com/forums/showthread.php?t=2576614

@muavdrones (may we know your name?)

I feel really proud knowing that a young Indian has created a flight control board!     

It must have taken a lot of hard work and patience for the hardware as well as the firmware. What you have done is really commendable! I hope you share the finer details of the FC with us so we can understand and appreciate your work even more.

Having said that, I have a few observations to make.

1) Here's what the Invensense  support replied regarding the difference between the 6050 and the 6500:

QuoteThe MPU-6050 is higher power, lower noise, and larger package versus the MPU-6500

It's better to use an external magnetometer as it takes longer to fetch the magnetometer data (with the accelerometer and gyro data) and a lot of people recommend placing the magnetometer away from the main board to reduce noise.

2) Most common FCs don't use parallel processors in order to reduce cost, size and complexity. They produce good enough results at low cost, which is what most sellers want.
The high end FCs on the other hand run the main loop at such a high rate that they don't need parallel processors.

And a few questions...

Are you using the on-chip DMP of the MPU 9250? And are you using the SPI or I2C bus?
What is the cycle rate of your main loop?
How are you decoding the rx signals and creating the servo signals?

I found that pin change interrupts and timer/ counter interrupts add noise to the main loop. Using external hardware for these two functions gives a cleaner loop and removes a lot of load from the 328.

I'd be honoured to collaborate with you. Just give me a ping.

@ Swapnil,

Yes the interrupts did create a problem at first , so what i did was to offload the receiver interrupts , UART interrupts as well as the GPS onto the second independent core which has its own resources , byt hsi we i create a H/W layer between the core Kinematic Control Unit and the Interface unit.

The core one has TIMED ISR to handle sampling nd motor control. The sampling is pushed into a ring buffer while ISR'S control motors separately , the equivalent best O(n) complexity i achieve is 5ms while worst is 7ms, so about 180-200 Hz including mag nd baro control.

I have had a lot of with programming the Higher processors like STM32F407Z as well as STM32F103RET6 , and the Mojo FPGA board , yes all technically have a much higher control execution for the code , but What i am trying to prove is that with a Distributed Parallel Computing environment (DPC) , a processor like an ATMEL328 is enough to provide autonomous control very efficiently , cross platform. In fact i have done a details comparison of RTOS vs Single LOOP and found some surprising results in terms of execution consistency. 

How can you manage EKF checks/ multiple Sensor comparison to correct /detect error with DPC style processing. Also what are the communication protocols used to communicate between processors?

I have updated a detailed reply to Partric on the DIY drones link that explains the evolution of our self developed DPC bus . Check that out .It gives a general idea of how and why the DPC  was created and hardware layering was preferred to software layering that is being used in today's autopilots . The Goal was to create an autopilot that is user friendly & app expandable ( future ready )  

@ Swapnil : we have developed a fused soft iron compensator for the mag which typically when fitted on a drone has around a 5 deg shift in heading at full throttles when ESC wires pass <=5 cm  with no interference at > 5 cm .

@ akhilzid : Now , coming to the EKF part , yes the EKF is a very advanced SLAM algorithm which gives us real-time values in terms of vectoral orientation from the earths axis's instead of our traditional method of XYZ model of our local body. No , I don't implement the entire block of the EKF , but parts of it , like for position hold the calculated velocities from the IMU after normalization and compensation , then X, Y and ecef X , ecef Y is passed thru a preferential gain lead lag filter (where again the auto correlation of the speed accuracy from gps is used as the gain) . I have a nonlinear quadrant calculator which fuses the local frame velocities to global frame based on mag orientation . I did a comparison of algorithmic thru put and speed on an cortex M4 (the discovery board F407Z ) I was using eclipse at the time , I used the EKF from open pilot as it was directly Java/eclipse compatible. my code at the true clock of 168Mhz without delay just running on int main the EKF executed with dummy sensor values  at (370 - 450) uS while my code was at (118-145) uS , yes my code will not be as accurate as EKF as I am calculating pseudo N,E ,D directly from mag heading , while EKF does it using the magnetic flux on each axis and the speed and heading accuracy , but , I can give a faster correction incrementally to achieve an accurate position hold.