Mavic air out of control

[slup]

Yes I powered it up indoor walked outside, about 3 - 4 meters and put it on the ground, then used the automatic take off. But shouldnt it give me a warning for magnetic interferance or at least compass calibration required?

No you can't rely on that at all ...

Ok ... think we starts to see the light in the tunnel here. Much is explained by a start up in a magnetic interfered area indoors (full of thing's that can create that kind of interference) & then carried outside. I imagine that you also first powered on the AC ...then the RC, explaining that values in the log doesn't show up until a long time later.

The magYaw disagreed then with the IMUYaw already at take off ... going into the "toilet bowl" flight path as soon as you applied elevator input at 12sec.

Always check that the drone icon on the map in your app is pointing equal to reality ... if not abort launch attempt & move away and try take off elsewhere.

It's an easy check you always should do after powering on your drone, connected to your RC/app & placed it in the take off spot ... but before lift off. This to avoid a really scary event coming from launching from a magnetic disturbed place with following flyaway at height in an uncontrollable "toilet bowl" shaped flight path.

 

[sar104]

No you can't rely on that at all ...

Ok ... think we starts to see the light in the tunnel here. Much is explained by a start up in a magnetic interfered area indoors (full of thing's that can create that kind of interference) & then carried outside. I imagine that you also first powered on the AC ...then the RC, explaining that values in the log doesn't show up until a long time later.

The magYaw disagreed then with the IMUYaw already at take off ... going into the "toilet bowl" flight path as soon as you applied elevator input at 12sec.

It's an easy check you always should do after powering on your drone, connected to your RC/app & placed it in the take off spot ... but before lift off. This to avoid a really scary event coming from launching from a magnetic disturbed place with following flyaway at height in an uncontrollable "toilet bowl" shaped flight path.

Always check that the drone icon on the map in your app is pointing equal to reality ... if not abort launch attempt & move away and try take off elsewhere.

Right - this is almost certainly what happened. And it also makes it pilot error, because the correct orientation of the aircraft was not checked at takeoff.

In general I strongly recommend not moving the aircraft after power up - it is far better to let it sit and initialize at the takeoff point.

 

[Murmansken]

No you can't rely on that at all ...

Ok ... think we starts to see the light in the tunnel here. Much is explained by a start up in a magnetic interfered area indoors (full of thing's that can create that kind of interference) & then carried outside. I imagine that you also first powered on the AC ...then the RC, explaining that values in the log doesn't show up until a long time later.

The magYaw disagreed then with the IMUYaw already at take off ... going into the "toilet bowl" flight path as soon as you applied elevator input at 12sec.

Always check that the drone icon on the map in your app is pointing equal to reality ... if not abort launch attempt & move away and try take off elsewhere.

It's an easy check you always should do after powering on your drone, connected to your RC/app & placed it in the take off spot ... but before lift off. This to avoid a really scary event coming from launching from a magnetic disturbed place with following flyaway at height in an uncontrollable "toilet bowl" shaped flight path.

Well I am glad that it is my own fault and not the drones, but why can´t you control it with the remote when it is in "the toilet bowl" flight path should´nt it respond to the controls? Well lesson learned and I hope that this never happens again.

 

[slup]

Well I am glad that it is my own fault and not the drones, but why can´t you control it with the remote when it is in "the toilet bowl" flight path should´nt it respond to the controls? Well lesson learned and I hope that this never happens again.

Put it simple ... the drone doesn't know in which direction it is pointing. So with this, usually everything is fine as long until the drone either by itself due to wind for instance need to apply counter actions in order to maintain it's position ... or if the pilot with the sticks apply any horizontal directed movements. Then all goes haywire ... this due to the FC apply movement with the help of the motors to maintain position or move to another, as the drone doesn't have the correct heading the action to move/maintain position fails ... so it tries again ... fail even more ... try again. And the snow ball starts to roll & all movements gets larger & larger. Your stick inputs in this situation just adds more mess into the equation.

So ALWAYS check the drone icon on the map in GO4 & make sure it's pointing equal to reality before you take off ... otherwise this will happen again.

 

[sar104]

Well I am glad that it is my own fault and not the drones, but why can´t you control it with the remote when it is in "the toilet bowl" flight path should´nt it respond to the controls? Well lesson learned and I hope that this never happens again.

If the drone were in ATTI mode, where you have direct control of pitch and roll, then you could control it. But in P-GPS mode that's not what stick inputs mean - forwards means forwards relative to the compass direction that the drone is facing - or rather thinks it is facing. If it has that wrong, then forwards sends it in what the FC thinks is the wrong direction, and it tries to correct. That correction is what causes the toilet bowl or other kind of uncontrolled flight.

 

[slup]

If the drone were in ATTI mode, where you have direct control of pitch and roll, then you could control it. But in P-GPS mode that's not what stick inputs mean - forwards means forwards relative to the compass direction that the drone is facing - or rather thinks it is facing. If it has that wrong, then forwards sends it in what the FC thinks is the wrong direction, and it tries to correct. That correction is what causes the toilet bowl or other kind of uncontrolled flight.

Might add that I think... that the drone probably will fall back to ATTI mode eventually as the FC kind of gives up(even though you perhaps not have an manual ATTI switch) ... but by then most drones have crashed.

 

[Murmansken]

Thank you all for your time and commitment to solve this issue. As I said before lesson learned and I won´t make this misstake again.

So what action should I take now? Just new props and try again and this time check the drones orientaition on the map?

 

[Deleted member 94047]

the drone probably will fall back to ATTI mode eventually as the FC kind of gives up

I have not yet seen this happen and we have had quite a few yaw error crashes posted here. It looks like the FC doesn't like giving up.

 

[slup]

I have not yet seen this happen and we have had quite a few yaw error crashes posted here. It looks like the FC doesn't like giving up.

Have seen it once so far ... but you're right, the FC will persist quite a long time.

 

[Deleted member 94047]

So what action should I take now? Just new props and try again and this time check the drones orientaition on the map?

1- Right now, check to see if all the sensors in the IMU are working properly to make sure the aircraft has survived the crash well. From the GO4 app, go to the aircraft pane, advanced, and sensors state. Check if the two accelerometers and gyros are green, and have no error codes. In the same page, check the status of the compass.

2 - In the future, never power the aircraft in one place and move it somewhere else before take off. Pick an appropriate place to take off and power it on there.

3 - Make sure you don't take off near around metal objects that could interefer with the compass. Always check the orientation of the drone icon on the map matches the actual orientation of the drone before take off.

That should get you started.

 

[sar104]

I have not yet seen this happen and we have had quite a few yaw error crashes posted here. It looks like the FC doesn't like giving up.

Have seen it once so far ... but you're right, the FC will persist quite a long time.

DJI has gradually made that switch less likely. The Phantoms would drop into ATTI with very little provocation when yaw errors occurred. The MP took longer, and the more recent models seem very reluctant to make the switch in time to save the aircraft.

 

[Prismatic]

... but why can´t you control it with the remote when it is in "the toilet bowl" flight path should´nt it respond to the controls? ...

With a yaw error condition, the drone may try to respond to your inputs, but that response is overwhelmed by its futile effort to position itself where it's supposed to be.

Suppose your drone starts up facing north. You lift off and hover at 30m. A breeze from the east pushes the drone slightly west. Seeing an uncommanded move to a position west of the intended hover location (IHL), the flight control compensates by applying just enough eastward thrust to compensate for the drift; that means spinning up the props on the left (west side) and slowing the props on the right (eastern side). That's how the drone maintains a stable position. This is the normal case.

Now suppose the same situation--the drone is truly facing north, and there is a breeze from the east--but this time, due to magnetic interference at startup, the onboard compass incorrectly indicates that the drone is facing east. So when the flight control detects that westward drift, it acts on the understanding that the aircraft is facing east, and attempts to compensate by spinning up the rear (west side) props and slowing the front ones (east side). This, of course, pushes the aircraft north, not east.

The flight control sees that northward motion as uncommanded and unexpected. It again tries to compensate, now for a position error NW of its IHP.

But because the drone is still not actually facing the direction the flight control believes it is, the "corrections" make the situation worse. The errors compound, and the drone zooms off into the distance, or into an obstacle.

 

[sar104]

With a yaw error condition, the drone may try to respond to your inputs, but that response is overwhelmed by its futile effort to position itself where it's supposed to be.

Suppose your drone starts up facing north. You lift off and hover at 30m. A breeze from the east pushes the drone slightly west. Seeing that uncommanded movement, the flight control compensates by applying just enough eastward thrust to compensate for the drift; that means spinning up the props on the left side and slowing the props on the right side. That's how the drone maintains a stable position. This is the normal case.

Now suppose the same situation--the drone is truly facing north, and there is a breeze from the east--but this time, due to magnetic interference at startup, the drone thinks it's facing east. Now when it detects that westward drift, it attempts compensate by spinning up the rear props and slowing the front ones. But this pushes the aircraft northward instead of eastward. The flight control sees that, and again tries to compensate for uncommanded movement. Again, because it's not actually facing the direction the flight control believes it is, the "corrections" make the situation worse. The errors compound as the drone zooms off, into the distance or into an obstacle.

And here is exactly that happening on this flight:

 

[Murmansken]

Ok thanks for the input all of you ? I checked every sensor and compass all turns green so i guess it survived the crash Otherwise where to buy new IMU?

 

[slup]

Ok thanks for the input all of you ? I checked every sensor and compass all turns green so i guess it survived the crash Otherwise where to buy new IMU?

So far & with the cause for this event well established ... can't see why you should buy a new IMU?

 

[sar104]

Ok thanks for the input all of you ? I checked every sensor and compass all turns green so i guess it survived the crash Otherwise where to buy new IMU?

Why do you need a new IMU?

 

[Murmansken]

So far & with the cause for this event well established ... can't see why you should buy a new IMU?

Ok, glad to hear that, I have heard that if you crash the drone the imu can get damaged and give you problems...

 

[Deleted member 94047]

Ok, glad to hear that, I have heard that if you crash the drone the imu can get damaged and give you problems...

But yours is not. So why change it? Calibrate if necessary, and give it a good test flight in a safe environment (read wide open field). But the props, I say get rid of them and buy new ones.

 

[slup]

And here is exactly that happening on this flight:

View attachment 96114

@sar104 ... in relation to your calculation & chart do you know if that's what shown in the CsvView's GeoPlayer?

 

[Murmansken]

But yours is not. So why change it? Calibrate if necessary, and give it a good test flight in a safe environment (read wide open field). But the props, I say get rid of them and buy new ones.

The props are totally wrecked so there will be new ones. Allready calibrated the imu. Yes next test flight will be in an open field or on the lake where there are no obstacles.