M2P does have dangerous low light VPS problems

[ScrappyMavic]

I like to stress test the low light capabilities of the VPS system and so here's what I did. With both downward LED and obstacle avoidance turned off, I got into a hover indoors in a room with dim-able lights. I slowly decreased the brightness in the room until the drone switched to ATTI mode and lost its position hold. What I can say is that M2P stays in VPS hold mode for way darker conditions than the original MP. However I think DJI pushed their dark VPS aspirations too far. During one of my tests in very dark conditions, the M2P started slowly drifting but didn't switch into ATTI mode. I watched this closely for about 10 seconds of gentle drifting, after which point the drone just rocketed forward full speed and into the wall without any input of mine. I have done this same test on the original MP many times and never had an issue like this. So by allowing the system to run in sketchy dark conditions, I'm guessing something in the VPS firmware overflows or saturates, leading to eventual out of control. The good news is there are many ways to guard against this type of problem in FW (disable VPS at less dark conditions, sanity check VPS command vs. IMU continuity, fix overflow / saturation, etc), and I hope DJI addresses this in the next update.

 

[Kilrah]

That kind of testing is very stupid - dimmable lights typically blink and do so the more you dim them down, and are very likely to cause artifacts and issues on computer vision systems that would not be present in natural low light conditions.

 

[altaic]

That kind of testing is very stupid - dimmable lights typically blink and do so the more you dim them down, and are very likely to cause artifacts and issues on computer vision systems that would not be present in natural low light conditions.

Wow, that’s unnecessarily negative and weirdly dismissive. You’re assuming he’s using LEDs or fluorescents. Instead, how about, “That’s interesting. Are you using incandescent lights? Otherwise, artifacts can arise from the interaction between the camera frame rate and dimming circuits, resulting in vision issues.”

Also, hello. I’m a first time poster and have been lurking for a couple months. This is a great forum with lots of useful info. I look forward to more investigations like this so we can understand the workings of our awesome yet sometimes baffling flying machines.

 

[ScrappyMavic]

That kind of testing is very stupid - dimmable lights typically blink and do so the more you dim them down, and are very likely to cause artifacts and issues on computer vision systems that would not be present in natural low light conditions.

Hey little life tip for you, throwing out "stupid" quickly and easily on a first post really lowers your class. The bulbs are incandescent and produce extremely low flicker do to the thermal time constant of the filament being much longer than 1/60 seconds.

Second, whatever concern you are raising here never caused any issue on original Mavic Pro. Hence I highlight a "new issue". Hard to argue with that.

Third, lets just think if I'm subjecting the drone to some strange artificial conditions. 1) Will it fly indoors? Yes, DJI promotes it. 2) Will there be 60 Hz flicker? Yes all over the US. 3) Will the brightness every be stressed toward the dark end? Absolutely.

So in these totally normal conditions, I'm suggesting DJI should not have the FW fly full speed into the wall. I'm not sure how can argue with that.

 

[Kilrah]

And I don't know how one can expect it not to in such borderline conditions given the way the technology works in the first place. Indoors with no GPS vision becomes the only way for the aircraft to know where it is, so if that fails erratic behavior is inevitable. Hence why me using the "stupid" word - knowing how these things work what you did was just asking for a crash.

You got lucky the time you tested the MP and not when you tested the MP2 - but in both cases borderline conditions for VPS is not something you should operate VPS in.

There are clear indications about that in the manual - which doesn't actually suggest the onboard light is helping aka min brightness spec is the same, and there's an additional warning about "performance may be affected when bottom light is enabled" notice.

Also note the minimum height specced for proper VPS operation is higher for the M2 than for the M1.

You’re assuming he’s using LEDs or fluorescents.

I confess, it's been a decade since I've seen an incandescent in my part of the world.

 

[sar104]

I like to stress test the low light capabilities of the VPS system and so here's what I did. With both downward LED and obstacle avoidance turned off, I got into a hover indoors in a room with dim-able lights. I slowly decreased the brightness in the room until the drone switched to ATTI mode and lost its position hold. What I can say is that M2P stays in VPS hold mode for way darker conditions than the original MP. However I think DJI pushed their dark VPS aspirations too far. During one of my tests in very dark conditions, the M2P started slowly drifting but didn't switch into ATTI mode. I watched this closely for about 10 seconds of gentle drifting, after which point the drone just rocketed forward full speed and into the wall without any input of mine. I have done this same test on the original MP many times and never had an issue like this. So by allowing the system to run in sketchy dark conditions, I'm guessing something in the VPS firmware overflows or saturates, leading to eventual out of control. The good news is there are many ways to guard against this type of problem in FW (disable VPS at less dark conditions, sanity check VPS command vs. IMU continuity, fix overflow / saturation, etc), and I hope DJI addresses this in the next update.

Did you have the auxiliary lower light on for this test?

There are several differences between the Mavic Pro and Mavic 2 VPS systems. In particular the Mavic Pro was optical/ultrasonic, forwards and downwards only, while the Mavic 2 is optical/infrared 3D. What was behind the Mavic 2 in your test?

 

[ScrappyMavic]

And I don't know how one can expect it not to in such borderline conditions given the way the technology works in the first place. Indoors with no GPS vision becomes the only way for the aircraft to know where it is, so if that fails erratic behavior is inevitable. Hence why me using the "stupid" word - knowing how these things work what you did was just asking for a crash.

You got lucky the time you tested the MP and not when you tested the MP2 - but in both cases borderline conditions for VPS is not something you should operate VPS in.

There are clear indications about that in the manual - which doesn't actually suggest the onboard light is helping aka min brightness spec is the same, and there's an additional warning about "performance may be affected when bottom light is enabled" notice.

Also note the minimum height specced for proper VPS operation is higher for the M2 than for the M1.


I confess, it's been a decade since I've seen an incandescent in my part of the world.

I may be beating a dead or injured horse here, but if you have ever worked in engineering, or designed a system or subsystem, you try really hard to make it not "fail erratically". So if there are serious problems in low light conditions with VPS going wonky, you would try really hard to have appropriate firmware thresholds and safeguards to drop into ATTI mode rather than fly full speed into the wall. As I mentioned before, there are many many ways I can think to have the firmware drop into ATTI mode rather than stick in VPS and cause failures. See the OP. This is totally a question of robustness, of reliability, of engineering excellence. In many other places on the M2P, DJI demonstrates extremely reliable and well engineer systems. There is no reason they can't up their game here too.

Also I don't think I got lucky on MP1, and without knowing my background, you are just guessing and waving your hands to cover your lack of class. Over a period of 2 years, I probably flew 50 flights indoors, in fairly dark conditions, with frequent drops to ATTI mode. I never saw wonky behavior and never crashed into a wall. The M2P revealed the problem within 5 flights. Collect some data yourself, do some research, but stop your random criticizing. Thanks!

 

[ScrappyMavic]

Did you have the auxiliary lower light on for this test?

There are several differences between the Mavic Pro and Mavic 2 VPS systems. In particular the Mavic Pro was optical/ultrasonic, forwards and downwards only, while the Mavic 2 is optical/infrared 3D. What was behind the Mavic 2 in your test?

Please see OP.

 

[sar104]

Please see OP.

I was replying to your OP. It didn't address either of my questions, which is why I asked them, and you made no comment on the hardware differences, which is why I mentioned them.

 

[ScrappyMavic]

I was replying to your OP. It didn't address either of my questions, which is why I asked them, and you made no comment on the hardware differences, which is why I mentioned them.

From the OP "With both downward LED and obstacle avoidance turned off, I got into a hover indoors in a room with dim-able lights.". Downward LED == auxiliary lower light. What was behind the Mavic 2? The other wall of the room, about 10 feet back. I'm not sure the forward / backward cam sensors are used for VPS hover. I've not seen any evidence of it. Looks like all bottom to me.

 

[FoxhallGH]

Would also be useful to know the colour/texture of the floor you are hovering over @ScrappyMavic , as that could have some effect on the effectiveness of the VPS? Thanks

 

[lolo780]

I fly in the dark often and would not trust any VPS system. Replace the tripod switch setting with ATTI and fly it like a P4.

RC Groups - View Single Post - Official DJI Mavic 2 ***Owner Thread***

 

[sar104]

From the OP "With both downward LED and obstacle avoidance turned off, I got into a hover indoors in a room with dim-able lights.". Downward LED == auxiliary lower light. What was behind the Mavic 2? The other wall of the room, about 10 feet back. I'm not sure the forward / backward cam sensors are used for VPS hover. I've not seen any evidence of it. Looks like all bottom to me.

Ah - I didn't realize that's what you meant by downward LED. I also don't think that the lateral sensors are used for hover, but it they detect moving obstacles then the aircraft may move. You should pull the mobile device DAT file and take a look at the data and event stream to see if it sheds light on why it moved.

 

[DanMan32]

He had obstacle avoidance turned off so back/front ghost obstacles are out of the picture here. Side OA sensors aren't enabled under normal flight so the're completely out of the picture here, unless it was in tripod mode. Even with ghost obstacles, unless APAS is enabled, AC should just stand still and refuse to move toward the ghost.

I tend to agree, marginal VPS shouldn't cause a sudden move into the wall. I could see drifting to the wall though.

Even with the slow reaction time of an incandescent, a very low dimmer setting can cause flickering as the duty cycle is very low. This would be difficult to determine though, as you'd need a high speed shutter or frame rate to see the flicker clearly, yet the low light would need a slower shutter speed, or very high ISO.

 

[ScrappyMavic]

Ok, I've analyzed the log and V3 DAT and have some updates. It appears the drone had actually turned off vision / VPS 10 seconds prior to the crash, so we can't blame VPS. Sorry for the false alarm. However we can still blame DJI firmware in it's mode switching between VPS and GPS and pure ATTI. Here's what happened:

1) I do this in the basement and expect no GPS. However, this time I did have a number of satellites
2) As I reduced the dimmer brightness prior to crash I noticed no ATTI notification, this was because it was in GPS hold mode after it lost VPS
3) Eventually the drone disables GPS as well (General:gpsUsed == False). At this exact point, the pitch and velocity kick up without any RC control input. This is the point that something really went wrong.
4) I apply full negative elevator but it's too late

It would appear the drone should have entered pure ATTI mode, but instead had something corrupted. I wonder if it was using some wrong / incorrect GPS values as the flyCState == GPS_Atti at the time of crash, when it seems like it should have been just Atti.

Color state here is visionUsed. Vision was off 10 seconds prior to the incident.


Color state here is gpsUsed. The exact point that this transitions to false, the drone pitch and velocity take off.


Color state here is flyCState. The entire time it's GPS_Atti. This seems like a possible issue? Why did it not switch to Atti?


Large plot from the V3 DAT, just showing all RC stick inputs were zero prior to the drone taking off by itself.

 

[sar104]

Those plots are too confusing and lack some essential parameters to understand what happened. I'd also need to see the event stream to follow the sequence. I've no idea what you mean by "pure ATTI mode", or what "corrupted" refers to in this context. I suggest that you stop guessing and post the actual DAT file, otherwise this discussion is rather pointless.

 

[ScrappyMavic]

Here is the DAT.

Here is the flight record TXT.

 

[BudWalker]

Ok, I've analyzed the log and V3 DAT and have some updates. It appears the drone had actually turned off vision / VPS 10 seconds prior to the crash, so we can't blame VPS. Sorry for the false alarm. However we can still blame DJI firmware in it's mode switching between VPS and GPS and pure ATTI. Here's what happened:

1) I do this in the basement and expect no GPS. However, this time I did have a number of satellites
2) As I reduced the dimmer brightness prior to crash I noticed no ATTI notification, this was because it was in GPS hold mode after it lost VPS
3) Eventually the drone disables GPS as well (General:gpsUsed == False). At this exact point, the pitch and velocity kick up without any RC control input. This is the point that something really went wrong.
4) I apply full negative elevator but it's too late

It would appear the drone should have entered pure ATTI mode, but instead had something corrupted. I wonder if it was using some wrong / incorrect GPS values as the flyCState == GPS_Atti at the time of crash, when it seems like it should have been just Atti.

Color state here is visionUsed. Vision was off 10 seconds prior to the incident.
View attachment 54936

Color state here is gpsUsed. The exact point that this transitions to false, the drone pitch and velocity take off.
View attachment 54937

Color state here is flyCState. The entire time it's GPS_Atti. This seems like a possible issue? Why did it not switch to Atti?
View attachment 54938

Large plot from the V3 DAT, just showing all RC stick inputs were zero prior to the drone taking off by itself.

View attachment 54939

I agree, it should have switched to ATTI. In fact it should have always been in ATTI.

In the good old days before the Mavic Pro the P3 would switch to ATTI whenever a navigation problem was suspected. Since the introduction of the Mavic Pro DJI has adopted a strategy whereby the FC will attempt to reconcile navigation problems instead of switching to ATTI. Sometimes that works and sometimes it doesn't.

I think that GPS_ATTI really means that the FC is attempting to navigate using either GPS or the vision system. I've looked at a few incidents were GPS wasn't being used but the vision system was. It was clear that the FC was attempting to navigate and the flyCState was GPS_ATTI.

But, here neither the vision system or GPS was being used when the fly away occurred. You'd think it should have switched to ATTI and not try to navigate.

 

[lolo780]

Reasons to replace Tripod mode with ATTI. The 3 position flight mode switch is one of the great features of the M2.

 

[mavicn00b]

I watched this closely for about 10 seconds of gentle drifting, after which point the drone just rocketed forward full speed and into the wall without any input of mine. I have done this same test on the original MP many times and never had an issue like this

I did this test with my Mavic 1 but I wasnt using dim-able lights, just a simple on/off switch. I just killed the lights with my finger on the sticks and it lunged forward like that until I pulled it back preventing a crash. Its certainly not limited to Mavic 2.
The Spark doesnt have this issue as it uses IR for the forward sensor which works in the dark.