The project ARDUcluster , aimed at safety of drones , has been realized in the form of kits: control board , wiring, firmware , system emergency radio , etc
As you can see in the diagram above , it doubled the navigation control system (in our case PX4 Pixhawk or APM) , are replaced with the wiring between the two Pixhawk and the inclusion of a control board ( Arduino compatible ), which manages the sorting of Power Motor Motor Control Board , the criteria for automatic switch in flight, and controls for the emergency parachute . The card ( ARDUcluster ) also receives the commands of the second transmission system of emergency which has been inserted in the kit .
The dual system of traffic control , redundancy (albeit for emergency ) of the guidance system , the automatic function check before each flight and other integrated solutions provide. That's a considerable improvement of the safety of the vehicle in single fault .
Comments
@ Dan, this is exactly how highly available systems work. They arbitrate amongst themselves and agree which is the master and owns attached resources. They then communicate with attached resources. For this to work on a APM basis you'd need to have a common bus/buses between all sensors, all outputs (ESCs etc) and the APMs. You'd want it to be quick. I also think if we're planning to protect against a faulty APM we'd need a way to prevent it from accessing the outputs, physical isolation style i.e. a relay or similar maybe an H bridge to isolate the signal channels
@Ugo please don't think I'm trying to belittle your work, I think this is excellent I agree we need greater resilience. I do think that if this is to be done right however we can't rely on a single point of failure which the cluster would represent and I stand by my point that this is actually less resilient
Regards
Chris
Chris, what you wrote sounds great - if there was a way to join the 3 FCs together with a high-speed low-latency bus like you said, you could have a really great solution where each PH/APM takes its sensor inputs from its own GPS/Mag/Gyro and puts them on the bus, so all 3 APs have access to all 3's data.
Using this, you could be even more granular than detecting and disabling a failed AP, you could disable a failed sensor and use the data from the other two, even if the active elected AP was the one with the failed sensor.
I agree with Dan the cluster board seems like a single point of failure. Also when the mobile device is used to override both controllers how is flight stability managed, if the commands from the phone aren't fed to the APMs then they will continue trying to correct attitude, position and speed according to their previous settings.
The only way I see this working is if the cluster board is a flight controller in it's own right. So then the questions become how good is that flight controller and what are the odds of it glitching vs the odds of the APMs glitching? Who writes and maintains it's code? Unless it can be demonstrated to be more reliable than the APM you've actually created a weaker system not a stronger one!
Redundancies are great but i see none here. Perhaps a better system would be error correcting/detecting boards with a hot failover ready to take control but this would require ESCs etc and all sensors to be accessible full time from both boards and some arbitration code on the FCs to allow for decision making. You'd need both boards to share both sets of sensors so they can agree between themselves which is valid and which isn't. Better still but even more costly would be using, as was said earlier, at least 3 APMs for this. Maybe sharing MAV data across 3 boards with an arbitration routine and error checking in each board could be implemented with the current board but i suspect the processing overhead would be too high.
This is great, and something I have been thinking about a lot lately, although I was wondering if it would be possible to do in software alone with 3+ Pixhawks talking to each other a la Airbus and Boeing's FBW setup, giving you a primary, secondary and a witness/tiebreaker when there is a disagreement in solution.
My concern here is that you likely still have a single point of failure (your cluster board).
While there is a lot to be said for having dual FCs, I wonder if letting the FCs themselves coordinate control and elect the master might work better? Then perhaps you could have the actual servo wires physically joined together with only the elected master outputting signal at any given time (thereby eliminating the combiner as a potential failure point). Otherwise, you really need to build the redundancies all the way down the line, which would be hard to do except on planes/copters conducive to that (x8?)
Anyway, I think this is a great start to acknowledging the need for redundancies all around. Nice job!
Additional perspectives on this approach to meeting regulatory requirements are available from this article, as referenced on Facebook.
well, I agree, but we are not the ones deciding the rules. anyway a little more security isn't bad
Because buying motors and escs 4 at a time wasn't making me poor enough!
Seriously, good work!
Prestissimo metteremo la scheda tecnica sul web. (è in revisione)
Non lavoriamo con la resilienza (sarebbe complesso ed eccessivo) ma semplicemente valutando i canali pwm di uscita da pixhawk. A breve vi spiego tutto
Hi Max,
Looks interesting.
How does the cluster determine which pixhawk is faulty out of the two ? Normally to do this you need a voting system with minimum 3 (or 5 like what planes use for double failure resilience)...
-
1
-
2
of 2 Next