Redundancy systems & How Ardupilot use the failsafe co-processor of pixhawk hardware

Hi, i always had the question on how to manage a complete failure of Flight Control systems

i kow some implementations on extra procesors asisted systems are implemented in a great group

of modern and old flight controllers.

So for example, i think its interesting have 2 FC in the same structure, so if one is ded the other one

continues....thats already implemented on pixhawk in a diferent way

so with the schematic "B" we have 2 pixhawk with one gps..

so in that way we have an optocopter with 2 pixhawks...

It apears to be that Ardupilot Software dont use the co-processor of the pixhawk system..

So, i would like to know more abut that...

Ardupilot really uses the Co-procesor in case the principal fails,?or not...

https://drive.google.com/open?id=1tZjIiO1oVAjPgcDBHmWMShjnuNodMo4t

thanks a lot for comment..

Views: 173

Reply to This

Replies to This Discussion

@Alberto, First, there is NO redundancy in the Pixhawk. Yes it has a second CPU, but it does nothing for redundancy. Yes it has two gyros, but that does nothing for redundancy. There have been LOTS of engineering on redundancy in aircraft flight control. To start see the Space Shuttle redundant computers treatise.. Next read this discourse "Why Flight Critical Systems are Redundant."

Those readings should answer your question. These are all about OLD technology. Today's technology is at least two orders of magnitude more reliable. Note the B MAX failure was attributed to a fundamentally crude mechanical flipper tilt sensor which got JAMMED by a bird strike and they had NO redundancy!

The relatively low cost of flight controllers like the Pixhawk/PX4/SPRacing, et al. make the implementation of a "space shuttle" level of redundancy a tempting academic exercise. However, one has to look at what has the highest probability of failure, and it boils down to the MEMS tuning fork gyros (I'm only talking computers/sensors here. We know the cables, power supplies, and other DIY FC related stuff are cheap junk which is easily mitigated)The simplest solution is to read three gyros and compare. Two gyros with nearly the same output would be the value used. Unless of course the values are wild; i.e, zero, etc. For 99.9999 reliability we would need five sensors, but lets be realistic about potential for failure. A side consideration is what is the payload; high value cameras, people?  Maybe we just want to be assured our cheapo $40 FC isn't going to crash and wreck our $500 GoProng.

A "space shuttle" level of redundancy would use multiple FC boards with their own sensors and sharing software whereby each FC can compare what it has with what is output by the other controllers. One design problem with the Pixhawk and its associated firmware is the native processing of sensor data. This is VERY inefficient of CPU resources. A pre-processor should sample the data, fuse it, and provide attitude data at about 200hz (think of the old ArduIMU). The Pixhawk/PX4 wastes tremendous CPU time processing data in Kalman filters; try a simple soft mounting of the sensors and then sample sufficiently high to filter the mechanical noise/vibration. With a flight controller using a "smart IMU" that samples at 8khz and feeding normalized data at 200hz or better, the FC has more than enough processing power to compare shared data from redundant flight controllers. There is no real reason for a FC to be doing low level sampling of a sensor.

Note using a "supervisor" CPU to judge the outputs of multiple FCs add in the failure of itself to the equation;lowering reliability. What if the supervisor fails?

Someone at DoD/DIUx said to me last year when I did a presentation after I said my flight controller uses a 300MHZ CPU, why do you need so much CPU processing power? This is why. To perform innovative flight control tasks that have not been thought of yet, or were deemed TOO complicated for a typical STM32xxx flight controller. 

Look at the PC we run today. Who would have thought we would need an i5-2400/3GHZ CPU! Windows 10 is a version of Windows that FINALLY works. All the previous versions were just a scam and Gates owes us all $5k...

Now we have the cheapo Chinese STM32F7s (216MHZ) and on the horizon, the Cheapo Chinese STM32H7s at 400MHZ. (FYI no hardware crypto on STM chips from China[no crypto technology to China; trade restrictions])

Believe me someone will find a way to use up all the gobs of processing power! 

Happy flying!

First of all thank you very much for answer Thomas.

Yes, i know that its the IO witch operates the main pwm and the RC imput. (comunicates with the main via serial..)

And it apears to the tat the bypas function its only present on plane software for logical reasons...

You said: "The Pixhawk/PX4 wastes tremendous CPU time processing data in Kalman filters; try a simple soft mounting of the sensors and then sample sufficiently high to filter the mechanical noise/vibration. With a flight controller using a "smart IMU" that samples at 8khz and feeding normalized data at 200hz or better, the FC has more than enough processing power to compare shared data from redundant flight controllers. There is no real reason for a FC to be doing low level sampling of a sensor."

and i found that very intresting of course, the main FC shoul only be used to "flight", and yes i know how important is time resources in computing...

other important thing is how threading is used i gess...

thank a lot for the comment it helps  meto learn more

i suppose that is for an important reasson

Thomas Butler said:

This is VERY inefficient of CPU resources. A pre-processor should sample the data, fuse it, and provide attitude data at about 200hz (think of the old ArduIMU). The Pixhawk/PX4 wastes tremendous CPU time processing data in Kalman filters;

Finally one more important think to say

the technology of which we are speaking is used for delicate things
like transport of human organs
 
https://discuss.ardupilot.org/t/powered-by-ardupilot-first-ever-dro...


Thomas Butler said:

A side consideration is what is the payload; high value cameras, people?  Maybe we just want to be assured our cheapo $40 FC isn't going to crash and wreck our $500 GoProng.

In that case, use a car or helicopter. Do you want to trust delivery of a kidney to a little quad-copter; I think not!

Alberto Vila said:

Finally one more important think to say

the technology of which we are speaking is used for delicate things
like transport of human organs
 
https://discuss.ardupilot.org/t/powered-by-ardupilot-first-ever-dro...


Thomas Butler said:

A side consideration is what is the payload; high value cameras, people?  Maybe we just want to be assured our cheapo $40 FC isn't going to crash and wreck our $500 GoProng.

That 400hz is the process control loop rate which in the Pixhawk (STM32F4 at 216MHZ) and 100hz in APM (16MHZ Atmel2560) would roughly correspond to the ESC input update rate; how fast the control loop can spit out ESC values. The software is running as a state machine spending much loop time checking for this and that and performing low-level time-consuming sensor fusion and acquisition, flight trajectory/fl;ight plan processing, etc. As opposed to being event driven.

50hz to 200hz refresh is all that is needed to run ESCs in a quadcopter. 200hz is very good. A typical PWM input ESC (1.5 to 2ms PWM) is limited to about a maximum 490hz input update.

Anything over 200hz update to the ESCs is just overkill for cargo/camera multi-rotor drones. 50hz would suffice for planes which does not have the real-time attitude stabilization requirement. Inertia of the motors/props limits response.


Alberto Vila said:

Reply to Discussion

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service