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..
Replies
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:
http://ardupilot.org/dev/docs/apmcopter-programming-attitude-contro...
400 hz pixhawk1?
Thomas Butler said:
i suppose that is for an important reasson
Thomas Butler said:
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
@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!