Expect the unexpected!

What could possible go wrong? Threat and Error Management (TEM) is a vital part of anticipating problems and ensuring safe operations.

Welcome to Drone FEEDBACK Edition 10.

I hope you have had some good winter flying for pleasure, gathering data of one sort or another or perhaps doing trials for medical deliveries. Seasonal icing, fog and of course rain have been the main challenges the sector has had to overcome over the last few months. This has led to cold fingers trying to manipulate controllers and their myriad of buttons as well as small screens, batteries not lasting as long as they do at warmer times of the year, and other “gotchas” lying in wait for the unwary drone pilot.

In this issue we have a number of reports that were sent directly to CHIRP and we have kept our eyes open for some additional Human Factor related happenings that we feel would be useful to bring to the attention of the drone flying community. We have included a report from NASA and the UK AAIB, both of which exemplify situations that might happen to any of us and that involve Human Factors.

Whilst the days are now starting to get longer, we have been hampered by fog recently and although some of the latest drones alert you to “low visibility” these days don’t let that warning alone be the deciding factor for the decision to take-off or not. As we have noted in previous editions, propeller icing forms in a number of different scenarios so stay wary of that too when the temperature drops and you are flying in the early hours!

Human Factor related errors will however continue to creep into day-to-day operations and make life difficult. Let’s see if we can learn something from the occurrences described below.

Rupert Dent, Drone/UAS Programme Manager

Report to CHIRP!

Reporting to CHIRP is easy by using either our website portal or our App (scan the appropriate QR code shown or search for ‘CHIRP Aviation’ – ignoring the birdsong apps that may 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, none of your details are shared outside CHIRP, and we have our own independent secure database and IT systems to ensure confidentiality.

CHIRP FEEDBACK Survey

   

We value your opinion about our FEEDBACK newsletters and associated engagement methods, please spend a few minutes responding to 10 short questions about CHIRP Aviation FEEDBACK

Reports

DUAS29 - Unexpected move post-launch

Initial Report

The flight was planned to be a short-range flight (10m) with a hover to execute a maintenance cycle of a set of batteries for the DJI M30T.  Preflight checks were carried out and the aircraft was powered up. Once the home point had been recorded, the pilot completed final checks and throttled the aircraft up to take off.  Immediately on becoming airborne, the aircraft pitched forward and flew rapidly forwards for approximately 4 metres at high speed at a height of under 1m. It then appeared to brake of its own accord. Standard flight procedures involve initiating screen recording prior to take off so the incident was recorded on video. Additionally, the detailed flight logs have been examined and confirm that: a) the home point had been recorded; b) 20 satellites had been locked onto; and c) only the left stick (throttle) was moved by the pilot during this period. The pilot allowed the aircraft to stabilise and then immediately returned to the take off point and landed.

Playback of the screen recording suggests that in the 2 secs immediately prior to take off, the on-screen telemetry was showing a groundspeed of up to 1.5m/s, even though the aircraft was stationary. Because the pilot was carrying out airspace checks in this time, this anomaly was not apparent.

The latest firmware had been applied to the aircraft and controller 4 days earlier, and a total flight time of 90mins had been flown without issue.

Lessons learned: Pilots to confirm speed is registered as zero immediately before lifting and ensure no persons are within 5m of aircraft in any direction at take off / landing

Further Correspondence: There was some very helpful correspondence with the reporter that sheds additional light on what might have happened:

Further analysis of the flight logs shows a ‘horizontal speed’ of between 1 and 3m/s being logged, even though the aircraft was stationary on the ground, in the seconds immediately before lifting off. The indicated direction of travel was backwards from the lat/long readings. The on-screen display and audio confirmed 20 GPS satellites and home position recorded, leading the pilot to conclude it was safe to take off.

My current working theory looking at the flight log data is that immediately on lifting off, the aircraft believed it was moving backwards, horizontally due to an inconsistent GPS signal. There was a wall approximately 6m behind take off point and so the obstacle avoidance system activated immediately and caused the aircraft to ‘brake’ by pitching heavily forwards. This can be seen in the 25 degree pitch recorded in the flight logs with no pilot input. The physical result was the drone moving rapidly forwards for around 4 metres.

Our pilots have been given extra guidance as follows:

The pilot has logged over 200 flights on the M30T aircraft.

CHIRP Comment

Vision sensors switched on and low light levels along with a low satellite count don’t go well together! We know and have experienced how drones can move themselves a meter or two in the air without being commanded to do so when satellite count gets low or there is multipathing which results in low signal quality. If airborne in poor light, vision sensors intermittentley see and then don’t see a nearby obstruction. We recommend that where the number of satellites indicated on the controller at switch-on is inadequate, it is worth checking in the sub menus, to see the level of satellite reception and the signal quality, before starting the motors. In many of the latest drones, the number of satellites being received and the quality are indicated in the right hand top corner of the controller. Once the controller is switched on, the indicator displays a number and changes from red, to orange and then finally green. Once it is green, you are good to go!

With adjustable proximity-activation distances, if the pilot is too close to the aircraft on start up, it will normally give an aural warning. This is the moment to re-calibrate the activation distance as part of pre-flight checks and before take-off. As can be seen in this instance, if you have them set at say 10m but you are standing 5m from the aircraft on take-off, it may result in a forward movement of the aircraft if the proximity setting is switched to “avoid” rather than “brake”, particularly if you add being in an environment with low light levels to the mix as well. We would suggest a minimum distance of 10m between the pilot or an obstacle and the aircraft at takeoff rather than 5m. The reason is that it will give a little more time for the pilot to react, possibly switching into ATTI mode if appropriate, should they need to intervene quickly during takeoff if the aircraft starts doing something unexpected or unanticipated. Alternatively if an appropriate distance from fixed objects cannot be achieved, then it would be wise to consider moving to a better TOAL site entirely.

DUASxx15 - Collision during swarming

Initial Report

From AAIB report No AAIB-29203. A swarm of 638 UAs took off as part of a planned test of a light display. The preprogramed launch and animation flight were completed without incident. As the UAs switched to ‘return to home’ mode they returned to their grid positions. Several UAs then flew out of formation, before the pilot sent an emergency hold command to which the fleet responded, and all UAs held their position. A manual ‘return to home’ command was sent and the UAs returned to their grid formation. When the swarm began to descend the same UAs again flew out of formation. The swarm was then landed in altitude order, due to concerns about battery endurance. All UAs stayed within the planned geofence. Three UAs sustained broken arms and there were several chipped propellers. An investigation by the operator determined that deviations from the planned flight route were caused by flat batteries in the controller unit, which had been left switched on when stored.

Lessons learned: The Operator has introduced a new procedure to remove all batteries when not in use.

CHIRP Comment

We agree with the initiative to remove all batteries when they are not in use. We would also suggest that if it isn’t already there, it would be a good idea to add a controller battery check as part of the pre-flight checks. Whilst we do not have a significant amount of experience with swarms, we have set out below a few basic recommendations that readers may wish to consider when operating a swarm:

With swarm light shows becoming more frequent, these provisions are designed to manage some of the potential pitfalls of flying swarms.

Finally, it is worth highlighting that this occurrence is in some respects a good news story. In dealing with the issues that occurred, everything that was supposed to happen did and the UA stayed within the geofence.

DUASxx16 - Inadvertent flight above 400ft

Initial Report

At CHIRP we are in touch with several other Human Factor reporting entities, including NASA and their Aviation Safety Reporting System (ASRS) who perform the confidential reporting function in the United States. We are grateful for their permission to reproduce below an HF occurrence that was reported to them in October of 2023 as report ACN: 2951851. I have summarised the report below, but for those that are interested to see the whole report and the level of detail NASA manage to get reporters to fill out, follow this link to the site: https://asrs.arc.nasa.gov/search/database.html. To find drone related reports within their online database choose Federal Aviation Regs (FAR) and select: Part 107 or Public Aircraft Operations (UAS) or Recreational Operations / Section 44809 (UAS).

I was operating my UAS on a mapping mission with a base station for RTK (Real-Time Kinematic Positioning) corrections. I was running an automated mapping mission using the KMZ file using the app. This was my first operation of the KMZ file as opposed to a KML file. As per the KMZ file, I was having the mission fly to remain no more than 400 feet AGL to the terrain, and in order to maintain a visual line of sight I would move throughout the hilled/undeveloped area in order to maintain VLOS.

I would have to remove the cap on the application in order to allow the drone to fly the 400 feet AGL over the hilled areas. This mission became lengthy as I would return to the home start point, move a few hundred feet to a good vantage point that would keep a VLOS, then start the drone and move with it. I would then have to return the drone to home and I came along with it, which proved to be fatiguing. Part of this fatigue was caused by me being hypervigilant to the nearby airport, as there were airplanes practicing landings/touch and goes, (across the highway, but still close by) and I wanted to ensure no airplanes were moving towards the south (towards me).

Towards the end of the mission, the drone began the return to home. During this the drone began to rise to 1000 ft. I was keeping visual line of sight directly and realized it was becoming increasingly difficult to see. I looked at the remote and realized it was at 1000 ft AGL. I then ceased the operation and took manual control and brought the drone down as quickly as possible. Upon investigating the issue, I soon realized that because I set the return to home safely at 1000 feet, the drone automatically went to that height. My error was not setting it at the 400 feet that I normally set it to. I set the max altitude in the application to 1000 feet, in order to move along the hillsides. (this height would only happen in relation to the altitude). This was also my first operation in a hilled/varying terrain area which added another layer of difficulty. I mostly run mapping missions on smaller flatter terrain.

Lessons learned: For future flights with varying terrain areas, I will set the return to home altitude no more than 250 feet, which is one of the highest points in the area above my start point. I will also manually fly the drone home at a much lower altitude instead of letting the drone automate itself for a return to home when it comes to unfamiliar sites or varying terrain sites.

CHIRP Comment

An explanation may be required for some regarding the difference between a .KML file and a .KMZ file. In essence a .KML file is a file format that is used for storing geographic data. A .KMZ file is a file format that stores several .KML files (they are in effect zipped thus the Z), as well as their associated resources.

What the reporter is saying at the beginning is that by using a .KMZ file as the source data for the mapping mission, he was undertaking a more complex and longer flight plan than he had done before. Crucially, the RTH height needs to be set separately from the mapping mission part of the flight and needs to consider not just the surrounding terrain height, but also the maximum height of 400ft that is normally permitted for a standard drone flight. It is also important to remember that the vision system settings need to be considered as well, specifically whether the drone hovers or avoids obstacles if it comes across them when performing an RTH.

Forgetting to adjust the RTH height settings before a flight is an easy mistake to make, but it can have unexpected consequences. We would advocate RTH height settings being added to the sequence of pre-flight checks. They should be based on the maximum height of terrain / obstacles in the region being flown for the mapping mission, plus a safety margin.

There was a final aspect that the Board discussed in relation to this occurrence. Some pilots will automatically press RTH at the end of a mission and some will choose to manually fly the drone back home. What do you think the pilot should have done in this instance?

DUASxx17 - Collision with wind turbine

Initial Report

From AAIB record-only UAS investigations reviewed October to November 2023, published within AAIB Bulletin: 1/2024. The remote pilot had planned a series of automated mapping missions. On the third day of conducting this mission, the UA lost real time kinematic signal which caused the UA to pause during a turn away from a wind turbine. The remote pilot resumed the flight and the UA initially reversed along its previous flight path, flying into the wind turbine. The remote pilot was not aware the turbine had the ability to rotate 360° around its vertical axis. This required a larger area to avoid for the UA to maintain 50m clear of the turbine in all positions, which was not taken into account when planning. The UA sustained significant damage and was replaced. There was no visible damage to the wind turbine.

 

CHIRP Comment

This occurrence relates the consequences of not ensuring that the automated settings are appropriate for the flight being undertaken. Real Time Kinematic “RTK” input has become a very useful tool for drone-based survey data capture. It increases accuracy. However for an automated mission it is important to set what the aircraft will do should RTK disconnect. It can either be set to hover or to continue the mission to the end of the sequence. In this instance it paused and then retraced its flightpath to where the RTK had dropped out, in order to then continue the mission without leaving any data gaps. Clearly the wind shifted, the turbine shifted with it and this is why the aircraft came into contact with the blade. What is not clear is whether the vision systems were active or, if they were, whether it was the speed of the turbine blade that was so high that the vision system transmission lag with the control inputs resulted in it hitting the aircraft.

At CHIRP we do meet, with a certain regularity, occurrences where the root cause was the pilot initiating one controller input which then leads to another automated control input that wasn’t expected. The pilot then finds themselves behind the aircraft and struggling with where the control logic is going to take them next. Anticipating what happens next is key to dealing with this and there is no substitute for reading and re-reading the user manual, as well as comprehensive and regular currency training.

DUAS30 - Flew through electricity cables

Initial Report

Performing Beyond Visual Line of Sight (BVLOS) flights with visual mitigation (observers positioned out along the flightline who are in touch with each other and the pilot) for the purpose of data capture, we flew through cabling between two pylons a total of 4 times and only noticed they were there when looking at the photographs after the flights. The pylons were obscured from the TOAL site because we were in a cutting. We had previously flown an adjoining section of the same infrastructure in the opposite direction and the pylons at the end point of the two sections were obscured from the TOAL at both ends of each section, even if the aircraft always remained VLOS. The electricity cables were across the infrastructure rather than parallel with it. This meant they were much more difficult to see. The first photo I attach is a general view from aircraft. The pilots were located on the right-hand side, away from the track. There was little visibility of the cables that were across the track and the pylons were obscured from view. The previous flight was flown towards the road bridge, from the far end. The cables were between 30 and 45m high and crossed over this side of the road bridge. The second photo is an approximately 11X zoomed picture looking under the road bridge.

Lessons learned: When checking for electric cables, it is not sufficient to just look for pylons alone. Electric cables are difficult to see and the site inspection should include the start and end point.

CHIRP Comment

As the CAA has recently launched a consultation on Atypical Air Environment, this is a particularly well-timed report. When flying linear infrastructure for the purpose of data capture, identifying ground control points, image overlap, on-board data-storage capacity and data-block sizes for delivery are all primary considerations in establishing site work methodology. This means that, on occasion, several flights might take place where they are flown in opposite directions towards each other.

The end point of two flights that meet in the middle but are flown in opposite directions, may inadvertently end up not being subject to on-site visual inspection by the pilot. Pylon cables are difficult to see with the naked eye, particularly if they are at some distance. This report shows how easy it is to mistakenly fly through unseen wires when the pilots are concentrating on the output, rather than the flights. This occurrence is all about the lack of real pre-flight planning. Closer attention to relevant Apps that supply all the information for low-level flying is essential and a focus on the detail as well as ensuring the relevant layers are switched on, would have avoided this situation.