Loss of operator control involving an Aeronavics SkyJib 8 remotely piloted aircraft, near the Melbourne Cricket Ground, Melbourne, Victoria, on 29 March 2015

What happened

On 29 March 2015, an Aeronavics SkyJib 8 remotely piloted aircraft (RPA) (Figure 1) was being used to assist with media coverage of the International Cricket Council World Cup Final, at the Melbourne Cricket Ground (MCG), Melbourne, Victoria. The RPA was being operated from the top of the south-western scoreboard of the MCG. The operating team consisted of:

• a flight controller, who piloted the RPA
• a ground station controller, who performed a range of functions including monitoring the position of the RPA and providing a back-up control for the flight controller
• a camera gimbal controller, who controlled the camera mounted beneath the RPA.

Figure 1: RPA prepared for flight with camera mounted beneath

Source: RPA operator

The accident flight followed four earlier uneventful flights that day. The crew completed all pre-flight checks^[1] and made broadcasts on appropriate air traffic frequencies, then launched the RPA at about 1430 Eastern Daylight-saving Time. On this particular flight, the operator intended to capture footage of the MCG and surrounds as the competing teams entered the MCG and during the pre-match ceremonies. The RPA’s take-off and departure were normal. The RPA was flown slowly southward toward Hisense Arena (Figure 2), climbing to a height of about 300 ft above ground level. The route was similar to that flown during earlier flights, without incident. All three control systems (flight control, ground station control and camera gimbal control) appeared to be functioning normally during the departure and transit to Hisense Arena.

About 2 minutes into the flight and soon after the competing teams entered the MCG, with the RPA over the northern roof of Hisense Arena, the camera gimbal operator lost control of the gimbal. The gimbal operator reported the loss of control to the other team members. Several seconds later, the ground station controller also lost communication with the RPA. At that point, with the RPA moving slowly southward over Hisense Arena, the flight controller made a decision to discontinue the flight and return the RPA to the top of the scoreboard. The flight controller made appropriate control inputs but found that the RPA was unresponsive, and it continued to move slowly southward.

Having lost normal control of the RPA, the flight controller commenced alternate RPA recovery procedures. The flight controller switched from GPS to attitude mode,^[2] but was still unable to control the RPA. The flight controller then activated the ‘return to home’ function, but this was also ineffective. The flight controller then reverted to manual control,^[3] in an attempt to recover control of the RPA, but the RPA remained unresponsive. Throughout this time, the ground station controller continued attempts to re-establish communication with the RPA, also without success.

About 20 seconds after the initial control problems, the RPA commenced travelling at medium speed in a westerly direction, and began slowly descending. The flight controller continued attempts to re-establish control by switching between control modes and again activating the ‘return to home’ function, but all attempts were unsuccessful. When the RPA reached a point south of Rod Laver Arena, it appeared to cease lateral movement and stabilise just above treetop level. Continued attempts by the flight controller to regain control were unsuccessful, and the RPA descended beneath the treetops, out of sight of the controlling crew.

The RPA collided with terrain on the median strip on Batman Avenue to the south of Rod Laver Arena, a little over 3 minutes after the flight had commenced. The operating crew had maintained line of sight with the RPA until it descended beneath the treetops. Initial control difficulties were experienced when the RPA was just over 200 m from the position of the operating crew. The collision with terrain was about 450 m from their position (Figure 2).

There were no injuries to people on the ground, and no damage to other property, but the RPA and associated equipment were substantially damaged during the collision.

Figure 2: Approximate flight path of the RPA, from the take-off location on top of the south-western scoreboard at the MCG, to where control was lost over Hisense Arena and the collision location on Batman Avenue

Source: Google Earth with additions by the ATSB

Operator’s approval and risk assessment

The operator had approval from the Civil Aviation Safety Authority to operate the RPA near people and over populous areas while taking aerial photography during the event. The approval included a number of conditions related to such things as RPA control capabilities, the operating area and the operating environment. The operator had also conducted a risk assessment relevant to the flight during which the accident occurred. This assessment included consideration of a range of environmental factors, and outlined a number of risk mitigation measures. Among other things, the risk assessment included consideration of:

• weather conditions that may affect control of the RPA
• light conditions that may affect the ability of the operating crew to maintain visual contact with the RPA
• the intended flight path with respect to the location of people and property
• the location of structures, other obstacles and other air traffic that may affect the flight
• the adequacy of emergency procedures and possible equipment failure modes
• the operating environment in terms of noise and possible distractions (operating crew and members of the public).

Operator’s investigation

The operator investigated the accident, with a particular focus of establishing the reasons for which control of the RPA was lost. The investigation included consideration of a number of system-related and environmental factors, and the behaviour of the RPA following the loss of control.

The operator’s report concluded that radio frequency interference was the most likely cause of the accident. The volume of radio frequency traffic at the time of the accident was probably substantial, and perhaps sufficient to override RPA control signals. Numerous fixed telecommunications facilities and mobile broadcast vehicles in the vicinity of the MCG were probably transmitting at the time of the accident. Over 93,000 people attended the event, many of whom were probably using personal mobile communication devices at about the time of the accident. Furthermore, the use of portable communication devices by event management personnel (such as security and emergency services personnel) may also have contributed to the volume of radio frequency traffic.

The operator considered that the behaviour of the RPA was consistent with signal interference or confusion, rather than signal loss. In the event that the signal was lost, the RPA would have entered a fail-safe mode. In fail-safe mode, if the RPA had a valid GPS signal it would have returned to the starting point and landed. Without a valid GPS signal, the RPA would have held position, then descend slowly in that position, until touch down. Additionally, the operator found no evidence that there was any fault with the RPA control systems or any hardware issues, which may have resulted in the loss of control.

The operator’s investigation report commented that very similar operations had been conducted without incident prior to the accident flight. On this particular flight, the scale of the event, and probably the amount of associated radio frequency traffic, were more substantial. The operator’s report also acknowledged that further testing and analysis was required before the primary cause of the accident could be confirmed beyond doubt.

Safety action

As a result of this occurrence, the RPA operator has advised the ATSB that they are planning further tests to better understand the nature of the loss of control of the RPA. A better understanding of the nature of the problem may allow identification of engineering measures to reduce the risk associated with the possibility of radio frequency interference.

The operator also intends to review procedures and update risk assessments considering the circumstances surrounding this accident.

Safety message

On this occasion, the available evidence suggests that a high volume of radio frequency traffic compromised RPA control and communication functions. This accident highlights the need for careful consideration of ‘what might be different this time’ during risk assessments, including the identification of appropriate risk mitigation strategies. Although the operator had conducted a risk assessment for the accident flight, the possible effects of a substantial increase in the volume of radio frequency traffic had not been specifically considered.

In a broader sense, this accident highlights the ongoing importance of appropriate RPA operational controls and procedures. These are particularly important where operations are intended in the vicinity of populated areas or other air traffic. The careful application of operational controls and procedures, underpinned by robust risk assessment, will become increasingly important as relevant technologies develop further and new RPA applications continue to emerge.

Important information for RPA operators, including information about relevant regulations, operational approval requirements and RPA associations, is available on the CASA website.

Aviation Short Investigations Bulletin - Issue 42

Purpose of safety investigations The objective of a safety investigation is to enhance transport safety. This is done through: identifying safety issues and facilitating safety action to address those issues providing information about occurrences and their associated safety factors to facilitate learning within the transport industry. It is not a function of the ATSB to apportion blame or provide a means for determining liability. At the same time, an investigation report must include factual material of sufficient weight to support the analysis and findings. At all times the ATSB endeavours to balance the use of material that could imply adverse comment with the need to properly explain what happened, and why, in a fair and unbiased manner. The ATSB does not investigate for the purpose of taking administrative, regulatory or criminal action. Terminology An explanation of terminology used in ATSB investigation reports is available here. This includes terms such as occurrence, contributing factor, other factor that increased risk, and safety issue. Publishing information  Released in accordance with section 25 of the Transport Safety Investigation Act 2003 Published by: Australian Transport Safety Bureau © Commonwealth of Australia 2015 Ownership of intellectual property rights in this publication Unless otherwise noted, copyright (and any other intellectual property rights, if any) in this report publication is owned by the Commonwealth of Australia. Creative Commons licence With the exception of the Coat of Arms, ATSB logo, and photos and graphics in which a third party holds copyright, this publication is licensed under a Creative Commons Attribution 3.0 Australia licence. Creative Commons Attribution 3.0 Australia Licence is a standard form licence agreement that allows you to copy, distribute, transmit and adapt this publication provided that you attribute the work. The ATSB’s preference is that you attribute this publication (and any material sourced from it) using the following wording: Source: Australian Transport Safety Bureau Copyright in material obtained from other agencies, private individuals or organisations, belongs to those agencies, individuals or organisations. Where you wish to use their material, you will need to contact them directly.

__________

1. Pre-flight checks included confirmation that the GPS had acquired a sufficient number of satellites, the RPA ‘home lock’ feature was functional, and that battery systems were fully charged. The ‘home lock’ feature allows the flight controller to command the RPA to return to its starting point, using the flight control system ‘return to home’ function. The ‘return to home’ function uses GPS information to command the RPA to return to its starting point.
2. GPS mode provides RPA position and attitude stabilisation, while attitude mode provides platform stabilisation without GPS position stabilisation. In attitude mode, control inputs are required to counter the effects of wind. The control mode will switch automatically from GPS mode to attitude mode after a set time if the GPS signal is lost.
3. Manual mode is the most basic form of RPA control. In manual mode, the RPA is controlled by flight control stick inputs, without position or attitude stabilisation.