Mavic 2 Lost to the Ages

[paulatkin73]

Actually, that's not correct. Flyaways don't always lead to a crash.

elaborate?

 

[BudWalker]

elaborate?

I added this to my post. Maybe you didn't see it. It's a reference to the first time I saw this behavior. There was no fly away in this incident
Recorded flight data vs real time data

But, there have been many other Yaw/magYaw separation type incidents that didn't result in a fly away.

 

[BudWalker]

....
the part that baffles me, still, is the fact that DJI left the final failsafe not exposed into the settings anywhere and this final 'ATTI mode switch' is indeed used instead of the forced landing. i......

I don't understand this. I assume you're referring to the .txt posted in #9. There was no switch to ATTI mode.

Also, the failsafe spec can be seen in the column MC_PARAM.failSafeAction. But, there is something odd about this as can be seen in this flight. IMC_PARAM.failSafeAction was set to GoHome until 812.5 secs when it was set to Hover. Actually, there was a gap between 812.5 and 847.1 secs. At 847.1 secs the OSD.flightAction was set to OutOfControlGoHome. So, it would seem there is an inconsistency between MC_PARAM.failSafeAction and OSD.flightAction. Welcome to DJI land

 

[paulatkin73]

I don't understand this. I assume you're referring to the .txt posted in #9. There was no switch to ATTI mode.

Also, the failsafe spec can be seen in the column MC_PARAM.failSafeAction. But, there is something odd about this as can be seen in this flight. IMC_PARAM.failSafeAction was set to GoHome until 812.5 secs when it was set to Hover. Actually, there was a gap between 812.5 and 847.1 secs. At 847.1 secs the OSD.flightAction was set to OutOfControlGoHome. So, it would seem there is an inconsistency between MC_PARAM.failSafeAction and OSD.flightAction. Welcome to DJI land

right. well, what people really need is the way to crack this dji hardware open and go free source with the code.
failsafe routines usually are set on 2 or 3 levels. you should be able to set what to do on radio signal loss, RSSI driven failsafe, what to do on battery failsafe, within configurable battery left limit and a critical voltage limit, and what to do in case of the critical inconsistency of core FC metrics.
there were several posts i saw during last 3 months alone where a suspected reason of the crash was identified as an IMU failure that resulted inthe uncotrollable model drift who knows where. that sounds to me as an embedded switch into ATTI mode instead of the immediate landing.

in this thread itself, why model drifted away, again, after the inconsistent imu/compass scenario? why there was any movement at all after that and why model was broken apart? there is 0 justification for any of that. gyros were alive, so, all it needed was to keep the horizon and land safely where it was. standard classic failsafe. instead, it crashed. odd and unexplainable design.

 

[sar104]

I don't understand this. I assume you're referring to the .txt posted in #9. There was no switch to ATTI mode.

Also, the failsafe spec can be seen in the column MC_PARAM.failSafeAction. But, there is something odd about this as can be seen in this flight. IMC_PARAM.failSafeAction was set to GoHome until 812.5 secs when it was set to Hover. Actually, there was a gap between 812.5 and 847.1 secs. At 847.1 secs the OSD.flightAction was set to OutOfControlGoHome. So, it would seem there is an inconsistency between MC_PARAM.failSafeAction and OSD.flightAction. Welcome to DJI land

I think we have seen previously that this parameter doesn't reflect the setting until signal loss occurs. However, in this case the setting changes a couple of times just before signal loss, which is very odd.

 

[BudWalker]

I think we have seen previously that this parameter doesn't reflect the setting until signal loss occurs. However, in this case the setting changes a couple of times just before signal loss, which is very odd.

View attachment 66625

That's right. But, I thought it was set to Hover until it's actually used. If these values are reversed from what they actually are then that would be consistent with the OSD.flightAction. Too bad we can't see the AC .DAT.

If you're referring to the MC_PARAM.failSafeAction change at time 338.8 secs there was a probable signal loss there as well. The next record occurs 7.5 secs later at time 346.3.

 

[BudWalker]

right. well, what people really need is the way to crack this dji hardware open and go free source with the code.
......

You might want to check out the onboard SDK
DJI Developer

 

[sar104]

That's right. But, I thought it was set to Hover until it's actually used. If these values are reversed from what they actually are then that would be consistent with the OSD.flightAction. Too bad we can't see the AC .DAT.

If you're referring to the MC_PARAM.failSafeAction change at time 338.8 secs there was a probable signal loss there as well. The next record occurs 7.5 secs later at time 346.3.

That's right, but it's odd that the parameter changes just before the signal is lost. I'd expect it to change after signal loss and then be reflected in the value on reconnection. I must be missing something basic about how that works.

 

[Bryce steiner]

DJI just posted a repair report and the first thing says an ESC Status Error. This is the image they posted. What does that mean?