Almost had a flyaway this morning

[zeusfl]

The APAS 5 moves the drone itself. I am wondering if is another case of ghost issues.

 

[Korrd]

Not sure. I know for a fact that my mavic air 2 detects the sun as an obstacle and either slows down or stops when flying towards or away from it, which is quite weird.

 

[zeusfl]

Not sure. I know for a fact that my mavic air 2 detects the sun as an obstacle and either slows down or stops when flying towards or away from it, which is quite weird.

Yes, the same thing happens when you fly over water and the sun's reflection affects the drone.

 

[slup]

Unfortunately we will never be able to find a conclusive cause to this out from the mobile device .txt log ... we would at least need full access to the mobile device .dat log to have any possibility to track down the cause, but that is for the M3 encrypted.

Between 132,3sec into the flight to 148,7sec the M3 moves uncommanded & doesn't obey in particular forward flight stick commands ... so both roll & pitch are affected, but also yaw to some smaller degree.

Here below it's clearly seen that no uncommanded movements are occurring when it comes to throttle commands & height hold ... all fine there (neutral stick = value 1024 & z-speed (vertical) negative value = ascend, positive = descend).

(Click on all charts below to make them larger)


Yaw is slightly affected especially where I have placed the chart marker, again is stick value 1024 = neutral ...



The biggest uncommanded movements happens in the horizontal plane, both pitch & roll are greatly affected. Have below paired up the aileron & elevator stick inputs with heading speed & the tilt direction. It's here clear that something is going on. The event starts there to the left in the chart where the chart marker is placed at 132,3sec... & continues to just before the M3 is switched to Sport mode (blue background=GPS mode, pink=Sport mode). Besides seeing the uncommanded speed increase in a northerly direction we also see a forceful equally uncommanded braking before the M3 goes to Sport mode ... so Sport mode wasn't the reason for why this event stopped.



Have in below sat picture marked out the different events during this incident ... & also added some about the wind direction & the tilt direction axis which can be seen in the purple graph in the above chart.



In the end nothing out from the mobile device .txt log gives a clear reason for this ... it just confirms the OP's story & also confirms that Sport mode wasn't part of that the incident stopped, my guess is that it had been enough to yaw away from the bright sun in order to stop this ...

Seeing below picture included in the log & hearing how the newest version of APAS works ... I say that we are pretty close to the truth if we believe that the sun+APAS+OD sensors had something to do with this.

 

[Deleted member 103366]

@slup where are you getting the graphs showing stick inputs from? All I see is 1024 values right across the flight. If you are using CsvView, what version?
Thanks

 

[slup]

...where are you getting the graphs showing stick inputs from?

Check out post #7 & use the PhantomHelp link there instead.

 

[Deleted member 103366]

I am on a Mac at the moment I will have a look when I am on a PC, are you running CsvView etc. on a download from the Phantomhelp page? Prior to post 25 I tried CsvView on, I think, the downloaded csv and possibly the txt but had no joy.
If you are getting the graphs straight from Phantomhelp, how?

 

[slup]

I am on a Mac at the moment I will have a look when I am on a PC, are you running CsvView etc. on a download from the Phantomhelp page? Prior to post 25 I tried CsvView on, I think, the downloaded csv and possibly the txt but had no joy.
If you are getting the graphs straight from Phantomhelp, how?

I'm using the .csv from the link in post #7 & bring the data up in CsvView 4.2.4.

 

[Deleted member 103366]

DUUUUHHHHHH .......I had the old version of the csv downloaded.

 

[GtoJon]

I think it's a bad IMU. I had the same issues with my Inspire 2. Had to return it twice. They replaced it. Of the one I got right out of the gate went to 1742' & I was not a happy camper. They replaced it again.

Cheers & Good Luck, Jon

 

[slup]

I think it's a bad IMU...

Nah ... doubt that.

To much regarding the craft attitude & speed fits the following flight path (which usually aren't the case during IMU problems) ... putting that up against how the newest version of APAS apparently can auto move the craft without stick commands & a bright low sun just in the direction where the craft won't go gives other much more plausible conclusions.

Unfortunately there aren't enough data available to come to a definite cause in this case ...

 

[BudWalker]

Nah ... doubt that.

To much regarding the craft attitude & speed fits the following flight path (which usually aren't the case during IMU problems) ... putting that up against how the newest version of APAS apparently can auto move the craft without stick commands & a bright low sun just in the direction where the craft won't go gives other much more plausible conclusions.

Unfortunately there aren't enough data available to come to a definite cause in this case ...

I think it may be an IMU malfunction. That, or a problem with the data fusing algorithm used by the FC. At about 134 secs the IMUCalcs:VelN starts too increase but the OSD:xSpeed value computed remains close to 0.0. IMUCalcs:VelN is computed by DatCon and is based on successive locations while OSD:xSpeed is the speed computed by the FC.

From the OP's description I would tend to believe that IMUCalcs:velN is correct and OSD:xSpeed is incorrect. I.e. the problem lies in the FC not in the IMU hardware. Note also that when Sport mode is engaged these two data start to converge. This would be consistent with a FC problem.

Too bad we can't see the .DAT.

 

[slup]

I think it may be an IMU malfunction. That, or a problem with the data fusing algorithm used by the FC. At about 134 secs the IMUCalcs:VelN starts too increase but the OSD:xSpeed value computed remains close to 0.0. IMUCalcs:VelN is computed by DatCon and is based on successive locations while OSD:xSpeed is the speed computed by the FC.
View attachment 138946
From the OP's description I would tend to believe that IMUCalcs:velN is correct and OSD:xSpeed is incorrect. I.e. the problem lies in the FC not in the IMU hardware. Note also that when Sport mode is engaged these two data start to converge. This would be consistent with a FC problem.

Too bad we can't see the .DAT.

Good catch there ... couldn't find the IMUCalcs through the Phantomhelp .csv in post #7 (which is the source I usually go for). Wanted to look at it as that would have given away any IMU/FC problem ... but stood without that indicator, how did you bring it up?

The change in tilt angle going for braking & stopping the uncommanded movement looks like it comes a tad before Sport engages ..?

 

[BudWalker]

Good catch there ... couldn't find the IMUCalcs through the Phantomhelp .csv in post #7 (which is the source I usually go for). Wanted to look at it as that would have given away any IMU/FC problem ... but stood without that indicator, how did you bring it up?

The change in tilt angle going for braking & stopping the uncommanded movement looks like it comes a tad before Sport engages ..?

Run CsvView in the normal way; not by directing the FlightReader to start CsvView. You will also need to tell FlightReader to produce the metric values for xSpeed, etc.

 

[slup]

Run CsvView in the normal way; not by directing the FlightReader to start CsvView. You will also need to tell FlightReader to produce the metric values for xSpeed, etc.

I'm not following you regarding "FlightReader" ... I'm just downloading the PhantomHelp .csv to my desktop, open CsvView & chose the .csv in the first box there stating "Click here to specify ..."

 

[BudWalker]

I'm not following you regarding "FlightReader" ... I'm just downloading the PhantomHelp .csv to my desktop, open CsvView & chose the .csv in the first box there stating "Click here to specify ..."

Sorry about this. The short story is that the IMUCalcs doesn't work with M3 .txt logs in version 4.2.4. I'm working on distributing 4.2.5.

 

[slup]

I think it's a bad IMU...

Nah ... doubt that.

With further data depicting possibilities, provided by @BudWalker & his CsvView tool I need to change my mind here ... in this particular case it actually seems to be related to that the IMU is reacting to false incoming data from the flight controller.

Sorry about this. The short story is that the IMUCalcs doesn't work with M3 .txt logs in version 4.2.4. I'm working on distributing 4.2.5.

Great @BudWalker ... have the IMUCalcs up & running in the new version now, so far all seems to be working. Will keep you posted if I find any oddities.

... IMUCalcs:VelN is computed by DatCon and is based on successive locations while OSD:xSpeed is the speed computed by the FC.

That's some unique info ... very valuable to know from where the signals originates when it comes to pinpointing which data that most probably is wrong

...Note also that when Sport mode is engaged these two data start to converge.

Not sure about that the flight mode change had something to do with that the event ended ... at 148,495sec the telemetry indicate an abrupt change in order to stop the uncommanded motion, the craft start to tilt south & the XSpeed rapidly change to correctly record a positive Northerly speed. At 149,308sec the OP change to Sport mode.

This second in between when the log show signs of counter measures against the uncommanded motion & when the mode change is logged might be within the margin of error ... but as the .TXT log is recorded in 10Hz that shouldn't be the case.

...This would be consistent with a FC problem. Too bad we can't see the .DAT.

It's a lot of graphs in the below chart ... but let us group them a bit & compare against the OP's story to make it easier.
First ... the chart covers the whole event, it starts to the left & ends where I've placed the chart markers at 148,495sec.

If starting to look at ...

The red graph (difference between computed IMU & GPS speed in a northerly direction)
The blue graph (Xspeed is when the craft is in a GPS mode, the FC(IMU) speed in a northerly direction)

We can immediately see out from the red graph (especially from about 142sec) & forward) that it's a big deviation between the IMU & GPS speed (which usually should be close to zero) ... the deviation are also in a positive direction (to north). Weighing in the OP's story about that the AC actually moves north gives a strong indication about that the GPS speed is correct & the IMU speed is wrong.

The blue graph on the other hand (IMU speed in a northerly direction, assumed to be wrong) instead hardly change at all initially (close to zero) but at about 140sec the value turns negative with approx. 2,5m/s in average & stays there until the incident stops at 148,495sec. This actually indicates that the AC should be moving in a southerly direction.

If we then look at ...

The black graph (the tilt (combined pitch & roll) direction the AC have ... 0=north, +-180=south, -90=west, +90=east) ... we see that the AC starts from about 140sec. to consistently lean into a northerly direction even though the wind comes from east which should be the only thing the AC have hold against in a hover.

The magenta graph (how many degrees the AC tilts, 0 degrees=AC is positioned totally flat) ... from about 142sec the tilt angle goes up to approx 28 degrees, that's a pretty steep tilt & will generate a sudden speed increase on par with a full stick command.

The green graph (the heading speed) reflects the magenta tilt angle above ... and eventually the craft reaches a nearly 37mph speed in the black graphs northerly direction.

All logical so far ...

(Click on the chart to make it larger)


So why starts the AC to tilt into a northerly direction only hovering if the (weak) wind comes from east ...and why increases the tilt angle which results in a rapid heading speed increase..?

From the FC's point of view ... when the blue Xspeed (speed in a northerly direction) goes negative at 140sec. it tells the FC that the AC moves south ... to counter that it commands the AC to lean north to stop the (false) movement. But as the negative Xspeed doesn't get stopped ... the FC commands an even more steep tilt into north & that makes the AC to speed away starting at approx. 142sec.

If looking on a sat picture with the GPS path (red) & the IMU path (green) depicted it's clear that the FC/IMU thought that the AC wasn't moving but the GPS said the opposite.

During the whole incident the AC moved along the hand-drawn red arrow below (according to both the GPS & OP), but the hand-drawn green arrow is what the FC/IMU thought it moved during the same period. (the red cross marks where the incident starts)

In order to establish the reason for why the FC made the decision to disregard the GPS data a decrypted .DAT log is needed... which we unfortunately don't have access too when it comes to the M3.

 

[Point Zero]

Amazing work!

 

[BudWalker]

CsvView 4.2.5 is available. Download from here
CsvView Downloads

 

[bkushner]

That would just mean that obstacle avoidance might not work.
It should not cause uncontrolled flight.

That won't have any negative influence on your flying.

This is when I'm getting all my issues...At dusk. It's definitely something with the sensors...I turn them off now if flying in low light..also fly over the water like you are.,