Nothing in the log indicates a bird strike... it's much more likely that the left front prop failed & the prop itself came withing the upward OD sensor indication area & triggered a UPWARD OBSTACLE DETECTED message coming at 476,5sec.
The AC attitude change comes very abruptly while you command the AC to fly sideways to the left (a full negative aileron command). At 476,4sec into the flight the AC pitch down & rolls over further to the left... both these movements indicate a thrust loss from the front left corner. This is also supported by that the AC starts to rotate CW, this as the front left should generate CCW rotational torque... so without a prop on the left front a rotational torque imbalance is created, 2 props torque CW & only one CCW... = the AC starts to rotate CW.
Note. I spotted what turned out to be the bent pin on the pivot of one front arm because the affected arm drooped when compared to the other arm. If both front arms are symetrical post a photo of them looking front the front and at the drone's nose.
If you end up having to replace rears arms and also replace the female half/halves of the pivot/s watch you do not displace the rear ventilation grills, I noticed recently that I have displaced/rumpled the one by the female pivot I removed and refitted. If the rear arms DO NOT rotate upwards from their flying positions then it is likely the "lugs" are ok. My rear arm rotated upwards slightly when I throttled up to make the drone climb.
Meaning no offense but the answer concerning new bits would not be relevant to you, I am in the UK.
Other bits were from wrecked drones bought via ebay.
A drone that has been in salt or fresh water is a good bet for plastic parts providing it descended in a controlled manner and DID NOT crash, if it went into salt water consider EVERYTHING other than plastic parts to be scrap.
scroll down the page, there are instructions down there.
Retrieve the log and upload it to that site then post the resulting URL here.
If you encounter problems reply here and include the model number of the controller and whether or not you sync logs with DJI, if you do not sync DO NOT change that setting.
Update: today I got the occasion to test it more rigid. I flew above the field where the crash occurred and put some stress on the RC. I did it there because it would be quite easy to recover in case of a new incident. First I let it hover some while and observed the arms while ascending an descending, but saw no anomalies. Then I flew in normal and in sports mode, did ascent and descend in full speed and made it rotate 360 degrees at the same time etc. No crash now: yippee!
After the flight I put it on a table and the two rear legs did not touch the table.
I also did not see anything of the 'jello' effect that slup mentioned in #34. So all seems to be ok, but I hope I don't overlook something.
The only thing that caught my attention is that the battery (the same as the one used at the crash flight) did restart its counting of number of charges and that was reset to 1. Could that be a result from the crash? Strange, but I cannot explain it otherwise. Before the crash it was counting correctly and so it does now, but it restarted from 1 instead of 10, which was the initial number of charges when I bought the (second han) battery.
I also made a video during the test flight today, but cannot find any sign of it (I thought I could see a preview) on Airdata UAV nor on the DJI GO4 app and I wonder if that is normal.
The charge count and battery serial number are recorded in the csv of the flight log.
Serial number = column ID, "RECOVER.batterySn" & or column JF "DETAILS.batterySn".
Battery production date? column DQ, "CENTER_BATTERY.productDate".
charge count = column DG, "CENTER_BATTERY.loopNum".
It might be an idea to check any previous flights flown with that battery to see if your impression is correct.
If you have a windows computer and if you have a lot of M2P logs then there is a way to process them en masse and get their csv's with TXTlogToCSVtool.exe
Hi folks, I'm glad to present you the result of my work. A lot of us have been unhappy, because until now, there was no offline TXT FlightRecord to CSV Converter. And after websites such as HealthyDrones and djilogs.com started to charge for their services, I decided I really need some offline...
phantompilots.com
Copy the logs to one folder then open a command window in that folder and paste everything in green
The charge count and battery serial number are recorded in the csv of the flight log.
Serial number = column ID, "RECOVER.batterySn" & or column JF "DETAILS.batterySn".
Battery production date? column DQ, "CENTER_BATTERY.productDate".
charge count = column DG, "CENTER_BATTERY.loopNum".
It might be an idea to check any previous flights flown with that battery to see if your impression is correct.
If you have a windows computer and if you have a lot of M2P logs then there is a way to process them en masse and get their csv's with TXTlogToCSVtool.exe
Hi folks, I'm glad to present you the result of my work. A lot of us have been unhappy, because until now, there was no offline TXT FlightRecord to CSV Converter. And after websites such as HealthyDrones and djilogs.com started to charge for their services, I decided I really need some offline...
phantompilots.com
Copy the logs to one folder then open a command window in that folder and paste everything in green
Great link, Yorkshire_Pud, I did not know about that. I'm gonna download it and try it out on my txt files here.
Concerning the battery cycle count: it was a second hand battery that I myself used for the first time, but when I checked it after purchase I saw the number of charging cycles was 10. After using it in my M2P it was for some reason reset to 1. No big deal, but I just wonder how this can be explained.
Btw another thing I noticed is that the battery temperature is not recorded, but that is probably normal, I saw the same with my Mini 2 batteries and after a firmware update suddenly the temperature graph was displayed.