Loss of control during taxi, involving RF Designs Mephisto, remotely piloted aircraft, Bruhl Airfield, 2 km south-west of Tara, Queensland, on 19 June 2020

On the weekend of 13‑14 June 2020 a team of remote pilots and maintainers from Remote Piloted Systems (the operator), RF Designs (the maintainer) and a client company arrived at Bruhl Airfield, 2 km south-west of Tara, Queensland (Figure 1). Over the weekend they set up and prepared for a week of test flying of two autonomous test bed aircraft, the RF Designs Albatross and the RF Designs Mephisto (Mephisto). The aircraft were assembled, following disassembly for transport, and systems tested prior to operations commencing on the Monday morning. This work was overseen by the operator’s chief remote pilot (CRP) and a senior manager of the maintainer.

Figure 1: Location of Bruhl Airfield

Source: Google Earth annotated by the ATSB

Throughout the following week the team conducted multiple test and evaluation flights for the client each day. These usually involved multiple aircraft and multiple pilots through the launch (take-off), mission, and recovery (landing) phases.

On the morning of Friday 19 June, the final operational flights were carried out for the client company. Following this, the client’s personnel commenced packing up and preparing to depart the site. With all relevant permissions and approvals in place, the operator’s CRP took the opportunity to conduct post maintenance test flights on Mephisto HP001, to ensure that it was airworthy and prepared for future operations. During the week, HP001 had undergone maintenance which included the aircraft’s flight controller being removed and reinstalled following its use in another Mephisto aircraft.

The flight plan for the test consisted of two flights, testing all three of the aircraft’s modes (see the section titled Aircraft operations), and the flight controller setup and tuning. The first flight was to involve a launch in manual mode, followed by a circuit and recovery in fly by wire (FBW) mode. If the results of this flight were acceptable the aircraft was to be repositioned to the western end of the runway for the second flight. There it would be transitioned to autonomous mode and conduct a fully autonomous launch, circuit, and recovery.

At 1242 Eastern Standard Time,^[1] HP001 was launched, with both flights completed without incident. Figure 2 shows the Global Positioning System (GPS) tracks of the aircraft during the first and second flights with the track colour indicating the aircraft’s mode. Figure 3 shows the transition between the flights and the completion of the second flight, the initial taxi, loss of control and the recovery.

Figure 2: Mephisto test flights 19 June 2020

Source: Google Earth and operator annotated by the ATSB

Following the autonomous recovery at the conclusion of the second test flight, the pilot attempted to transition the aircraft out of the autonomous mode and back into manual mode for taxi to the hangar. The pilot toggled the automatic mode switch and increased the throttle setting to provide thrust to taxi the aircraft. Once the aircraft had sufficient momentum to allow for the taxi the pilot attempted to reduce the throttle setting. However, the aircraft did not respond to the pilot’s commands and the turbine engine continued to accelerate.

The aircraft was now in relatively close proximity to the pilot and moving towards other personnel who had been observing from nearby. The pilot considered arresting the aircraft by hand but, due to the aircraft’s speed and momentum, they determined that was not practical. The pilot re‑toggled the automatic mode switch, allowing them to regain control. With the aircraft back under control, the pilot directed the aircraft across the runway to the southern side of the airfield away from the hangar and personnel. The aircraft was arrested, at low speed, by the airfield boundary fence.

The aircraft was then attended by the pilot and several other personnel who conducted a normal shutdown before pushing it back to the hangar for inspection. The inspection determined that the aircraft only had minor damage to the skin due to the impact with the fence.

Figure 3: Mephisto test flight 2 - occurrence flight

Source: Google Earth and operator annotated by the ATSB

__________

1. Eastern Standard Time (EST): Coordinated Universal Time (UTC) + 10 hours

Aircraft information

The RF Designs Mephisto remotely piloted aircraft (RPA) (Figure 4) is a high-performance autonomous testbed aircraft. First flown in 2019, it is based on the CARF-Models Mephisto large model aircraft and modified by RF Designs at their facility in Brisbane. These modifications included a flight controller, additional fuel tank, additional shielded wiring, and some larger and more robust control components, all allowing for autonomous test operations.

Figure 4: RF Designs Mephisto

Source: RF Designs

The aircraft, which can be disassembled for transport, is a composite construction of carbon fibre and fibreglass, 3.1 m long, with a wingspan of 2.6 m. It has a maximum take-off weight of 35 kg, retractable undercarriage and flaps and is powered by a Kingtech K260G2 turbine. Delivering 26 kg of thrust, the turbine can propel the aircraft to a maximum speed of 85 m/s (165 kt) and an altitude of more than 5,000 feet.^[2]

The client owned a fleet of 6 of the aircraft that were operated and maintained by Remote Piloted Systems and RF Designs respectively. Of the fleet, 5 were operationally capable (Figure 5), and 1 (HP001) was used for testing and training.

For the week of 15‑19 June the operator brought 4 of the fleet to conduct operations for the client, 3 operational Mephistos and the test and training aircraft for backup and spare parts.

Figure 5: Operational Mephisto fleet

Source: RF Designs

Aircraft operations

The Mephisto could be operated in three different modes, manual, fly by wire (FBW) or automatic.

In manual mode the remote pilot in command (RPIC) had full control over all aircraft functionality with no interaction from the flight controller’s stabilisation programming. This required that the aircraft be manually trimmed and stabilised by the RPIC. In FBW mode the RPIC commanded the aircraft directly, however, the flight controller’s stabilisation programming interpreted and implemented these commands to ensure stable flight. This meant that if the pilot removed control input, then the aircraft would continue in straight and level flight.

Finally, in automatic mode a flight plan consisting of a series of waypoints was programmed into the flight controller using the ground control station (GCS). When the RPIC activated the automatic mode and the flight plan, the flight controller commanded the aircraft through the programmed waypoints with full control over aircraft systems. When the automatic mode was disengaged the aircraft’s systems return to the settings commanded by the RPIC’s controller.

The crew of the Mephisto consisted of two remote pilots - the launch and recovery pilot (LRP) and the GCS operator. The pilot who was actively flying the aircraft was designated the RPIC. For the autonomous flights the RPIC was the GCS operator as they were monitoring the flight and had the ability to intervene and take control of the aircraft if required.

The LRP primarily conducted launches and recoveries and operated the aircraft in manual or FBW mode within visual line of sight. This usually involved flying the aircraft to or from a holding point where it was transitioned to or from the command of the GCS operator for automated flight.

The GCS operator monitored aircraft systems during all flights, conducted flights beyond visual line of sight (BVLOS) and monitored automatic flights. Due to the difference in their roles the LRP and GCS operator were located at different points on the field (Figure 3). The LRP was on the flight line next to the runway providing them the best view of the aircraft for launch and recovery. The GCS operator worked from inside a hangar which provided a more stable environment for the equipment used to monitor and control the aircraft while away from the launch and recovery location. Due to their physical separation, the pilots communicated via radio.

Due to the risk to the aircraft of an inadvertent mode change when transitioning from the GCS operator to the LRP following a flight, a specific process was used for the handover. This process started after launch once the LRP handed over control to the GCS operator. At this point, the LRP would place the automatic mode switch (see the section titled Remote controller) on their controller in ’auto on’ and set the flaps to fully retracted.

At the time of the occurrence, following the automated test flight, the GCS operator had handed control back to the LRP for taxi. The pilot advised that prior to the hand over their controller had been set up with the automatic mode switch selected to ’auto on’ and the flap control in the fully retracted position.

Flight controller

Each Mephisto aircraft was fitted with a Pixhawk 2 flight controller, which was programmed with ARDUpilot software to enable flight in all modes. The flight controller recorded a range of parameters which could be downloaded and used for simulation, recreation, and analysis.

The flight controller received a constant stream of data from a range of inputs including control inputs from either the LRP remote controller or GCS, GPS information, airspeed and engine fuel flow. It then controlled the aircraft via a series of servos that manipulated the aircraft flight control surfaces and turbine engine controls.

Abort landing command

The ’abort landing’ command within the flight controllers programming allowed the GCS operator or LRP to abort an autonomous landing via the remote controller or GCS. The LRP controller triggered the command when 3 criteria were met.

- The aircraft was in the autonomous mode.

- The aircraft was in the landing stage.

- The throttle on the LRP controller was increased above 90 %.

When these criteria were met the aircraft overrode control inputs, increased turbine power to the take-off throttle setting (100 %), pitched up and maintained the current heading until a target altitude was reached.

Remote controller

To control the Mephisto the LRP used a TARANIS X9D Plus hand-held controller, manufactured by FrSKY. The TARANIS X9D Plus (Figure 6) was a programmable, 24 channel, 2.4 GHz transmitter that could be used to control a range of remote devices, including RPA. The controller had 8 programmable control switches, (6 3-position and 2 2-position) that the user could assign to modes or operational settings.

For this operation, to ensure redundancy, the 2 position switches activated the ’return to launch’^[3](RTL) function. This meant that 3 position switches were used to control the aircraft’s modes. To reduce risk of the automatic mode being inadvertently deactivated the modes were switched separately. One switch controlled the automatic mode (on and off) and the other selected manual or FBW. The control hierarchy placed the automatic mode switch above the manual or FBW switch so an inadvertent movement of the manual or FBW switch would not disengage the automatic mode.

Figure 6 shows the location of these switches. The operation of any of these switches required a defined movement and the pilot described that changing between positions made an audible ’click’.

The automatic mode switch was configured with 2 ’auto on’ and 1 ’auto off’ position, which was the top position. This configuration had recently been updated from 1 ’auto on’ and 2 ’auto off’ positions. This change was due to a risk to the aircraft associated with inadvertent deactivation of the automatic mode during flight, particularly when the aircraft was BVLOS. To ensure that the switch was in the correct position it was normal for pilots to drive the switch to an end point of the control to ensure that the desired mode had been selected.

The LRP controller was not fitted with the ability to activate the aircraft’s flight termination system (FTS) (see the following section titled Flight termination systems and active failsafe) or operate as a ’kill switch’, cutting power the aircraft’s engine. In the event that the LRP required the FTS to be activated they would request the GCS operator activate it.

Figure 6: TARANIS X9D Plus with key controls identified

Source: FrSKY annotated by the ATSB

Flight termination systems and active failsafe

Under the Civil Aviation Safety Authority (CASA) permission for the operation (see the section titled Operational information) the aircraft was required to be fitted with a primary active failsafe system and primary and secondary flight termination systems. The primary active failsafe system was designed to ensure that the aircraft did not depart the operational area in the event of a communications loss with the controller. It was designed to return the aircraft to either the launch point or some other holding point within the operational area that allowed the RPIC to conduct necessary checks and perform relevant actions to re-establish communications. If necessary, the system could be activated by the LRP, GCS operator or automatically if the aircraft exited the operational area. The aircraft’s RTL function met this requirement.

The FTS was a secondary level of control that was activated if the primary active failsafe failed or was unable to return the aircraft to a stable location. The system worked by bringing the aircraft to the ground as quickly and as safely as possible, with the main aim of protecting personnel and property. In the case of the Mephisto, the FTS was set to place the aircraft flight control surfaces in a configuration to induce a spin and cut fuel to the engine. This arrested as much forward momentum as possible prior to impact with terrain. The FTS was activated by either the GCS on a dedicated control link or automatically if the aircraft departed a contingency area around the operational area.

CASA specifically stated that the FTS was not intended for use on the ground. However, the system’s process meant that, in the event of an issue on the ground, it would provide a way to rapidly arrest momentum of the aircraft and put it into a known state.

At the time of the incident the aircraft in question was fitted with both the primary active failsafe and FTS. However, due to the rapid development of the aircraft the flight manual had not been updated and contained information that the flight termination system had not been fitted and remained in development.

Operational information

The operator, maintainer and client company had been conducting BVLOS, autonomous and multi-aircraft test flights from Bruhl airfield since November 2019. They had been using a range of smaller, primarily electrically driven aircraft types and recently began using the Mephisto, to allow for higher performance operations and testing.

Bruhl airfield, located approximately 265 km west-north-west of Brisbane Airport (Figure 1), was chosen for 3 reasons. Firstly, it was familiar to several of the crew members. Secondly, it was remote and the surrounding area desolate. This meant that the operational area had a low the risk to persons and property in the event of an aircraft malfunction. Finally, it was accessible by road for the operator, maintainer, and client company from Brisbane.

Operational permissions

Permission for autonomous, BVLOS, multi-aircraft operations at Bruhl airfield operations was granted by the CASA in November 2019. The operator was authorised for flight BVLOS above 400 ft within defined areas and in compliance with certain conditions until 30 November 2020 or revoked. These conditions included:

• the fitment of a ’primary failsafe mode’ which could command a return to launch, ensuring that, during this process, the aircraft did not increase height or depart from the operational area
• fitment of both primary and secondary flight termination systems, with the secondary being able to command immediate flight termination in the event of the loss of communications with the primary.

Operational schedule

Operational test flights for the client’s systems were carried out throughout the week, finishing prior to the incident flight at approximately midday. Through the week these operations started at around 0900 and continued throughout the day, with a break for lunch.

Following each flight there was the requirement to download and analyse the aircraft flight data, liaise with the client company, conduct any required maintenance, and prepare aircraft and flight plans for following flights. These tasks were usually carried out by the incident pilot in their role as the operators CRP.

There was no formalised procedure for taxiing the aircraft back to the hangar. However, the pilot reported that there was a standard process that Mephisto pilots followed to provide the aircraft with enough momentum for the taxi. This process, as outlined below, was for a Mephisto aircraft having completed an autonomous recovery and positioned on the runway.

1. LRP to take control of the aircraft.
2. automatic mode to be deactivated with the aircraft in either FBW or manual
3. remote controller throttle advanced to 100 %
4. pilot to wait for the throttle to spool up to the desired level (approximately 30 %), due to throttle lag this could take approximately 6-7 seconds
5. pilot to throttle back on the controller to desired level
6. pilot to taxi the aircraft back to the hangar under its own power.

Crew information

A team of five pilots, all cross trained on the GCS and as LRP for the Mephisto aircraft, were available to conduct the week of flight activity. In addition, at the time of the incident, multiple training pilots were observing the test flight in preparation for CASA flight testing during the following operational period.

For the incident flight the aircraft crew consisted of the LRP, who was also the operator’s CRP, and a GCS operator. Both the LRP and GCS operator held current remote pilot licenses (RePLs) with appropriate category and type endorsements for operation of the Mephisto.

Fatigue

The International Civil Aviation Organization (2016) defined fatigue as:

A physiological state of reduced mental or physical performance capability resulting from sleep loss, extended wakefulness, circadian phase, and/or workload (mental and/or physical activity) that can impair a person’s alertness and ability to perform safety related operational duties.

Fatigue is a known contributor to a range of adverse effects on human performance. These can include, slower reaction times, decreased vigilance, shortened attention span, reduced short term memory capacity, and reduced decision making capability.

The pilot reported that at the time of the incident they, and others undertaking the operation, were experiencing a heightened level of fatigue due to the tempo of the operation.

Three people on site were designated to monitor fatigue of the operational crew, the incident pilot (as the operators CRP), a senior manager of the maintainer’s company, and a representative from the client company. The pilot reported that following an out‑landing incident earlier in the week, the client’s fatigue management personnel reported that they believed that there was a heightened level of fatigue among the operational personnel. This increased awareness of the fatigue levels prompted increased monitoring of the crew. However, no further action was deemed to be necessary.

Fatigue guidance

At the time of the incident, there was no regulation that applied to fatigue management for operators of RPA. However, in the company operations manual, the operator had used guidance from CASA's sample operations manual, which identified the following 3 areas of fatigue management to be followed:

• the chief pilot must consider and minimise the potential for fatigue to effect operations
• pilots were not to conduct RPAS operations if they believed that they were suffering from fatigue that was likely to impair their performance
• pilots must immediately report fatigue related concerns to the chief pilot who would take appropriate action to remedy the situation.

To comply with this, the chief pilot was required to consider several factors relating to each mission, including:

• travel time to the operation
• complexity and duration of the operation
• the time of day that the operation was to take place
• environmental conditions.

Fatiguing conditions

Through a review of the operation and the pilot’s history the ATSB identified 3 factors that could have contributed to a significantly heightened fatigue level. These were environmental conditions, operational requirements, and disrupted sleep.

Environmentally, while the incident occurred during winter, the LRP were operating outside on the flight line, in sunny and warm conditions. While there was no concern about the effect of the temperature, the pilots did identify a risk of dehydration, which can be a contributor to fatigue. These factors were being managed through breaks through the day and access to shade, fluids and food.

Operationally there were 2 periods that would have affected the pilots fatigue levels. Firstly, in the week leading up to the operation the pilot had been undertaking a range of maintenance testing and other preparatory activities. This involved multiple round trips to and from Brisbane to the airfield for test flights, a trip of approximately 3 hours each way. In addition to the flights and aircraft preparation this also involved data download, analysis and associated aircraft tuning both at the airfield and in Brisbane.

These activities were not only fatiguing themselves but limited the pilot’s opportunity for rest in preparation for the operational week, which they were aware was going to have an increased operational tempo. The pilot was aware of the heightened risk of fatigue due to these factors and sought to mitigate them over the weekend prior to the operation by taking more of an oversight role of preparations and leaving individual tasks to crew members.

The pilot reported that during the operational week they had 12 to 14 hours of duty each day. This involved carrying out aircraft test flights for the client company, overseeing LRP and GCS operations for the operational and test aircraft. In their role as CRP, the incident pilot, was also monitoring the crew for signs of fatigue, overseeing maintenance, preparing aircraft, and planning and reviewing data for the operations undertaken each day. The maintenance and preparatory tasks were undertaken in the morning prior to commencement of the days flying operations and, in the evening, following the completion of operations until going to sleep. This meant that, with the exception of mealtimes, there was limited to no time where the operations were not the focus. While the incident occurred in the middle of the day it was at the end of the final test flight of the week’s operations.

The pilot reported that sleep opportunity was in line with their regular habits, getting approximately 7 hours each night. However, during these operations they were staying at the airfield and rooming with another person. The pilot reported that this probably resulted in disrupted sleep. All other members of the crew were roomed off site in individual accommodation, which both promoted sleep opportunity and removed them from the operational environment.

Fatigue review

Unlike crewed aircraft operations, this operation did not need to comply with Civil Aviation Order (CAO) 48.1 Instrument 2019. Despite that, the ATSB reviewed the pilot flight and duty times against the instrument and appendices 1 (basic limits), 4 (any operations) and 5A (daylight aerial work operations and flight training associated with aerial work) to gain an appreciation of what level of fatigue was considered likely to affect performance.

Based on this review it was determined the pilot had exceeded the cumulative duty period limits, had not had sufficient off duty time and did not have adequate sleeping facilities as per the instrument requirements. As such, if the pilot had been seeking to fly a crewed aircraft subject to CAO 48.1 requirements, they would have been considered unfit to fly.

Recorded data

As discussed in the Flight controller section, the Pixhawk 2 flight controller can record and store a range of timestamped flight data and status messages.

The data for the two test flights, was downloaded by the operator and the data and relevant software for interpreting it were provided to the ATSB. Figure 7 shows data from these flights with throttle, flap and altitude traces. Additionally, the active aircraft mode is shown and some of the recorded aircraft status messages.

Figure 7: Flight data showing 19 June test flights

Source: ATSB utilising data provided by the operator

Figure 8 shows data from the second flight with the transition into automatic mode and the aircraft then launching conducting a circuit and being recovered. Following the landing there were a number of mode changes and an aircraft status message that corresponded with the ‘abort landing’ function being activated, the pilot toggling the mode switch to disengage this function and directing the aircraft away from personnel on the flight line.

Figure 8: Flight Data - Mephisto test flight 2 - 19 June

Source: ATSB utilising data provided by the operator

Figure 9 shows greater detail of the incident over the period of 20 seconds from 12:47:00 to 12:47:20, during which the aircraft was under the control of the LRP. This time covers the aircraft on the ground preparing to taxi, the throttle being advanced, and the ’abort landing’ function being activated, as identified by aircraft status message 2. It shows the mode selections by the pilot as they disengaged the abort landing function and toggled into manual mode as the aircraft was directed towards the airfield fence.

The chart shows that the aircraft remained in automatic mode and the flaps remained extended until approximately 12:47:04 when the throttle trace showed an increase to 100 %. At this time the aircraft status message appeared, giving the indication that the ’abort landing’ function has been activated and the flaps retracted while the throttle remained at 100 % as the aircraft followed the ’abort landing’ process.

The data showed the pilot toggling the automatic mode switch to off, and back on, to overwrite the ’abort landing’ function. It shows the throttle trace as the pilot directed the aircraft away from the flight line and across the runway towards the fence, and finally the re-engagement of the manual mode for the aircraft to be shutdown.

Figure 9: Flight Data - Incident - 19 June

Source: ATSB utilising data provided by the operator

__________

2. The aircraft’s maximum altitude was not confirmed – 5,000 ft is the maximum altitude allowed under the operational permissions obtained from the Civil Aviation Safety Authority.
3. When activated the return to launch function automatically flew the aircraft back to the launch point or another designated point and, depending on programming, either held in place (allowing the RPIC to regain control) or conducted an automated recovery.

Introduction

At 1247 on 19 June 2020, the pilot of an RF Designs Mephisto, remotely piloted aircraft (RPA) completed an automated test flight and attempted to transition the aircraft out of automatic mode to taxi it back to the hangar.

The pilot was unaware they had not deactivated the aircraft’s automatic mode prior to increasing the throttle to provide sufficient momentum for the taxi. This action activated the aircraft’s ‘abort landing’ function and prevented the engine from throttling down as the pilot was commanding.

The following analysis will look at the factors that resulted in the incomplete deactivation of the automatic mode, the pilot not realising the aircraft remained in the automatic mode and the delay in regaining control of the aircraft.

Deactivation of automatic mode

Following the landing, the pilot attempted to deactivate the aircraft’s automatic mode using the automatic mode switch. The switch had 3 positions with 2 positions set for automatic mode on and 1 for automatic mode off. The pilot recalled that they had moved the switch as indicated by the click and movement that was felt. However, they did not recall whether it was moved 2 positions or 1. The data showed no deactivation of the autonomous mode, indicating a single position change.

This meant the aircraft was in a state different to what was intended leading to the activation of the ’abort landing’ function when the pilot advance the throttle, and the subsequent loss of control.

The LRP remote controller (TRANSIS X9D Plus) had only two 2-position switches available, which for redundancy were both being used for return to launch functionality. This meant that the automatic mode selection was relegated to a 3-position switch. The technique of driving the switch to an end point that the Mephisto pilots used went some way towards mitigation of an error. However, the use of a 3-position switch increased the likelihood of a mis-selection and an undesired state.

This potential had been identified by the operator with the change of layout for the 3 positions from off-off-on to off-on-on. It was believed that this was a way to limit the risk of an aircraft accidentally being forced into manual or fly by wire mode while flying beyond visual line of sight. However, it did not overcome the issue of an incomplete or incorrect mode selection.

Aircraft state awareness

There were 3 cues to alert the pilot that the aircraft remained in the automatic mode. Firstly, the aircraft’s flaps had not retracted when they attempted to disengage the automatic mode, despite being set to fully retracted on the controller. Secondly, the pilot should have felt and heard two distinct ’clicks’ as the control moved through the second ’auto on’ position and into the desired ’auto off’ position.

The pilot commented that they did not remember seeing the flaps retract and recalled feeling and hearing 1 click but could not recall the second. The ATSB considered a number of reasons why the pilot may not have detected or reacted to these cues. These included: deliberate pilot action, distraction, expectation bias, and fatigue. Based on the available evidence, it was considered that the heightened level of fatigue was the most likely explanation. This is discussed further below.

Delayed control recovery

In the event of a RPA loss of control on the ground, where the engine was still functioning at a high-power setting, removing engine power is the quickest and easiest way to arrest momentum and bring the aircraft back under control. The flight termination system (FTS), as required under the CASA permission for the operation and fitted to the aircraft, provided the ability override the aircraft’s automatic mode, immediately cut fuel to the turbine and drive the aircraft controls into a configuration to induce a spin.

While this system was designed to operate in the air, its functionality, specifically cutting fuel to the turbine, would have allowed the aircraft’s momentum to be arrested more quickly. However, this system could not be activated from the launch and recovery pilot’s (LRP) controller and relied on communications with the ground control station operator to activate it. The aircraft’s data showed that there were only seconds for the pilot to react and take appropriate action. While calling for the activation of FTS would have stopped the aircraft it would not have been practical in the time available.

Had the LRP’s controller been fitted with a switch that could activate the FTS, there would have been no requirement for the extra control inputs to deactivate the ‘abort landing’ function and regain control of the aircraft.

Fatigue

For this operation the potential effects of fatigue on crew members had been identified and a range of fatigue management and mitigation strategies were in place. However, these strategies did not specifically account for the added work created by the incident pilot’s additional role as the operator’s chief remote pilot (CRP).

For example, in addition to flight operations and testing, they were liaising with the client company, monitoring other team members for signs of fatigue and staying at the field in shared accommodations. Additionally, while the crew was being monitored for fatigue, the 3 personnel assigned to monitor the fatigue - the CRP, the maintainers senior manager and the clients fatigue monitoring personnel did not have anyone assigned to monitor their fatigue levels. Fatigue monitoring is only effective if all personnel are being monitored.

Considering their workload and reduced rest opportunity, the ATSB assessed that it was likely that the pilot was experiencing a level of fatigue that affected performance. Heightened fatigue levels are known to cause a reduction in ability to react to external stimuli and effect a person’s attention and decision-making capacity.

The level of fatigue felt by the pilot at the time of the incident likely had an effect on them missing the visual (flaps not retracting), tactile (not feeling one click rather than two) and audible cues (hearing one click not two) that indicated the aircraft had not exited the automatic mode.

From the evidence available, the following findings are made with respect to the loss of control during taxi involving RF Designs Mephisto, HP001 at Bruhl Airfield on 19 June 2020.

Contributing factors

• When the throttle was advanced for taxi, the automatic mode, which had not been correctly deactivated, entered an ’abort landing’ state. This overrode the pilot’s commands to decrease throttle and the turbine thrust continued to increase, resulting in a loss of control.
• The use of a 3-position switch (with 2 positive and 1 negative position), for a 2‑position role, increased the likelihood that a pilot would inadvertently not deactivate the automatic mode prior to manoeuvring the aircraft.
• The controller did not have a ’kill switch’ to override the aircraft’s automatic mode and shutdown the turbine in the event of an issue. As a result, the pilot was forced to toggle the aircraft’s mode switches and direct it away from personnel rather than being able to override it.
• The pilot was experiencing a level of fatigue known to impact performance. This likely led to a lack of reaction to multiple cues that the aircraft had not exited the automatic mode.

BVLOS             Beyond Visual Line of Sight

CASA               Civil Aviation Safety Authority

CRP                 Chief Remote Pilot

FBW                Fly by Wire

FTS                  Flight Termination System

GCS                 Ground Control Station

GPS                 Global Positioning System

LRP                 Launch and Recovery Pilot

RePL                Remote Pilot License

RPA                 Remotely Piloted Aircraft

RPIC                Remote Pilot in Command

RTL                  Return to Launch

Sources of information

The sources of information during the investigation included the:

• pilot flying
• aircraft manufacturer and maintainer
• Civil Aviation Safety Authority
• Operators manual for the FRSky TARANIS X9D Plus
• recorded data from the aircraft
• ARDUpilot documentation.

References

ICAO. (2016). Doc 9966: Manual for the Oversight of Fatigue Management Approaches 2nd Edition. Quebec, Canada: International Civil Aviation Organisation.

Submissions

Under section 26 of the Transport Safety Investigation Act 2003, the ATSB may provide a draft report, on a confidential basis, to any person whom the ATSB considers appropriate. That section allows a person receiving a draft report to make submissions to the ATSB about the draft report.

A draft of this report was provided to the following directly involved parties:

• the operator and pilot flying
• the maintenance organisation
• CASA

No submissions were received.

Safety action not associated with an identified safety issue

Safety action by Remote Piloted Systems (the operator).

In response to this incident the operator introduced the following changes to the Launch and Recovery pilot’s controller switch layout and allocations, procedures for taxiing the Mephisto aircraft and operational planning to reduce risks identified:

• 3‑position mode switches were replaced with 2‑position mode selection switches to eliminate issues with incomplete deactivation of the automatic mode.
• All launch and recovery pilot controllers had a ’kill switch’ added that overwrites the aircraft’s mode to manual and drives the throttle immediately to zero thrust. This switch is gated to enable easy to operation, when necessary, but is also difficult to inadvertently activate.
• Taxi procedure has been changed/formalised to require that all aircraft are shutdown on the runway and pushed back to the hangar by hand rather than under their own power.
• The operational timeline has been extended from 7 to 10 days, with additional time to setup and prepare the aircraft and a break before operations commenced.

Safety action by RF Designs (the maintainer).

Since this event the RF Designs has introduced the following two safety improvements:

• The aircraft flight manual has been updated to clarify the presence of the flight termination system, removing the phrase ’not currently fitted, in development’.
• Specific fatigue management requirements, including references to CAO-48.1, have been added to the RPA operations manual.

The ATSB welcomes the prompt safety action taken by the operator and maintainer to address the deficiencies identified in this incident.