M2Pro suddenly refusing to reduce altitude or land- showing negative altitude

This has never happened to me before. I was flying my Mavic 2 Pro this evening with my father and daughter. This was intended to be a short 10-15 mins flight, I had 3 batteries with me which were not fully charged (~60%).

I flew with the 1st battery without a problem and landed as soon as battery warning came on. Then turned the drone off, and swapped to the second battery (controller stayed on- connected to my iPhone and DJI Go app). Drone turned on without issue and connected to the controller and app. As soon as I took off, drone shot up 20-30 metres or so without my instruction. It was unusual. I tried to lower altitude and it kept fighting against me and pulling up. If I let go of the stick, it was just ascending on its own. I tried to land and the drone would descend to maybe 10 metres or so above ground level and would then bounce up and down and would not descend further.

I simply could not bring it to lower its altitude further or land. I tried to engage automatic landing but it then increased altitude. I then noticed that the altitude was -80-90m as if the drone thought it was below ground level. I had not taken off from a higher location- I was literally standing in one spot.

I then started receiving low battery warning and I could not bring the drone to land. I flew the drone towards some bushes so that if it dropped from the sky it won’t hit anyone and will hopefully have a softer crash. It then started ascending again into the tree and chopped some leaves/branches. Ultimately, it reached a critical battery level and then quickly descended into the ground and made some noise as if the motors were engaged but couldn’t spin due to the “crash”.

The battery appeared slightly swollen when removed from the drone but can still be inserted into the drone okay. However, it isn’t lighting up anymore. The charger LED is red when the battery is put to charge.

I have downloaded the flight log and have attached it at the link below. I would appreciate some advice and insight into what happened as I have completely lost confidence in an otherwise outstanding drone which I have been using for a number of years.

Let me know if there is any further information which might help work out what happened or if I need to approach DJI about this.

Thanks in advance!


There was one issue – which my not have been apparent at the time. Before taking off, the current altitude was 287 feet.

While your flight log doesn’t explain the unusual altitude, it seems that was the cause of your issues. Assuming you have no damaged hardware (due to a previous crash maybe?), then I’d try calibrating the IMU like this:

1 Like

Additionally to the previous comment. This is not good practice. If you do not completely restart everything after replacing a battery, there is always the chance that corrupt data can occur. Always check your altitude, compass direction, and battery levels prior to take off.

Second observation. The home point was never established prior to takeoff.

Lastly, here is the event log. Notice the highlighted areas. That is a different issue, but is related to your landing issue, although you can see in the data where you throttle up and your altitude decreases. The sensors were fighting your manual inputs.

Another anomaly is that the M2 thought it was descending. The Flight Controller then compensated by commanding an ascent. The FC’s value for the downward velocity and the time differentiated height data should be about the same. Here this is not the case.

It should look like this (from my Mavic 2)

The .DAT log should provide more info about the cause of the discrepancy. @Mr008 the .DAT should exist on the Go 4 App if the logs are not being synched with DJI. Info on retrieving the .DAT can be found here
subsection Mobile device DAT files (DJI GO 4 & DJI Fly)

Your particular .DAT will have the file name

Actually, the Home Point was recorded at about .202 secs. Not sure why it wasn’t reported in the event Log.

Doesn’t replacing a battery pretty much restart everything on the drone? Restarting the Go 4 App when the battery is replaced isn’t required.

@BudWalker I only looked at the CSV file in CSV View and not the log file. It didn’t show a "Home Point "recorded. However after looking at the CSV in Excel and the log file in CSV View, it does show the Home Point as you mentioned. I wonder why that is not in the CSV File?

As for restarting the APP. That’s just something I’ve always done, just as a precaution. It shouldn’t be necessary. I restart the controller as well just to be on the cautious side.

@BudWalker This is the downloaded CSV file in excel. In CSV View, neither the CSV or the log file show the home point update in the Event Log. Graphically you can see the update point in either file.

Hi @msinger , Fly_Dawg , and @BudWalker and thank you all for helping me troubleshoot this issue.

@msinger - I am not sure why the altitude was showing as that prior to take-off. Would that explain not being able to land? I have never crashed the drone but there was an IMU message before the first flight (the one prior to this one) and it said to give it a moment to initialise (or something to that effect, I cannot recall the exact phrase) and then gave the go ahead to proceed to flying so I had no indication there was anything I should do prior to flying.

Fly_Dawg I normally completely restart everything between flights but I didn’t realise there was an actual need to do more than simply restart the drone. This time, I was thinking of packing up for the day, and then decided to do one more fly over and with the controller and phone still on, I just swapped the battery and turned the drone back on. Everything connected okay so I proceeded to take off as normal.

Previously when ambient light was too weak, the drone would still allow me to descend and land. This time it was as if it was attached by a rubber band from about 80m in the sky and would only descend so far and then quickly bounce back up as soon as I stopped trying to force it down. It wasn’t a case of the drone avoiding some collision, it would just drift up and would work against my attempt to descend with no ability to override.

@BudWalker your observation that the M2 thought it was descending when it wasn’t sounds plausible. It kept drifting up as if to counteract some perceived loss of height. I am attaching the .DAT file as requested.

I am also attaching the log and .DAT file for the previous flight in case there is some information that may be helpful or any sign of any sensor/calibration failing.

As an aside, my battery has been plugged in overnight and is still not lighting up and the LED on the charger is glowing red. I suspect it is permanently dead…? (would that have been due to over discharging it when I could not land?)

DAT file for the affected flight: flight 058
CSV for the previous flight log

There appear to be two rather than one more DAT file from that day (there were only 2 flights). I have attached both DAT files in case they provide further clues 2 DAT files for previous flight

Thank you all for helping troubleshoot this and let me know if you need me to provide any further files/information.

To be honest, I cannot say I’ve seen many situations like this one (not recently anyhow). If you’re able to retrieve the DAT flight log, there could be additional details available there.

Yep, I don’t think that warning is what caused the descent issue.

Hi @msinger , I have uploaded the DAT flight log in my last post in case that sheds more light.

1 Like

Looking at the 3 secs before the motors were started it can be seen that at least one of the accelerometers was incorrect. During this interval there should be no accelerations and the composite acceleration (i.e. acceleration modulus) will be exactly 1.0. In this case it appears to be about 0.9.

And here is the data from the previous flight where is the correct value of 1.0

Without knowing the attitude during this interval it can’t be determined which accelerometer(s) is incorrect. A non-horizontal attitude will cause accelX and accelY to be non-zero and accelZ to be not equal to -1.0. But, I’m going to guess that accelZ is incorrect; it’s value is about -0.85.

The Z axis accelerometer is oriented pointing down. An increase from -1.0 to -0.85 would mean the M2 is accelerating downwards. This, in turn, would cause the Flight Controller to think the M2 has a downward velocity. The GPS receiver derives down velocity from the doppler effect on the received GPS signals. Comparing that to the down velocity computed by the FC it can be seen that the FC’s down velocity is greater than the GPS down velocity.

I’m with @msinger on this. Try doing an IMU calibration and then provide the .DAT created when the calibration was done. Was the M2 dropped, kicked, etc between the previous flight and this one?

1 Like

More on this. In addition to the incident .DAT (FLY058) the two previous .DATs were submitted; FLY056 and FLY057. FLY057 was short and ended about 17 secs before FLY058 (the incident .DAT) started. What’s interesting is that the problems evident in FLY058 are not present in FLY057. In particular, the composite acceleration is very close to 1.0 and not the 0.85 just 17 seconds later.

@Mr008 I’m guessing this gap is the battery change you mentioned?

Hi @BudWalker , thank you for the careful analysis and explanation.

The order of events was
Flight 1- Flew and then turned off the drone. This generated FLY056.
Then changed battery and turned on the drone but saw that the charge in my second battery was not as high as I expected so turned off the drone (never took off)- this must have generated FLY057. I then changed to battery #3 and took off for the second flight generating FLY058.

I will do an IMU calibration this weekend. I am guessing the IMU calibration will generate a DAT file without the need to take off just as me turning on the drone must have generated FLY057. Is that correct? I am cautious about taking off before I have investigated this further and I know this problem will no recur.

Thanks for the help!

1 Like

Yes, a .DAT will be created even if there isn’t a flight. The GO 4 App needs to be running to record the .DAT.