Discussions

Hello all,

I had a frightening experience with an APM 2.5 today that I was hoping some could shed light on. The quad ended up heavily damaged, but more importantly it went out of control and could have flown into others at the field. We are trying to piece together what happened to avoid in the future.

I will try and start at the beginning to give all the facts first:

- This is my father's quad that has about 20 flights on it. It is using APM 2.5 on firmware 2.9.1b. Equipped with the standard 3dr telemetry unit running on  a small netbook PC.

- No previous issues with the quad and worked well up to this point.

- Just recently equipped with simonk ESC's and a 5.8ghz FPV system. Initial flights were fine.

What happened:

We were flying at an indoor fun fly today. It is a very noisy RF environment. The walls are metal and there are up to 50 pilots flying in one soccer field. I consider it the most abusive environment for our RC systems there is. DSM2 glitches are pretty common here...

Anyway, the quad flew great the first flight. I suggested that we raise the rate P gain as a result of the new Simonk ESC's. On the next flight I went to connect the telemetry via mission planner. It initially timed out without making connection (a hint I should have looked into more). The second try resulted in the params being loaded very slowly and gave an error before finishing. The third time worked, and *seemed* to load all the parameters into MP.

I clicked the rate P up a few percent and pushed 'write'. After I walked over to the flight line and set it down.

I armed the quad and as soon as the throttle was raised (10% stick) the quad went full throttle towards the roof. It did not respond to my commands and rolled inverted. I chopped the throttle and it fell inverted towards the ground, narrowly missing some other pilots in the area.

Trying to figure out what happened we briefly viewed the T log (APM logging was not on). The one thing that stands out is the telemetry packet reading in the corner of the flight data display. It hovered around 20% for the whole log.

Is this likely the cause? Does this mean that the connection was poor? Is it possible the 'writing' of the parameters became corrupted due to the poor connection? Can the firmware/parameters become corrupted somehow like this? What does the bad packet reading mean? Did I do anything wrong that i could have avoided this issue?

Now he is in the process of fixing the quad. We will see what parameters we can read off the APM in its state now.

Any advice would be greatly appreciated. While this event was very frightening, I ignored warning signs and it could have likely been avoided, please don't take this as criticism of the APM or Ardupilot software! We just want to learn more and hopefully avoid this in the future.

Thanks!