Do your emergency procedures make any sense in the real world?
This is a blog aimed fairly and squarely at those UAS operators working against an operations manual. This usually means that you hold a GVC (or legacy NQE recommendation) and have therefore gone through some groundschool training either face to face or online.
The next step after your training is usually that you are provided with a templated Operations Manual containing, amongst other things, a set of emergency procedures. These lay out, step-by-step, how the remote pilot and any other crew are expected to react in an emergency to mitigate the risks associated with the specific scenario.
The emergency scenarios the CAA want you to deal with as a minimum are detailed in CAP722A section 4.12 and will be familiar to anybody who has used drones professionally over the past few years.
The problem is that some emergency responses appear to have been written by somebody who doesn’t understand the how people react to verbal instructions.
For many of the emergencies, where members of the public (or “uninvolved people”) may be at immediate risk from a plummeting drone, the emergency procedure will specify a “call” that must be shouted by the remote pilot or other appropriate member of the team. In many cases, the call for a catastrophic failure is “UAV FAIL” or similar.
Have a think about that for a second.
A drone is dropping from the sky, possibly from 50 to 120m. This gives the person underneath between 3 and 5 seconds to get out of the way. You can’t assume they know that a drone is operating above them unless they have been specifically brought under your control. Even if they have been warned, they may have a hundred more important things on their mind when you or your spotter gave them a garbled explanation of what may be going on with a drone. It is unlikely they will see it as an existential threat…after all, you’re allowed to operate it in a town centre so it’s fool proof, right?
The drone is coming down, possibly silently, possibly noisily (but faster than expected because not all drones cut the motors when they lose a corner and flip…they continue to drive their props and pull themselves towards the ground. The sound may alert the uninvolved person, causing them to look up. Depending on the circumstances this could just mess up their face for the foreseeable future or, depending on the impact force (dependent in turn on the mass of the drone), it could break their neck. Best avoided.
Not to worry, you or your spotter, has just spotted that the drone is in trouble and shouted, “UAV FAIL”. Possibly loudly enough for the person to hear. Your initial reaction time was probably around a second. After all, you’ve been flying for years and nothing like this has ever happened before. Complacency has almost certainly set in. You may even have been glancing at the screen when the failure occurred and spent another second looking up to check that the screen is reflecting reality. None of this is unexpected or unnatural in any way.
So, we are two or three seconds into your emergency already. If the drone was low, it may already have hit the victim. The first second was you looking up toward the drone and failing to find it. The second was you realising you need to do something and working out what it is. The third is you shouting “UAV FAIL” just as it says in your manual.
Unfortunately, although you know exactly what you mean by the words “UAV fail”, no ordinary member of the public has a clue. It takes too long to call and means nothing to its intended audience.
Why the hell is it in your manual?
Time for a review
Have a think about the scenario above. There are some aspects that are difficult to overcome. Gravity is, unfortunately, outside your of control, so the speed of descent (short of a parachute system) isn’t something you can readily mitigate against. There are mitigations for overflight but we are assuming here that we are in full emergency mode and there are unavailable or have failed.
What you can do is use a very different call. You need something that can be called very loudly (so a more “plosive” sound than the “U” in “UAV” fail is essential). It also needs to be easily understood by anybody who hears it, assuming there are no language or disability barriers.
My favourites would be “DOWN!” or “MOVE!”
It is possible to shout these at an incredibly high volume. I have caused visible shock among small groups of people being safety briefed even when they knew I was about to call it. Both can have a visceral effect and as they can apply to a range of emergencies – not just drones) then they may be more likely to get a response from uninvolved people. “MOVE” is probably more likely to get somebody out of the way quickly but is slightly harder to shout at such a high volume and isn’t as urgent a call (in my opinion). Either is infinitely better than “UAV FAIL”, “UAS FAIL”, “SUA FAIL” or any of the standard drone related calls. In fact, if anybody shouted UAV fail or SUA fail at me out of the context of my own flight operation,, even with my background I would take a few seconds to process it.
Change your approach
Looking at the advice above, there is a clue to a better approach to your manual. Just use your imagination and picture real-life scenarios. Do this for every aspect of your manual and it will serve you far better. When you are next doing a job, make a note of the order you naturally do things like your pre-flight checks. Better still, get your spotter to make notes for you. What exactly do you do and in what order? It may well not be the same as in your manual…so change your manual to reflect your real-life procedures.
Run through all of your emergency procedures and check the logic of them. Would you really press the RTH button in the event of satellite loss? It won’t work, but hey, fill your boots. Think through the impact of each emergency scenario on the equipment and people concerned and then adjust your procedure appropriately. It will make them more relevant, easier to remember and safer for the public and your reputation.
If you found this useful and are in the process of updating your operations manual then you may find these other two blogs handy: