Help with MA flyaway/crash

[Simmo]

Jim, just to jump in, the Sport button can be modded to 'activate' Atti mode. I believe that @sar104 has this mod on his.

 

[sar104]

Many thanks @sar104 for your help on this. Absolutely invaluable.
I will send the MA off & wait for DJIs response. Fingers crossed!

Two questions:
The MA controller has customisable buttons on it - is there any way of making one of these a manual ATTI mode switch?
Surely, if the IMU detects a conflict like this, there should be a better reaction than to do this. Wouldn't it be better to trust its GPS signal and go into some kind of 'limp mode' where the pilot can manually bring it back in or go into RTH mode based just on the GPS location?

Thanks again

There is no DJI-approved way to get an ATTI switch on the remote. The Mavic Pro has the capability in the firmware but it's hidden - you first have to enable parameter modification in the DJI Assistant 2 application, and I think it only works on earlier app versions (≤ 1.1.2). I don't know if anyone has successfully done this with a Mavic Air.

The "better" reaction, in my opinion, would be an earlier switch to ATTI when yaw/IMU exceptions occur. RTH, or any kind of automatic navigation mode (Including positional hold) is simply not possible if the FC can't trust the heading, because while it may know perfectly well exactly where it is, it has no knowledge of which direction (relative to the aircraft - i.e. forwards, backwards, left, right) to move or resist drift. So ATTI is the only viable option.

 

[Simmo]

Yet again, I failed to realise that we are discussing an Air, not a Pro.. I apologise.

 

[sar104]

Yet again, I failed to realise that we are discussing an Air, not a Pro.. I apologise.

It might still work with the MA - I just haven't seen any accounts of anyone trying.

 

[JimPD]

If I understand correctly, there is no way to select ATTI mode manually on a Mavic Air, even if you had the time to work through the settings menus in the App?
The a/c can decide to change mode to ATTI itself?
Surely this cannot be right

 

[sar104]

If I understand correctly, there is no way to select ATTI mode manually on a Mavic Air, even if you had the time to work through the settings menus in the App?
The a/c can decide to change mode to ATTI itself?
Surely this cannot be right

That is correct. It's not a user-selectable setting, at least not without some parameter modifications that may or may not work. The Phantoms have always had an ATTI switch (the P2 also had full manual if you were feeling brave), but the Mavic line doesn't.

 

[Simmo]

No. Not user selectable. Nothing in the app.
The Pro, there is a work around, by hacking the firmware.
Yes, the AC will decide to go into Atti by itself, without relevant information to say otherwise..

 

[Simmo]

Far out man. that was a dead heat!!

 

[sar104]

Far out man. that was a dead heat!!

I think I won by a nose...

 

[Simmo]

I think I won by a nose...

Well I'm better looking.??????
You have a big nose.........

 

[BudWalker]

Thanks, but don't forget that @BudWalker was figuring this stuff out well before me, and he wrote the DAT file conversion software that we all use.

Thanks. One of the more rewarding aspects of developing CsvView/DatCon is that others are able to do more with it than I can. This wasn't always the case. I must confess that nowadays when I see an incident that looks like a difficult time sink I hope you'll take the bait. Quite often you do and then do a better job than I would.

And, don't forget all the offline discussions that we've had that have led to DatCon improvements.

 

[BudWalker]

....
@BudWalker - there appears to be a tick frequency error or similar - the timebases in the txt log and the DAT file conversion are slightly different.

I don't see how the frequencies could be different. Maybe what you're seeing is that the offsets are different. This happens because the tablet .DAT doesn't have the record type that provides the time base offset of the .txt log. In this case DatCon has to then estimate that offset by looking at the motorStart data.

 

[sar104]

Thanks. One of the more rewarding aspects of developing CsvView/DatCon is that others are able to do more with it than I can. This wasn't always the case. I must confess that nowadays when I see an incident that looks like a difficult time sink I hope you'll take the bait. Quite often you do and then do a better job than I would.

And, don't forget all the offline discussions that we've had that have led to DatCon improvements.

You are far too modest. Some of the data-crunching functions I've written make analysis faster, but you often spot stuff that I miss. I do enjoy the collaboration though.

 

[Paul2660]

I realize this is Mavic Air based, but the Mavic Pro has come into the discussion. Doesn't ATTI mode does give you a warning on the display of the Mavic Pro and PP? I know it shows on the DJIgo4 screen in red.

I thought if you went into Atti Mode on the Mavic PP the controller display will show that, ATTI mode. Also the djigo4 app should also say ATTI not GPS or OPTI. I have only had only flight go into ATTI, on a spark, and it did show me ATTI on DJIgo4 screen.

I realize you can't switch the Spark or Mavic lines into ATTI, (not going to hack the firmware to get there), but once in ATTI, you should still be able to fly it as long as you can see it, I realize the the drone orientation can be confusing and flying at distance in ATTI would be difficult.

Paul C

 

[sar104]

I don't see how the frequencies could be different. Maybe what you're seeing is that the offsets are different. This happens because the tablet .DAT doesn't have the record type that provides the time base offset of the .txt log. In this case DatCon has to then estimate that offset by looking at the motorStart data.

That was my first guess when I was comparing the txt data with the DAT data and noticed that the flights (takeoff to crash) had different durations, but I don't think it is the cause. The txt log doesn't include tick numbers unfortunately, but the graph below shows the IMU1 yaw data from the DAT file plotted against the DAT offsetTime, and the OSD_yaw data from the txt log plotted against the txt log OSD_flyTime__s_. There is slight difference (~ 0.5 s) in the offset, but notice that as the flight progresses the difference increases. To be precise, the DAT time scaling is 17% faster than the txt log time scaling.



I may be missing something obvious, but I'm not sure what.

 

[sar104]

I realize this is Mavic Air based, but the Mavic Pro has come into the discussion. Doesn't ATTI mode does give you a warning on the display of the Mavic Pro and PP? I know it shows on the DJIgo4 screen in red.

I thought if you went into Atti Mode on the Mavic PP the controller display will show that, ATTI mode. Also the djigo4 app should also say ATTI not GPS or OPTI. I have only had only flight go into ATTI, on a spark, and it did show me ATTI on DJIgo4 screen.

I realize you can't switch the Spark or Mavic lines into ATTI, (not going to hack the firmware to get there), but once in ATTI, you should still be able to fly it as long as you can see it, I realize the the drone orientation can be confusing and flying at distance in ATTI would be difficult.

Paul C

That's correct - it is clearly indicated when it switches to ATTI. The problem, on this flight, is that it never switched - the FC remained in P-GPS and continued to try to resolve the errors, unsuccessfully, until it crashed.

 

[JimPD]

The crazy thing is - when it gave the warning about heading exception, it said to switch to ATTI mode if a/c behaves erratically (I understand that the app covers all DJI a/c, some of which have such a switch). Yet having given such a warning, it didnt switch itself. Could this be a malfunction in itself?

 

[JimPD]

Its all parcelled up to go in the post tomorrow.
Would a printed copy of this thread help my case?

 

[sar104]

The crazy thing is - when it gave the warning about heading exception, it said to switch to ATTI mode if a/c behaves erratically (I understand that the app covers all DJI a/c, some of which have such a switch). Yet having given such a warning, it didnt switch itself. Could this be a malfunction in itself?

No - many people have pointed out the uselessness of that message. It is presumably legacy code from the Phantom firmware. Several of us have noted that the more recent firmware has been more reluctant to make the switch to ATTI - previously those kinds of errors would have triggered the switch. I don't know why they have changed that, because it doesn't seem to be a robust approach.

 

[sar104]

Its all parcelled up to go in the post tomorrow.
Would a printed copy of this thread help my case?

I don't know about the entire thread, but the graphs in post #12 tell a fairly complete story.