Lost Aircraft

[slup]

...My question was more about your conclusion though. You based it solely on data that we don't know to be accurate.

That's why I try to use "guess" "think" "believe" "assume" "indicate" & "plausible" when I combine questionable data with my own experience from looking into nearly all cases here at the forum since 2019... it ends with assumptions, very much like you write in the first text section in post #23.

Motor & raw sensor data is usually needed in order to be conclusive regarding the root cause to a loss of thrust incident.

 

[msinger]

That's why I try to use "guess" "think" "believe" "assume" "indicate" & "plausible" when I combine questionable data with my own experience from looking into nearly all cases here at the forum since 2019... it ends with assumptions, very much like you write in the first text section in post #23.

Considering that DJI has access to all available flight data (like motor speed) while the TXT flight logs are being constructed, and it’s been clearly documented that an entire prop was lost, I'm more inclined to go with the recorded data rather than speculate about other possible causes. DJI's flight logs have historically proven to be highly accurate, so in situations like this, I tend to trust the data they've documented.

Here’s an example showing how a DJI Mini 2 behaves when half of a prop is lost:

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

It's quite different than the data you shared above. While the aircraft does yaw back and forth at times like you've proposed might happen in such a case, the altitude remains fairly consistent and the aircraft is able to safely return back to the home point.

 

[slup]

...it’s been clearly documented that an entire prop was lost, I'm more inclined to go with the recorded data rather than speculate about other possible causes. DJI's flight logs have historically proven to be highly accurate, so in situations like this, I tend to trust the data they've documented.

Recon that you lean against the message "Motor idle. Check whether propellers are installed (Code: 30166).; Propeller fell off." in the log.

Can't judge the reliability in that message (as I remember seeing it before in cases where all 4 props have remained when the drone was found) but can't find the usual evidence of a prop loss in the rear left in the telemetry data, hence I think the thrust loss wasn't immediate.

But you're right... you are entitled to your own conclusions & speculations & I haven't any problems with that at all.

Here’s an example showing how a DJI Mini 2 behaves when half of a prop is lost... and the aircraft is able to safely return back to the home point.

And you know that a Mavic 3 Pro can also..?

 

[msinger]

you are entitled to your own conclusions & speculations & I haven't any problems with that at all

Agreed. And I wasn't trying to call you out, but rather trying to understand how you came to such a conclusion when it seems we only have data CsvView calculated with an algorithm that likely doesn't return the expected result in cases like this.

And you know that a Mavic 3 Pro can also..?

No, I only know of this specific case, and one more with a Phantom 4 some years ago (I don't have that data).

While I wouldn't be surprised if a half missing prop caused a crash, I know of no such confirmed cases.

 

[BudWalker]

@slup @msinger good observations about yawUnWrapped. CsvView computes yawUnwrapped differently than Mike’s algorithm. I like his method better and will use that in the next version of CsvView. Both methods have the same fundamental limitation due to a low sample rate.

I noticed that that battery current increased when the M3 began to tumble. This is consistent with a (partially) blocked motor rather than a lost prop.

 

[msinger]

Since the gimbal attempts to stabilize itself, that data could also be used to try to determine which direction the aircraft is yawing. When I consider the changes in gimbal yaw, I get an unwrapped yaw that has a more consistent spinning motion.

 

[slup]

So in the end we have three different possible failure scenarios, one from a generic error message, one from an uncertain unwrapped yaw calculation & one based on a battery current... all generating a thrust loss & really plausible but speculative.

Remember the old good days guys, when we always had a readable DAT log, either one from the mobile or even that from the craft

 

[slup]

...When I consider the changes in gimbal yaw, I get an unwrapped yaw that has a more consistent spinning motion.

View attachment 178881

Shape wise really similar to Budwalkers CsvView yaw unwrapped calculation... unfortunately also showing a initial & between 202-206sec "wrong" direction to align with a thrust loss in the rear left.

 

[msinger]

Shape wise really similar to Budwalkers CsvView yaw unwrapped calculation

Shape-wise, isn't my latest unwrap example showing a more consistent spinning motion than Budwalker's CsvView?

 

[slup]

Shape-wise, isn't my latest unwrap example showing a more consistent spinning motion than Budwalker's CsvView?

Consistency isn't the issue I think... it's instead the direction, that the rotation buildup goes positive... is CW, both initially & between 202-206sec. That bothers me as with a thrust loss in the rear left it should mostly be CCW... so why does the drone rotate CW (if we for a moment assume that it really does)?

 

[msinger]

Consistency isn't the issue I think

The last chart you posted above makes it seem as if the aircraft was quickly yawing side-to-side (between 201 and 205). And my last chart shows a pretty consistent rotation in the same direction. And, yes, that's assuming any of that calculated data is accurate.

That bothers me as with a thrust loss in the rear left it should mostly be CCW

Tell us more about that. Which data is showing you the thrust was lost in the rear left?