Software Bug and High Winds Down Drone
The UK Air Accidents Investigation Branch (AAIB) has reported on an accident involving a 2.4kg Aeryon Skyranger R60 Unmanned Air System (UAS) / quadcopter drone serial number SR9112798 on at 03:30 Local Time on 18 January 2018 at Brixton, London.
The Accident Flight
The AAIB report that:
The UA [Unmanned Aircraft] was being operated in a built-up area at night, with appropriate authorization from the CAA. It was carrying a camera and was being operated by a pilot and observer. Both the pilot and observer had received training on the Skyranger R60 and been issued with the appropriate permission by a CAA National Qualified Entity. They were however relatively inexperienced at operating UAS at the time of the accident.
Prior to the flight, an inspection of the area was carried out to identify suitable takeoff and landing sites and to check for any local hazards. A check of the UAS was also completed with no faults identified.
Flight settings were loaded into the ground control unit, with a programmed maximum operating height of 121 m. The pilot stated he then lifted the UA into a 1.5m hover to complete calibration and safety checks, which all proved satisfactory. The UA was then climbed towards its planned operational height, but as it reached a height of about 50m it started to drift and the ground control unit displayed a ‘Strong Winds [N10]’ message . The UA, unable to hold position, then drifted out of sight over an adjacent five-storey building, generating a ‘Position Control Warning’.
Aware the UA was not following the intended flight track the pilot moved to regain sight of the UA without success.
The ground control unit then indicated a loss of control signal. The UA camera image was lost and the control screen switched to the home screen, with no apparent connection indicated with the UA. The UA did not return to the pre-programmed home position (the takeoff point) and a search of the local area revealed the UA had impacted the ground about 30 m from the take-off site, breaking into several pieces.
The Safety Investigation
The UA’s internal data storage card was damaged on impact, preventing data recovery. Flight logs recorded on the ground control unit and video imagery was however recovered.
These indicated that after the control link was lost, the UA went through a number of direction and height changes before descending and impacting a tree top at a height of approximately 15 m, then falling to the ground.
The system was loaded with that the manufacturer had become aware on 23 December 2016 contained an error that would become evident when “a ‘non-fatal’ message was generated and the UA became unable to hold position”. In this occurrence the drone had automatically entered the ‘return home’ mode when the high winds prevented it holding station. This error…
…resulted in the UA considering it was over its home position, regardless of its actual location, and landing. A software fix was completed on 6 June 2017, but this was not made available until the manufacturer’s software Version 3.7 was released on 8 January 2018.
The operator did not have ready access to gain this software upload according to the AAIB, and even if they had the accident occurred just 10 days after this non-mandatory upgrade was issued.
The manufacturer was aware of only one other incidence of the error occurring operationally and believed the conditions required to trigger it were sufficiently rare that the delay would not pose an undue risk to operators.
The drone’s user manual states that it can operate in sustained wind speeds of up to 65 km/hr (35 kt) and gusts of 90 km/hr (48 kt). The AAIB comment that:
Forecasts for London City, Heathrow and Gatwick Airports indicated the risk of strong south‑westerly winds at the time of the intended UAS flight, along with a risk of rain. The nearest airfield to Brixton that had a valid TAF at the time of the incident was London City and the TAF issued at 0306 hrs gave a risk of winds blowing from the west at 25-30 kt with gusts of 40-50 kt from 0300 hrs until 0800 hrs. London City produced METARs at the time of the incident, and at 0320 hrs the wind was from 250° at 30 kt mean with gusts of 47 kt. At Heathrow, the second closest airfield to Brixton, at 0320 hrs the wind was from 260° at 31 kt with gusts of 45 kt.
The pilot and observer used the Gatwick TAF and a weather app to obtain wind speeds in planning the flight. Both provided only forecast data. The app-predicted wind speed at the time of the flight was 42 km/hr (22 kt) with gusts of 77 km/hr (41 kt) at ground level.
Recorded data from the UA “indicated that sustained wind speeds in excess of 65 km/hr were experienced approximately 75 seconds into the flight for about 20 seconds.
The data recovered from the UA indicate that after takeoff, when the UA left the shelter of the surrounding buildings, it experienced wind speeds above its design limit and was unable to hold position. …the most probable cause of the loss of link between the UA and the ground station just after the wind warning occurred was the fact it drifted out of radio line of sight.
Whilst the low height at which the UA was blown over the building contributed to the attenuation of the radio signal, the siting of the ground station and the height and proximity of the building would still have provided a potential issue in maintaining a strong signal between the ground station and UA had it achieved its proposed operating height.
Having lost its ability to hold position, with no command made by the pilot in response, the UA should have attempted to return to its home position, which in the strong winds would have proved difficult.
The combination of the wind and position warnings, with the return home function triggered, caused the software error to make the UA attempt to land immediately, rather than to return to the home position in order to do so. The UA descending contributed to the loss of signal, after which the UA was committed to try and land, resulting in the collision with the tree and the subsequent impact with the ground.
Had the UA remained in visual line of sight, not only should it have been obvious to the pilot what the UA was doing, but he should have had the ability to take over manually to try and return the UA to the home position or find an alternative safe place to land.
The AAIB comment that:
The manufacturer had taken six months to provide a software fix to the problem and a further six months to release it. The delay in doing so was due to the consideration by the manufacturer that the failure was unlikely to occur, and by inference was not critical to the safe operation of the UAS. The delay was further compounded by the fact the operator was not aware of the software problem or the fact that an update existed. As the UAS was not required to be certified, due to its low weight, there was no oversight of these aspects by the relevant authorities.
This accident demonstrates some of the issues associated with this emerging technology. New operators with little, or no, previous aviation experience are still developing procedures whilst operating small UAS which do not require certification due to their relatively low weight. The combination presents a challenge which operators, manufacturers and regulators will continually need to monitor and develop to ensure the safe operation of this expanding area of aviation.
The operator carried out a “comprehensive review of their procedures” and liaised with the manufacturer on the technical aspects of the accident. They have taken actions that have included:
- Ensuring software checks and updates are integrated into the maintenance procedures.
- Ensuring at least one member of the operating team is experienced in operating the system and introducing a mentoring scheme to provide opportunities to increase experience levels with appropriate oversight.
- Providing information on the most appropriate sources of weather information to be used in planning and operating flights and ensuring these take into account actual, as well as forecast, weather conditions.
- Providing pilots and observers with training on weather effects experienced in a built-up environment, especially related to wind.
- Introducing reduced wind limits on the operation of UAS to allow a safety factor, mitigating the risk of exceeding the limits. These will also be varied to take account of each pilot’s experience.
- Revised training on the assessment of ground station transmitter siting to minimise the likelihood of signal loss.
- Review of incident and accident reporting procedures.
- Drone Goes Walkabout: Hemispherical Human Factors Hiccup: On 27 September 2016, a 55lb / 25kg Pulse Aerospace Vapor 55 Remotely Piloted Air System (RPAS) / Unmanned Air System (UAS) or ‘drone’ helicopter, suffered a Loss of Control (LOC) was operating a trial flight at Lighthouse Beach, Ballina, NSW after a navigational programming error.
- Facebook Aquila Drone Accident: Gust Induced Structural Failure: On 28 June 2016, while making its first flight, the Facebook UK Aquila 1A unmanned aircraft, N565AQ (serial number F1501), experienced an inflight structural failure on final approach near Yuma, AZ. The damage was induced by wind gusts say investigators.
- EASA Issue Drone Safety Risk Portfolio and Analysis: The European Aviation Safety Agency (EASA) has issued their analysis of the main safety risks involving Unmanned Aircraft Systems (UAS) / Remotely Piloted Air Systems (RPAS) / Drone operations.
- UPDATE 28 August 2019: Drone Operation Injury: NTSB examine an injury caused after the loss of control of a UAS during a university demonstration.
- UPDATE 12 January 2021: Inspection UAS Collides with PNG LNG Export Jetty
- UPDATE 12 April 2021: USAF MQ-9A Reaper Lever Confusion: Human Factors