Drone flew 600m away from me - out of my control!

[MAvic_South_Oz]

Nope.
Still bad Sam.
Not sure if this could have something to do with your drone issue, not sure if anyway can tell why it so . . . well, all over the place.
If you look through other posts in this section of the forum, check other logs, you'll see how a normal flight looks, all very easy to see where the fly happened and how it was conducted.

 

[MAvic_South_Oz]

Opened the txt file from post# 13 and it is the the weirdest thing I have ever seen

View attachment 93817

If we take this at face value, the AC encountered a compass error at 838s and nothing that comes after makes any sense. CsvView threw up this error when it opened the txt file though, so I am guessing there is something wrong with the data.

View attachment 93818

@sar104 @BudWalker - you guys ought to have a look at this one

Looking at the Phantom Help link to the data Sam put up, every single parameter from from columns with time, flight mode, gps, altitude, speed etc, all jumping from one extreme to the other.

 

[slup]

LOL ... your props fell off 32 times ... never been seeing that error in the Airdata details, & the time goes backwards!



No ... joking aside, this is corrupt. Trying to figure out why all your logs have ...(1).txt, did you open them up in a txt viewer & re-saved them before providing them?

 

[Deleted member 94047]

I uploaded the txt file to AirData to see what it would make of it. And this flight apparently broke all the records for the Mini except for speed.

 

[MAvic_South_Oz]

Here is the link

Is this the actual flight location @SamCrouch ??
If you weren't on holiday up there, it is probably a bit far north for you !

 

[sar104]

Opened the txt file from post# 13 and it is the the weirdest thing I have ever seen

View attachment 93817

If we take this at face value, the AC encountered a compass error at 838s and nothing that comes after makes any sense. CsvView threw up this error when it opened the txt file though, so I am guessing there is something wrong with the data.

View attachment 93818

@sar104 @BudWalker - you guys ought to have a look at this one

The data have some issues and need a little cleaning up, but mostly make sense once processed.



I don't have time to finish that right now, but I'll get to it later today.

 

[slup]

The data have some issues and need a little cleaning up...

I'm listening ... how come ? ?

 

[Capt KO]

RTH set correctly?. Home point recorded? Did you ever get a response when you did hit return to home if you did?

Rereading I have not found any place where you said you tried RTH

 

[jpit]

At that speed if would have reached the moon in a fraction of a second.

 

[sar104]

I'm listening ... how come ? ?

I can't answer the why, but I can fix the data.

 

[sar104]

RTH set correctly?. Home point recorded? Did you ever get a response when you did hit return to home if you did?

Rereading I have not found any place where you said you tried RTH

RC RTH was engaged at 42 seconds.

 

[slup]

I can't answer the why, but I can fix the data.

Hmm ... that's worrying, I mean, that the log can be corrupted & in need of fixing ?

 

[sar104]

What appears to have happened is that you engaged RTH and then cancelled it before the aircraft had returned. Then you gave it all kinds of stick inputs that flew it away from the home point, and up to a height of around 70 meters. Eventually it lost connection and although it was back in RTH mode at that point, it was unable to make progress back due to the wind.



The track, until the downlink was lost, is below:



I could make a rough estimate of where it might have ended up, but it's going to have a large uncertainty.

 

[MAvic_South_Oz]

If it was having trouble from that end point into the wind at take off point, maybe it did blow over landfall, and there may be some hope ?
Not sure how the lake shape goes further to the right.
It looks like Dopplers flight data link map in post #25, so maybe.

 

[xspwhite]

What appears to have happened is that you engaged RTH and then cancelled it before the aircraft had returned. Then you gave it all kinds of stick inputs that flew it away from the home point, and up to a height of around 70 meters. Eventually it lost connection and although it was back in RTH mode at that point, it was unable to make progress back due to the wind.

View attachment 93849

The track, until the downlink was lost, is below:

View attachment 93850

I could make a rough estimate of where it might have ended up, but it's going to have a large uncertainty.

What is that big gray patch that it flew/blew across?

 

[MAvic_South_Oz]

What is that big gray patch that it flew/blew across?

The lake (loch) mentioned in the original post.

 

[sar104]

It looks like the aircraft may have drifted some distance after losing downlink, based on it's velocity at the end of the flight in RTH.



Uncertainty exists here in the battery depletion rate at the end of the recorded flight, but if the rate continued as logged, that would put the aircraft into autolanding at around 1060 seconds and on the ground at 1085 seconds. Extrapolating velocity to that time gives the following as a track:

 

[Deleted member 94047]

@sar104 - First, thank you for another lesson. You don't run out of surprises do you? Now some questions. How rare is this kind of data corruption? It is the first time I see it. And is there an option to fix it within CsvView? Or do you do it with some other program? Thanks!

 

[sar104]

@sar104 - First, thank you for another lesson. You don't run out of surprises do you? Now some questions. How rare is this kind of data corruption? It is the first time I see it. And is there an option to fix it within CsvView? Or do you do it with some other program? Thanks!

I think I've seen a similar case once before. So it's probably quite rare. I doubt that CsvView can fix it since it requires a somewhat customized signal processing. As it happens I first developed simple functions to fix those kinds of errors some years ago, when a bug in some Tektronix digitizers caused similar random offset issues. I was programming and controlling the digitizers with Igor Pro, and the same basic approach works for these data.

 

[sar104]

@sar104 - First, thank you for another lesson. You don't run out of surprises do you? Now some questions. How rare is this kind of data corruption? It is the first time I see it. And is there an option to fix it within CsvView? Or do you do it with some other program? Thanks!

If you are interested in the fix - it really is simple. This is the function code, where data_wave is passed as the field to be fixed. Note that offsetmax is determined by inspection.

Function fix(data_wave)​

Wave data_wave​

int n​

variable offsetmax​

WaveStats data_wave​

offsetmax = 20 ​

n = 1​

do​

if (abs(data_wave[n] - data_wave[n-1]) > offsetmax)​

data_wave[n] = data_wave[n-1]​

endif​

n+=1​

While (n < V_npnts)​

End​