.st0{fill:#FFFFFF;}

Drones

The postmortem of a drone crash 

 May 16, 2018

By  Peter

Join Our Mailing List

We publish fresh content each week. Read how-to's on Arduino, ESP32, KiCad, Node-RED, drones and more. Listen to interviews. Learn about new tech with our comprehensive reviews. Get discount offers for our courses and books. Interact with our community.

One email per week, no spam, unsubscribe at any time.

During my career as a hobbyist drone pilot, I had a few rough landings, but never a crash. Until Tuesday, May 15, 2018.

I took my DIY drone out to a nearby oval for a test flight. I had made significant changes to the drone’s configuration as part of the course I am currently working on: “Make an Open Source Drone: More Fun.”

I wanted to test several new features, such as radio telemetry, failsafe (radio, geolocation, and battery), flight modes and a couple of automatic missions.

A few minutes into the 2nd test flight, this happened:

I was testing the radio failsafe when I lost control of the drone. I captured the flight in this 5-minute video:

The video contains footage from the ground and the live telemetry data as received by Mission Planner. Although I had a HD camera onboard, regretfully, I didn’t turn it on to record before the flight. I wanted to preserve battery power for a later flight.

First, I want to write about the aftermath of the crash, and then about possible causes and learnings.

Aftermath

Unfortunately, the video did not capture the moment of impact of the drone on the ground.

But, I saw what happened on impact and the milliseconds before it.

I was trying to regain radio contact with the drone as it was plunging into the Earth, and I think I managed to do that just before it crashed. Although the drone, as it was falling from a max altitude of 50m, was in free fall and out of control, it seemed to have almost leveled out just before it hit the ground.

It must have hit the ground at a small angle.

The only broken part was arm #2, and the GPS antenna mast, as you can see here:

I have tested everything else and confirmed there is no more damage.

  • The air radio telemetry module lost its plastic cover, which I put back on with a bit of tape. It still works.
  • The onboard safety button works, although its connector shrink tube is pulled out of position by 2-3mm (see pic above).
  • The radio receiver works.
  • Amazingly, none of the propellers were damaged. Usually, they are the first to break.
  • The HD camera works. Now, I know that the velcro strap will keep it onboard no matter what.
  • The flight controller works.
  • I lost two of the vibration-absorbing rubber plugs for the base of the Pixhawk.
  • The real-time FPV camera works, even though it became separated from the velcro tape, and disconnected from the wiring. I found it around 10 meters away from the wreckage.
  • All the motors still work.
  • The GPS/magnetometer works, even though the mast broke and the module was disconnected. I also collected it a few meters away from the wreckage.
  • The battery had some damage in its shrink tubing but works fine.

All in all, I was very fortunate. To restore my drone, I need one new arm, a new mast for the GSP, and two rubber plugs.

Possible Causes

I have spent time thinking about what might have caused the crash. I will list the facts I have collected, and then I will try to interpret them to explain the crash.

I started the test flight in manual flight, using the Stabilize mode.

0:33 – At around 5 meters altitude, I turned off my controller; this triggered the radio failsafe, as expected. You can see that at 36 seconds into the video.

By default, RTL will hold position at an altitude of 15 meters (see RTL). Because I turned off the radio at around 5 meters, I wasn’t too alarmed when the drone started climbing slowly.

1:00 – You can see the drone climbing to over 15 meters, and continuing. At that point, I thought something is not right. I expected the drone to stop there. A few seconds later I decided to regain control as the drone was at 21 meters and climbing.

1:18 – Radio fail safe is turned off as you can see in the Mission Planner telemetry. That was good news. It means that the drone had radio connection with the radio controller again. I tried to bring the drone to land by reducing throttle, but I could not see any effect. The drone kept climbing.

1:21 – At 29 meters, and climbing. I only use the throttle to bring it to land because I don’t want to change its position. I start to see the risk of a crash, and I’d alternatively crash it in the oval instead of a nearby house or road.

1:23 – Drone is at 31 meters and climbing. Fence Breach appears in the telemetry artificial horizon in Mission Planner. I set the geofence failsafe to trigger at 30 meters altitude, and it did (see my geofencing settings below). Great! But the drone kept climbing!

1:31 – I suspect there might be something wrong with my controller because I can’t see any effect of my control inputs in the drone’s flying. I use Mission Planner (“Ground Station”) to send an “RTL” command to the drone. Although telemetry is still coming through from the drone, I don’t notice any change in the way it flies. The Fence Breach warning is still showing in the artificial horizon as the drone is now at 34 meters and continues to climb.

2:05 – I try, again, to bring the drone back by sending it RTL from the Ground Station. It is now at 42 meters, well above the ceiling of the geofence, and the height of the RTL flight mode. It is becoming clear to me that the probability of getting my drone back in one piece is low. I calculated it to 9.68%. If I had a self-destruct flight mode onboard, I would have used it at this point to avoid injuries on the ground. I don’t, so I flick the switch to Stabilize flight mode and attempt to take control of the drone. You can hear the click of the switch.

2:26 – At 56 meters, the situation is dire. I still don’t have control, and I try a few futile attempts to switch to RTL using the panic switch (SWB) and the SWC+D combination. Eventually, I go back to Stabilize, although my memory of this is fuzzy.

2:32 – At 42 meters, whatever I did seems to destabilize the drone. It starts dropping from the sky like a drone that is out of control. Listen for the characteristic high-pitch sound coming from it. Take cover.

2:35 – The drone hits the ground and breaks up. I look for survivors.

What (I think) went wrong

I am unable to come up with a final theory of what happened. I do have a few key questions for which I have no answer.

Both radio and geofence failsafes worked. What I don’t understand is why the drone continued to fly above the RTL altitude of 15 meters and even above the geofencing ceiling of 30 meters.

Could it be interference in the GPS signal because of the high-voltage electricity lines around the oval? There is a redundant altimeter in the Pixhawk that I expected to have assisted in calculating the true height. Was altitude drift a plausible cause? Maybe. There seems to be a history of this.

While altitude drift may have been a contributing factor in causing the pilot disorientation and confusion, I think it was only partly contributor of the final crash. At 2:32, I did something that caused the drone to exit a stable flight and into free fall. I can’t remember clearly what I did.

I strongly suspect that I disarmed the motors in mid-flight accidentally. If I find evidence that I actually did that I would not be surprised. I did want to bring the drone down to the ground to prevent it from drifting horizontally and ending up on someone’s roof or worse.

Because the failsafes had engaged, it is possible that no other flight mode was possible, so perhaps the only thing I could do at that point was to disarm the drone.

All other modes available on the controller should not cause this kind of behavior. Played back the flight from the logs, but I cannot see any indication of disarming the motors. I admit that I never had to do a thorough investigation of the flight logs. The evidence may be there.

If anyone wants to have a try, here’s the logs (Mission Planner / Ground Station) and APM/Pixhawk.

Lessons learned

As an amateur pilot, I have a lot to learn. This crash taught me a lot in just a few seconds.

First, don’t make too many configuration changes without testing, in flight, in small intermediate steps. My mistake was that the drone had too many config changes before my last flight. I wanted to save time, so I bundled all these changes and hoped to test them all in a single flight.

Second, start with low-risk tests first. Starting with a radio failsafe test first (high-risk) is definitely st*p*d. Why not just test a couple of flight mode first?

Third, ensure your testing defaults are conservative. Make the geofence ceiling 20 meters instead of 30, and the radius 10 instead of 50.

Four, have some spare parts.

Five, fly over soft ground. When you have a crash (it’s a matter of time), you will be able to recover most of your hardware if it crashes on grass rather then concrete.

Six, fly away from people. For obvious reasons.

Seven, don’t fly at all if you are not prepared to lose your drone. Although this was my first crash, I actually feel very good about it.

I’m now waiting for the spare parts to repair my drone and go out for another test flight. I can’t wait!


Tags

Crash, Drone, Fall, News, Postmortem, Video


You may also like

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

I’m thrilled to announce that my upcoming course, Introduction to Electronics, is just a few weeks away from being released on both Udemy and Tech Explorations. This course was designed with the absolute beginner in

Read More
New Course Coming soon: Introduction to Electronics

Robotics is one of the most engaging and effective ways to teach programming, problem-solving, and critical thinking. Today, we’re diving into the CrowBot Bolt, a programmable robot car explicitly designed for STEAM (Science, Technology, Engineering,

Read More
Exploring the CrowBot Bolt: A Hands-On Robotics Kit for STEAM Education