Help understanding crash on a balcony

[mobilehomer]

First - RTFM, many times, especially the italicized and bold sections. Then PRACTICE slow maneuvers. There are no DJI drones that use the Fly app that disable the VPS regardless of the OA condition.

 

[Meta4]

I agree, but I do not believe that slipping out of P-GPS mode caused the crash, because I saw no unstable behavior nor ATTI mode at take off and during the first minute of the flight, which happened in the same environmentaL conditions and no GPS.

Losing GPS does not cause a crash.
How you handle the drone without GPS could well cause a crash.
Atti Mode doesn't cause "instability".
The drone will maintain height and is perfectly controllable.
The data suggests that you had VPS for the first 22 seconds of the flight while on the balcony and then zoomed off into the distance, without GPS or VPS until 1:15.8.

This is a very interesting observation that escaped me at first, i.e., that drifting towards the wall was being prevented by the OA system. However, as I said above, I do not believe that losing GPS brought the drone directly into ATTI mode

You might not believe it but without GPS or VPS, the drone is in Atti Mode.
Atti Mode is P-GPS without GPS.

, both because of my visual recollection and because a summary look at the logs shows that GPS was lost after 8m26.5s of flight and ATTI mode was entered after 8m42s.

Your GPS reliability dropped below the necessary 4/5 from 8:11.0 and within a couple of seconds (8:14.3) the drone was in Atti Mode.
The Phantomhelp data is misleading, continuing to show P-GPS for the flight mode even though GPS is not used.

Moreover I believe OA is disabled by default in ATTI.

It's not disabled. It just can't work without VPS or GPS.

This article, for example (even though not directly from a DJI source), claims that in Sport mode, where OA is disabled by default, " if you're flying along in Sport mode and lose GPS for some reason, the drone will enter ATTI mode (as VPS was already disabled)".

VPS isn't disabled in Sport Mode.
It just can't function properly at the increased tilt angle used in Sport mode.
But this is largely irrelevant because VPS has a very limited height range anyway.

However, I see absolutely no good reason for a software implementation in which OA is switched off by switching off the vision system.

Obstacle avoidance is not disabled by switching off VPS.
But if you disable VPS and fly in a spot without GPS and where VPS would have functioned properly, that's your problem.

 

[Meta4]

However, it keeps the question of what went wrong in my case still open. It possibly points at an independent failure of P-OPTI after OA was disabled.

What went wrong is quite clear.
P-Opti did not "fail", the drone was never in P--Opti.
It was in Atti Mode and so had no "brakes".
You weren't aware of this or the implications and used full stick joystick inputs with obstacles close by.

 

[Meta4]

The point I was making is that the article implies that disabling OA implies disabling VPS.

The article is incorrect.

In this case however, it seems the jury is still out on whether disabling OA when GPS is lost disables VPS.

Your imaginary jury doesn't know the facts.

 

[Yorkshire_Pud]

or do they correspond to empirical observations? And also do they represent a static error (i.e., the drone went to a stable position whose distance from the commanded is given by those numbers) or was the drone sort of oscillating around the commanded position with an amplitude of oscillations given by those numbers?

Empirical, the drone being at eye level or only slightly higher and in a hover, so that I could see the movements.
The drone would move from the chosen point in random directions but never more than the estimated distances from the chosen point of hover.
Just as a matter of interest I have left a Mavic Mini hovering indoors (no GPS) unattended for maybe 5 minutes and when I came back it was were I had left it.
I would also say that with the Mavic Mini and perhaps the M2P the VPS is good enough to detect and respond to flapping cloth or paper etc. that is within the VPS's field of view.

I can vouch for the fact that sports mode DOES NOT disable VPS, on the occasions I have flown the M2P indoors I am normally troubled by the upward looking OA sensor detecting the ceiling.
In fact it once prevented lift off when I was attempting to take off from somewhere maybe 1m below the ceiling.
After switching to sports mode the M2P still has position holding and braking indoors though, due to space limitations, I use only slight movements of the joystick.

Totally off topic but the upward looking OA sensor seems to be given a great deal of authority. I have been able to force an M2P/Z to the ground by lowering a hand over the sensor and, from memory, it pushed the drone into the landing protection 'zone' without triggering a landing.

 

[Heavydpj]

Aggressive joystick input + no brakes is a bad move when the drone is close to obstacles and that's what caused your crash.

IMO, this is really what it comes down to.

I launch and recover my drone to my balcony all the time, sometimes while playing the Imperial Death March in my head. I do it completely manual, because I know I'll lose GPS once I get under the roof. I've also done it at night ...

Typically, I'll bring it in to just outside my balcony in a quick holding hover while I switch to Cine mode and bringing her in nice and easy. Sometimes there may be challenges with squirrely winds, but only at the threshold of the balcony. Once it's safe inside, it's actually fairly easy to control.

 

[CodaDiLupo]

Your imaginary jury doesn't know the facts.

Lol, someone got out of bed the wrong side, apparently. While I do appreciate your help, I'm not a big fan of the line by line bickering typical of online forums, so while I will try to reply to all the points you make (at least to the relevant ones), I will do so in the context of a more articulate discussion. In other words, I will be long and boring and not as catchy as your one-line zingers.
My perspective on why the claims you make do not correctly explain what happened are based both on the drone flight modes and on experimental data. An important point to keep in mind is that being present at the event, I got a unique, privileged perspective of what can explain well what I saw happening and what not so much. And, BTW, yes, my jury is imaginary. It's called a metaphor.

Losing GPS does not cause a crash.
How you handle the drone without GPS could well cause a crash.
Atti Mode doesn't cause "instability".
The drone will maintain height and is perfectly controllable.

You might not believe it but without GPS or VPS, the drone is in Atti Mode.
Atti Mode is P-GPS without GPS.

Sure, an icy road does not cause a crash, but how you handle the car on it that might result in one. I am a firm believer in the use of shortcuts in communication, when the implicit logic behind them is very obvious. I guess in this case it wasn't that obvious, but luckily you got what I meant about the loss of GPS.

Now to the key point of disagreement. While I want to completely reassure you of my unshakeable belief that "without GPS or VPS, the drone is in Atti Mode" (which I wrote clearly when I summarized the drone's theory of operations in my first reply on this thread), this is NOT equivalent to saying that "ATTI Mode is P-GPS without GPS". The latter is in my opinion is a very misleading statement, given the fundamental differences that exist between P-GPS and ATTI.
Believe it or not, the essential difference between the two modes is not the presence/lack of GPS, it is the presence/lack of feedback control. If anything, it is much more meaningful to say that "P-OPTI is P-GPS without GPS" (but with VPS, of course), because P-GPS and P-OPTI are essentially twin modes in which the drone operates under stabilizing closed-loop control that makes sure that its horizontal position track the joystick command from the pilot and that external disturbances that would change the desired trajectory are compensated. The only difference between these two modes is in the sensors they use to compute the drone position, which allows them to be used complementarily. For this reason, a switch between these two modes (even though it likely involves complicated technical details like coordinate transformations) has no stability implications, and at most might result in a loss of precision, as @Yorkshire_Pud documented.
Completely different is the switch from any of these two modes to ATTI, which happens when neither GPS nor VPS signals are good enough to provide a position estimate. Without a position estimate, clearly the feedback loop cannot be closed, and hence open-loop operations are forced.
It cannot be stressed enough how closed-loop and open-loop operations are fundamentally different because in open loop, the horizontal dynamics of the drone is unstable, meaning that given an initial excitation to the drone, like a burst of wind, and with the joystick input set to zero, its horizontal position will start drifting in time. Of course the drone is controllable and that drift can be counteracted by properly operating the joystick. However, controllability is a very different property than stability and flying operations in ATTI mode are inherently unstable. It is important to keep in mind that in ATTI mode also the physical effect of a joystick command is different than it is in P-GPS/P-OPTI. In these two closed-loop modes, when the pilot moves the joystick lever he transmits a position command in a certain direction. It is the control system that, based on that command and on its estimate of the current position, determines how much current to send to each motor to produce the necessary torque that results in the propeller action that is needed to reach the commanded position. In open-loop mode, there is no estimate of the current position because both GPS and VPS are off, so the controller cannot perform any of these computations. As a result, when the pilot moves the joystick lever in a certain direction, he is directly setting the level of current that is sent to the corresponding motor. Unless he has a perfect knowledge of the electromechanical characteristics of the motors and the aerodynamical properties of the drone, the command he sends won't be the one needed to bring the drone where he wants, so he will have to adjust. In other words, the pilot becomes the closed loop controller that commands the motors based on his visual assessment of where the drone is vs. where he wants it to be. Since normally an average drone pilot cannot match the speed of an electronic controller, nor has a sophisticated array of sensors to count on, what follows is all but a smooth flight, with continuous overshoots, overcorrections, and the likes, which gives the feeling that you refer to as "having no brakes" (incidentally, in order to break in open-loop mode you need to explicitly move the joystick lever in the opposing direction of that of motion, to generate negative current that counteract the forward inertia that persist after you brought back the joystick to the zero position).

It is exactly this transition from stable closed loop to unstable open loop that makes every mode switch from P-GPS or P-OPTI to ATTI an inherently risky moment, because it gives rise to a sudden transient behavior in which the drone starts drifting horizontally with a velocity depending on external factors like wind strength to which the pilot needs to react with urgency to avoid a potential crash (it's not the switch that causes the crash!). How much urgency is needed depends on wind strength, its direction, the distance from nearby obstacles and the "bandwidth" of the pilot as a human controller.

This lenghty preamble is important to understand what happened during my flight

What went wrong is quite clear.
P-Opti did not "fail", the drone was never in P--Opti.
It was in Atti Mode and so had no "brakes".
You weren't aware of this or the implications and used full stick joystick inputs with obstacles close by.

I decided to start this thread because I experienced a crash that opened my eyes to how unexpectedly a transition to open-loop mode can happen and as a consequence I was looking to gain more insight on the conditions that trigger it either from people who have been in a similar situation or from people who have a better familiarity with analyzing flight logs. I already know that the crash was ultimately caused by where I chose to fly out from and return to and by my inability as a human controller to avoid it after the unexpected switch to ATTI. Hell, I even wrote it myself at least twice in here. I don't need to be told that as if it was a great discovery. If that is what satisfies your curiosity, that's great, just let me decide what is that I am looking for in this discussion.

Onto the flight data:

The data suggests that you had VPS for the first 22 seconds of the flight while on the balcony and then zoomed off into the distance, without GPS or VPS until 1:15.8.

P-Opti did not "fail", the drone was never in P--Opti.

The plots below are generated from the flight log analyzed with CsvView
The first plot shows the flight modes as nominally reported by the log, with the drone entering P-GPS mode immediately after flying off the balcony at 4.9s and staying in that mode until it enters ATTI mode at 522.1s, a handful of seconds before the crash.

This is obviously misleading because we know that GPS is not present during the first minute+ of flight by the fact that the home point does not get set until 1m16s. However, even if known to be misleading, the info plotted above is what you have relied upon to make the two claims quoted above, i.e., that P-OPTI was not the mode used whenever GPS was unavailable, both at the beginning and at the end of the flight. You need these claims to make a third one, i.e., that the whole initial portion of the flight from the balcony to where GPS kicked in was in ATTI mode. The reason why you need this third claim is clear: if ATTI was not entered on the way out of the balcony, it is much harder to motivate that ATTI was entered on the way back because of the small number of satellites seen at that location. The number of satellites is of course the same while exiting or entering the balcony in a time span of 8 minutes, so if a low number of them were the trigger, ATTI should have been entered in both situations. This is where the "priviliged perspective" that I mentioned at the beginning comes into play: being the pilot I know very well that ATTI was never entered during the initial portion of the flight, because for all I said above piloting an open-loop drone is VERY different than piloting a closed-loop controlled one and there is no way that one could perform either of them not realizing the drone was in the opposite mode (ATTI is NOT P-GPS without GPS!).
This is the certainty that told me your claims do not explain what I saw and after discovering that the flight log carries the signals gpsUsed and visionUsed, I can now prove it with the plot below, where the colored regions are marked by the flight mode used in that time interval.

The situation is almost perfectly specular on the way out and on the way back: when not enough GPS satellites are available, the drone operated under stable closed-loop optical feedback, which was replaced by GPS feedback during the central portion where enough satellites were available and went back again to optical feedback as the approach to the balcony led to the loss of satellites (caveat, as a figure of speech, the drone did not own nor lose satellites). What destroys the perfect specularity is the switch to ATTI mode at the very end.

The last pic provides zooms into the situation at the end of the flight.

With the drone at most a couple of meters away, hovering in P-OPTI, I disabled OA at 515.1s. As mental sanity would have it, this does not cause an immediate loss of VPS, as P-OPTI lasts for about 5s more. What happens next is quite puzzling though, because there is a very unexpected switch from P-OPTI to P-GPS. Unexpected because it happens at the location where the satellite count is at its minimum. Maybe the result of a sudden deterioration of the VPS signal? However, it's clear that P-GPS mode cannot be sustained at that location and in fact after about 2s there are 0.2s in which neither GPS nor VPS is available, causing the drone to switch to ATTI mode.

This seems to corroborate my hypothesis that what triggered the switch to ATTI was a sudden deterioration of VPS performance (even though it did in a rather tortuous way, by going through P-GPS with insufficient satellites) . It is still rather puzzling to me that, after having such done a fine job subbing for GPS for extended portions of the flight both near the balcony and far from it (i.e., at different flying heights) VPS suddenly fails at the most delicate moment, shortly after OA was deactivated, when there was no safety net to protect from a crash.

 

[CodaDiLupo]

IMO, this is really what it comes down to.

I launch and recover my drone to my balcony all the time, sometimes while playing the Imperial Death March in my head. I do it completely manual, because I know I'll lose GPS once I get under the roof. I've also done it at night ...

Typically, I'll bring it in to just outside my balcony in a quick holding hover while I switch to Cine mode and bringing her in nice and easy. Sometimes there may be challenges with squirrely winds, but only at the threshold of the balcony. Once it's safe inside, it's actually fairly easy to control.

Thanks for your perspective. Considering your level of success repeating this maybe you should switch to playing the Triumphal March from Aida in your head ;-)

Since you are writing in this forum, I assume you have a Mavic 2 as well. I am not familiar with Cine mode. Does it provide a workaround for switching to full manual mode (ATTI) that in Mavic 2 is not explicitly possible?

In this related thread people who fly a Mavic Air 2 suggest to approach the balcony sideways, as that drone has no lateral OA system.

 

[Meta4]

I will do so in the context of a more articulate discussion. In other words, I will be long and boring

And that's where you lost me.
I've already put considerable time and effort into analysing your flight data and answering your wordy questions.
I don't have the time or interest to wade through the essay you've come back with.

And I stand by the analysis I've given you.

 

[Kilrah]

VPS suddenly fails at the most delicate moment, shortly after OA was deactivated, when there was no safety net to protect from a crash.

As mentioned VPS is a complex vision-based system, and the detailed workings of that are out of our reach so the "it was available or not" is all we get, and the only thing a pilot can and should do is go with "it's a nice tool when it works, but it may become available at any time with no clearly understandable reason", that's just how it is - although as mentioned the balcony situation is pretty clearly prone to making it fail because it isn't hard to understand that it's far less than an ideal situation to base vision-derived information from.

To illustrate the complexity the volume of logs for the vision system alone is bigger than for the whole rest of the aircraft when exported through Assistant - but unlike for aircraft logs there are are no tools to make anything out of them outside of DJI.

 

[CodaDiLupo]

And that's where you lost me.
I've already put considerable time and effort into analysing your flight data and answering your wordy questions.
I don't have the time or interest to wade through the essay you've come back with.

And I stand by the analysis I've given you.

No worries. Thank you very much, I appreciate the considerable time and effort you put into your pronouncements and it would only be unfair to expect you to take upon yourself also the much harder task of debating and substantiating them.

 

[mobilehomer]

No worries. Thank you very much, I appreciate the considerable time and effort you put into your pronouncements and it would only be unfair to expect you to take upon yourself also the much harder task of debating and substantiating them.

Not that Meta needs support, but he is one intelligent, EXPERIENCED expert. His experience is well worth heeding. But, that's on you. I am not as well versed as he, but even I know that in order to land on a balcony, one must disable OA and come in slowly. Also the air currents set up by the props can wreak havoc on stabilization. Learn from your mistake.

 

[Yorkshire_Pud]

Does it provide a workaround for switching to full manual mode (ATTI) that in Mavic 2 is not explicitly possible?

With an M2P/Z there is, as far as I know, no official way of manually switching (as in throwing a switch) to ATTI mode. The Phantom 3 has it but that is an older drone.
The software "DroneHacks", or similar, might offer a way to replace cine mode with a switched ATTI mode.

Speed limitations etc. aside, cine mode activates the sideways looking OA so it would be even more restictive when used in an approach to a building's balcony.

Since you say the flight was in daylight I am left wondering if the drone was too high above the surface/ground beneath it for the VPS to successfully work or, could the ground have been in shadow when compared to the ambient lighting around the drone? Since VPS uses, I believe, 'cameras' to see the ground using visible light I am wondering if and how well, they can see into shadow. Maybe, if the drone had been able to get closer to the building before it lost GPS, the VPS could have 'locked onto' the balcony.

I think you problems started with having OA on during the landing-phase / approach-to-the-building. DJI switch it off during automated landing, they preumably do so for a reason, and my experience says that, during landing/approach, it varies from being a nuisance to a down right liability.
As for why VPS did not work for you my third paragraph contains the only ideas I have.

BTW I flew an indoor flight (no GPS) with a M2Z yesterday and the csv's of log, produced by Phantomhelp and CsvView, shows the flightmode/OSD.flycState to be P-GPS & GPS-ATTI respectively whilst the drone was in P mode, (flight mode switch centred).

 

[Meta4]

it would only be unfair to expect you to take upon yourself also the much harder task of debating and substantiating them.

I have explained and explained further and substantiated.
I won't get into an extended "debate" with someone who wants to ignore basics and debate the way he would like to think that things work.

 

[Grandpa]

I have explained and explained further and substantiated.
I won't get into an extended "debate" with someone who wants to ignore basics and debate the way he would like to think that things work.

As I have mentioned in other posts, you can only lead a horse to water. You can’t make him drink it.

 

[CodaDiLupo]

As mentioned VPS is a complex vision-based system, and the detailed workings of that are out of our reach so the "it was available or not" is all we get, and the only thing a pilot can and should do is go with "it's a nice tool when it works, but it may become available at any time with no clearly understandable reason", that's just how it is - although as mentioned the balcony situation is pretty clearly prone to making it fail because it isn't hard to understand that it's far less than an ideal situation to base vision-derived information from.


- but unlike for aircraft logs there are are no tools to make anything out of them outside of DJI.

Hi @Kilrah, you are touching some of the core issues that I was planning to look into. i.e., what are the signals available in the flight logs that allow to monitor the status of the VPS during flight and what are the trigger conditions to switch in and out of P-OPTI.
I am relatively new to analyzing DJI flight logs and I have already realized that is somewhat more of a learnt craft than an exact science, as different tools provide different data (for example here I attached the csv file produced by CsvView, which has much more columns than that from phantomhelp generated from the same txt log) .

You mentioned in an earlier post how the behavior of vpsHeight gave a clue of a non-working VPS system, and it is indeed a very weird behavior (in the pic below OSD.vpsHeight, which is called OSD.sWaveHeight by CsvView, is shown in comparison to two other height measurements).


However, despite this behavior the logs indicates that the vision system was active for horizontal control when GPS was not available and, not knowing the control algorithms, it is unclear to me how the height signals influences horizontal position control.

So as you said, a lot of unknowns about VPS, and very few signals seem to be present in the csv files.
However, at the end of your post you mention that there is a way to get more VPS-related signals exporting the log through Assistant but that only DJI can perform analysis on them. Can you please give me some more info on that?
Thank you for your help.

EDIT: I had forgotten the attachment

 

[Kilrah]

Can you please give me some more info on that?

Not really, you connect the aircraft to Assistant, there's an Export logs function, and that puts out massive files that are encrypted and you can't do anything with other than send to DJI if they ask for them.

 

[CodaDiLupo]

I have explained and explained further and substantiated.
I won't get into an extended "debate" with someone who wants to ignore basics and debate the way he would like to think that things work.

I will not get into a debate either with someone who explictly stated he did not even bother to read what I wrote.
In regards to substantiation, I have not seen any log-based evidence you presented to claim that P-OPTI was not entered after P-GPS at the end of the flight nor that ATTI was entered after leaving the balcony.
If neither you or @Grandpa will present it, I rather take my chances to look for my own source of water and not find one, than drink from one that does not look clear.

 

[Yorkshire_Pud]

Note that you need to use at least* the correct version of the Assistant 2 for the drone. But at Kilrah says, those logs are of no use to you, you can't read them,.......which is a great pity.

* I do not know if versions of the Assistant 2 that are designed for use with later drones are backwards compatible......

 

[CodaDiLupo]

Not really, you connect the aircraft to Assistant, there's an Export logs function, and that puts out massive files that are encrypted and you can't do anything with other than send to DJI if they ask for them.

Gotcha, only encrypted output comes out. In regards to DJI resources, it seems that the FRAP system mentioned in this post might be of interest