DUAS xx21

Single Column View
Loss of control following geofence breach

AAIB Report 29335 published October 2024Whilst being operated in a manual flight mode, the unmanned aircraft breached the geofence and changed to an automated flight mode. In response, the remote pilot reduced the throttle and changed back to the manual mode. Control of the aircraft was lost because the mode was changed at a low throttle setting and the subsequent actions to regain control were unsuccessful. The aircraft struck the ground and was destroyed.

The operator no longer uses the manual mode and has promoted the use of standardised phraseology between the ground control station operator and the remote pilot. Further action has been taken to consider and apply a suitably sized geofence for each operational flight.

The Operation Safety Case on which the Civil Aviation Authority (CAA) granted a Specific Category Operational Authorisation was missing definitions and procedures for the use of geofences and actions to be taken in the event of a breach. A Safety Recommendation has been made to the CAA as these omissions have further effect, as the use of a geofence is widely used as a mitigation for several other operational risks.

The Remote Pilot (RP) was undertaking a skills currency flight using a Malloy Aeronautics T150 unmanned aircraft and was assisted by a Ground Control Station (GCS) operator. The RP and GCS operator were in two-way communication via radio. The RP was flying circuits in Stabilised flight mode (stab mode) at a training ground. It is a remote site on farmland used by the organisation he was contracted to fly with, as an R&D and training pilot. The geofence for the flight was 40m high by 300m radius with the centre on the take-off point (see picture). The dimensions of the geofence were not considered by the RP and GCS operator prior to the flight but accepted as a standard training envelope.

The GCS operator noticed the aircraft was approaching the upper limit of the flight geography zone within the geofence and he informed the RP using terminology not immediately understood by the RP. The RP was aware that the aircraft was turning to the right and climbing quicker than he had expected. Shortly afterwards the aircraft breached the upper limit of the geofence and reverted to an automated Return to Launch (RTL) flight mode. The RTL automation initially commanded the aircraft to climb, which the RP instinctively counteracted by reducing the throttle. The GCS operator informed him that RTL mode was engaged, and the RP changed the flight mode, by cycling the three-way flight mode selector switch on the handheld transmitter, to loiter and then back to stab mode.

The aircraft diverged from level flight and was seen to follow an erratic flight path unfamiliar to the RP, during which it achieved a maximum pitch of -41° and -60.9° of roll. To regain control the RP increased the throttle to 100%, which caused the aircraft to overcorrect, and it then pitched to 85.3° with 60° of roll before descending rapidly from a height of 37 m. The RP realised he could not regain control and switched to an automated mode (loiter mode) but by this time the aircraft was heading towards the RP’s ground position, and he decided to close the throttle, bringing it to the ground. Twelve seconds had passed from the geofence breach before the aircraft struck the ground approximately 50m from the RP’s position and within the horizontal boundary of the geofence.

There are a number of points worth highlighting from this report. This isn’t the first occurrence where communication between the RP and the GCS has perhaps been one of the Human Factors that caused an accident. It seems that the initial communication between them resulted in an element of confusion. Perhaps adopting the use of more familiar crewed aviation terminology might have made communication easier?

Fairly quickly afterwards, the RP’s understanding of what the aircraft would do after they toggled the mode switch then exaserbated the problem. If the pilot had known that switching to Loiter and then Stab modes was going to result in the effect that it did, there is no doubt they would not have done it. Perhaps the Operator  should have put more emphasis on ground school/training as well as familiarisation on type. One wonders whether or not latency in the controls was what then led to the final sequence before it impacted the ground.

Geocaging is going to become more important in the future, given the role it will play in Specific Operations such as Atypical Air Environment and BVLOS with Visual Mitigations. Fully understanding what the aircraft will do if it gets close to the cage limts will be an essential part of training. Also, checking the geocage setting should have been part of the pre-flight checks, along with making sure the alerts weren’t inhibited. For the same reasons as mentioned above, the detail described in Volume 2 of the Ops Manual should cover all of the possible iterations of touching the edges of the cage, so pilots can be familiar with what the automated actions of the aircraft will be, if it does touch the edge of the cage.

Finally, choosing an environment a little further from a railway track for training exercises would have probably been a wise move. The aircraft might have landed on a train which, incidentally, could have been well inside the cage! Even if the line marked as 25m from the railway track was part of the OSC, setting the geofence as a 300m radius from the take off spot seems to be inconsistent with what their approvals allowed.