PSA / WARNING: This Can Happen To You

[ianwood]

I didn't think they were real. I thought they only happened to people who didn't pay attention to the details. They weren't really flyaways. Well, not any more.

Today, I had a flyaway. It was a perfectly normal flight for 11 minutes. I was reshooting a location I had shot two weeks ago. I had the P2 in a static hover about 10m off the ground (15m from me) while I figured out my last few shots.

It then took off at ~25 degrees down angle at full speed and smashed into the street. Both gimbal and Lightbridge ripped clear off and tumbled across the street. It was over in two seconds. The battery had half-way dislodged and was still on (1 solid, 1 blinking). All four props were destroyed, two right at the hub.

I gathered all the pieces, cursing profusely and took them home. I then checked everything out in detail.

• The battery is fine. 22 cycles. Balanced. Test flight on my backup P2 was 14.5 minutes.
• IMU, no calibration needed as per the Phantom Assistant. Had advanced calibrated 2 weeks ago.
• Compass MOD is 1403.
• I had checked the props prior to flight and they were fine. Not so much now.
• I ran stress tests on the ESCs / motors. Totally fine. No unusual noise. Balanced bell housings.
• RC calibration is perfect.
• I went back to the site, looked for any magnetic, EMI, RF sources. Nothing.

So that leaves really one maybe two possibilities:

• Lightbridge commanded the movement (no idea if that's even possible).
• More likely, the IMU and / or Naza locked up or received bad IMU data.

With bad data or a frozen IMU, the Naza would get bad reference data for where gravity is and then would command the motors to correct for it. That would create an unrecoverable situation.

Either way... It was a flyaway. They're real. And they can happen to you. Fortunately, it happened in an area where it was recoverable. Gimbal is bent beyond repair. The GoPro somehow took the brunt of the impact. It's gone as are the last 20 seconds of the video so no crash.

 

[LuvMyTJ]

My condolences. Sometimes they get a mind of they're own.
Rebuild or parts?

 

[TeamYankee]

Well, it could of been a NAZA issue.. or RF interference causing the phantom to fly by itself on the noise.
I have a cell tower near me that if I fly in front of one of the dishes or through the "beam" from the dish then the P2 either goes to failsafe RTH or swerves off course badly until it goes out of the beam area and then comes to a hover awaiting further stick inputs.

 

[ianwood]

RF noise won't cause a flyaway. If you fly in front of a microwave repeater, it's a very focused beam and will effectively irradiate the innards of your bird for as long as you are in it. Even then, the effects wouldn't be very strong or long lasting and wouldn't result in a sustained uncontrolled flyaway.

 

[Ezookiel]

For it to descend at that speed, I can't have been being commanded to by anything, unless it was also totally overriding the stupidly slow descent speed built into these things.

 

[sergekouper]

This is THE thing that shouldn't have happened to you! Now reading your post, my confidence in DJI is destroyed as well (even if it was not that strong anyway), and worrying for my bigger DJI bird too... Very sad to hear. Were you ATTI when it happened?Did you swipe the zone with a spectrum analyser before take off?
It's stays a congested area with imposing buildings as well. IMO it could be an interference in the neighbourhood, dead gps spot close to this building, maybe a local draft ...
Sorry for you anyway.

 

[HunterSK]

Several months ago I experienced a similar issue. Wrote up a detailed report here:

http://www.phantompilots.com/threads/are-flyaways-flying-away.30877/#post-282613

Up until then I had 200 successful flights and was practically convinced that flyaway were because of severe operator error. I did my usual check list, everything was normal and my bird flew itself into the ground.

I suspect it was some sort of software or sensor error (no evidence of course). Definitely not a hardware issue, as once I replaced with fresh propellors the affected Phantom flew as normal.

 

[CarlJ]

I didn't think they were real. I thought they only happened to people who didn't pay attention to the details. They weren't really flyaways. Well, not any more.

Yeah, I'm starting to rethink my position on that as well.

Really sorry to hear Ian.

So does this mean you'll be getting a P3?

 

[Jaybee]

Wow, that's a gutting situation man : (

I know first hand how these situations knock your confidence in multirotor technology. Despite a year of successful flying with my second P2, I still have a sense of relief every time I complete a flight.

Out of interest, what firmware version do you have installed?

On the surface it does feel like a major software malfunction. Even if the control signal was interfered with, a rapid decent speed like that wouldn’t have ensued. That really should only possible in full manual mode.

Once again, this demonstrates the importance of airframes having detailed flight controller data recorded, so, providing you can retrieve your downed airframe, the manufacturers can decipher what happened which ultimately will help the continued development of the technology.

Clearly the reliability of the software / hardware relationship is what makes or breaks multi-rotor technology. Manufacturers can boast the latest and greatest hardware, but a small code glitch could mean game over for someone’s airframe. Case in point, updates like the recent 3.10 disaster do nothing for a pilot’s confidence. This challenge isn’t limited to just DJI and exists for all manufacturers. I recently read about someones nasty ALIGN M680 flyaway after 80 successful flights.

Quick aside, if anyone is reading this considering buying the P3 – do yourself a favour and wait a while. Historically, teething problems are more than likely with any new DJI product and the P3 packs in loads of new software integration – expect issues.

Hoping DJI respond to this asap for you.

 

[TeamYankee]

hmm.. you have a point with the rapid decent.. maybe DJI or some other third party will release a flight logging system to capture essential NAZA data on a micro SD card.
I'd be up for that!

 

[N017RW]

This Naza is a member of the lowest tier MC DJI currently sells.

Can't vouch for this guy's qualifications but here's some food for thought.

https://richardstechnotes.wordpress...mems-9-dof-imu-is-doomed-to-failure/#comments

 

[RichWest]

This Naza is a member of the lowest tier MC DJI currently sells.

Can't vouch for this guy's qualifications but here's some food for thought.

https://richardstechnotes.wordpress...mems-9-dof-imu-is-doomed-to-failure/#comments

Interesting link, thank you! He sounds like he knows his stuff or at least is very interested in the understanding of such systems....https://www.linkedin.com/in/richardbarnettus

Really the concern is industry wide within the RC world. Without redundant processes, there will be issues. When the control hardware (IMU/MC) has a glitch things go wrong. I always reference, one is none, two is one...

Further, buying a P3 is not going to solve this issue. Evidence from the Inspire-1 fly-aways as your example. Firmware should improve things, but will not solve the issue...

 

[LuvMyTJ]

This Naza is a member of the lowest tier MC DJI currently sells.

Can't vouch for this guy's qualifications but here's some food for thought.

https://richardstechnotes.wordpress...mems-9-dof-imu-is-doomed-to-failure/#comments

Interesting but scary read.

 

[ianwood]

Once again, this demonstrates the importance of airframes having detailed flight controller data recorded, so, providing you can retrieve your downed airframe, the manufacturers can decipher what happened which ultimately will help the continued development of the technology.

Very true. I just put an updated Arduino based CAN logger in my other P2 and was planning the same for this one. Won't fly again without it. I want full instrumentation so that should this ever happen again, I have every single sensor calculation. I hate that I don't really know what happened here.

The lack of video for the last 20 seconds including the crash nearly made me insane yesterday.

This Naza is a member of the lowest tier MC DJI currently sells.

Can't vouch for this guy's qualifications but here's some food for thought.

https://richardstechnotes.wordpress...mems-9-dof-imu-is-doomed-to-failure/#comments

Interesting. I kind of agree and disagree with him at the same time. It's messy and the integration is so codependent that it only takes one sensor to go way off to throw the whole thing off. There's no easy way to validate the quality of your input data.

Ironically, in my day job, I've been working on mobile solutions that use sensor fusion to enhance GPS based navigation / tracking i.e. using magnetometer, gyroscope and accelerometer for inertial / reference data to derive intermediate positions between infrequent or poor accuracy GPS points. I only half understand what the data scientists come up. Just had a long explanation of quaternions the other day.

The one thing I will say is that it took roughly 200 flights to get this to happen. So, it's pretty rare.

 

[RichWest]

ianwood - I found the thread for the " Arduino based CAN logger", 39 pages.... Very interesting and am fascinated by the data it could provide. Out of curiosity, what is the cost to implement all the required hardware into the P2 with this solution?

I don't have an account at OSH Park at present to see beyond the curtain....just curious.

 

[ianwood]

ianwood - I found the thread for the " Arduino based CAN logger", 39 pages.... Very interesting and am fascinated by the data it could provide. Out of curiosity, what is the cost to implement all the required hardware into the P2 with this solution?

I don't have an account at OSH Park at present to see beyond the curtain....just curious.

I have one of pawelsky's older boards in my other P2. The guy is a genius. I will be trying my hand at soldering up some of his boards. Just ordered five from OSH Park.

The data is incredibly detailed. Key to diagnosing an incident like this, you get:

• All sensor raw and calibrated values
• All RC input values
• Control and flight mode
  
• All GPS data including DGPS, HDOP, VDOP
  
• Computed pitch and roll
• ATTi commanded pitch and roll
• Motor RPM (all motors)
• Individual cell voltage

 

[stan]

If you don't feel comfortable soldering SMD I can help you out. Just let me know

 

[Jaybee]

Very true. I just put an updated Arduino based CAN logger in my other P2 and was planning the same for this one. Won't fly again without it.

Sounds interesting, all new to me. Can you link some info?

 

[RichWest]

I have one of pawelsky's older boards in my other P2. The guy is a genius. I will be trying my hand at soldering up some of his boards. Just ordered five from OSH Park.

The data is incredibly detailed. Key to diagnosing an incident like this, you get:

• All sensor raw and calibrated values
• All RC input values
• Control and flight mode
  
• All GPS data including DGPS, HDOP, VDOP
  
• Computed pitch and roll
• ATTi commanded pitch and roll
• Motor RPM (all motors)
• Individual cell voltage

Out of curiosity, what is the cost to implement all the required hardware into the P2 with this solution?

 

[landmannnn]

I will probably get shot down here, but are we looking for complexity where there is none?
A device that requires 2.4/5.8ghz, GPS and a digital compass to fly will, at some stage, behave unexpectedly in area with large amounts of steel, flat surfaces (multipathing) and potential interference.
Surely one, or any combination of the above are more likely candidates than errant coding?