Fly aways due to compass errors

[miker570]

Compass errors seem to be attributed to many of the fly aways and crashes reported here. I understand that the compass calibration is a must and the instructions in the manual state you have to stay away from metal objects to prevent compass errors. However It is not always obvious you are near some metal, like rebar in concrete when you take off.

That said, it seems like bad programming to have compass errors result in uncontrolled flight and fly aways. If the compass is telling the motors to fly away when there is no stick input, this is the worst possible error handling. I understand that the compass is used to hold it’s position in the wind when hovering, but to fly away without any stick input shows that the software is not cross checking GPS to know when the drone is really drifting in the wind or if the compass is giving faulty info. There has to be a better way to handle these errors.

I would think a better way it handle compass errors would obviously be to throw an error after cross checking the gps, and just hover or hold position, rather than accelerating in the wrong direction without stick inputs. The compass error should direct the pilot to use RTH or fly home manually immediately.

There has to be a better way to handle these errors than uncontrolled acceleration and crashes. Any better ideas?

 

[cybervet]

I Think that the error you are talking about is a yaw error from the IMU and not the compass.

 

[xspwhite]

I dont think you should use RTH if you have a compass error.

 

[miker570]

I had a recent fly away due to compass errors and it was RTH that save me.. GPS knew exactly where is was, and RTH brought it home precisely where it took off from. I was very lucky in my case.

 

[Meta4]

I had a recent fly away due to compass errors and it was RTH that save me.. GPS knew exactly where is was, and RTH brought it home precisely where it took off from. I was very lucky in my case.

The errors you are referring to are Yaw Errors.
GPS always knows the location of the drone and the home point.
But if your drone is affected by a yaw error, RTH cannot help you (except in very few cases where the yaw error is very small).

 

[miker570]

Ok but whatever the error, uncontrolled acceleration without stick input is the worst possible error handling. Landing or allowing the pilot to manually fly home would at least give the pilot a chance at recovery.

 

[Meta4]

Landing or allowing the pilot to manually fly home would at least give the pilot a chance at recovery.

But that's just not possible in a yaw error situation.
The drone is incapable of holding position because every time it tries to make a correction, the correction makes things worse.
The drone ends up "chasing its tail" just trying to stay still.

 

[sar104]

Compass errors seem to be attributed to many of the fly aways and crashes reported here. I understand that the compass calibration is a must and the instructions in the manual state you have to stay away from metal objects to prevent compass errors. However It is not always obvious you are near some metal, like rebar in concrete when you take off.

That said, it seems like bad programming to have compass errors result in uncontrolled flight and fly aways. If the compass is telling the motors to fly away when there is no stick input, this is the worst possible error handling. I understand that the compass is used to hold it’s position in the wind when hovering, but to fly away without any stick input shows that the software is not cross checking GPS to know when the drone is really drifting in the wind or if the compass is giving faulty info. There has to be a better way to handle these errors.

I would think a better way it handle compass errors would obviously be to throw an error after cross checking the gps, and just hover or hold position, rather than accelerating in the wrong direction without stick inputs. The compass error should direct the pilot to use RTH or fly home manually immediately.

There has to be a better way to handle these errors than uncontrolled acceleration and crashes. Any better ideas?

You misunderstand the problem. It is the combination of GPS position data and an incorrect IMU heading that directly causes the behavior, because the FC cannot distinguish between motion caused by an external force (wind) and motion caused by FC-commanded thrust that is not in the direction that it expects.

The most robust solution is currently implemented in the Mavic 2 firmware, under which the FC resets the IMU yaw value to match the compass yaw if those two values diverge at takeoff. It doesn't help though if the yaw error has other causes.

 

[sar104]

Ok but whatever the error, uncontrolled acceleration without stick input is the worst possible error handling. Landing or allowing the pilot to manually fly home would at least give the pilot a chance at recovery.

Landing is available as an operator option. Flying manually is not, unless the aircraft switches to ATTI, and that doesn't always happen fast enough for the reasons I mentioned above. That's why I have ATTI mode programmed into the mode switch - in the Tripod default location on the M2 and the Sport location on the MP.

 

[MAvic_South_Oz]

It's probably one of the worse scenarios to occur in flight, isn't it ?
Is it correct that in general if the home point red arrow drone orientation is correct on the ground befroe take off, it is unlikely this will occur during flight ?
I think recently I was one flight analysis where something did happen in flight, the Esperance Western Australia flight, but uncommon ?

It'd be great if other firmware could be upgraded to do what the M2 does now . . . possible do you think @sar104 ?

 

[sar104]

It's probably one of the worse scenarios to occur in flight, isn't it ?
Is it correct that in general if the home point red arrow drone orientation is correct on the ground befroe take off, it is unlikely this will occur during flight ?
I think recently I was one flight analysis where something did happen in flight, the Esperance Western Australia flight, but uncommon ?

Unless the aircraft subsequently flies into magnetic distortion then that is correct.

It'd be great if other firmware could be upgraded to do what the M2 does now . . . possible do you think @sar104 ?

It's certainly possible since it is easy to detect and correct.

 

[miker570]

.....because the FC cannot distinguish between motion caused by an external force (wind) and motion caused by FC-commanded thrust that is not in the direction that it.....

This seems to be the weak area in the software. If stick inputs override the FC other inputs, there might be a chance to recover manually? It’s the uncontrolled acceleration that should have some way to override .. maybe automatically switching into ATTI when the inputs are confused might be better error handling option?

 

[sar104]

This seems to be the weak area in the software. If stick inputs override the FC other inputs, there might be a chance to recover manually? It’s the uncontrolled acceleration that should have some way to override .. maybe automatically switching into ATTI when the inputs are confused might be better error handling option?

But the inputs are not confused - the FC has no immediate way to know that it is not fighting an external force. It will switch to ATTI once it has made that determination.

 

[miker570]

Perhaps there should be some pilot controlled option presented when it thinks the external force is beyond some threshold, giving the pilot a chance to opt out of autonomously trying to hold position, when in fact it really was not wind but incorrect flight positioning data.

I see many of these crashes had high wind warnings, but I think at least in my case, it was not wind but incorrect data that made it accelerate away thinking is was high winds it was fighting, but it was really fighting against bad data inputs.

 

[Meta4]

when in fact it really was not wind but incorrect flight positioning data.

There's no problem with position data at all.
It's directional data that is the problem in the cases you are talking about.

 

[miker570]

Ok the point I’m trying to make, there should be a way to prevent uncontrolled acceleration caused by invalid data input, whatever it is. I think many pilots would agree that having your drone fly away uncontrolled is extremely undesirable, and trying to explore some better software error handling to prevent loss of control, which is likely to lose it or result in a bad crash.

 

[sar104]

Ok the point I’m trying to make, there should be a way to prevent uncontrolled acceleration caused by invalid data input, whatever it is. I think many pilots would agree that having your drone fly away uncontrolled is extremely undesirable, and trying to explore some better software error handling to prevent loss of control, which is likely to lose it or result in a bad crash.

No one would disagree that it is undesirable. But if there were an easy way to prevent it then you might imagine that DJI, who are very good at this stuff, would already have implemented it.

 

[miker570]

A way to turn off the “auto-pilot” when it misbehaves shouldn’t be that difficult.

 

[Meta4]

A way to turn off the “auto-pilot” when it misbehaves shouldn’t be that difficult.

To borrow what was already said in post #17
But if there were an easy way to prevent it then you might imagine that DJI, who are very good at this stuff, would already have implemented it.
Perhaps you should have a chat to DJI's design engineers?

 

[miker570]

Ok maybe DJI reads this, perhaps add a manual mode M in addition to Position, Sport and Cinema?