DJI Mavic, Air and Mini Drones
Friendly, Helpful & Knowledgeable Community
Join Us Now

Help understanding crash on a balcony

Status
Not open for further replies.

CodaDiLupo

Active Member
Joined
Sep 13, 2018
Messages
42
Reactions
0
Age
56
Hello,
I would appreciate if anyone could help me get a better understanding of what I did wrong that caused a crash of my Mavic 2 Pro on the balcony where I was trying to land it. I was maneuvering the drone towards the balcony, when, at about a couple of meters of distance, it stopped its forward motion and started hovering without responding to my input command to move closer. In a previous occasion that I had experienced that, the drone was at arm's length, so I had just grabbed one of the plastic "feet" under the motors and moved it on top of the balcony floor This time it was not possible, so my reaction, attributing the refusal to proceed forward to some conservative judgment of the obstacle detection algorithm, was to disable it and then move carefully the drone towards me. However, what happened was totally unexpected by me: as soon as I disabled the obstace detection system, the drone stopped hovering and started rapidly drifting diagonally towards the wall on its front left. The velocity of this drift and my complete surprise conjured to make my reaction useless to stop the drone before it hit first the wall and then the floor.
From the logs I see that as soon as I disabled obstacle detection, the drone entered ATTI mode, in which (from what I read) the drone is far less maneuverable, which would partially explain what happened, even if not completely as the suddenness and the speed with which drone moved seemed as if it was commanded in that direction. I have many questions, whether the switch to ATTI mode caused the crash, whether that mode switch is automatic when disabling obstacle detection or if some other factors played a role (like a weak GPS signal).
However besides the postcrash forensics, I think the main learning from me would be to understand the best way to maneuver the drone back to a home point located on a structure with the characteristics of a balcony, i.e., a space enclosed by a low front wall, a tall back wall and a ceiling but with an opening that is large enough for a safe entrance.
I am attaching a few log files into a zip for analysis, and the link to AirData. Please let me know whether additional info is needed.
Thanks
 

Attachments

  • flightLogs.zip
    637 KB · Views: 23
From the logs I see that as soon as I disabled obstacle detection, the drone entered ATTI mode, in which (from what I read) the drone is far less maneuverable
Just a small, but important distinction in that statement: When the aircraft is in ATTI mode, it's not less maneuverable—it is simply manual control and not locked to position via GPS when you let go of the sticks. If you had expected to be in ATTI mode (and you have experience flying in ATTI), it would have been quite maneuverable via stick action, albeit requiring more stick action to keep it in place or keep it from hitting an obstacle (I would call that 'requires more attention' than 'is less maneuverable').

However, turning off obstacle avoidance should not have turned it to ATTI. If you already had lost enough satellites to not have GPS lock, you would have already been in ATTI. Perhaps you were, but it wasn't hitting the wall because obstacle avoidance was providing enough back control (I've not tested obstacle avoidance in ATTI mode, so I'm not sure if it works).

All of that said, I personally wouldn't have made the choice to land ON (and I assume take off) from a balcony if you had a choice aside from mere convenience. It sounds like you've already had experience ("In a previous occasion") to know that doing so was with some risk. Yet you did it again and got differing, though still troubling, results. If you have some real need to train for this (search and rescue), that's a different thing, of course.

Chris
 
Last edited:
Hello,
I would appreciate if anyone could help me get a better understanding of what I did wrong that caused a crash of my Mavic 2
A few GPS basics will help understand the incident.
GPS gives your drone its horizontal position holding ability and gives it "brakes".
The drone knows where it is and where it should be so it can resist wind and hold position.
Without GPS, the drone will just drift on the breeze and continue moving when you take your hands off the joysticks.

To have good GPS reception, the drone needs to be able to receive transmissions from enough sats spread across enough of the sky.
If you fly from a site where a lot of sky is blocked off, the drone can't receive signal from sats in the blocked off part of the sky.
Block off enough sky and you lose the benefits of GPS and the drone is now in Atti Mode.
The drone doesn't "switch" to atti mode.
Atti Mode is what's left of P-GPS Mode when there aren't enough satellites.

In Atti Mode, the drone is fully controllable, very manoueverable, but has no brakes, so it requires careful and gentle joystick input if flying near any obstacles.

In this flight, your drone had poor GPS reception right from the start, presumably because the balcony site had a very restricted skyview.
This meant that the drone couldn't receive signal from many sats, and those that it could were likely bunched in the same small piece of sky and unable to provide a good spread that is required for accurate position data.

You launched without having GPS reception, and flew until 1:13.8 when it started to get approximate location data.
At 1:16.5 the drone managed to get slightly better GPS reception and just enough sats to record its homepoint (an unknown distance from where you launched).
The drone can't measure speed or distance until it has good GPS.

As you flew further away from the building, the drone had a bigger skyview and increased the number of sats it could receive.
From about 8 minutes, you were bringing the drone back in to where the sky was blocked and the sat numbers came down.
At 8:11, the flight controller reported that the GPS reliability was no longer acceptable and a few seconds later the drone was in Atti Mode, without position holding ability or brakes.
You left it drifting for 25 seconds before making a few full stick joystick inputs at 8 45.5 (maybe to avoid and obstacle ?).
Aggressive joystick input + no brakes is a bad move when the drone is close to obstacles and that's what caused your crash.

However besides the postcrash forensics, I think the main learning from me would be to understand the best way to maneuver the drone back to a home point located on a structure with the characteristics of a balcony, i.e., a space enclosed by a low front wall, a tall back wall and a ceiling but with an opening that is large enough for a safe entrance.
The best way would be to fly from somewhere that allows the drone to have a full skyview.
That way you will have a drone that doesn't drift or skid through space and it will stop when you want it to.

Flying from this balcony is likely to cause more problems in future and they could end up being worse for you and/or the drone.
 
What they said. Plus a balcony being a very small space leaves very little rook for margin of error. As even the return to home function is not very precise if you don't prepare for it in advance. When the GPS can be off by 2 or 3 feet. Most of the stability is in the GPS and visual positioning (when it can see a clear distinguish surface below it).

The extra risk is that if you have to take off but can't go straight up, return to home if activated is going to crash into the building or whatever structure is above the home point.

In a nutshell... Don't take off from a balcony.
 
The extra risk is that if you have to take off but can't go straight up, return to home if activated is going to crash into the building or whatever structure is above the home point.
RTH can't work without GPS, but because he couldn't get GPS at the launch point it wasn't until 1:16 before he got GPS and the drone could record a homepoint,
Because of this, the homepoint recorded was 1200 feet north of the launch point.
If RTH was used it would have taken the drone there, well away from the flyer.
 
RTH can't work without GPS, but because he couldn't get GPS at the launch point it wasn't until 1:16 before he got GPS and the drone could record a homepoint,
Because of this, the homepoint recorded was 1200 feet north of the launch point.
If RTH was used it would have taken the drone there, well away from the flyer.
Yep that too. I wouldn't take off without getting a good GPS lock. Could end up having the rth being just 12 feet off the balcony and not even realize it.
 
Was this flight really 14 months ago?
If you have not used the drone since then or at least charged the drone's batteries there is a fair chance that the batteries are dead and the same might apply to the controller.

2 points in addition to the above posts.

1) it is good idea to switch OA off as the drone nears the home point or you start the landing phase. OA can cause all sorts of problems at such times, as you and I have found out. It very nearly caused me to crash my first M2P drone on my first flight with it, it was a second hand drone and the previous owner had left OA on and I had not switched it off, my mistake.
If nothing else it could detect you and in this case I would guess it detected the building and did what it is supposed to do, it was not "conservative judgment of the obstacle detection algorithm".

2) The drone has a visual positioning system that is more accurate than GPS ..... PROVIDING that the ground is within range of its sensors and there is sufficient light for the VPS to work. In the absence of sufficient GPS this does give the drone position control using visible 'landmarks' but according to a google, sunset in Cancun on 15/08/2021 was 19:17 and the flight seems to have been sometime after 22:00.
If that is correct then the flight was probably in darkness and the VPS could not work.
I would guess the drone was outside the light pool from windiws in the building when the accident started.
 
Last edited:
Thanks for all the feedback. I took a little while to reply because I wanted to think through all you guys wrote. If I understand correctly the operations of the Mavic 2 Pro, in the P-GPS mode the drone is under closed-loop position control in the "horizontal" plane, where the (x,y)-position that is fed back is computed from the GPS signals. In order for this to work properly, the drone needs to "see" enough satellites. As the number of satellites seen by the drone decreases, the computation of the (x,y)-position starts becoming more inaccurate until the position estimate is deemed so inaccurate that the system has to switch mode. If certain conditions are satisfied (e.g, there is enough light, the flying height is relatively low and so on) the drone enters P-OPTI mode, which has the same closed loop control structure as P-GPS with the only difference that the drone position is not reconstructed from the GPS signal but from the drone's visual system signals. If conditions for P-OPTI are not satisfied, the drone enters ATTI mode, which is basically open-loop control in which the external disturbances (like wind) are not anymore automatically compensated but it's the pilot's task to provide that with appropriate joystick commands.

Going into the specifics of this event, let me start by saying that I do understand all your guys' comments that the crash would not have happened if not for my lack of prudence in taking off from a balcony without GPS signal available to set the Home Point, which eliminated the recourse to a safe RTH. However, in my opinion, this is a classic situation in which we let the advanced technology used by the system get into the way of getting something rather simple done. I just wanted to bring to me a drone that was in the air three meters away from me. One does not really need the availability of a large number of GPS satellites nor an Obstacle Avoidance (OA) system to do that, the latter being actually an obstacle to overcome in this situation. One just needs a control system that makes the drone track the joystick commands and compensates for external disturbances. In other words, a well-functioning P-OPTI mode. Understanding how this crash happened in my opinion is interesting because it can shed some light on the complicated (at least for me) relation between flight modes and sensors availability, which is the main motivation that led me to post. It is now rather clear to me that the crash happened because I was totally unprepared for the drone entering ATTI mode and suddenly losing compensation against the wind. The question is why did the drone enter ATTI mode?

In my recollection the drifting did not start at a random moment as it would have been the consequence of losing GPS, but the drone was hovering stable in position until the exact moment in which I switched off the obstacle avoidance (OA) system. If I understand correctly the AirData system, the player's flight logs can only show the part of the flight in P-GPS mode. This would indicate that GPS-based position is lost at 8m26.5s after my first attempt to bring the drone to the balcony at 8m20.5s had been thwarted by the OA system. Screenshot 2022-10-15 005632.png

While the notification log does not show an explicit indication of such an event until 8m42s, one can see that the GPS signal was indeed lost because the "distance from home" (i.e., from that bogus point that, as Meta4 remarked, was set more than 1 minute into the flight when there was "enough" GPS signal) suddenly dropped from 395m to 0. Screenshot 2022-10-15 011358.pngAt this point (8m26.5s), I believe the drone should have switched from P-GPS to P-OPTI, which is the same mode used in the first minute and 13 seconds of flight, and which is very safe when the drone is in full sight of the pilot. I said I believe, because unfortunately the AirData system does not seem to be able to identify the P-OPTI mode. Another attempt I made to bring the drone to the balcony in P-OPTI mode at 8m30s was once again thwarted by the OA system, which led to my decision to disable the OA system at 8m35s. In my recollection this is when the drone started drifting and crashed against the wall in a handful of seconds. However, the notification log shows ATTI mode being entered only 7 seconds later, at 8m42s. I am not sure whether I believe that, because 7s in P-OPTI would have been more than enough to bring the drone over to the balcony and land it.
BTW, @Yorkshire_Pud, the flight started at 17.18 Cancun time so there was plenty of light for the P-OPTI system to operate, I am not sure how you arrived at the conclusion that it happened past 22.

In conclusion, if my recollection of immediate drifting after disabling OA is correct, it would mean that disabling OA caused the drone to get out of P-MODE and into ATTI. This would not make much sense from a design perspective because there is no reason to exit closed-loop control only because one wants to disable OA in a scenario in which the drone is in full view. I would call this a design fault that is good to be aware of.
If instead ATTI mode was entered only 7 seconds later, what caused the switch from P-OPTI to ATTI?
The fact that no ATTI mode was entered at the beginning, when I flew the drone off the balcony without GPS, seems another element that points to a causal relationship between disabling OA and entering ATTI mode.

@Meta4, which tools did you use to analyze the flight logs? From what you wrote it seems that you were not only able to extract much more info from the flight logs than what shown by the AirData system but also your timestamps seem not aligned with those shown above. For example you mention a full joystick correction at 8.45.5s after 25 seconds of drone drifting. This means the drifting should have started at 8m20.5s, when according to the timestamps above the drone was still in P-GPS mode. A final big joystick move definitely makes sense, as the disperate attempt to avoid the final collision with the wall, but certainly it wasn't after 25 seconds of lost control. Maybe the additional info provided by your tool can give me some better hint of what caused the transition into ATTI mode.
 
Last edited:
@Meta4, which tools did you use to analyze the flight logs? From what you wrote it seems that you were not only able to extract much more info from the flight logs than what shown by the AirData
You have only been looking at a small part of the flight data.
There is a lot more in the recorded flight data that you aren't seeing in the brief Airdata summary.
Have a look at this spreadsheet:

Maybe the additional info provided by your tool can give me some better hint of what caused the transition into ATTI mode.
My explanation comes from what I saw in that spreadsheet.
There's no mystery about when or how the drone slips out of P-GPS mode.
The number of satellites drops and so does the GS reliability calculated by the Flight Controller.
When it drops below 4/5, it's not used.

btw ... the number of satellites is only part of t.he issue.
The sats also have have a good spread across the sky.
10 sats might be fine if they show a good spead, but 10 sats clustered in one part of the sky or all in a line won't give good reliability.
 
Last edited:
  • Like
Reactions: LongRifle
I believe the drone should have switched from P-GPS to P-OPTI
OPTI needs proper view of the ground, recognizable pattern, reasonably flat, not too far and decently lit. In this case it apparently didn't have that available. If you're just out of a balcony then the ground below is likely to be too far for OPTI to work.
 
VPS is used whenever it is available irrespective of of the GPS count.

I have flown, low, from a particular area with good GPS in both full daylight and darkness. The position holding in daylight was within 1 to 2 inches, at night it was within maybe 2 to 3 ft.

The 10pm comes from the date / timestamps shown in the csv downloaded from the Phantomhelp website DJI Flight Log Viewer - PhantomHelp.com
using excel in windows it was /is in column 1 / A using open office on a MacBook column 2 / B.

Just as a matter of interest, is it your recollection that this was a daytime flight?

I recollect noticing discrepancies between log-name timestamps and those in log csv's before but associate that with Airdata rather than Phantomhelp, I will have to check whether my mind is playing tricks on me.
 
Thanks, I really appreciate, The log definitely contains much more data than Airdata shows and I will have to spend some time to understand what the data in each column are.

There's no mystery about when or how the drone slips out of P-GPS mode.
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.
OPTI needs proper view of the ground, recognizable pattern, reasonably flat, not too far and decently lit. In this case it apparently didn't have that available. If you're just out of a balcony then the ground below is likely to be too far for OPTI to work.
As I mentioned above, it that was the case then OPTI should not have worked during take off either, when I slowly raised the drone above the balcony and slowly moved it outside of it. Environmental conditions (light, wind, etc) were exactly the same but no drifting occurred. The only difference is that OA was enabled then. The only other reason I can think of for the different behavior at the beginning and at the end of the flight, is a marginal stability of the P-OPTI mode: flying over a specific point caused a sudden deterioration of the signal and the switch to ATTI mode. I don't know enough about the logs yet to know whether such a situation can be read from them
VPS is used whenever it is available irrespective of of the GPS count.

I have flown, low, from a particular area with good GPS in both full daylight and darkness. The position holding in daylight was within 1 to 2 inches, at night it was within maybe 2 to 3 ft.

The 10pm comes from the date / timestamps shown in the csv downloaded from the Phantomhelp website DJI Flight Log Viewer - PhantomHelp.com
using excel in windows it was /is in column 1 / A using open office on a MacBook column 2 / B.

Just as a matter of interest, is it your recollection that this was a daytime flight?
Hi Yorkshire_Pud, I know what you mean as the csv file that I got from Meta4 shows the same. It is kind of weird. I need to get familiar with the Phantomhelp website before I can make any sensible comment. However, I am 100% certain that the flight happened in the afternoon when there was plenty of light. I went back to the room to escape the intense sun and the heat and had the brilliant idea of flying the drone. If I had here the video I shot during the flight I would post it, but that will have to wait until I'm back home next week.

The accuracy data you mention in P-OPTI for different lighting conditions is very interesting. Are those numbers contained in the flight logs 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?

However, turning off obstacle avoidance should not have turned it to ATTI. If you already had lost enough satellites to not have GPS lock, you would have already been in ATTI. Perhaps you were, but it wasn't hitting the wall because obstacle avoidance was providing enough back control (I've not tested obstacle avoidance in ATTI mode, so I'm not sure if it works).
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, 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. Moreover I believe OA is disabled by default in ATTI.

The more I read on the subject, the more I get the feeling that DJI tends to conflate the concepts of forward obstacle detection and forward vision. 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)". However, I see absolutely no good reason for a software implementation in which OA is switched off by switching off the vision system (and hence preventing P-OPTI from working as well), as it can be done much more safely by simply disabling any reaction to a detected obstacle. After all, if you want to hit something, you don't need to close your eyes, just don't brake or swerve
 
Last edited:
NOTE: I just found this twin blog post, describing the same identical situation. The advice given was "disable OA" or "switch to S mode" (where OA is automatically disabled), which suggests that such a move should not disable closed-loop feedback, either GPS-based or vision system-based. 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.
 
This article, for example, claims that in Sport mode, where OA is disabled by default,
In Sport mode OA is disabled because the speed allowed in Sport results in too much tilt which causes the OA sensors to be looking at the ground and not seeing far forward enough anymore to be useful.

As I mentioned above, it that was the case then OPTI should not have worked during take off either, when I slowly raised the drone above the balcony and slowly moved it outside of it. Environmental conditions (light, wind, etc) were exactly the same but no drifting occurred.

Disabling OA doesn't disable VPS. But VPS is based on optical flow/object recognition, that's a pretty approximative science, and in a marginal condition like a balcony it's totally possible that starting from it and leaving would be fine, but coming back and taking some time there the info from it would become erratic enough / for long enough that it dips below the reliability threshold. Logs show going from GPS straight to ATTI, so at the time GPS was considered unreliable VPS was already unreliable. In the log you can see that vpsHeight is 15.4 for pretty much the entire flight after takeoff until the end, so it never got a reliable signal to activate VPS again when coming back.

These things always do their best to choose the most assisted mode possible, but they also have to be pretty strict about giving up when the data is unreliable. Trying to keep relying on GPS/VPS when the data from it is bad can be very dangerous with the aircraft going full speed to random directions and with the pilot having no opportunity to do anything about, which is way worse and more frustrating than giving up, falling back to ATTI and letting the pilot have a chance of getting back to safety using his skills. Obviously he needs to understand how the system works and have those skills, but choosing that path is always better than an almost certain crash.

Both the GPS and VPS systems have limitations, and taking off from an obscured balcony is borderline for both of them. That needs to be understood and if you do that you must be even more ready to take manual control than usual.
 
Last edited:
However, I see absolutely no good reason for a software implementation in which [...]

I think the important thing to understand here is not what would make sense to you, but what is. Discover through research (as you are doing) what it is DJI has designed and operate it within those properties, whether you would have designed it that way or not.

One thing I've learned over time of using DJI products since the Phantom 3 Pro, and watching the design changes of the products I've used since then, is that DJI is very much interested in limiting liabilities. It seems like you found a situation or two that conflicts with that, but I'm guessing that decision probably weighed against something heavier that made more sense to them. They word their documentation around those decisions.

I doubt they would share any legal responsibility for damage incurred in your flying scenario.

Chris
 
that DJI is very much interested in limiting liabilities.
Definitely a thing that does back the "give control back to the pilot", because then it's not "the aircraft crashed and you had no control" it's "the aircraft crashed and you couldn't save it". But regardless of liability it's still technically the right thing to do anyway, so no point going all "conspiracy theory" on it...
 
Definitely a thing that does back the "give control back to the pilot", becasue then it's not "the aircraft crashed and you had no control" it's "the aircraft crashed and you couldn't save it". But regardless of liability it's still technically the right thing to do anyway.
Well, except that the have done the opposite. They removed manual ATTI mode ability (without hacking).

I suppose that might less a limiting of liability and more a reducing of support issues / noise (from people crashing their aircraft too often in ATTI mode). Easier to just remove it and stop those instances from even happening.
 
Yes I totally agree removing ATTI is stupid since it prevents people from training with it and being ready for the day they'll have to manage it which will pretty likely happen one day... But that's a different thing, falling back to ATTI early when data is unreliable instead of leaving the pilot powerless is still the right thing to do.
 
In Sport mode OA is disabled because the speed allowed in Sport results in too much tilt which causes the OA sensors to be looking at the ground and not seeing far forward enough anymore to be useful.
The point I was making is that the article implies that disabling OA implies disabling VPS.
Logs show going from GPS straight to ATTI, so at the time GPS was considered unreliable VPS was already unreliable. In the log you can see that vpsHeight is 15.4 for pretty much the entire flight after takeoff until the end, so it never got a reliable signal to activate VPS again when coming back.
Thanks, I just found out how to get that info from the logs. I will do some further study
 
Last edited:
I think the important thing to understand here is not what would make sense to you, but what is. Discover through research (as you are doing) what it is DJI has designed and operate it within those properties, whether you would have designed it that way or not.
That is exactly the knowledge I am trying to gain through this post. Not for legal recourse, as I have no problem in admitting that the main responsibillity is mine for flying in the conditions I chose. However, I deem very important to know exactly what to expect in each situation, especially when it does not follow what I would consider the logical path.
In this case however, it seems the jury is still out on whether disabling OA when GPS is lost disables VPS.
 
Status
Not open for further replies.
Lycus Tech Mavic Air 3 Case

DJI Drone Deals

New Threads

Forum statistics

Threads
130,592
Messages
1,554,172
Members
159,596
Latest member
da4o98