Little Ripper has a day out, shark spotting drone flies away

Little Ripper drone being held by team

An expensive mistake reported by the Australian Transport Safety Bureau. An obvious stand out is the poor range of the command and control (C2) link. For an expensive commercial system, 165m is not far.

The RPA was part of a six-month trial for search and rescue group Westpac. That trial had started in February of 2016.

https://youtu.be/nq_SWlu1LIA

On 27 September 2016, a remotely piloted aircraft (RPA), was operating a test flight at Lighthouse Beach, Ballina, New South Wales.

According to telemetry data recorded on the remotely piloted aircraft system’s ground control station (GCS), at about 0910 Eastern Standard Time, the RPA lifted off from its start position in front of the surf clubhouse. About 30 seconds later, when the RPA was at an altitude of about 36 ft, the flight mode entered ‘manual’ mode. The RPA then tracked according to manual inputs from the pilot for about 7 minutes, at which time (when at 124 ft altitude) the data-link signal was lost. Thirty seconds later, the RPA entered the ‘home’ flight mode, and commenced tracking to the programmed home position at an altitude of 154 ft. The last position of the RPA recorded by the GCS was about 165 m NNE of the start position, and about 4 km SE of Ballina/Byron Gateway Airport.

In the home flight mode, the RPA did not respond to the control inputs made by the pilot, and the pilot subsequently lost sight of the RPA. The RPA was not found despite an extensive search.

The south-eastern point used to georeference the image on the ground control station map was selected to a northern hemisphere latitude, which resulted in incorrect waypoints and home position for the mission.

The RPA data-link signal to the ground control station was lost, so it commenced tracking to the programmed home position, which was in the Coral Sea Islands about 1,200 km north of the start position.

Incorrect reference data can have potentially serious consequences in remotely piloted and manned aircraft. It is imperative that remotely piloted aircraft systems incorporate means of minimising the opportunity for errors to occur and also for detecting and correcting errors that do occur.

What happened

On 27 September 2016, a Pulse Aerospace Vapor 55[1] remotely piloted aircraft (RPA), was operating a test flight at Lighthouse Beach, Ballina, New South Wales (Figure 1).

Figure 1: Photo of a (different) Vapor 55 RPA

Figure 1: Photo of a (different) Vapor 55 RPA

Source: www.skylineuav.com.au

According to telemetry data[2] recorded on the remotely piloted aircraft system’s ground control station (GCS), at about 0910 Eastern Standard Time (EST), the RPA lifted off from its start position in front of the surf clubhouse (Figure 2). About 30 seconds later, when the RPA was at an altitude of about 36 ft, it entered ‘manual’ flight mode. The RPA then tracked according to manual inputs from the pilot for about 7 minutes, at which time (when at 124 ft altitude) the data-link signal was lost. Thirty seconds later, the RPA entered the ‘home’ flight mode, and commenced tracking to the programmed home position at an altitude of 154 ft. The last position of the RPA recorded by the GCS was about 165 m NNE of the start position, and about 4 km SE of Ballina/Byron Gateway Airport.

In the home flight mode, the RPA did not respond to the flight control inputs made by the pilot and the pilot subsequently lost sight of the RPA. The RPA was not found despite an extensive search.

Figure 2: Recorded RPA track

Figure 2: Recorded RPA track

Source: Google earth and remotely piloted aircraft system operator, annotated by ATSB

Mission planning

Prior to the flight, the pilot’s preparation for the planned mission involved using Google earth on a computer (not the GCS), and selecting a north-western and a south-eastern reference point. These markers defined an outer rectangle, within which the flight was to take place (Figure 3).

Figure 3: Planned operating area defined using NW and SE markers

Figure 3: Planned operating area defined using NW and SE markers

Source: Google earth, annotated by ATSB

The pilot then transferred an image of the google earth map for the area onto the GCS using a USB stick, and uploaded it to create the ‘Lighthouse Beach’ mission. To georeference[3] the image, the pilot then overlaid the markers in the image with a point icon on the controller, and entered the latitude and longitude of two positions into the dialogue box on the GCS. The north-western GCS marker is visible in the top left corner of Figure 4, but the latitude and longitude values visible are image text only.

Once the image had been georeferenced, the pilot then used the graphical interface to place the start and home icons and any intervening waypoints for the planned mission (Figure 4).

Figure 4: Image uploaded onto GCS with planned mission overlaid

Figure 4: Image uploaded onto GCS with planned mission overlaid

Source: Remotely piloted aircraft system operator, annotated by ATSB

Incorrect georeference

The remote pilot reported that both they and an observer checked each waypoint before the flight, verifying latitude, longitude, altitude and height. However, the GCS data shows that during the planning phase, while the north-western marker was correctly assigned, the south-eastern marker was incorrectly assigned to a georeference point with a latitude in the northern hemisphere. This resulted in all of the waypoints and home location being incorrect, as they were created by dragging icons on the georeferenced image. Waypoints 2, 3, 6 and 7 had latitudes in the northern hemisphere, and the home position was assigned to 17.222395° S and 153.591582° E. That location was in the Coral Sea Islands about 1,200 km north of the start position (Figure 5).

Figure 5: Actual location of home position and select waypoints from the GCS

Figure 5: Actual location of home position and select waypoints from the GCS

Source: Remotely pilot aircraft system operator, Google earth

The RPA’s start position was correct as it was obtained using the RPA’s GPS. As the aircraft entered manual mode after take-off and the pilot did not initiate the automatic mode to fly the programmed mission, it was only when the RPA lost the datalink, stopped responding to the pilot’s manual control inputs and commenced tracking for the programmed home position, that it left the planned operating area. The pilot can also manually give the ‘home’ command. In all home and automatic modes, the handheld controller is ignored unless the pilot gives the ‘manual’ command via the GCS application and manually takes control of the RPA.

The GCS has a ‘flight plan’ tab, which shows the planned distance and time (among other items) for the mission, which could have alerted the pilot to the incorrect latitude references. However, a check of the flight plan tab had not been included in the operator’s pre-flight procedures. In addition, the flight plan tab includes a measure tool that can be used to check that the map size is correct.

The manufacturer advised that the following steps are included in their pre-flight procedure specified in the aircraft flight manual:

  • verify flight plans
  • verify lost communication home waypoint.

The operator stated that there was no further detail of the verification process in the manual nor was there any detail of the checks provided during training by the Australian distributor of the RPAS.

The default hemisphere was north (N) in the GCS for entering positions. The manufacturer stated that there was no feature that would change the default (to south (S)). The manufacturer assessed that changing the default could lead to issues with the conduct of appropriate pre-flight checks.

The operator reported that information about the default setting to north was not provided in the Aircraft Flight Manual or the initial training from the Australian distributor.

Loss of data-link signal

The RPA system commands homing after 10 seconds of data link loss when in automatic mode and 2 seconds if in manual mode. In this incident, as the RPA was in manual mode, it initiated homing after 2 seconds.

The cause of the lost signal could not be determined. The operator thought that there may have been interference from a media outside broadcast unit located about 30 m from the GCS. However, the media personnel advised the operator that they were using a satellite communications link and therefore should not cause interference.

Appropriate action

The manufacturer advised that once the aircraft commenced tracking to an incorrect home location, the appropriate action would have been to use the ‘hold’ or ‘manual’ command so that the joystick flight control could be used.

The remote pilot advised that they had attempted to use the ‘hold’ command, as they were shown in their training, but the RPA did not respond. No evidence of this was recorded in the GCS data.

Safety analysis

Although the pilot reported having completed the pre-flight preparations and associated checks, the data stored on the GCS showed that the incorrect (northern) hemisphere was assigned to the south-eastern georeference marker at the time the map image was created. This led to the home position being assigned a location in the Coral Sea Islands, so when the RPA lost signal and tracked for home, it headed north and was not recovered. The same outcome would have occurred if the pilot had selected the RPA to fly home, even with a continuous data-link signal. While all of the intermediate waypoints were also incorrect, as the GCS remained in manual mode, the RPA did not attempt to track to any of those waypoints.

Findings

These findings should not be read as apportioning blame or liability to any particular organisation or individual.

  • The south-eastern point used to georeference the image on the ground control station map was selected to a northern hemisphere latitude, which resulted in incorrect waypoints and home position for the mission.
  • The RPA data-link signal to the ground control station was lost, so it commenced tracking to the programmed home position, which was in the Coral Sea Islands at a latitude 17.22° S, about 1,200 km north of the start position.

Safety action

Whether or not the ATSB identifies safety issues in the course of an investigation, relevant organisations may proactively initiate safety action in order to reduce their safety risk. The ATSB has been advised of the following safety action in response to this occurrence.

Manufacturer

As a result of this occurrence, the RPAS manufacturer has advised the ATSB that they are taking the following safety actions:

  • Audit of training curriculum to ensure that pilots understand how to verify GPS coordinates, interpret their values and signs. The training course will continue to train pilots on the tools available to them within, and outside of the GCS software.
  • Share this incident with operator trainers so that new operators can learn from the events of this incident.
  • Continued education and outreach discussions with RPAS operators pertaining to decreased mishap rates through training and currency policies.

Remotely piloted aircraft system operator

As a result of this occurrence, the remotely piloted aircraft system operator has advised the ATSB that they are taking the following safety actions:

  • The pre-launch checklists have been modified to include additional and enhanced procedures to verify data input and flight plans.
  • Investigate the fitting of either GPS or cellular tracking devices to remotely piloted aircraft.
  • Update the risk assessment form to include location of external broadcast stations such as television outside broadcast units.
  • Brief all company pilots on the event for safety and education purposes.
  • Continue liaison with the manufacturer.

Safety message

Incorrect reference data can have potentially serious consequences in remotely piloted and manned aircraft. It is imperative that remotely piloted aircraft systems incorporate means of minimising the opportunity for errors to occur and also for detecting and correcting errors that do occur.

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. RPA operators should expect data loss events and prepare for these appropriately.

The ATSB SafetyWatch highlights the broad safety concerns that come out of our investigation findings and from the occurrence data reported to us by industry. One of the safety concerns relates to data input errors.