Design, build and operations

Always expect the unexpected

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.”

We always welcome readers’ comments. 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 input to mail@chirp.co.uk.

There were a couple of comments in social media about Edition 10. The specific report that was commented on was one that appeared in an AAIB report which featured the use of RTK on a DJI M 300 when inspecting a wind turbine. We had chosen to concentrate on the potential Human Factors element of using RTK, where we have direct experience of both the good and bad aspects when it is being used for mapping! The comments pointed out that we should also have mentioned other safety related factors, and in particular that inspections of wind turbines normally take place when the brakes have been applied to both the turbine rotor itself and the yaw drive. Well, we are happy to put the record straight by repeating their point here in Edition 11.

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.

The ‘I learned About Human Factors From That’ (ILAHFFT) section in our other newsletters is a feature where we encourage people to send us tales of incidents or events that, although they may have turned out ok in the end, might not have been their finest hour!  If you have any anecdotes or amusing ‘There I was…’ stories then please do share them with us so that we can pass on any messages or lessons to others.  Send any interesting tales to us at mail@chirp.co.uk and put ILAHFFT in the subject header.  We promise full confidentiality to protect the innocent (and not so innocent!).

Reports

DUAS31 - Battery fell out in flight

Initial Report

Our fleet of a certain type of fixed-wing drone does not have consistent battery bay measurements.  This led to me incorrectly fitting the battery to the aircraft, which finally resulted in the battery being dropped from the airframe and a consequent hard landing breaking two rear v-tail elevators.

CHIRP questions and reporter’s answers:

1. Can you confirm that the battery bay size on each aircraft that is built is slightly different, but the battery size is always the same, thus the difficulty in being able to fit the battery correctly?

Answer: Yes, there is slightly more padding in some of our aircraft. The batteries are the same size. The interesting issue is that I was following my own experience of engineering and effectively laying “flat” the battery, which was the orientation most appropriate for the airframe in front of me. However, the battery was setup for fitting to the “upright” orientation.  I was unaware we had two formats of battery bay spacing.

2. Is the battery secured in its position by sticky tape, rather than a more permanent method?

Answer:  The battery is secured (normally) by two separate attachments. One Velcro strap and Velcro underneath the battery so it cannot slip backwards. In this case the Velcro on the floor of the airframe battery bay was not able to attach to the Velcro on the battery because it had been rotated to the side.

3. Did the battery dislodge as part of a landing sequence, or did it happen when you were inverted?

Answer:  Landing and go-around. We don’t fly inverted.

4. Are there other build-quality issues that also have an impact on pilot confidence in the equipment?

Answer:  There are no other issues at present, and build standards are being addressed internally.

5. Have your comments as the pilot been accepted internally and fed back into the Safety Management System in the appropriate manner?

Answer:  Yes.

Lessons learned:

As an organisation we need to improve the consistency of the build-standard of the same type of aircraft.  This will enable our RPICs to have confidence in the required on site assembly across that fleet and ensure safer operating of the flight.

CHIRP Comment

There are a few points worth emphasising from this report:

• Manufacturing an aircraft that has several different ways of fitting the battery, but no outward indication that helps the pilot tell which version it is, will almost certainly lead to confusion and eventually a battery being incorrectly fitted. Whilst it sounds as if this has now been addressed, it is something of a classic problem. There may well of course be an underlying reason we are not aware of, but consistency in manufacturing tolerance at the point of construction, and then later when performing the initial pre-flight checks, is always a plus.
• It seems that there was no manual explaining how you fit the battery either in the controller or in a physical printed format that the pilot was following which might have alerted them to the different installation alternatives. If there had been it would undoubtedly have helped.
• There is no mention of training in the report, but on the assumption that there was training on this particular aircraft, perhaps the alternative battery installation formats should have been highlighted and made clear in training material and the Operators Manual. In particular if incorrect fitting was likely to result in movement of the centre of gravity, which is what looks like happened in this occurrence, an emphasis on what the outcome of incorrect fitting could be, might have helped the pilot remember how important it was to fit the battery correctly.

Ultimately it is the pilot’s responsibility to ensure the battery in the aircraft that is about to fly is secured in the correct way so, if there’s any doubt, then there’s no doubt, ask someone to clarify anything that you’re unsure of before you operate your equipment.

DUASxx18 - Drone took off with incorrectly fitted rotor arms

Initial Report

In preparation for night-time multirotor drone (~25kg MTOW) maritime surveillance flights, the drone was set up as per pre-flight procedures by the Hub Operator (HO) (personnel in charge of setting up the drone, given the Remote Pilot (RP) is located in a remote operations centre away from the actual flight location). The RP noted the slot time to operate in as approaching, in addition to it being dark, with the HO using their mobile phone to provide lighting during the initial drone set up.

The drone took off, reaching a cruise altitude of 50m where it began to fly its pre-planned routing towards Waypoint 1. During the flight the RP noticed abnormal flight path deviations (no geofence breech), until the Control Unit (CU) alerted of a ‘Flight Zone Exceedance error.’ As an automated response, the drone auto-initiated land-mode as per its design, at which point the RP intervened by initiating hover. During this time the drone had climbed to 56m, requiring the RP to further intervene and descend to 50m whilst concurrently initiating a Return to Base (RTB), given the unstable nature of the flight. The drone landed safely; however, it was noticed the flight path was unusual/abnormal during the landing phase.

On landing, the RP communicated the abnormal behaviour to the OEM support engineer, including the Flight Operations Manager where a full investigation was conducted. The investigation concluded that Motor Arm 5 & 6 were fitted incorrectly with 5 being in slot 6 and vice-versa. There were perceived commercial pressures to make the allocated slot time, which lead to SOPs not being followed correctly and vital steps being missed.

Investigation outcomes:

• The remote pilot and hub operator were current and competent on the type of aircraft flown, both having operated recently and on a regular basis. There were no identified training issues on either record.
• The HO had limited visibility due to inadequate lighting and was trying to put the drone together whilst holding a mobile phone light in one hand.
• SOPs dictate that pre-verification photos should be sent from the HO to the RP to ensure the drone is set up correctly; the wrong arm position was missed by the RP.
• The drone flown had no defects and was subject to no firmware updates prior to flight and was considered airworthy.

To mitigate for further reoccurrence:

• HOs are now issued with head torches to aid drone setup at night-time.
• Checklists have been updated to include a double photo verification process by both the RP & the HO specifically for drone arm position, creating a more robust independent check.
• The organisation operating the drone conducted additional training to familiarise all RP & HOs with the new checklist procedures.
• The slot time for the operation was increased as the team debrief highlighted commercial time pressure for the operation.

CHIRP Comment

This is a detailed report of the occurrence as well as the follow up actions, that has been logged in the Operator’s Safety Management System. During set up, fixing the rotor arms in the wrong position under low-light conditions is clearly an HF occurrence. However, we would also suggest that, from a manufacturing perspective, it could be regarded as a design oversight that it is physically possible to do this. So, whilst it is an operator’s report, we suggest it might be worthwhile feeding back to the manufacturer that the next generation of the drone should have a physical modification that prevents fitting a rotor arm in the wrong place.

We like the list of actions taken after the occurrence, such as additional photographic verification of the arms being locked in the correct position and then being sent by the HO to the RP, as well as ensuring the pilots are equipped with head torches. There was clearly some time pressure coming from the allocated slot time, but a verbal cross check of actions performed by the HO whilst handing over to the RP, might well have done the trick.

One other aspect of the report caught our eye. It seems that the flight was over water and, on a Flight Zone Exceedance error being triggered, the drone initiated an auto-land. The RP was then required to switch to hover, before the pilot descended to the flight planned height limit. If the option exists on the UAS used, we suggest that the RP sets the default trigger to “Hover” or “RTB”, when flying over water, rather than the option “Auto Land”. We would also recommend that this setting should apply when flying over a built-up area.

Whilst the decision to equip the crew with head torches is good, we would probably go a little further and suggest that the take-off and landing site should really have some form of permanent static flood lighting.

Finally, it is worth noting that most Operators perform a control check just after the initial lift off at a height of around 10 metres. The purpose of doing this is to ensure that the movement of the sticks corresponds to the correct movement of the aircraft. We wonder if doing this would have resulted in the controllability issue being noticed slightly earlier in the flight.

DUASxx19 - The Swiss cheese strikes again

Initial Report

AAIB report 29008 published June 2024. The aircraft was operating at West Wales Airport when the remote pilot observed the engine had stopped. The aircraft had lost all electrical power but continued to fly briefly before disappearing behind a hedge. The aircraft landed a short distance beyond the south-western edge of the airfield. It sustained minor damage; there was no damage to property or injuries to people.

The plan involved the aircraft taking off from West Wales Airfield (WWA), operating in visual line of sight (VLOS) within the air traffic zone (ATZ), and beyond visual line of sight (BVLOS) below 3,000ft amsl within 1.8 km of the remote pilot (RP), all within danger area D202D. The RP conducted the take-off at 1215 hrs and handed control of the aircraft to the RP station operator (RPSO).

A number of tests were conducted to validate the autopilot and flight control systems. At 1350hrs the RP observed that the engine had stopped, with the aircraft 1,000ft agl over the centre of the airfield and routing along the northern edge of Runway 25. He informed the RPSO that he was taking control by saying “my bird” to which the RPSO acknowledged “your bird”. However, the RP then advised the RPSO that he was not able to gain control; the RPSO then attempted to regain control but without success. The RPSO advised ATC of the situation. Meanwhile, the aircraft continued further along the direction of Runway 25 for about 30secs before turning right and circling, then disappearing from the RP’s sight beyond a hedge (see graphic of the track during the accident flight).

The UAS was a Prion Mk3 fixed-wing monoplane with a 4-stroke petrol engine, which uses an electronic fuel injection system and an electric alternator generator. It has a maximum take-off mass of 55 kg with up to a 4.5 m wingspan and is 3 m in length. The airframe remains visible to the naked eye within a flight envelope of 1,000 m lateral distance up to an altitude of 1,000ft agl.

The Prion MK3 uses ground power prior to engine start. Once the engine has started, power is supplied by an on-board alternator generator. In the event of the generator failing, there is an emergency lithium polymer battery, which will continue to power the systems for a minimum of two hours (calculated at 20°C). This battery is tested for charge before each flight and is continuously charged by the alternator generator while the engine is running. There is a warning system fitted to ensure this battery is connected before flight. The field crew could monitor the charge status of the emergency battery using the flight telemetry system, if selected for display. After flight, the aircraft is connected to ground power, which also charges the emergency battery.

Operator investigation:  The operator’s post-flight investigation determined the accident occurred because of the total loss of electrical power. This occurred on the second flight of the day once the emergency battery became discharged, resulting in loss of flight control, communication with both the RP and the RPSO and the shutdown of the engine. Consequently, the aircraft glided to the point it touched down.

The investigation established that the alternator generator system was not delivering power nor charging the emergency battery because of an incorrect wiring connection which had not been identified during assembly. Prior to the accident, the wiring for each airframe was unique. The operator has since standardised the schematics and wiring across the fleet. It also identified that the field crew had not selected the option on the flight telemetry system to enable them to monitor the voltage of the back-up battery.

The investigation also established that the powerplant had been changed the previous day, but that validation of the performance of the alternator generator system had not been carried out. It identified that the fault existed for the first flight of the day which lasted only 35 minutes but which, consequently, did not fully deplete the emergency battery. The fault was not identified prior to the second flight since the emergency battery was charged by the ground power connection prior to flight, preventing the pre-flight check from identifying that the emergency battery charge had been depleted during the first flight.

The operator identified that the after-flight check list was missing a check of the emergency battery status prior to the aircraft being connected to the ground power. It also improved the engine monitoring graphical interface flight telemetry system to include voltage indication of the emergency battery to allow its charge status to be monitored in flight (updated engine monitor page shown with new emergency battery voltage indication top right). This would indicate if the alternator generator system was faulty.

CHIRP Comment

Whilst it is easy to see that the emergency battery is charging properly in the second graphic (post the manufacturer’s reconfiguration of the controller display), it is interesting to note that the design of the aircraft originally meant that the wiring layout of each aircraft was unique. This no doubt resulted in quality control of the wiring during manufacture being a difficult and time-consuming process, prone to error.

Given the original controller display design aspect combined with pre- and post-flight emergency battery checks being missing from the list, the holes in the Swiss cheese were lining up perfectly. When the power plant had been replaced the day before the occurrence flight, there appears to have been a functional check of the alternator generator missing from the installation protocol, such that the incorrect wiring was missed.

In summary, the following Human Factor mistakes seem to have all combined to lead to this accident:

1. A manufacturing quality control failure to check the functionality of the generator.
2. A missing engine change post-installation check that the emergency battery generator was functioning correctly.
3. The pilot did not check the generator charge display option or do a pre- and post-flight emergency battery check.

DUASxx20 - Always expect the unexpected

Initial Report

The flight was part of an educational challenge taking place on an approved and managed site. The aircraft was scrutineered by experienced aircraft professionals, as well as pre-flight checked and the failsafe and all controls checked. The remote pilot checked the controls and took off with the UAS, which was a VTOL-type aircraft.

The aircraft took off well, hovered nicely and responded to all controls. At this point the remote pilot took the aircraft higher (100ft) and transitioned to airplane mode, which again was successful, and the remote pilot began a circuit in plane-mode. At the right end of the circuit the UAS became unresponsive, and the remote pilot put it back into multirotor mode to hover, which it did, however control was still unresponsive.

At this point the remote pilot activated the manual failsafe, which did not work, so went to the electronic failsafe and turned off the controller, which also did not work. The UAS was then tracked visually as far as it could be seen until power failed and it glided to the ground in a distant field but could not be found.

The reporter subsequently noted that one of the learnings was anticipating the reaction of the crowd, when the pilot shouted “flyaway and loss of control” and started the emergency response sequence. Somewhat unexpectedly, those on site looked up and started to follow the aircraft, rather than remain clear. This was dealt with by an onsite debrief the next day.

CHIRP Comment

Perhaps the HF point most worthy of noting with this occurrence is the reaction of the spectators. Whenever you are flying it is important to consider what the reaction of the public might be when triggering an Emergency Response Plan (ERP). The crowd may well react in an unexpected manner that may have an impact on what you choose to do as part of the ERP. In this instance, the crowd regarded the flyaway as something to watch and participate in, rather than stay away from; they may have regarded it as helpful to follow the aircraft for the purpose of assisting in its recovery or it is possible there was a competitive element motivating the need to watch someone else’s aircraft suffer from a flyaway!

Unfortunately, the aircraft wasn’t recovered so diagnosing the reason for the flyaway, (which we emphasise happened after it had been scrutinesed, had its failsafes checked and had its geofencing checked), has not been possible. It would undoubtedly have been very useful, if it had been found.  It’s worth remembering sometimes that no matter how many checks and re-checks you perform, there’s always scope for something unexpected to go wrong that you hadn’t considered so never be complacent that you’ve got all the bases covered!