Yes, Landing Protection CAN be disabled, but...

[Zbip57]

The solution is, the flight controller must record that initial position and velocity when the motors are first started for take off.

If the drone is sitting on the ground, that's easy enough. That spot becomes the zero location. And, since it's sitting without moving on the ground, the flight recorder marks that spot with zero velocity.

With those items properly initialized, from there on the accelerations precisely measured by the IMU can be used to integrate backwards to establish current velocity and position at any moment in time.

Except...

Let's say the acceleration plot of the x-axis alone looks more like this.



Integrating once to get velocity is already a lot more complicated. Integrating twice to establish position is going to be a lot less trustworthy.

Now consider that, when launching off my hand, I can't guarantee I was holding the drone perfectly motionless. Its position at time zero was a little wobbly. Its velocity certainly wasn't zero either.

The flight controller runs its "fusion" calculations when fed SIX separate degrees of freedom based on the IMU's measurements of linear acceleration in the x, y, and z axes, and rotational accelerations in the pitch, roll, and yaw axes.

If the drone isn't sitting perfectly still (handheld, or bouncing in a boat) when all those axes are initialized, it has a significant effect on the accuracy of any subsequent dead-reckoning calculations. And those errors propagate exponentially the longer the time runs from there onwards.

The flight controller can probably navigate relatively accurately by dead-reckoning alone based on the input from nothing other than the IMU, for a short period of time starting from properly zeroed initialization.

But, that's what the other sensors are for. The GPS marks an actual starting position on a global map, and the GPS is polled by the flight controller at some frequency to continuously update actual position and actual velocity, so the accelerations measured by the IMU and their integrations can be periodically verified and updated.

It's the same for the vertical z-axis accelerations measured by the IMU. The IMU can only measure acceleration. Any change in acceleration can be integrated backwards to determine velocity, and integrated a second time to calculate vertical position. But that can only be put to use accurately by the flight controller if it knows with certainty what the initial upward velocity was, and what the initial vertical position was.

For that it relies on updates from the barometric sensor. The flight controller near-instantly calculates height based on what the IMU is telling it, but it confirms whether that height has changed as predicted, or remained the same as predicted, by periodically polling the barometric sensor.

If the barometric pressure hasn't changed, the flight controller knows its height hasn't changed. If the IMU calculated height has drifted, due to roundoff error, from what the barometric sensor is showing, the flight controller corrects to what the barometric altimeter is currently indicating.

If the flight controller were instead taking its cue from the infrared sensor, the response would be entirely different. Unless the drone is flying over perfectly level ground, the distance measured by the infrared sensor is constantly fluctuating as the drone passes over fluctuating terrain features.

If the flight controller was polling the infrared sensor height to verify and correct the height calculated from the IMU acceleration measurements, the drone should be constantly raising or lowering its height, effectively causing the drone to do Terrain Following as it tracks the elevation changes below.

As I showed in my videos, the drone never responds to any changes measured by the infrared height sensors, unless Landing Protection is triggered when sensing anything within 0.5m (2ft).

 

[Zbip57]

Sorry for all the calculus. But it's important to realize how the IMU does this stuff. The flight controller is probably able to accurately make the drone take off and climb to a height of precisely 1.2m based on the inputs from the IMU alone. But rounding errors will eventually cause the results of those calculations to drift. Periodic inputs from all the other sensors are necessary to make frequent corrections.

Pitch and roll levelling is relatively simple, because the IMU can always sense which way is down because of the direction that gravity is pulling. Yaw variations are corrected by the magnetometer readings of the compass. Height variations are corrected with input from the barometric sensor.

X-y axis horizontal positioning and speed calculations are tuned by reference to GPS coordinates. If the GPS fails, the optical sensor of the VPS unit takes over (when within range). But if BOTH the optical sensor and GPS are absent, the flight controller can only rely on the IMU to measure accelerations, then do the math integrations to calculate changes in its speed and position. That's ATTI mode, and you can see how quickly that calculated position degrades.

If you're sitting in that train car with no windows to see out of, your body won't know if the car is stopped or travelling smoothly at some constant velocity. Your body, like the IMU, is very good at sensing accelerations. But without input from other sensors, like your eyes, you woudn't be able to tell the difference between steady flight at 500mph in an airliner, 50mph in the rail car, or sitting still and not moving at all.

 

[3rdof5]

Excellent thread! Very informative.

 

[dajomu]

There are many misconceptions concerning the downward sensors on DJI drones.

One of the biggest is the often repeated myth that VPS downward sensors should always be disabled whenever flying over water, as though those sensors can somehow force your drone to crash into the water. People support that argument by pointing to DJI's warning to use caution when flying over water, as the VPS sensors may cause unexpected behaviour.

It's important to distinguish between the two separate functions of the VPS sensor. Typically there is one optical sensor, and two either ultrasound or infrared sensors.

The optical sensor is for horizontal position hold, in the absence of sufficient GPS reception whenever the control sticks are centred. The optical sensor only works if it can fixate on distinct visual surface cues. A uniformly coloured surface like a smooth field of white snow, or a painted floor of one solid colour, or insufficient lighting might provide insufficient distinguishable landmarks to fix on. Similarly a flat mirror surface reflecting nothing but clear blue sky leaves nothing for the optical sensor to fix on. Or, if the optical sensor sees only the drone itself reflected in that mirror surface, then it may track and follow the movement of that object, the drone itself. If it locks onto a leaf drifting by on the current, or wind ripples and waves, the optical sensor may track those and not hold a fixed position. Note: This will only ever happen if there is insufficient GPS lock and the control sticks are centred. You may be expecting the drone to stop as usual and hold position, then be surprised when it wanders away by itself, tracking something else with its optical sensor.

The other sensors are either ultrasound or infrared, each providing similar function. One emits a signal, the other receives the reflection after it bounces off the surface below. The time difference tells the exact height above that surface. These VPS height sensors are very accurate, but have a limited range of somewhere up to 10m (~35'). While lower than that over any surface or obstacle, a precise AGL height is recorded in the flight log. However, as far as I can tell, the VPS height only ever plays an active control in the landing protection system, because altitude hold is otherwise measured and maintained by the IMU and barometric altimeter.

The barometric altimeter resets to zero at takeoff, with all subsequent height measurements constantly referenced back to that zero height takeoff location. However, changes in local air temperature and pressure can cause significant fluctuation in the accuracy of the barometric altimeter's reading. It can vary by as much as ±10' upon return to the same spot where it took off from. Here's how this can create problems...

Let's say it early evening, the sun is setting, and the land's surface is cooling off. You take off from the beach and fly your drone low out over the lake. The lake water takes longer to cool down than the land. So the air over the water is warmer than at your takeoff location on the beach. Warm air is less dense than cold air. Even though you're watching and flying the drone VLOS along at the same low height skimming the surface of the water, the barometric altimeter reading might now be indicating a greater height than is actually true. If instead you're watching only the monitor showing a glassy smooth surface passing below, and you look at the now incorrect height reading indicating plenty of height, you might be tempted to lower the drone's altitude and end up dunking it into the lake...

If you have disabled the landing protection system of the VPS height sensor, there's nothing to prevent an inadvertent ditching like that from happening. That is one of the design purposes of the landing protection system, to prevent the drone descending lower than 0.5m (~2'). The drone will descend no lower, unless you respond by deliberately holding the throttle stick down to confirm you wish it to land. It's a safety feature, eh.

If you slowly lower the drone's height down to the ground, or water, or treetop, or whatever, regardless of what the barometric altimeter is currently correctly or incorrectly showing as height, once the VPS height is within active range it accurately tracks the drone's clearance above that obstacle. That shows up in the flight log. If the drone descends to closer than 0.5m (~2') above that obstacle, landing protection will stop the drone from descending any further, unless you hold the throttle stick down to confirm your intent to land.

But, there are obvious limits to its effectiveness.

If you fly with high speed at low height, the drone won't have enough time to react to sudden sensor changes in height measurement. The height sensor is ineffective when flying over surfaces that absorb, rather than reflect the ultrasonic or infrared pulses, or over surfaces that scatter the reflection so the return pulse is too weak to be registered by the sensor. That can happen when flying over grassy fields... or water. That doesn't mean the VPS will cause your drone to crash. It means the VPS may not be able to prevent your drone from crashing when you're trying to fly it into the ground... or water.

If you deliberately disable the VPS by covering the sensors with tape, or by any other means, it means you have deliberately chosen to remove any possible protection afforded by the VPS system. However, there sometimes (even often) are good reason for wanting to do this.

There definitely are times when the landing protection system is downright infuriating, and I wish DJI provided a simple toggle in the Fly app to allow us to disable it whenever we choose.

You may be confident in your ability to fly at heights with less than 0.5m clearance, for example flying through a small window opening. But if you do it too slowly, the VPS height sensor has time to detect the window sill below, and the landing protection system suddenly kicks in to automatically lift the drone at least 0.5m higher than the window ledge, thereby ramming the drone up into the top edge of the window frame! Erg! That's not what I wanted to do...

Or, you're on a moving boat bouncing in waves and wish you could just reach out and grab your drone to land it. But every time you put your hand anywhere near it, the drone leaps up 0.5m (~2') to avoid your grasp...

Well... Here's one solution for y'all, using the Litchi app. See video below.

By the way, this was already described over a year ago by @EyesWideShut:
Disable auto-landing/ ground sensor feature?

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

(Non-Litchi solution described here). As of July 2023, Litchi does not support the Mavic 3 Pro, and the DJI Fly App still lacks an option to disable the Landing Protections system. So landing/hand catching from a tossing boat is still an issue, as well as the other issues described so well in EyeWideShut's video linked above. And, to be clear for anyone who has not tried it, the technique used for hand catching while standing on an unmoving surface does not work well when you are standing on a boat that's being tossed around in ocean chop. HOWEVER, I have found that I can completely disable the landing protection system, solving all of these problems and introducing new ones, by covering the bottom sensors with black gaffer tape (such as "Real Premium Grade Gaffer Tape by GafferPower on Amazon). I first tried blue painter tape, and that didn't work. I suspect the IR sensor could "see" through that tape. But the gaffer tape worked. That tape is designed to leave no residue behind, which is comforting. There may be a risk that the tape could fall off during a flight if the surface to which the tape is attached gets hot, which is likely during flight. So I use rubber bands around the body of the aircraft to hold the tape in place as an extra precaution. PLEASE NOTE that I am sharing the above technique for information only. There may be risks to this technique that I have not described, or that I don't know about. So only use this technique at your own risk,, and certainly practice any new flying technique on dry land first!

 

[Droning on and on...]

This is a fascinating thread. Lots of good information. A few nits i need to pick, though...

Yes & No. The barometric pressure sensor (not altimeter) always outputs a pressure reading in hPa’s relative to MSL.

To be accurate about the barometric pressure sensor, it measures pressure relative to 0 (zero) psi/hPa/inHg/mBar... Not MSL. The pressure at MSL varies no differently than anywhere else on the surface.

An absolute altitude above MSL is included in flight logs. This comes from the GPS unit, not the barometer, and has an error margin as much as several hundred feet, depending on the satellite configuration at the time.

 

[Droning on and on...]

That should only be possible in the absence of sufficient GPS reception, for example if too much of the sky view is blocked when flying in the bottom of a narrow gorge or between tall buildings.

This is not correct.

GPS does not have sufficient accuracy to be used for positioning close to the ground. That's the entire reason for the VPS camera.

The crossover point is 10m/33ft. Below that, Optical Flow is used to control positioning in a hover. This is why flowing water can fool the system, in spite of conflicting GPS data, and track moving water a long way, causing a loss of control while hovering.

The dynamic surface of moving, churning water also causes confusing measurements from the ToF sensor (forget the primitive ultrasonics, they're near useless under these conditions), which can lead to odd height behavior with no stick input at all.

Yes, drones have taken a swim under these conditions. Usually with some minimal pilot input, but not in control.

 

[Zbip57]

This is a fascinating thread. Lots of good information. A few nits i need to pick, though...

Pick away. It's great to exercise our brains occasionally.

To be accurate about the barometric pressure sensor, it measures pressure relative to 0 (zero) psi/hPa/inHg/mBar... Not MSL. The pressure at MSL varies no differently than anywhere else on the surface.

Furthermore, sea level itself varies dramatically with the tides. Hence the need for mean sea level MSL which uses an average value.

An absolute altitude above MSL is included in flight logs. This comes from the GPS unit, not the barometer, and has an error margin as much as several hundred feet, depending on the satellite configuration at the time.

Besides being highly inaccurate, it's not all that useful in any case unless referenced to a database of the actual height of land below the drone and subtracting that to give an current height above ground of the drone. Because that's all that we're really interested in.

How high is the drone above ground right now? We have no way of ever accurately knowing that.

The DJI Go app on my Phantom 3 Pro used to display both the barometric height display and the VPS AGL height display. The DJI Fly app for the Mini however shows only the barometric height. The VPS height is recorded in the log, but you never see that during the flight.

The barometric height only shows how high the drone is relative to its takeoff location, which isn't all that useful if you fly it off a cliff or up a mountainside. How can you accurately know your current above ground height, or whether you're ever exceeding the mandated 400ft AGL regulation?

 

[Zbip57]

...10m/33ft. Below that, Optical Flow is used to control positioning in a hover. This is why flowing water can fool the system, in spite of conflicting GPS data, and track moving water a long way, causing a loss of control while hovering.

I'll come back to that, with a new video, in my following post. Standby...

The dynamic surface of moving, churning water also causes confusing measurements from the ToF sensor (forget the primitive ultrasonics, they're near useless under these conditions), which can lead to odd height behavior with no stick input at all.
Yes, drones have taken a swim under these conditions. Usually with some minimal pilot input, but not in control.

This is the one that concerns me the most, as I still don't understand how the ToF sensor could ever possibly cause this to happen, regardless of whether it's an ultrasonic or infrared sensor.

As I've demonstrated in my previous videos, the VPS height sensor does actively measure and record height above ground or obstacles whenever it's within working range. Those heights are recorded in the flight log. But the drone never reacts to any of those measurements unless something is detected by the Landing Protection system within ~2ft of the underside of the drone.

Whether the drone is in motion or stationary in a hands-off hover, its height always holds level based on the barometric sensor. The VPS height sensor measurements never produce any visible effect at all. When flying on an uphill or downhill slope, across a deep ditch, or off a cliff, the drone's height never changes in reaction to those varying readings from the VPS height sensor when the terrain height changes beneath the drone. It never reacts in a hover either, as shown by raising or lower your hand below the drone (unless within ~2ft).

So even if the VPS height sensor could be confused by inconsistent or inaccurate height measurements caused by the "dynamic surface of moving, churning water", how can this ever cause the drone to take a swim?

I'm just not seeing it. Please, do a repeatable experiment and post a video demonstrating how this would even be possible.

OK, on to the optical sensor...

 

[Zbip57]

I previously wrote that the optical sensor is only used in the absence of sufficient GPS satellite reception. To which you replied:

This is not correct.
GPS does not have sufficient accuracy to be used for positioning close to the ground. That's the entire reason for the VPS camera.
The crossover point is 10m/33ft. Below that, Optical Flow is used to control positioning in a hover. This is why flowing water can fool the system, in spite of conflicting GPS data, and track moving water a long way, causing a loss of control while hovering.

First off, it's not actually a loss of control. It might be completely unexpected, when you leave the drone hovering in place, to have it suddenly wander away all by itself tracking a floating leaf. But, if you're paying attention, you do still have complete control via joystick input.

It's easy enough to demonstrate the effect of the optical sensor tracking a moving surface. In the absence of sufficient GPS reception, my Mini will rely on its optical sensor to hold position while in a hover (when low enough for the optical sensor to be within range). But I get good GPS reception everywhere within our house, so I had to cover the GPS antenna with aluminum foil to demonstrate this.

This video shows three experiments. With the GPS antenna covered by aluminum foil, and thus insufficient GPS reception, the optical sensor does hold the drone in hover, and it does track and follow the movement of the rug as I slowly pull it away from under the drone. That is as expected.

Second, using the Litchi app, I disabled the optical sensor. With the vision positioning system disabled, and the GPS antenna masked with aluminum foil, the Mini is left in ATTI mode and unable to hold a steady position in hover when the control sticks are released. That's also as expected.

Third, with the optical sensor re-enabled and the foil removed, i.e. both GPS and vision positioning system enabled, which one takes priority? With the Mini hovering over the rug and holding a steady position, will the drone follow the rug as I drag it away? Or will it hold position based on its GPS info?

The surprising results, as shown in this video, are quite conclusive.

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

 

[Droning on and on...]

I previously wrote that the optical sensor is only used in the absence of sufficient GPS satellite reception. To which you replied:

First off, it's not actually a loss of control.

No point in a semantic debate, perhaps we'll just have to agree to disagree.

In my definition of the concept, loss of control simply means the drone is behaving in a way neither expected, nor commanded.

If i expect the drone to hover in place and it starts moving off somewhere without my input, its certainly not flying under my control. The fact I can regain control and stop it doesn't change that.

 

[MS Coast]

The surprising results, as shown in this video, are quite conclusive.

Good stuff! Thanks for taking the time to prepare and post the video.

 

[Zbip57]

No point in a semantic debate, perhaps we'll just have to agree to disagree.
In my definition of the concept, loss of control simply means the drone is behaving in a way neither expected, nor commanded.

Well, yes. It's definitely semantics. But it ties back to the central point of this entire thread.

Too many people report, or repeat, the belief that VPS sensors can somehow cause "loss of control" of their drone, forcing it to go out of control and fall into water. I'm still waiting for anyone to explain and give a clear demonstration of how that can happen.

If i expect the drone to hover in place and it starts moving off somewhere without my input, its certainly not flying under my control. The fact I can regain control and stop it doesn't change that.

In this case, as in so many others, the root cause of not understanding why something unexpected happened can often be traced to a lack of appreciation of how the drone is programmed to operate.

For example, if you take off too quickly from a beach and fly out over the ocean before the drone had sufficient GPS reception to mark a Home location on the beach, you shouldn't be surprised if a subsequent RTH operation lands the drone in the water.

The Home location will only be registered after sufficient GPS satellites are located. If the drone is already out across the water when it marks its Home Location, well, that's just the way it works. If you then press RTH, and go fetch another beer expecting the drone to automatically return to the beach, you cannot later claim that a "loss of control" forced the drone to disappear into the ocean.

The fact that you do have control, being able to cancel RTH, does change that.

Similarly, you surrender control to the drone's automatic features whenever you take your hands off the joysticks expecting it will stop and hover in place. If the drone then wanders off tracking a leaf floating on the water's surface, it doesn't mean you've lost control. The drone is behaving exactly as it programmed to do, and you have the ability to stop its movement at any time by wiggling the joysticks. If you didn't expect it to wander off on its own, it's only because you weren't aware that this is how the drone is programmed to behave.

If the drone is left unattended long enough while tracking a floating leaf, and you weren't paying attention to what was happening, and it drifted into a tree and crashed, you cannot claim it went "out of control".

I do have to thank you. I made this video because I was convinced that I was right, and I was determined to prove you wrong. Instead, I discovered that you are absolutely correct! The optical sensor will track moving objects causing the drone to move while in hover, "in spite of conflicting GPS data"!

I didn't know that before. But I certainly do know to watch out for it now.

 

[Droning on and on...]

Like I said, @Zbip57, not willing to engage in a semantic debate over the minutiae of what an arguably abstract and broad word like "control" means.

 

[MS Coast]

In my definition of the concept, loss of control simply means the drone is behaving in a way neither expected, nor commanded.

If an A300 encounters an unexpected downdraft and descends 100 feet without input from the pilot, should we say that it aircraft is out of control?

 

[Zbip57]

I'll admit I was surprised by the outcome of this video, because I was mistakenly convinced a good GPS fix would override the optical sensor. But it does make sense that (when in range) the optical sensor provides a more accurate means of holding position, unless whatever it's fixated on is actually moving.

At the end of the video, I was trying to figure how high the drone would go before it stopped following the movement of the rug. As the drone went higher, more of the (unmoving) pattern in the interlock brick became visible within the field of view of the optical sensor, compared to the smaller area of the (moving) rug. So at some point it's smart enough to ignore the movement of the rug, and instead fixate on the brick pattern.

Obviously if it's hovering over a uniformly coloured surface with no pattern details, or there's not enough light to make out details, etc then the optical sensor has nothing to fix on.

But if it's hovering over a white floor and an ant walks across within view of the optical sensor, will the drone follow the ant? If it's hovering over a glass calm lake, high enough not to disturb the surface with prop wash, will it see only itself reflected against a clear blue sky? If it sees its own reflection, would it know if it's standing still or drifting, regardless of whatever the GPS data is telling it?

 

[Droning on and on...]

If an A300 encounters an unexpected downdraft and descends 100 feet without input from the pilot, should we say that it aircraft is out of control?

Yes.

That's certainly how I would characterize a similar situation if I were flying a 152.

The pilot then uses control input to try to regain control. If the aircraft continues to exhibit behavior not commanded by the pilot, it is performing uncontrolled behaviors.

Similarly, if a car driving along hits a patch of ice and starts to yaw to the left without changing it's trajectory, I would characterize that as a loss of control. If the driver provides steering input and regains control it doesn't change the fact they did not initiate the slide, don't want it, and are frantically trying to regain control (can't think of a different word to use) and stop it.

I think we've both made our views on this clear, I have no more to say about it.

 

[Zbip57]

If the aircraft continues to exhibit behavior not commanded by the pilot, it is performing uncontrolled behaviors.

This is definitely straying into semantics, but it's kinda fun.

Rather than a car skidding on ice, let's go back to airplanes, specifically one equipped with an autopilot system. The pilot programs the autopilot system to automatically fly to certain waypoints at the desired altitudes, and he then presses a button to engage the autopilot. When he wants his commands executed, Capt Picard says, "Make it so." The aircraft automatically responds to the programmed commands.

If the pilot has incorrectly entered the coordinates or altitude information, the plane will still react to the programmed inputs as it was commanded to do. The pilot might be startled by the unexpected results, but the plane is under "control" of the pilot's programmed inputs. If the pilot goes away for an extended bathroom break, upon return he'll be surprised to find that the airplane isn't heading where he intended. But if instead he, or his copilot, is paying attention, someone will disengage the autopilot to regain manual control. Either way, the aircraft was always under control, either as programmed or as manually steered.

The same thing happens when you take your hands off the control sticks on your drone's controller, when the drone's autopilot system engages as programmed to hold position in hover. The autopilot reacts as it is programmed to do, until you choose to immediately disengage the autopilot by moving the control sticks.

If you're surprised to see your drone has wandered away tracking a leaf floating on the water's surface, that doesn't mean it has gone "out of control". It means you weren't paying attention and you, like myself, were unaware that this is how the autopilot system on your drone is programmed to behave, since the optical sensor apparently takes priority despite conflicting GPS data.

If you were paying attention, you can always stop any undesired movement of the drone and disengage the autopilot simply by moving the control sticks to resume manual control. Either way, engaging or disengaging the autopilot system, you are in control. But if you choose to engage the autopilot, by centering the control sticks, it pays to fully understand how that autopilot is programmed to behave.

 

[charliebicks]

Dear forum, I have messaged Zbip but perhaps someone has the answer to my conundrum.

I was filming the 3 day boat trip from Manaus to Sao Gabriel and was pretty shocked at how difficult it was to land the drone due to the sensors, and I subsequently crashed the drone.

The safe landing feature has often been a danger to landing the drone in the situations I find myself in, such as on a mountain at an incline, or on a moving ferry or boat.

I tried to tape the sensors with black electric tape in order to have complete control of the drone when descending, to nullify the safe landing feature. However I noticed that I was often getting some bizarre problems with descending the drone even 20m above my landing site, as if the tape itself was causing some kind of interference. Therefore this option does not seem viable for the drone.

Therefore I was wondering what might you suggest I do that I may completely nullify the safe landing feature so that I can have complete control of landing the drone. I use the Mavic 3 pro so I don't think the litchi app will work. Thanks!

 

[mobilehomer]

Dear forum, I have messaged Zbip but perhaps someone has the answer to my conundrum.

I was filming the 3 day boat trip from Manaus to Sao Gabriel and was pretty shocked at how difficult it was to land the drone due to the sensors, and I subsequently crashed the drone.

The safe landing feature has often been a danger to landing the drone in the situations I find myself in, such as on a mountain at an incline, or on a moving ferry or boat.

I tried to tape the sensors with black electric tape in order to have complete control of the drone when descending, to nullify the safe landing feature. However I noticed that I was often getting some bizarre problems with descending the drone even 20m above my landing site, as if the tape itself was causing some kind of interference. Therefore this option does not seem viable for the drone.

Therefore I was wondering what might you suggest I do that I may completely nullify the safe landing feature so that I can have complete control of landing the drone. I use the Mavic 3 pro so I don't think the litchi app will work. Thanks!

With the latest firmware and Fly updates, you can switch it off under the Safety tab.

 

[charliebicks]

With the latest firmware and Fly updates, you can switch it off under the Safety tab.

Thanks, I haven't updated since August.