VPS infrared height sensors. What do they ACTUALLY accomplish??

[Zbip57]

I chimed in because of the speed vs. forward pitch discussion.

No argument there either. It makes sense, despite what I had previously incorrectly assumed.

What is your evidence, or reference that indicates VPS optical flow is being used to calculate ground speed, and that it used in priority over GPS when available?

For that you need to read the two forum links in my initial post #1 above. One mavicpilots thread, the other on DJI forum.

In that Chinese river gorge incident the flight log showed near zero groundspeed, despite the continuous GPS track showing the drone moving backwards swiftly downstream. And when the pilot held full forward stick input, the recorded forward groundspeed increased to 10m/s whereas the GPS track showed the drone slowing it's downstream progress to a near stop.

If you accept that, in the absence of good GPS reception, the VPS optical sensor [when in range] will provide position holding, then it should also be capable to use that same VPS positioning data while the drone is moving to calculate its groundspeed, no?

And the VPS actually does take priority [when in range], as shown in my video where I'm dragging the patterned rug under my Mini, even though the drone had a solid GPS connection [which was a big surprise to me].

 

[Zbip57]

What is your evidence, or reference that indicates VPS optical flow is being used to calculate ground speed, and that it's used in priority over GPS when available?

Here's how to do an experiment to test this.

Ideally one could use an underground parking garage to block GPS reception, a garage that is also illuminated well enough to ensure good VPS function. Then try some full speed runs.

In Cinematic C-mode, my Mini is limited to 4m/s (9mph). Check the speed displayed on the app telemetry.

I don't currently have access to such an indoor space, so I'd need to do it outdoors with the top of my Mini covered with tinfoil again to block GPS reception. But it's raining right now.

 

[Droning on and on...]

No argument there either. It makes sense, despite what I had previously incorrectly assumed.


For that you need to read the two forum links in my initial post #1 above. One mavicpilots thread, the other on DJI forum.

Will do. As an aside, always frame any challenge from me like this as purely wanting to understand. I'm an engineer by training, and in my heart, despite moving into management (R&D) through my career.

In that Chinese river gorge incident the flight log showed near zero groundspeed, despite the continuous GPS track showing the drone moving backwards swiftly downstream. And when the pilot held full forward stick input, the recorded forward groundspeed increased to 10m/s whereas the GPS track showed the drone slowing it's downstream progress to a near stop.

If you accept that, in the absence of good GPS reception, the VPS optical sensor [when in range] will provide position holding, then it should also be capable to use that same VPS positioning data while the drone is moving to calculate its groundspeed, no?

I'd deduce exactly the same conclusion.

And the VPS actually does take priority [when in range], as shown in my video where I'm dragging the patterned rug under my Mini, even though the drone had a solid GPS connection [which was a big surprise to me].

Me too. And puzzling. Assuming the GPS fix is without error or horribly inaccurate, seems poor design to use VPS for anything when the two disagree. Rather, this should be a condition that signals VPS is failing due to a problematic surface (not well patterned, moving, etc.), and the system should use GPS instead.

VPS is far better for positioning when it's working. However, there are several well-known failure modes, and switching to GPS when the two disagree seems the better design to me.

 

[Zbip57]

As an aside, always frame any challenge from me like this as purely wanting to understand. I'm an engineer by training, and in my heart, despite moving into management (R&D) through my career.

Same here. I'm also a mechanical engineer. I need to understand why something happens. Even freak flyaways usually have a logical cause. Opinions are okay, as long as they make sense, but a verifiable repeatable experiment is far more convincing.

VPS is far better for positioning when it's working. However, there are several well-known failure modes, and switching to GPS when the two disagree seems the better design to me.

Agreed. I can see why VPS should get priority because it is more accurate. But there really should be a finite limit to how far the drone is permitted to drift before the flight controller realizes the drone has moved away from its original GPS location.

The curious case of the Chinese river gorge incident [sounds like a who-done-it mystery title] was especially odd because the drone initially held its GPS spot in hover until the pilot turned it around switching between video and photo modes. That's when it suddenly decided to drift away downstream. It's not surprising that GPS reception was sketchy in such a deep gorge, but the flight log still recorded a solid GPS track. And then it is the speed limit aspect that I find most disturbing. If he'd been able to manually switch to ATTI mode, then the drone would have ignored both the GPS and VPS position data, without which there could be no "ground speed" limit imposed. In ATTI mode the drone's airspeed would only be limited by it's pitch/roll angle limits.

If I were to repeat my experiment dragging the rug under my Mini, I wonder how far down the driveway it would follow me before eventually, if ever, realizing it had moved from its original GPS location?

 

[SethB]

@Zbip57 I really appreciated the clip with moving the mat in your post #16. That demonstration really tells the story, and I believe it validates your theory about the drone flying the Chinese river gorge.

The next question that comes up for me is whether that behavior would repeat at an altitude of 10’ or 15’ if a couple people were pulling a large rug across the patio? You’ve suggested that it’s a matter of adequately filling the frame of the VPS sensor; that may indeed be true, and/or it may be altitude limited.

I think it's an important question, given the multiple reports of drones diving into the ocean from various heights. Or, do you or others on this thread have ideas, theories etc about the many drones lost? Could they all have been wave action or inadvertent pilot error flying into the surface with unreliable height sensing?

 

[Yorkshire_Pud]

Here's how to do an experiment to test this.

One other potential source of speed data occurs to me. Might the drone carry a mapping of tilt-angle against airspeed in memory or be able to compute air-speed from tilt angle?
It seems to me that such an ability might be the source of wind warnings.

 

[Droning on and on...]

One other potential source of speed data occurs to me. Might the drone carry a mapping of tilt-angle against airspeed in memory or be able to compute air-speed from tilt angle?
It seems to me that such an ability might be the source of wind warnings.

Correct, and this is the source of wind warnings... attack angles that are just completely nonsensical for the measured GPS ground speed.

But you won't see this. Answering for others

 

[Zbip57]

The next question that comes up for me is whether that behavior would repeat at an altitude of 10’ or 15’ [...]

Check the User Manual for your own particular drone. For my Mini it says the VPS has a range [depending on conditions] of up to 30m(98ft) but "works best" between 0.5m(~2ft) to 10m(~33ft). So, definitely the VPS is still solidly within its best range at your 10'-15'.

The next question that comes up for me is whether that behavior would repeat at an altitude of 10’ or 15’ if a couple people were pulling a large rug across the patio? You’ve suggested that it’s a matter of adequately filling the frame of the VPS sensor; that may indeed be true, and/or it may be altitude limited.

At 10' to 15' the VPS is still working strong. It's definitely not altitude limited yet.

It's only a question of how big an area is seen within the field of view of the optical sensor. In my video, if enough of the image is filled by the patterned rug, then the sensor will concentrates on that whether the rug is actually moving or not. Or, if enough of the interloc brick driveway is exposed, then it'll fixate on that and ignore the small rug as it's moving.

I don't know where the threshold is between the rug being large enough or not. But clearly, the higher the drone goes, the greater the area seen by the optical sensor. So, the higher it goes, you'd need a bigger and bigger carpet to fool the sensor.

Similarly, I don't know by what criteria that same optical sensor sometimes chooses to trigger landing protection and label a landing site as "unsuitable". Instead of landing it will stop and hover while the app pops up a message asking for confirmation whether you want to continue the landing or not.

I think it's an important question, given the multiple reports of drones diving into the ocean from various heights.

Early models of the Mini were prone to propeller deformation caused by improper storage twisting and flattening the blade's pitch angle. That led to many unexpected crashes. Search for "uncommanded descent".

Other than that, there is no logical way whatsoever that the VPS could ever cause a drone to dive into the ocean. It just doesn't work like that. Yes, the optical sensor can cause the drone to wander away if you're not paying attention, if it's tracking moving objects, and that could cause it to fly into overhanging branches etc. But there is no mechanism within the VPS system that would ever cause the drone to descend.

At worst, a failure of the VPS height sensor could only ever fail to prevent the pilot from driving the drone into the ground or water if he is accustomed to it normally preventing the drone from lowering closer than 0.5m.

The VPS infrared height sensor can only ever cause the drone to ascend, if it senses anything within 0.5m(~2ft) of the drone's underside. I demonstrated that in the first four videos in this YouTube playlist.

 

[Droning on and on...]

The VPS infrared height sensor can only ever cause the drone to ascend, if it senses anything within 0.5m(~2ft) of the drone's underside. I demonstrated that in the first four videos in this YouTube playlist.

An interesting unintended "feature" this creates is upslope terrain-following, which works pretty well so long as the slope isn't too steep, and you don't try and go too fast.

Used to do this just for grins with my Mini 2, when I had one. It should work with any DJI drone, but somehow it just seemed cool with that deaf dumb and blind drone, who I named Pinball Wizard

 

[Zbip57]

An interesting unintended "feature" this creates is upslope terrain-following, which works pretty well so long as the slope isn't too steep, and you don't try and go too fast.

Exactly. If you fly slowly enough up a sloping driveway (for example), the drone will not come closer than 0.5m(2ft) to the surface of the driveway. The VPS system will automatically keep raising the drone to maintain a constant 2' buffer.

However, when flying back in the opposite direction along a down sloping driveway, the drone will maintain a constant level flight as the driveway drops further away beneath it.

The VPS height sensor can only ever cause a drone to rise if it detects anything within 2ft of its underside. The VPS will never cause it to sink.

 

[Droning on and on...]

However, when flying back in the opposite direction along a down sloping driveway, the drone will maintain a constant level flight as the driveway drops further away beneath it.

Exactly. Hence the carefully chosen term in my post, "upslope"

With the right hillside, it makes for some novel video, especially sped up about 2x.

 

[Zbip57]

I am of the opinion that the IR sensor will, normally, reduce the speed of a fast descent once the ground is detected. I am sure I have seen this in my drones, most likely the mavic 2s and mini 1&2. ..... and that's with the throttle fully closed all the way down to landing.

But at what point during descent from greater heights?

I've never taken notice of numerical value but a qualitative recollection is "quite high", in fact I seem to vaguely remember being surprised how high it looked ......,....,but it was a fair while ago.

I tested it in N-mode (Normal) on my Mini.

The manual for the Mini says VPS range is 0.5-30m, but "works best" between 0.5-10m. So I flew the Mini straight up to 40m to ensure it was well out of VPS range. Then I held the throttle full down for maximum descent speed right until the drone auto-landed.

Then, using the Litchi app, I turned off the VPS and repeated the same test, climbed to 40m, then max descent. But, I manually stopped the descent at the last moment to prevent the drone from auguring into the ground.

Lots of interesting things happened, which aren't all the evident from the video alone. I used @msinger's excellent Flight Reader to plot some data and graphs to better illustrate what's going on.

First, with VPS enabled, on the way up the IMU height (barometric) and the VPS height (infrared) agreed only until 12.2m. After that VPS lost contact and froze at 12.2m, while the barometric altimeter continued recording the increasing height.


On the way down the VPS first detected ground only from a height of 6.5m (21ft) and down.



Here's the data plotted, with the BLUE line showing the barometric altimeter climbing up to 40m height, while the RED VPS height stops recording (flat-lined) at 12.2m.



The GREEN line is the vertical speed with ascent speed shown as negative, and descent as positive [which seems backwards to me]. Max ascent speed was 2.0m/s and max descent fluctuated between 1.7-1.8m/s.

With the throttle stick held full down, the GREEN line is holding at its steady maximum descent speed 1.7-1.8m/, until at 78.4s the VPS comes alive again. It drops from its frozen 12.2m to suddenly show showing a height of 6.5m and falling. Here the line of the RED VPS height again closely overlays and matches the BLUE barometric height.

But interesting stuff starts to happen at 80secs beginning at a height of 2.8m (9ft). Still with the throttle stick held full down, the VPS senses the rapidly approaching ground and starts applying the brakes. The vertical speed bleeds off to zero and very briefly hovers at 0.5m height, before announcing Landing.

The last little blip in the GREEN vertical speed line shows the descent speed briefly increasing from zero (hover) until settling to an auto-landing. Cool.

The weird thing is the divergence between the RED VPS height and BLUE barometric height in the final phase. They are closely aligned, while VPS is active, until the moment at 80sec when the drone automatically started applying the brakes at 2.8m(9ft) to begin slowing its descent. At landing the VPS accurately shows ZERO height, whereas the barometric altimeter shows -1.4m.

Below is the same test with VPS switched OFF. Note the RED VPS height is shown as a continuous flat line at zero height.

The BLUE line displays the barometric height. I was aiming to climb to 40m, but overshot to 45m.

The GREEN line [again counter-intuitively] displays ascent speed as negative and descent speed as positive. So the squiggly GREEN line at top right is displaying constant max descent speed, again fluctuating between 1.7-1.8m/s, with a corresponding decline in height shown by the BLUE line until 110secs when I chickened out and released the throttle stick at a height of 1.6m (5ft).

Obviously without VPS providing auto-braking, had I continued to hold the throttle down the drone would have smacked straight into the ground.



Note the BLUE line, barometric altimeter, after I stopped its descent and then manually lowered the drone to landing. It briefly recorded a "height" of 2.4m below ground! I think that's due to the ground effect buildup of propwash pressure trapped between the drone and ground. The barometer interprets increased pressure as lower altitude.

There's one other thing to watch out. In any auto-landing with VPS enabled as normal, at the last moment before touchdown the gimbal automatically pitches the camera back up to horizontal. That doesn't happen when VPS is disabled!

I had the camera aimed straight down, and it stayed like that. With the camera pitched straight down, there's very little clearance between the ground and camera's lens. If you ever try disabling the VPS on your drone, make sure to rotate the camera back up from vertical before landing because any pebble on the ground might scratch your lens.

Here's the video. @Yorkshire_Pud, I added CC captions for ya.

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

 

[Yorkshire_Pud]

On the way down the VPS first detected ground only from a height of 6.5m (21ft) and down.

Hmmm I've never checked a log for such numbers but my "eyes on the drone" impression is that it was higher than that. I can't remember with certainty which model of drone that flight was made with.

Then, using the Litchi app, I turned off the VPS and repeated the same te

You brave chap lol. Of course providing you remember VPS is off and are prepared to manually reduce the descent rate or give upstick it's safe enough but if you forget ......... curtains.
BTW did you remember to switch VPS back on ?
I don't know if the Litchi setting will carry over to FLY but using Litchi again it could be an unpleasent way to find out that you had forgotten to switch it back.

at the last moment before touchdown the gimbal automatically pitches the camera back up to horizontal. That doesn't happen when VPS is disabled!

That I didn't know, thanks!!!!! but 9 times out of 10 I hand catch.

 

[Zbip57]

BTW did you remember to switch VPS back on ?
I don't know if the Litchi setting will carry over to FLY but using Litchi again it could be an unpleasant way to find out that you had forgotten to switch it back.

The VPS setting and other options such as RTH height configuration are stored on the drone and thus carry over between whatever app is being used.

So, yes, it's VERY important to remember to go back to Litchi when done to reset VPS to enabled.

It's sad that DJI doesn't include these useful options in the Fly app. By denying access, they're trying to make their systems "idiot-proof". How's that working out?

I can't say enough good things about Mike Singer's Flight Reader program. That's a very useful diagnostic tool. Try it for free for 7 days, but well worth the small one-time investment to show support for all his hard work.

 

[Yorkshire_Pud]

So, yes, it's VERY important to remember to go back to Litchi when done to reset VPS to enabled

Been caught by 'forgetting' with both the failsafe and emergency motor stop settings when 'messing about' WHOOPS, fortunately without consequences.

Try it for free for 7 days, but well worth the small one-time investment to show support for all his hard work.

I already use flight reader for my own logs.

 

[Zbip57]

I've never checked a log for such numbers but my "eyes on the drone" impression is that it was higher than that. I can't remember with certainty which model of drone that flight was made with.

That's certainly possible. It stands to reason that a heavier drone and/or higher descent speed would require the drone to begin earlier and higher to brake its descent.

 

[Droning on and on...]

It's sad that DJI doesn't include these useful options in the Fly app. By denying access, they're trying to make their systems "idiot-proof". How's that working out?

Not to be argumentative, but I suppose the answer depends on what capability the idiots are being protected from.

In this case I suspect it's working quite well