Yaw errors, might this be a solution?

[Yorkshire_Pud]

I was thinking, ( dangerous I know ) it seems to me that a characteristic of a "yaw error" flyaway is that once the drone is away from the home-point/takeoff-point a sudden, uncommanded and inexplicable recorded change in the drone's heading occurs.
That may not be precisely corrrect but I would bet that it is the way most people would interpret the situation/explanation.

Taking that to be, in essence, correct, would it be feasible for DJI to add code to the firmware to detect this apparent uncommanded turn. Then, once the situation was detected, warn the pilot that there may be a navigation problem and offer the pilot the option to start a landing, with GPS disregarded, in which, whilst VPS was inoperable, the drone would descend with 0 pitch and 0 roll unless the pilot commanded otherwise with the joysticks.
Yes I am aware that with inoperable VPS this would mean that the drone could be blown about by the wind but it at least gives the pilot manual control of the drone and might allow them, via either looking at the drone or using the screen, to fly the drone to safety whilst it is descending.

Since the change seems to occur close to the home-point/take-off point, "looking at the drone" should not be a problem and to be honest, in most cases, I would have thought that the drone would be low enough for VPS to work and working VPS in most cases means automated position holding etc..

Yes I am also aware that the correct thing to do is check that the app's 'map' etc. indicates that the drone is pointing in the correct direction but, since we have seen logs where this sudden 'turn' has occurred, people presumably haven't done this or don't know of it and presumably this will continue to happen.

DJI adding code to do the above might save future drones.

 

[Phantomrain.org]

Yes I know of that change of direction very well .

Its a great idea however because you have to Reset all the compass calculations by shutting the drone down and rebooting , would not be feasible in the sky.

I think in future they may have some kind of Back Up but that would be more weight and were not likely to see that because of that.

Lets see what Meta 4 says.

Phantomrain.org
Gear to fly in the Rain.

 

[Yorkshire_Pud]

Lets see what Meta 4 says.

Phantomrain.org
Gear to fly in the Rain.

I would also be interested to see what slup, sar104, BudWalker, msinger & boblui think but boblui hasn't been here in months.

 

[Droning on and on...]

Yes I am aware that with inoperable VPS this would mean that the drone could be blown about by the wind

Actually no, it will still use GPS for positioning, and while GPS can have errors as large as 30 ft under the worst situations, in practice the position detected is pretty stable, even if off on an absolute location, which is all that's needed for positioning.

 

[Droning on and on...]

Since heading can be determined via GPS location changes while moving, I'm surprised the system does have and prompt for a guided procedure to fly around in the immediate area to calibrate the compass from GPS heading information.

 

[Kilrah]

Since heading can be determined via GPS location changes while moving, I'm surprised the system does have and prompt for a guided procedure to fly around in the immediate area to calibrate the compass from GPS heading information.

GPS gives you the direction of movement with regard to the ground, but cannot tell which way the drone is pointing, which is... crucial to create any change of movement.

 

[Droning on and on...]

GPS gives you the direction of movement with regard to the ground, but cannot tell which way the drone is pointing, which is... crucial to create any change of movement.

Good point.

I still think this could be effectively done, as between the control inputs and GPS data, and the right sort of flight path (basically a circle) everything including wind can be figured out, at least well enough to get control of the drone and bring it back, rather than fly away.

My point is, the information from the compass can be inferred and synthesized from other information the drone has available. Not as accurate, but I suspect good enough for recovering from a compass failure.

Unlike GPS, which, if that fails you're toast. Since our drones are never beyond VLOS, this really isn't a concern

 

[Yorkshire_Pud]

Actually no, it will still use GPS for positioning, and while GPS can have errors as large as 30 ft under the worst situations, in practice the position detected is pretty stable, even if off on an absolute location, which is all that's needed for positioning.

But if GPS is disregarded, as I suggested, the drone will surely not know or not use GPS to establish its posiiton, therefore it will not 'correct' in the wrong direction.
I am pretty sure this has been commented on in at least one thread where, I recollect, the troubled pilot was told something to the effect that
"You took off without GPS but with a yaw error. Once the drone gained enough GPS to know its position the yaw error came into play and the drone corrected in the wrong direction."

 

[Yorkshire_Pud]

I still think this could be effectively done, as between the control inputs and GPS data, and the right sort of flight path (basically a circle) everything including wind can be figured out, at least well enough to get control of the drone and bring it back, rather than fly away.

Surely in a yaw error flyaway it is, for whatever reason, the original compass error that is the source of the problem and as a consequence the drone 'corrects' in the wrong direction.

My point is, the information from the compass can be inferred and synthesized from other information the drone has available. Not as accurate, but I suspect good enough for recovering from a compass failure

If you think it possible that people could save a yaw error drone can you direct us to a thread where that has been done? I don't remember one.
The closest to perhaps saving a yaw error drone that I might have seen mention of, is where the troubled pilot switched to cine or tripod mode and perhaps gave themselves time to think, but that was a long time ago and I am not sure if I have remembered the details correctly.
Or are you suggesting that the drone already this capability or could be given it via additional coding?

Unlike GPS, which, if that fails you're toast.

Why would we be toast if GPS packs up?
I have hundreds of indoor flight with no GPS and, providing VPS can work, GPS-less flight is rock solid.
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 have flown a mini up my stairs, quite narrow and unforgiving, concrete and steel, in ATTi mode, obviously without GPS, I have flown my P3Adv/Pro in ATTI outdoors without a problem.

 

[Droning on and on...]

But if GPS is disregarded, as I suggested, the drone will surely not know or not use GPS to establish its posiiton, therefore it will not 'correct' in the wrong direction.

Not sure what you're getting at here. If GPS is working, why would it not be used?

I am pretty sure this has been commented on in at least one thread where, I recollect, the troubled pilot was told something to the effect that
"You took off without GPS but with a yaw error. Once the drone gained enough GPS to know its position the yaw error came into play and the drone corrected in the wrong direction."

Yeah, with no GPS and a malfunctioning compass, that would be a problem

 

[Droning on and on...]

Surely in a yaw error flyaway it is, for whatever reason, the original compass error that is the source of the problem and as a consequence the drone 'corrects' in the wrong direction.

Yes, and the compass fault can be detected. Once it is, the flyaway can be stopped.

It's pretty simple: There are no control inputs commanding movement. If GPS is working, pitch/roll by the FC to hold position, using VPS or GPS to determine drift, should not result in large-scale changes in position. If this occurs, something else is wrong (like a compass fault), and the software should detect this, rather than getting confused and flying away.

If you think it possible that people could save a yaw error drone can you direct us to a thread where that has been done? I don't remember one.

I don't. I was speculating as to how the functionality could be enhanced if changes to the code were made, as this thread started with. ("would it be feasible for DJI to add code to the firmware to detect this apparent uncommanded turn")

Or are you suggesting that the drone already this capability or could be given it via additional coding?

Yes, that was what I was thinking.

Why would we be toast if GPS packs up?
I have hundreds of indoor flight with no GPS and, providing VPS can work, GPS-less flight is rock solid.

I was referring to the common situation where the drone is outdoors, a long ways away, BVLOS.

 

[Yorkshire_Pud]

Not sure what you're getting at here. If GPS is working, why would it not be used?

If there is a yaw error AND the drone knows its location, from GPS, then, it seems to me that the combination of yaw error AND the use of GPS leads to the fly away.
You can't remove the source of the problem i.e. the yaw error with out rebooting the drone, so remove the other factor, GPS.

I was referring to the common situation where the drone is outdoors, a long ways away, BVLOS.

Yaw error flyaways generally start quite close to the takeoff point, they shouldn't be BVLOS.
From what I have read, most times the drone doesn't get out of sight before it crashes.

 

[Droning on and on...]

If there is a yaw error AND the drone knows its location, from GPS, then, it seems to me that the combination of yaw error AND the use of GPS leads to the fly away.
You can't remove the source of the problem i.e. the yaw error with out rebooting the drone, so remove the other factor, GPS.

Ahhh, I think I get it now.

My point is that if GPS is working, that is sufficient to both detect the compass failure, and avoid a flyaway. Again, movement larger than the current GPS accuracy (HDOP) with no control input from the pilot detects the failure. The compass can then be ignored.

Even with yaw input, any position change large enough can indicate a failure. IOW, if, taking in all the sensor data (GPS, compass, barometer, etc.) the FC commands position-keeping roll/pitch action that results in loss of position-keeping and increasingly so, it should stop.

Why it isn't this smart, who knows? I suspect it's an ROI thing... much cheaper to just replace drones in these rare circumstances, than spend the R&D, testing, and support for the feature across all product lines.

Just let 'em fly away, and replace them.

 

[Yorkshire_Pud]

My point is that if GPS is working, that is sufficient to both detect the compass failure, and avoid a flyaway.

That may, or may not, in theory, be true but, the way things are currently implimented, it doesn't happen. If it did happen then people would experience these flyaways.

ingly so, it should stop.

but it currently doesn't, infact 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.

 

[Droning on and on...]

That may, or may not, in theory, be true but, the way things are currently implimented, it doesn't happen. If it did happen then people would experience these flyaways.

I'm not following... your responses are argumentative, as if I'm asserting this is the way it works. I am not.

Just like you, I'm speaking in the hypothetical, if code changes were made, just as you did starting the thread.

So I really don't understand the point of your argumentative responses.

Pointing out DJI drones don't do now what I'm positing they could do with modifications to the software doesn't seem be getting at anything.

but it currently doesn't, infact 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.

Yes. And I'm pointing out a better way to break that unstable system. If you'd like, add to the discussion. Simply pointing out again and again that it doesn't work this way doesn't advance the discussion.

 

[Yorkshire_Pud]

your responses are argumentative

not in my opinion.

 

[BudWalker]

I was thinking, ( dangerous I know ) it seems to me that a characteristic of a "yaw error" flyaway is that once the drone is away from the home-point/takeoff-point a sudden, uncommanded and inexplicable recorded change in the drone's heading occurs.
That may not be precisely corrrect but I would bet that it is the way most people would interpret the situation/explanation.

Taking that to be, in essence, correct, would it be feasible for DJI to add code to the firmware to detect this apparent uncommanded turn. Then, once the situation was detected, warn the pilot that there may be a navigation problem and offer the pilot the option to start a landing, with GPS disregarded, in which, whilst VPS was inoperable, the drone would descend with 0 pitch and 0 roll unless the pilot commanded otherwise with the joysticks.
Yes I am aware that with inoperable VPS this would mean that the drone could be blown about by the wind but it at least gives the pilot manual control of the drone and might allow them, via either looking at the drone or using the screen, to fly the drone to safety whilst it is descending.

Since the change seems to occur close to the home-point/take-off point, "looking at the drone" should not be a problem and to be honest, in most cases, I would have thought that the drone would be low enough for VPS to work and working VPS in most cases means automated position holding etc..

Yes I am also aware that the correct thing to do is check that the app's 'map' etc. indicates that the drone is pointing in the correct direction but, since we have seen logs where this sudden 'turn' has occurred, people presumably haven't done this or don't know of it and presumably this will continue to happen.

DJI adding code to do the above might save future drones.

I'm not sure what is meant by recorded heading change. But, there is the magYaw value which is computed from magnetometer and attitude data. MagYaw isn't recorded in the .DAT or .txt log files but is almost certainly computed and then used by the Flight Controller (DatCon computes magYaw as well). MagYaw isn't used by the FC for navigation though, probably because it's too slow. Instead the FC uses a heading value computed from accelerometer, gyro, GPS and, to a small extent, magnetometer data.

Back in the Phantom days the FC would detect situations where this computed heading value wasn't reliable and switch to ATTI mode. In essence the FC was giving up navigating and saying the pilot is responsible for navigating. Seemed like with every FW upgrade the threshold for switching to ATTI was lowered. This made this strategy better but also increased the number of false positives.

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.

After this DJI introduced the "vision" compass where the vision system was used to detect rotation. This seems to have met with limited success. One big problem occurred when the drone was over water.

Using GPS data to derive direction has been suggested many times. Although viable able in a qualitative sense I suspect the GPS data is just too slow and lacks enough precision to be viable. DJI has tried all these other attempts and would have tried this solution were it viable.

 

[Droning on and on...]

Keep in mind that position hold with VPS does not require GPS or a compass sensor. All that is necessary to implement optical flow algorithms is a single downward camera, and a barometric altimeter.

Don't take my word for it. The Parrot Mambo does it, as well as the Tello.

With optical flow, orientation relative to movement is known, so the FC does not need a compass to determine roll/pitch inputs to counter the positioning errors.

This is only necessary when high enough that optical flow resolution is less accurate at detecting movement than GPS. A compass is then necessary to calculate roll/pitch responses to changes in GPS position.

As the Tello demonstrates, the compass can be ignored during VPS positioning. If flyaway due to compass failures are occurring while the FC is using VPS for positioning, the problem is poor engineering. The compass should be ignored by the FC during VPS-driven positioning. Again, as the Tello shows, a compass need not be present.

Further, the disagreement between what Optical Flow analysis requires in pitch/roll action vs. what the faulty compass indicates would be another good place to throw a serious, LAND NOW error at the user, while drone is near by, 100% controllable with full position hold capability, operation to the pilot completely normal. Again, the compass can be completely ignored.

 

[BudWalker]

Keep in mind that position hold with VPS does not require GPS or a compass sensor. All that is necessary to implement optical flow algorithms is a single downward camera, and a barometric altimeter.

Don't take my word for it. The Parrot Mambo does it, as well as the Tello.

With optical flow, orientation relative to movement is known, so the FC does not need a compass to determine roll/pitch inputs to counter the positioning errors.

This is only necessary when high enough that optical flow resolution is less accurate at detecting movement than GPS. A compass is then necessary to calculate roll/pitch responses to changes in GPS position.

As the Tello demonstrates, the compass can be ignored during VPS positioning. If flyaway due to compass failures are occurring while the FC is using VPS for positioning, the problem is poor engineering. The compass should be ignored by the FC during VPS-driven positioning. Again, as the Tello shows, a compass need not be present.

Further, the disagreement between what Optical Flow analysis requires in pitch/roll action vs. what the faulty compass indicates would be another good place to throw a serious, LAND NOW error at the user, while drone is near by, 100% controllable with full position hold capability, operation to the pilot completely normal. Again, the compass can be completely ignored.

One thing to consider is that DJI VPS doesn't appear to be very robust. Depending on the platform VPS can be not producing position or velocity data for a significant amount of time. For example, here is some VPS values from a flight of my Mavic 2.


And, here is some VPS data from a Tello flight

 

[Droning on and on...]

One thing to consider is that DJI VPS doesn't appear to be very robust. Depending on the platform, VPS can be not producing position or velocity data for a significant amount of time. For example, here is some VPS values from a flight of my Mavic 2.

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).