We are going through a BVLOS certification process and regulators want me to solve this question:
Suppose the autopilot software or hardware crashes or becomes unresponsive, and for some reason the aircraft keeps its PWM outputs on and starts a fly away. How would you terminate the flight?
Our setup is a hexarotor running Cube Black with a companion computer with dedicated battery and a parachute that opens autonomously after detecting a fall. My understanding is that the regulators wants us to kill the aircraft by cutting power to the autopilot or cutting power to ESCs, or blocking PWM signals to ESCs.
With an unresponsive autopilot scenario, there is no point in trying to send commands from the c.computer or switching modes. How would you solve this? Is there any way to externally to externally reboot the autopilot, or cut signals to ESCs? @philip
@TunaLobster Thanks for your suggestion, but that logic is still running inside the autopilot code. If for some reason the autopilot crashes, I have to assume that the AFS routines will also be broken. So my question is if you have any other external ways to cut power to ESCs or disable/kill/reboot the autopilot from the companion computer.
If you are using a firmware that has the watchdog enabled on the FMU it will try to reboot. The AFS has worked in the past for BVLOS and Outback Challenge so Iām not sure what more the aircraft could do? You could find an ESC that has a programmable failsafe function I guess.
I like the question and wonder if this would work for you. Either for power shut off or somehow hooked to the safety switch would be ideal.
These I use for gas planes to kill the engine with a rc channel.
First of allā¦ the structure of a cube black consists of two processors
The FMU, this is the Autopilot, and all communications.
The I/O processor
The I/O processor is designed to allow you to bypass the FMU if you need to due to it failing for any reason.
You can send whatever you want to the I/O and have it bypass the FMU.
Things to think aboutā¦
If the reason for this is āsafetyā what makes the addition of a FTS āsaferā than a proven flight controller?
An external parachute controller, rather than the ardupilot parachute controller, lacks the information from the EKF to guarantee it has exact knowledge of the flight attitudeā¦ how can you guarantee an unproven addition is safer than the built in systems?
If you need to do thisā¦ utilise the pass through features of ardupilot and take advantage of the I/O processor. Itās the most proven piece of hardware in this industry. The onboard code is simple, and has an excellent safety record.
We used to use a watchdog board that monitored the FC, radio link, RC link, and controlled other externals via serial. It was programmed to terminate the flight if any parameters were violated.
Great in theory, but it just adds another point of failure.
If you have a triple redundant FC, as @philip describes, then your best bet is to use its capabilities, but ensure the weak link, your power system, is as bullet proof as you can make it.
Large commercial stuff I build can have up to 5 BECās on them to ensure power consistency and redundancy for the different circuits.
Where āgovernmentā regulations state additional redundancy we also carry a small battery to power the electronics in case of main battery failure (blown or melted battery monitor module is the only time this has happened) but that is only useful to activate the parachute when the EKF detects it is in free fall.
There is a big difference between whatās practical and what regs require.
Most important is the wording of your safety case to the regulatory body.
They want to know you are safe.
Their regulations are worded in such a way as to make you cover your arse and theirs.
But the regulations are not an instruction book as to how.
So you need to do the work to determine the safest method of de-risking your activities. Doing a risk assessment on each failure mode, itās chances of happening, and the consequences if it does.
Show them how you have made your system as safe as possible.
The general rule is to ensure that no additional risk than that posed by existing regular aviation is caused.
Ieā¦ if you are replacing a helicopter or fixed wing manned vehicle for the operation, your operation should be of no greater risk to the community than the manned operation assuming the manned operation is run by competent people. Ie, just because someone does something stupid in a manned mission, doesnāt lower your responsibility to do it safely
@samucs, we are currently finalizing a (patented) small module that works as a kill command (+parachute release). Our country laws impose for drone pilots to be able to shutdown the drone in case of fly-away (with independent system). If you want, you can contact me.
@philip Thanks for your points, we are already doing a very detailed risk assessment for the whole operation. As @Julien said, we must be able to shutdown the drone with an independent system which could be the companion computer sending a command to the carrier board for example. I believe many countries have similar laws.
@philip I will have a look at the I/O Processor recommendation. Could you point a documentation or wiki where we can learn more about using it? The idea would be to stop the motors if the FMU crashes.
