Wednesday, December 20, 2023

Beware the Unlock!

Welcome to my latest blog, created in response to recent CAA proposals in the UK to further restrict drone privileges. It was also prompted by a specific event that happened to me yesterday.

Whilst it may be that you will never apply for 'permission' to unlock a geofenced area imposed by software of your DJI drone, the reality in uber-controlled airspace in countries like the UK is that there will likely come a time when you have to.

I do most of my flying in entirely unrestricted mountain airspace, clocking up well over 1000km flight time just this past summer. Flying in remote areas is under threat, but I'll cover that in a future post. But this week, a notable historic building in my home town burned down; arson is suspected. It's a big story and one I wanted to document, as I have done without drones in the dim and distant past.

Now, the building and its immediate environs lie well outside the legally-defined ATZ of a local airfield - Mona - both a relief landing ground, mostly used for military circuit bashing and, on weekends and evenings, a very small civilian club aerodrome. Here's the CAA AIP map for it (pink/red shade), which would be the document used to prosecute anyone who flew into it or, alternatively, used to defend someone who said they didn't:

But, DJI is always keen to keep western regulators happy. To improve safety, it introduces a 'buffer zone' that adds to the legal definition of ATZs and other restricted airspaces. You can either argue this is a sensible precaution for a mass-produced consumer product, or else an undemocratic undermining of the legally-granted privileges where only map reading and self-discipline is required, as most areas of the law, to comply. I am firmly of the second view and will develop the reasons why later on.

Here, then, is how the Chinese maker, DJI, decides we will fly our drone in this area; I've extended the map to the east a little, because there's a boundary in there (yellow) that is of note:

Now, the building I wanted to capture was ever-so-slightly - maybe 100m at most - within that blue area, essentially along the A5114, where it is labelled directly under 'Llangefni'. 

The blue area, remember, is a DJI-imposed buffer zone which has no legal meaning. Referring back to the first map, the one that UK law defines for us, then you can see that the ATZ boundary lies well to the west of DJI's version of reality. In practice, the difference between UK law and the DJI buffer limit is ~500 metres in radius.

Within the yellow zone, the drone will launch and fly normally without any need to apply for 'permission' from DJI. We will likely get a warning of being near an ATZ and we will additionally be required to confim taking responsibility for the flight. This is clearly a step aimed at trying to preserve DJI's reputation and has very little to do with flight safety. There is never a moment, when in charge of a drone, that you are not fully legally responsible for the safe conduct of its flight. 

The drone will not, however, fly into the blue zone. It will simply come to a slow stop and refuse to go forwards into it. It will fly back home and in any direction not taking it into the blue zone, at least when we have not defined an unlock area, which is where my problems started.

Back to my flight. Here's the indicative (not actual) polygon (red) I drew - very small and limited to the minimum one day - to allow me to get a better view of the burned building. The direction I would fly into the polygon is shown by the black arrow, and the point of launch and intended recovery is at the unarrowed end of the black line:

OK, so my 'permission' came through OK, even though no such permission is required under UK law to fly in this area. We take it for what it is, set off with the drone in my motorcycle's top box, and look forward to some nice photos.

I entered the permitted polygon into the drone, and it reported success. But it wouldn't fly into the blue zone. Something not right, so I returned home to try and reprogram it (can't be done in-flight). Another successful upload of the polygon. This time, the drone did enter - glacially - into the permitted polygon and I was able to move freely within it, as planned. Here's the trace of the flight:


Happy with my sunny-day shots, I manually flew it back home, just a few hundred metres and a few seconds' flying away. All going well, until - BAM! The drone hit a virtual wall in the sky and refused to do anything. It couldn't be flown in any direction under manual control and would not respond to a 'RTH' command from the console. With what would ordinarily have been a reasonable amount of battery left now looking like a critical few minutes to figure-out what to do, things were looking bad!

Taking a look directly beneath the drone, anticipating a forced landing, all I could see was... large trees! Landing into those would likely be the end of my drone, insured for loss though it was. Slowly, I began to realise that the drone, for some reason, could be moved a very few metres either side of its hovering position, but no more. This was my saving grace, because it was just enough to allow the drone to forced-land on a commercial building's - mercifully flat - roof. And this it did, helpfully avoiding some safety wire fixings on the roof as it went about it under automatic control. Getting onto that roof, though, would take me the rest of the day and the help of kindly local roofers with a big ladder.

What happened here?

My guess was that the polygon was either being treated as an area within which the entire flight, including launch and recovery, was 'expected' by software had to take place, or else that the software saw flight beyond any of the polygon's faces from the inside of that polygon as flight into a restricted area, regardless of which direction you were trying to fly in. Even had I launched within the polygon, flying towards its boundary prompted something in the software to prevent the drone flying or even landing anywhere at all except pretty much directly under the point it decided to stop.

Now, my launch took place outside the polygon (and outside any restricted zone, whether mandated by DJI or the law), and there were no warnings or other indications of potential problems ahead. It flew into the 'permitted' polygon and moved around as expected. But trying to fly out of the polygon, returning home, it would not move past the polygon's boundary to the east and whilst moving away from the blue 'buffer' zone. 

From a report I found online, dating from 2018 - more than five years ago - it seems this problem has existed for a long time without being addressed by DJI. It does seem that the polygon, once created, will let you fly into, but not out of it, and has no understanding of which direction, relative to the restricted airspace, you are flying in. All points outside the polygon become, absurdly, defined as verboten.

Now, the drone's software clearly has the inherent ability to 'know' which direction it's flying in and where the restricted airspaces and their buffer zones are - this is the basis for how DJI improves safety by 'geofencing' and, indeed how automated return-to-home works. So why can't it 'tell' it's OK to return to a launch point that is in a direction away from restricted airspace?  There is no sensible answer to this, other than a certain laxity on the part of DJI, unless nobody ever told them about it (I've submitted a report after my incident).

The only workaround would seem to be to fly the entire 'mission' you have in mind that involves a permitted ('unlocked') polygon from within that polygon, including launch and recovery and ensuring that you have the maximum amount of safe landing area within that polygon, just in case things start to go wrong.

The other alternative would seem to be avoiding using unlocking polygons and their equivalents at all.

The problem with all this is that it can invoke the law of unintended consequences: refusing to move past the polygon's boundary - even when perfectly legal and safe to do so - and refusing to respond to commands, could have led to a scenario much less benign than landing on a roof - such as landing into a busy road or railway.

Anyhow, here is what it was all about. An old shire hall, police station and courthouse (separation of powers?), Grade II listed, now burned to a shell. It was due to be 'redeveloped' as flats.

Update - 27/12/2023

DJI have been in touch to offer their apologies for the problem I encountered, also offering a coupon to acknowledge the disruption and inconvenience it caused. They also offered to examine the drone under warranty, but I have declined because it seems to be a software, not a hardware problem. Tests undertaken 26/12/23 in mountainous terrain and involving deliberate signal loss due to that terrain showed that the drone and its software, acting without any permission polygon, acted flawlessly.


 






 









No comments:

Post a Comment

Clickbait Mail

Love them or loathe them, 'audit' videos are undoubtedly a very interesting window on human behaviour and the ability - or usually l...