Yaw errors, might this be a solution?

[Yorkshire_Pud]

Then, with the Mavic 2 a new strategy was introduced. Compass errors were detected by the magYaw value being different from the FC heading value. If detected the FC would command the M2 to slowly rotate while holding FC heading value constant. The compass error was fixed and rotation stopped when magYaw became aligned with FC heading value. Then the flight could proceed with the compass problem being fixed.

Would you know of a video of this slow rotation?

 

[MS Coast]

Like I said, poor engineering. DJI really ought to fix that

Curious: What was the altitude of the M2 during the VPS gap? Could it have exceeded the working VPS range as detected by the downward IR ranging sensor (or is the M2 ultrasonic? don't remember).

Poor VPS performance may also be attributable to a featureless surface below the drone, like a concrete slab, bare asphalt with no lines, or a smooth sandy beach. If the system doesn't see the image changing, it can't tell that the drone is moving.

 

[BudWalker]

Would you know of a video of this slow rotation?

Sorry, I don't. And, I took a look for the .DAT where this happens but was unable to find it. I'll look some more later.

 

[Yorkshire_Pud]

Sorry, I don't. And, I took a look for the .DAT where this happens but was unable to find it. I'll look some more later.

If I were to deliberately try to trigger this how would I go about it?
Put a fairly strong magnet near the drone at boot then, once the drone has booted remove the magnet? This would be indoors where there would be no GPS.

 

[BudWalker]

If I were to deliberately try to trigger this how would I go about it?
Put a fairly strong magnet near the drone at boot then, once the drone has booted remove the magnet? This would be indoors where there would be no GPS.

Needs to have GPS so that it's flying in GPS_ATTI mode. Before power up use either a magnet or a piece of ferrous material and place it near the Mavic Pro. Then turn the MP on and observe the red triangle direction indicator in the Go App map display. You're looking for the indicator to be different from the actual MP heading. If you need to move the magnet or ferrous material first power off the MP then power up after it's moved.

Once you've got the right spot for the magnet or ferrous material launch the MP and ascend enough so that MP is above the distortion caused by the magnet or ferrous material.

If the MP decides to fly away instead of rotating to correct the Yaw/magYaw difference I hope it doesn't suffer too much.

 

[Yorkshire_Pud]

Needs to have GPS so that it's flying in GPS_ATTI mode.

Then I misunderstood, I will read it again.
Just checking, this slow rotation, is it a feature of the MP or M2P?

 

[BudWalker]

Then I misunderstood, I will read it again.
Just checking, this slow rotation, is it a feature of the MP or M2P?

I'm sure that it's a feature of the MP. Not totally sure but I think the M2P does not have this feature.

If it's not in GPS_ATTI then there is no need to have a correct heading value. Presumably the heading correction wouldn't happen in ATTI mode.

 

[BudWalker]

Would you know of a video of this slow rotation?

I'm looking at several of my posts from around 2017. A few of those mention the existence of a video that demonstrates the fix heading by rotation behavior. I'm still looking.

 

[BudWalker]

Like I said, poor engineering. DJI really ought to fix that

Curious: What was the altitude of the M2 during the VPS gap? Could it have exceeded the working VPS range as detected by the downward IR ranging sensor (or is the M2 ultrasonic? don't remember).

Forgot which .DAT I presented but here is another from one of my M2 flights.

The VPS appears to turn off when the ultrasonic height rises above 5 - 7 meters. At least for this flight. In the over water flights VPS hardly works anywhere. Note that VIOosZ agrees with both the ultrasonic and barometric heights in the beginning but has drifted to about 30 meters difference at the end.

 

[BudWalker]

@Yorkshire_Pud
Took me a while to find this.
Recorded flight data vs real time data
It's the first time I could see that the Mavic Pro will attempt to correct a compass error by rotating the MP while holding the Yaw value constant.

A trip down memory lane. This was almost exactly 7 years ago.

 

[Yorkshire_Pud]

Thanks Bud.
Just came across a post by @sar104 which might provide a foundation for my thinking, post 24, page 2 of the thread Mavic air out of control
The thread is a worthwhile read.

 

[Zbip57]

I maintain that VPS position holding is, when available, FAR more accurate than GPS position holding. In fact I think that when VPS position holding is available, VPS position holding is used in preference to GPS position holding.

[...] I am pretty certain I have seen it suggested it feeds a positive feedback loop. Breaking the loop by disregarding the GPS input, in whatever way is deemed best, might break that loop. Hence this thread.

I can confirm that the VPS optical sensor position-holding takes priority over GPS position-holding. At least it does on my Mini while in a hands-off hover.

That was really not what I expected to see.

I was always under the impression that VPS took over only in the absence of a good GPS lock. When in a hands-off hover low over a lake, why should the Mini be allowed to unexpectedly wander away tracking a floating leaf when it already has a perfectly good GPS lock?

I tested that by hovering the Mini outdoors over a patterned rug, and then dragging the rug away. The Mini followed the movement of the rug and completely ignored the fact that its GPS position was changing. How far would it eventually have moved before the GPS discrepancy was noticed??

There's no doubt the VPS optical sensor is more accurate at position holding than GPS. But even without VPS the Mini is pretty good at holding horizontal position in hover using GPS alone. Anyway, this experiment demonstrated that the Mini's firmware is able to discern and prioritize between information obtained from the optical sensor versus the GPS sensor. This experiment showed it chooses to believe and prioritize the VPS optical sensor while ignoring conflicting GPS data.

Why couldn't a similar protocol be used to minimize the consequences of a yaw-error?

 

[Droning on and on...]

I can confirm that the VPS optical sensor position-holding takes priority over GPS position-holding. At least it does on my Mini while in a hands-off hover.

That was really not what I expected to see.

I was always under the impression that VPS took over only in the absence of a good GPS lock.

I don't share your thinking in this. It makes sense that, being more accurate below a certain altitude, VPS would be the controlling sensing technology. Stated more generally, I'd expect a good design to use whichever sensors produced the best result.

I have been, like you, surprised that there's no error detection comparing the two methods when VPS is primary to prevent this:

When in a hands-off hover low over a lake, why should the Mini be allowed to unexpectedly wander away tracking a floating leaf when it already has a perfectly good GPS lock?

I tested that by hovering the Mini outdoors over a patterned rug, and then dragging the rug away. The Mini followed the movement of the rug and completely ignored the fact that its GPS position was changing.

This problem has been around since the beginning of VPS, and has resulted in loss of control and crashes. What's more because the drone is moving but the FC thinks it's holding a stationary position, people have reported wild, paradoxical response to control input, making it difficult to regain control.

So it's hard to understand that the positioning system hasn't been enhanced to check VPS against GPS. It's probably been on the engineering list for years and years, and they just never get to it. Marketing prioritizes new features, so this never makes the cut.

 

[Zbip57]

I don't share your thinking in this. It makes sense that, being more accurate below a certain altitude, VPS would be the controlling sensing technology. Stated more generally, I'd expect a good design to use whichever sensors produced the best result.
I have been, like you, surprised that there's no error detection comparing the two methods when VPS is primary to prevent this:

When within VPS range (and given suitable lighting conditions etc) then yes VPS is more accurate. But I had always thought it was only used in the absence of sufficient GPS reception, like when flying indoors. VPS is very effective then. But I had always assumed that, simultaneously given good VPS and GPS, it would be the GPS that takes priority. I was surprised to discover that's not the case.

For sure it makes sense to rely, when available, on the more accurate VPS to hold a more precise location during hover. But it makes no sense to me to give priority to the VPS when the detected pattern is obviously moving, as evidenced by shifting GPS location data.

For example, when hovering in a wide open space over a lake with a clear view of many overhead GPS satellites, why give priority to the VPS when it's tracking wave ripples moving over the water's surface, or tracking a leaf floating downstream on a river's surface, when the GPS data is clearly indicating that the drone is no longer holding a constant position?

This problem has been around since the beginning of VPS, and has resulted in loss of control and crashes. What's more because the drone is moving but the FC thinks it's holding a stationary position, people have reported wild, paradoxical response to control input, making it difficult to regain control.

That part I don't agree with. It's not actually a "loss of control". It can lead to crashes if you're not paying attention. If you're expecting your drone to hold a fixed location while you're distracted tending to some other task, you might be surprised to find your drone has drifted downriver tracking a floating leaf. And it can lead to a crash if the drone then drifts into an overhanging branch, while you aren't paying attention.

But there is no wild paradoxical response to control input, and it's certainly not difficult to regain control. With the control sticks released to centre, you are effectively engaging the autopilot to hold this current position. The drifting caused by the VPS tracking and following a moving pattern can only occur if the sticks are centred and the autopilot takes over. If the drone doesn't actually remain hovering in the expected fixed location, to recover you merely need to give some stick input to cancel the autopilot and you immediately regain full control.

Any crashes occurring while the drone is wandering off on its own are pilot error for not paying attention. Any wild paradoxical response to control input are also purely pilot error induced by excessively panicked stick inputs.

So it's hard to understand that the positioning system hasn't been enhanced to check VPS against GPS. It's probably been on the engineering list for years and years, and they just never get to it. Marketing prioritizes new features, so this never makes the cut.

It seems like a simple enough fix. With control sticks centred the drone should stay put in one location. VPS is more accurate, so let's ignore small fluctuations in GPS data. But if the VPS is convinced the drone is still firmly fixed in the exact same spot over this piece of driftwood, but the GPS says that wood has drifted an alarming distance from its original location, at some point that should set off alarm bells.

 

[Droning on and on...]

That part I don't agree with. It's not actually a "loss of control". It can lead to crashes if you're not paying attention. If you're expecting your drone to hold a fixed location while you're distracted tending to some other task, you might be surprised to find your drone has drifted downriver tracking a floating leaf. And it can lead to a crash if the drone then drifts into an overhanging branch, while you aren't paying attention.

To be clear, this is not something either you or I can agree or disagree with. It's reported by people who have experienced this error. By "loss of control" what is meant is drone is drifting forward following that leaf in the stream, the pilot pulls the stick back to try to stop the forward movement – the correct control input – and the drone goes full-throttle sideways, slamming into the shore.

Response unexpected and completely at odds with the control input. I consider this "out of control", response "paradoxical" to the control input, and I suspect many others see such control/response behavior this way too.

 

[Droning on and on...]

But there is no wild paradoxical response to control input, and it's certainly not difficult to regain control. With the control sticks released to centre, you are effectively engaging the autopilot to hold this current position. The drifting caused by the VPS tracking and following a moving pattern can only occur if the sticks are centred and the autopilot takes over. If the drone doesn't actually remain hovering in the expected fixed location, to recover you merely need to give some stick input to cancel the autopilot and you immediately regain full control.

This is an incorrect understanding of how the Flight Controller on modern DJI drones work. In all available modes (N, S, C) the FC is always flying the drone, control stick inputs only providing a demand request, and that isn't even pitch or roll input, but rather forward/backward or right/left sideways movement. The FC will attempt to meet that request if possible.

This is most easily seen when there is more than an intermittent, light breeze. The FC will not only hold position with no input, but it will also attempt to hold course (not just heading) with just forward or backward input. This is without any roll input from the pilot.

Also, the FC controls for ground speed. Gone are the days when speed records could be set flying full-throttle downwind. The FC interprets pitch stick position as a proportional speed setting, not as an amount of pitch. Fly upwind at full stick, you'll go about the spec'd max speed for that model in that mode. Turn 180° and fly downwind, same result: Max spec'd speed, relative to the ground.

Difference? Examine the logs, and the pitch angle going upwind will be much greater upwind than downwind, the size of this difference being larger the more wind there is.

Whenever you give input with the sticks, what the FC does w.r.t. roll and pitch is a much more complex determination than just applying roll or pitch angles scaled to the stick deflection. The FC is going to try to move relative to the ground, as it senses it, on a straight course at a ground speed proportional to stick deflection. If nonsensical data is coming from the position-sensing system and the FC doesn't know this data is in error, strange, paradoxical responses to control input can occur, as the FC will implement roll behavior to stay on course, and achieve the ground speed that is being requested.

All things that are utterly impossible with bogus positioning data, and, as some have actually experienced and posted about on this forum wild crazy inexplicable responses to control inputs.

Any reader unwilling to accept my word on this I encourage you to see all this for yourself... go fly upwind, downwind, crosswind, and in a circle with a light wind 7-10mph, then extract the log and examine it.

This post contains just such a flight log.

This post contains a summary analysis of the log w.r.t. speed, pitch angle, etc.

 

[Zbip57]

It's reported by people who have experienced this error.

People "report" all sorts of misinformation. How often have you seen people give advice that you should never fly lower than 30m over any water otherwise the VPS will suck the drone down into the water?

Most of the time it's because in panic they pushed the wrong button at the wrong time, or pulled the control stick when they should have pushed it. Unexpected things can happen, but it's only very rarely a "loss of control". It's almost always pilot error with the drone responding to inputs exactly as it is programmed to do.

By "loss of control" what is meant is drone is drifting forward following that leaf in the stream, the pilot pulls the stick back to try to stop the forward movement – the correct control input – and the drone goes full-throttle sideways, slamming into the shore.

Can you point to any confirmed case (with data logs) of this ever actually happening? Or is that just based on somebody's opinion and "report" of what they think happened.

Response unexpected and completely at odds with the control input. I consider this "out of control", response "paradoxical" to the control input, and I suspect many others see such control/response behavior this way too.

I've posted this video before. It's from nearly 11 years ago with my original DJI Phantom carrying a GoPro with no video transmitter. So I was relying solely on line-of-sight. I let the drone get a bit too far away from me and no was no longer certain of its orientation. So I switched to Home-Lock and pulled back on the stick. Normally, that would bring the drone straight back toward the Home position, regardless of which way the drone was currently facing. Except this time it reacted in completely the opposite direction!

I expected it to come back to me, instead it flew even further away?? I glanced down to check my switch configuration, but then lost sight of the drone. Oh-oh.

I thought it was "loss-of-control" and panicked. But, in hindsight after carefully studying the GoPro footage, I realized it was totally my own fault and pilot error. I was flying in Atti-mode at the time and Home-Lock only works in GPS-mode. I didn't know that when Home-lock is selected while in Atti-mode, the drone reacts in Course-lock mode. Pulling back on the control stick exactly matched the drone's proper response to the Course-lock direction recorded at start-up. It all made perfect sense afterward, it just wasn't what I expected to happen at the time. If I'd lost the drone with no chance of reviewing the GoPro footage, I would have been left convinced that it was an unexplained "fly-away".

 

[Zbip57]

This is an incorrect understanding of how the Flight Controller on modern DJI drones work. In all available modes (N, S, C) the FC is always flying the drone, control stick inputs only providing a demand request, [...]

I'm sorry we're drifting far off the original topic of Yaw-error, as the positive feedback loop created by the initial compass error can and does result in actual loss of control. But even there the original cause is still pilot error, in that the pilot failed to check or failed to notice before takeoff that the drone icon on the app's map display wasn't pointing in the direction the drone was physically facing. Ignoring that false indication can lead to the dreaded yaw-error condition with the drone rapidly spiralling away out of control upon takeoff.

But, if we're allowed to go further off topic, I'm still curious to know how the VPS could ever be blamed for causing the scenario you suggested.

It's reported by people who have experienced this error. By "loss of control" what is meant is drone is drifting forward following that leaf in the stream, the pilot pulls the stick back to try to stop the forward movement – the correct control input – and the drone goes full-throttle sideways, slamming into the shore.

In my previous video I showed how, when in hands-off hover, the drone uses the VPS optical sensor to hold a fixed position over the patterned rug even as the rug is being pulled away.

Let's simulate your example with the drone "drifting forward following that leaf in the stream". So here the drone is pointing forward as I pull the rug forward, and will continue to do so as long as the sticks remain centred.

If I then pull the control stick back to stop that unwanted forward movement, "-the correct control input-", why would the drone ever suddenly go full-throttle sideways, slamming into the shore?

Your speed limit theory based on groundspeed is irrelevant. Yes, it's factual. But how is that supposed to apply in this case? Is the groundspeed while tracking the floating leaf being measured by the VPS sensor, or by the GPS?

If the VPS is taking priority again, then the drone's "groundspeed" would be zero if it is still precisely tracking the drifting leaf. As far as the drone knows, it isn't moving at all. It's staying precisely in one spot, directly over that leaf.

If instead the groundspeed is being measured by GPS location, then the flight controller knows the direction and speed at which the drone is moving. If the current is flowing at a speed greater than the permitted groundspeed limit, then the flight controller will apply opposite pitch/roll input to apply the brakes, and the VPS will no longer be able to keep up with the drifting leaf.

In any case, any control stick input applied by the pilot will always immediately cancel whatever the "auto-pilot" is trying to do to maintain its "hover" position. If I pull back on the stick, the flight controller reacts by pitching the drone rearward.

Yes, the groundspeed limit still applies. But what could ever possibly make the drone move sideways, rather than rearwards, and then go full-throttle sideways, slamming into the shore?

It doesn't make any difference in which direction I'm pulling the rug, or which direction the drone is actually facing relative to the movement of the rug while it's hovering. Pulling back on the control stick always make the drone pitch rearward, never sideways.

I consider this "out of control", response "paradoxical" to the control input, and I suspect many others see such control/response behavior this way too.

I would also consider is paradoxical if it ever happened to me. But I don't see how it's possible.

Can you think of a way to convincingly demonstrate this happening when dragging a large enough carpet in any direction?

 

[Droning on and on...]

@Zbip57, since I have no good reason to disbelieve the accounts of these control failures shared here, I don't. I think people are generally sincere when sharing an adverse incident on the forum.

As such, I have absolutely no interest or willingness to try and construct some scenario to demonstrate this problem. I don't doubt it happened.

You're obviously not convinced, which is part of the give and take of discussion. I note that you were misinformed about VPS vs. GPS positioning and when the drone uses it, are you open to the possibility that some of the assumptions your making here might be in error as well?

In any case, this comes down to "agree to disagree". I've offered an explanation based on my understanding of how the system works, and having been inside it (in a virtual sense) from my hacking days on the MP, I'm pretty confident in that understanding.

At this point I can't offer any more than I have already, as I'm not going to undertake what would be a rather significant undertaking to test and get some data.

If you'd like to I'm sure it would be appreciated by the community.

 

[Zbip57]

[...] are you open to the possibility that some of the assumptions you're making here might be in error as well?

Absolutely, yes. In my video demonstrating whether VPS or GPS takes priority, I freely admitted being surprised when my assumptions were demonstrably proven to be wrong.

Absent actual proof, assumptions are merely that -- assumptions. Everyone has, and is entitled to, opinions. Actual experiments, with demonstrated results that can be reproduced by anyone, carry far more weight than mere assumptions and opinions.

Absent demonstrated proof, then assumptions and opinions need to be backed up by convincing logic.

Since I have no good reason to disbelieve the accounts of these control failures shared here, I don't. I think people are generally sincere when sharing an adverse incident on the forum.

People share grainy indistinguishable photos of some black blob as "proof" of the existence of Sasquatch, or that aliens landed a flying saucer in their backyard. They may even in all sincerity believe it to be true.

But I'm a skeptic. In this day and age when everyone carries a cellphone equipped with a powerful camera, why has nobody ever captured a convincing definitive clear photo?

It's the same thing with the vast majority of "control failures" reported on these drone forums. For sure, it's a miracle these complicated modern drones manage to fly as reliably as they do. There are so many electronic steps involved between you wiggling a control stick and how the onboard flight controller eventually decides to interpret that signal, there's a million ways that could wrong.

But it only very rarely ever does go wrong. It's almost always something the pilot has done wrong, or simply misunderstood what he should have done differently, or misinterpreted the results.

The more DJI tries to make these systems idiot-proof, the more complex the systems turn out to be.

Trying to bring this back to the original topic of Yaw-Error, the cause of that has been pretty well figured out. An initial pre-takeoff compass error confuses the flight control when, after takeoff, the GPS heading disagrees with the compass heading (or something like that. I'll admit I don't fully understand it myself.) In any case it can easily be avoided by a simple pre-takeoff checklist item to confirm the map icon is pointing in the proper direction.

The resulting loss of control could also be cured by quickly switching to Atti-mode, which removes the influence of the conflicting GPS data. But DJI seems to have removed that option. On my Phantom (P1 & P3P) controllers, a simple toggle allowed switching between the various flight modes. With the Mini there's no option available to manually switch to Atti-mode.