A selection of HF occurrences

Contents

  • Report to CHIRP!
  • Comments on previous editions and reports
  • I Learned About Human Factors From That (ILAHFFT)
  • Get 5% discount at Pooleys Flight Equipment through CHIRP
  • DUAS xx23 - Software Coding?
  • DUAS 0033 - Drone Assist
  • DUAS xx24 - Vision Systems
  • DUAS xx25 - Fatigue and Stress

Automation Again

Welcome to Drone FEEDBACK Edition 13.

Well, as I write it has been another busy week on the regulatory front for the drone community. UK SORA has now been published with a timetable for implementation which has a key date of 23rd April, details on SAIL marking and the much-anticipated details on Pilot Competency. In addition, Ofcom (jointly with the CAA) has announced their approval for the use under licence of 978 MHz for airborne transmission onboard UAS. This will undoubtedly be an enabler for BVLOS flight. The DSCO online applications and renewals for Specific Category Operations excluding PDRA01s, is now pencilled in for Q2 of 2025. Statistics from the regulator indicate that the number of flyers continues to increase, so we can be sure there are a growing number of drones in the air. Curiously though, it looks as if the number of Open Category Operators is increasing at the expense of Specific Category Operators. Is the future brighter for lighter drones?!

A trend we continue to see is an increasing level of automation being incorporated into some of the flight /mission planning software, and this at an ever-faster pace. Blink and you have missed it! Image recognition is now being incorporated into what you can see in your control unit as standard, so you can count the number of people, cars or even boats that are in view. A recipe for distraction? How active See and Avoid technology will be incorporated into what is a relatively small handheld control unit really does remain to be seen.

Every one of these developments bring different human / computer interface risks along to the party. Each of them has a unique Human Factor related challenge that we are only beginning to identify.

Drone pilots – please do continue to report to Human Factor safety incidents to CHIRP. Many thanks to those who have done so.

Let’s look at another selection of good examples set out below.

Rupert Dent

Drone / UAS Programme Manager

 

Report to CHIRP!

Our reporting process is simple and quick using either our website portal or our App (scan the appropriate QR code shown or search for ‘CHIRP Aviation’ – avoiding the birdsong apps that come up!). In our reporting portal you’ll be presented with a series of fields to complete, of which you fill in as much as you feel is relevant – not every field is mandatory, but the more information you can give us the better. Although you’ll need to enter your email address to get access to the portal so that we can screen out bots etc, none of your details are shared outside CHIRP, and we have our own independent secure database and IT systems to ensure confidentiality. That way you can help to improve safety by sharing important lessons without worrying about possible consequences. Anything that could identify a reporter is removed from our reports before progressing or publishing them, and we liaise with the reporter in every step of the process. Each report plays its part in raising awareness of important safety issues and wider trends and provides lessons for all to learn from. Report-by-report we can make aviation safer – as our strapline says,

“you report it, we help sort it.”

Comments on previous editions and reports

We always welcome readers’ comments on what we produce. Whilst we try and keep an eye on social media sites, it is not always possible to keep track of the multitude of Drone-related sites and what is being discussed. Do therefore feel you can email us directly with your Human Factors or Just Culture related comments on the reports we write about at: mail@chirp.co.uk.

We have had a reader’s comment on the first report that appeared in Feedback 12: DUAS 00XXX Malloy Aeronautics T150 AAIB-29335. In essence they pointed out that in the AAIB report there was no mention of Human Factors being involved in the Accident. We passed this comment on to the AAIB and received the following response:

“As a routine part of AAIB investigations, Human Factors evidence is reviewed and analysed, which was the case with this investigation. The final report represents a summary of the evidence and analysis which, we believe, will improve aviation safety. In this case the Operator took actions to mitigate the HF aspect of this event but the lack of procedures in the approved OSC was thought to be a significant oversight which resulted in the Safety Recommendation to the CAA.”

I Learned About Human Factors From That (ILAHFFT)

 

Get 5% discount at Pooleys Flight Equipment through CHIRP

Pooleys have kindly agreed to support CHIRP’s fund-raising activities by allocating us a discount code on their website shop. Enter the code ‘Chirp’ (case sensitive) at the appropriate point at the payment stage to get 5% discount and generate some commission for CHIRP. Sadly, this doesn’t apply to the purchase of Bose headsets, but everything else qualifies! If you do use Pooleys for your purchases, or know other people who do, please do share the code. The more the code is circulated, the more it is used and the greater the commission generated to help CHIRP build its resources to do more. https://www.pooleys.com 

 

Reports

DUAS xx23 - Software Coding?

Initial Report

Note: this originated from AAIB report no 29959

Type of report: Accident

Aircraft Type and Registration: UAS Malloy Aeronautics T005

No & Type of Engines: 4 Electric T-Motor Engines

Year of Manufacture: 2024 (Serial no: 31)

Date & Time (UTC): 2 April 2024 at 1530 hrs

Location: White Waltham Airfield, Berkshire

Type of Flight: Experimental test flight

Persons on Board: Crew – None. Passengers – None

Injuries: Crew – N/A. Passengers – N/A

Nature of Damage: UA damaged beyond economic repair

Commander’s Licence: General line of sight certificate (GVC)

Commander’s Age: 33 years

Commander’s Flying Experience: 177 hours (of which 2 were on type). Last 90 days – 3 hours. Last 28 days – 1 hour

Information Source: Aircraft Accident Report Form submitted by the pilot and further enquiries by the AAIB

Synopsis: During a test flight to validate a flight control software update, the UA climbed and veered left. It then descended and struck two unoccupied General Aviation (GA) aircraft, coming to rest underneath the second. The UA was destroyed. The operator’s investigation identified that the UA lost control due to the software commanding more thrust than needed for level flight. Several technical, process and human performance factors contributed to the accident. The operator has taken thirteen safety actions to prevent reoccurrence.

History of the flight: A test flight was being conducted to validate a software update, which implemented visual tracking and following capability when flown in auto mode. The Remote Pilot (RP) was assisted by Command Unit Operator (CUO) and a Competent Observer (CO). The flight was being operated under the Open A3 Category. The flight was planned to take place at White Waltham Airfield, within the area (shown in white in Figure 1) designated for use as a UA site by the airfield and at least 150 m away from any buildings. After the airfield granted the operator permission for the flight, the operator’s flight team prepared the UA and conducted a team briefing and a set of pre-flight checks.

After being powered on, the UA was unable to acquire a GNSS signal, preventing a geofence, which mirrored the white area shown in Figure 1, from being applied. The RP decided to proceed with the flight on the basis that several means to activate the Flight Termination System (FTS) were available in case of an emergency. The team launched the UA and completed a short flight which validated the stabilised, alt hold and loiter flight modes. The UA was then repositioned. The RP launched the UA and, when he selected the auto mode, the UA climbed and veered left.

The RP was reported to have shouted “kill, kill, kill” and attempted to activate the FTS from his controller, which was not successful. The RP then used the backup controller to activate the FTS, which was successful. The RP and CUO then lost sight of the UA as it descended to the ground, with the CUO and CO both hearing ‘an impact with what they assumed to be one of the unoccupied GA aircraft parked outside a nearby hangar’.

Conclusion: The accident occurred because, when auto mode was activated, excessive throttle was commanded by the flight control software which caused the UA to veer to the left. The operator identified that the software commanded excess throttle because the flight model and feedback loops were inappropriately tuned. The flight team were unable to activate the FTS in a timely manner, in part because the pre-flight briefing did not sufficiently prepare them for enacting the emergency procedures, and because the software was designed to ignore FTS commands from the RP’s primary controller when in auto mode. However, the FTS did successfully activate when invoked from the backup controller. Although the RP initially refused to operate the flight when the geofence could not be applied, his decision was swayed by the fact that the geofencing is not required for Open Category flight, and because a previous T005 flight had taken place where a geofence was not used.

Safety actions: The operator has taken the following technical-related safety action:

 

CHIRP Comment

The CHIRP Advisory Board had several points they thought relevant:

Software Design issues. As a general remark regarding building software to digitise a sequence of actions, the Board observed that whilst there are many very capable coders out there, rare indeed is a coder that can write something from a user’s perspective. This just means that robust testing of “what if” scenarios on the ground needs to be undertaken before it is tested in flight. This includes good practice after a software update has been downloaded – see Safety Notice SN-2025/004. This Safety Notice recommends UAS operators and remote pilots flight test an unmanned aircraft after any [software] update or modification.

DUAS 0033 - Drone Assist

Initial Report

Whilst planning a mission over linear assets, Drone Assist was used to ensure the flight went near but not through the Wittering FRZ. However, the FRZ that is marked is much smaller than the MATZ, which is not marked. We flew through the MATZ without realising or co-ordinating with Wittering. Have we made a (Human) error?

 

CHIRP Comment

The diagram below shows the dimensions of a typical MATZ.

DUAS xx24 - Vision Systems

Initial Report

Note: this originated from an AAIB record-only UAS investigation reviewed Oct-Nov 2024

Report text:

7 Oct 2024 DJI M300  XXXXX London The UA was performing a survey at about 1 m above the River Thames. The remote pilot paused the mission to avoid a pier but unexpectedly the UA lost height and dropped into the water. The cause of the problem was not determined.

CHIRP Comment

Page 21 of the DJI M 300 User Manual states:

Using Infrared Sensing System

The Infrared Sensing System can only be used to avoid large, diffuse, and reflective obstacles (reflectivity > 10%). Please be mindful of blind spots (Darker Grey in the image below) of the of the Infrared Sensing System. The downward Infrared Sensing System is used for positioning and assisting height setting during take-off and landing, while the Infrared Sensing System on the other five sides are for obstacle sensing.

Vision System and Infrared Sensing System Warning

The measurement accuracy of the Vision System is easily affected by the light intensity and the surface texture of the object. The Infrared Sensing System can only be used to avoid large, diffuse, and reflective obstacles (reflectivity > 10%).

The Vision System may NOT function properly when in any of the following situations:

  1. Flying over monochrome surfaces (e.g. pure black, pure white, pure red, pure green) or without clear texture.
  2. Flying over highly reflective surfaces.
  3. Flying over water or transparent surfaces.

DUAS xx25 - Fatigue and Stress

Initial Report

Report text from NASA’s Aviation Safety Reporting System (report reference – ACN: 2166849)

I recently travelled from the east coast of the USA to [location] to perform a large-scale drone mapping mission. In this ASRS report, I want to focus on the importance of ‘Fatigue’ in IMSAFE (Illness, Medication, Stress, Alcohol, Fatigue, Emotion) so other drone pilots can learn from my outright mistakes.

The hastily put together plan was for me was to connect with a local / resident drone team in [location] and arrange to fly several 400′ AGL missions in this otherwise 100′ LAANC class Delta. The local team was in possession of a standing LAANC NOTAM / waiver that allowed flights up to 500′ AGL. The plan was that they would extend this waiver for me to use under their supervision. Given the size of the region we wanted to map (an entire college campus) a 400′ AGL flight plan would make this mission a relative walk-in-the-park. At least that was the plan.

Upon arriving, things started to fall apart quickly. The word from my corporate office was that there were complications with connecting with the local team. While corporate would continue to work on the problem, I should begin the data collection myself. AKA: start collecting data on a structure-by-structure basis at 100′ AGL… which, in fairness, was the backup plan. At this point, the correct action on my part should have been to either ask for additional resources to help with the mission execution (Visual Observers) or for me to wait in my hotel room until the necessary connections were made. While that sounds fine on paper, the reality is that between the jet lag induced fatigue and the stress of the severe blackeye the drone programme could suffer, I decided to be a good soldier and press on.

In retrospect, what amazes me is that, despite my training as a Part 61 pilot and extensive work with the FAASTeam related to flight safety, at the time it never occurred to me that the timezone induced (F)atigue and the corporate (S)tress are core elements in IMSAFE. It just never crossed my mind at the time.

Independent of IMSAFE, an additional complication was the local terrain. Being from the East Coast of the USA, I am basically a Flat Land pilot. Mountain flying is not something we need to worry about in my region. The area I was to fly, the campus, was extremely mountainous. While I had done several walk throughs of the campus via Google Earth, the sheer elevation changes were daunting in person.

Regardless, I pressed forward flying mission after mission at or about 100′ AGL – the “about” is what I will be focusing on. Complicating matters was the fact that the elevation change between my take-off point and the structure of interest was not always the same – something I had not thought about up front. Therefore, I resorted to guestimating the elevation differences. For example, if it looked as if the ground around the building was 50′ higher than my take off point, I would programme the drone to fly at 150′ AGL. The thought being that I would be 100′ AGL in the vicinity of the building.

Clearly this approach was flawed from the start. Not only could I not guarantee that my flights were at or below 100′ at all times, the process was subject to errors. For example: I realized I had flown one mission at 150′ AGL relative to my take-off location (and in theory 100′ AGL over the structure). The next mission I intended to fly at 100′ AGL, but I forgot to change the hard-coded altitude. That means that I flew that next mission at 150′ AGL – 50′ above the LAANC (Low Altitude Aviation Notification Capability) limit.

Eventually, I resolved my fatigue issue via natural means (aka sleep) and came to grips with my faulty decision making. As a result, I stopped flying missions using guestimates of altitude. Ultimately, I was able to connect with the local team and complete the remainder of the data collection at 400′ under their waiver. They also taught me how to exploit the autonomous AGL based flight planning in the drone. Ironically, I had known about the AGL feature, but being from a relatively flat region of the world, I had never used it and simply forgot about this feature. Had I used this option, I could have completely avoided my guessing the AGL flight levels around the structures at elevation.

Take aways:

1) We talk about the fatigue aspect in safety meetings, but its insidious nature was a wake-up call. Do not assume that you will be able to detect truly excessive fatigue (especially jet lag induced) while in that state – instead plan for it.

2) Do not underestimate the impact that fatigue and stress can play in your mission planning. The next time I am in such a position, I will explicitly bake in time for the on-the-ground team to accumulate to the new environment. The thought of “hitting the ground running” when extensive multi-time-zone travel is involved is wrong headed.

3) Sending one-person (aka one brain) out on a large mission was a mistake. This was somewhat understandable given that we were supposed to connect with an onsite team, but when that failed to materialize, that left one sleep deprived individual with no one to help with mission planning or as a general CRM (Crew Resource Management) voice.

4) By factoring in up front decompression time, you can better set expectations back in the corporate office and thus reduce stress on the in-field team.

5) If the plan is to connect with a team that has a waiver, it is mandatory that we connect with the team before departing. Launching blindly in the hopes that all the pieces would come together in the field was a recipe for failure.

6) Finally, just like in an aircraft where the pilot is expected to know how to use every piece of installed equipment, I should not have departed without doing my homework regarding the automated AGL flight plan support in the drones.

In conclusion I am disappointed in myself in how this mission unfolded. Yet, at the same time, I feel I am walking away with a significantly new and deep appreciation for the impact that [fatigue] can have both on my drone and crewed flight operations.

CHIRP Comment

The reporter’s ‘take aways’ are incredibly insightful. In addition: