KB9Radio
Well-Known Member
By the way, you can't legally fly at 150 meters in the US. I know you probably weren't at that height, but your message talked about the 150 meter limit. The legal limit is 400 ft (121.9 meters).
Last edited:
It's not a "firmware bug"My concern is it this bug repeats itself next time it will be a flyaway or a total crash that wrecks it beyond hope of repair.... if indeed its a firmware bug the DJI should be responsible
What message?By the way, you can't legally fly at 150 meters in the US. I know you probably weren't at that height, but your message talked about the 150 meter limit.
I was only trying to let the author of this thread know that you can't legally fly 150 meters in the US, nothing to do with any crash and didn't think I had indicated that it did. I don't care about the crash and had nothing to do with it. But I read it and the first thing that caught my eye was the 150 meter restriction mention, there is no such thing that I am aware of.What message?
He never went higher than 97 metres so whatever the message was, it wasn't relevant.
What triggered initial forced autoland?
The area I was flying under only had a NFZ altitude restriction of 150meters, I was well under that height at all times.
What triggered initial forced autoland?
Even if IMU disagree, why would it go up to 56mph? during forced autoland?
How did you read the .DAT?
The autoland was not the cause, it was just coincidental as explained above.I wonder if this flyaway behavior maybe wouldnt have happened had autoland not kicked in
It had nothing to do with firmware.I really hope the recent firmware update was not somehow a contributing factor, directly or indirectly to this, but if it was a flight controller or other hardware problem then dji needs to take a look to fix this.
...It was due to your choice of launching spot...
Can you describe your launch spot?
What was the surface you launched from?
Did you place the drone and power up or did you move the drone after powering up?
I wonder if this flyaway behavior maybe wouldnt have happened had autoland not kicked in...
...see my first page original post the screenshot from yesterday is showing 150m on both sides, im not seeing a 60m lower restriction.
So there was a genuine yaw error condition that was "fixed"and soon after there was a similar but unrelated mysterious hardware problem that was unnoticed earlier.The yaw error that was created initially after take off was fixed just a couple seconds later
... So this later incident at 88sec up on 93m height wasn't a ordinary yaw error due to a magnetic disturbed power on spot at all ...
I can read but still haven't heard from the OP in his own words despite asking several times.All info about this in the beginning of post #27
So there was a genuine yaw error condition that was "fixed"and soon after there was a similar but unrelated mysterious hardware problem that was unnoticed earlier.
And you're not concerned at the amazing coincidence and are attributing the issue to a rare and mysterious hardware problem?
I agree this incident was not caused by a geomagnetically distorted launch site . @sar104 did some experiments that showed the M2 can and does recover from a geomagnetically distorted launch site by adjusting Yaw after launch. This one is pretty impressive. The magnetic field strength was so strong that I wonder if it wasn't just a bending of the available geomagnetic field - was there a magnet close to the M2?This was an interesting one, really hard to find a conclusive reason here ... but I give it a try.
First of all ... if this flight had been performed with any other drone than a M2 it had been a disaster from start any way ... even without the HW failure I think it was.
The AC was launched here ... pretty sure that those concrete constructions was filled with steel. All set for a classical yaw error due to a magnetic disturbed power on spot.
View attachment 112016
Here below we see what happens in detail ... & how the M2 use it's unique function to prevent yaw error's due to magnetic disturbance.
Have never seen that high values for the magnetic field modulus (dark green graph) as here just before take off ... usually the values are around 1400-1500, but here it was above 4700. So the environment was severely magnetic disturbed.
As soon as the take off starts at 9,5sec the magmod (dark green graph) falls down toward normal levels & by that let the compass (blue graph) point correctly ... this immediately create a imuYaw & magYaw disagreement of 62 degrees. But here the M2 do it's magic & re-initializes the IMU(1) (Light green graph) at 10,8sec & on 2.1m ultrasonic height.
No real yawing was going on as the gyro (purple graph) was mainly constant.
View attachment 112017
The flight proceeded then without any oddities until 88sec when the AC came to a stop after a short throttle command to adjust the height down to 93m.
From here something is starting to go haywire ... looking at the velocity difference between the GPS & the IMU below show this clearly ...
View attachment 112019
Just seconds later the AC faces a imuYaw/magYaw dissagreement of nearly 180 degrees ... here seen by the purple graph on a 180/180 Y-axis.
View attachment 112020
And here on a sat map where the green bar symbolize imuYaw pointing direction & the yellow the magYaw ...
View attachment 112021
So what went suddenly wrong ... up on 93m height ..?
In order to check off if it was the IMU or the compass that failed I've below first put up a comparison between the unwrapped gyro together with the unwrapped imuYaw ... can be somewhat difficult to see but firstly the graphs aren't similar shape wise ... secondly, the gyro rotates nearly 2 times more degree wise compared to the imuYaw.
View attachment 112022
Then I compared the imuYaw with the magYaw in order to conclude which of the 3 (IMU, Gyro or Compass) that deviate degree wise regarding the amount of turning ... this shows that the magYaw & the gyro are reasonably in agreement ... & by that should be showing correct, It also shows that the imuYaw(1) rotate half of what the others register.
This is what causes the big nearly 180 degree disagreement between the imuYaw & the magYaw ... & as the turning is in reality twice as large as what the IMU think's, it now doesn't have knowledge of the real heading & will with this counteract with the wrong motors & fail in position hold ... making it flyaway in speeds exceeding the spec.
So was the IMU(1) failure the root cause ... or was it actually something else that failed that in the end made these consequences?
Usually only one of the 2 IMU's fail ... but if we check off how well both of the IMU's are tracking with the compass (which follows the gyro well) we see this ... The blue graph show the re-initialized imuYaw(1), it shows a very small disagreement on approx. a couple degrees ... this up to 88sec into the flight. The red graph shows the other one, IMU(0) ... it doesn't track with the magYaw at all to begin with, but as the time goes it is slowly corrected by the gyro & compass values & around 60sec into the flight the disagreement is small enough so it wouldn't set off a Yaw error flyaway if it had been the active IMU.
But strangely also IMU(0) goes heywire at 88sec and tops out on a imuYaw/magYaw disagreement on 110 degrees ...
View attachment 112023
Looking deeper then ...
During below period the AC is drifting & rotating uncommanded ... even though no yaw error have started yet ...
View attachment 112024
Here below we see that the AC is rolling over to left with a slight up pitch ... & moving at around 2m/s during this period on a couple of seconds before the yaw error starts.
View attachment 112025
Checking into the motor data shows a odd behavior for the left front motor ... both rpm, command & current draw wise.
RPM:
View attachment 112026
Command:
View attachment 112027
& Current draw:
View attachment 112028
So even though I'm not 100% sure I think the root cause to this incident was on a level above the IMU ... a failing Flight controller? ... this as both IMU's suffered errors & that the motors was commanded without a heading failure initially, no stick inputs in very light winds. Never the less ... this should fall on DJI, contact them & they will guide you to what they need.
Then lastly ...
Don't know if you was aware of that the altitude restriction zone of 60m was starting just on the other side of the road ... when you ascended up after take off & turned towards the bridge you got really close to it ... can't say how precise DJI fly zone maps are ... but here is how it was.
View attachment 112029
Unfortunately, it CAN be the firmware. Just because it's not a commonly encountered issue doesn't mean it's not a firmware bug. Having written and debugged networking drivers and protocol stacks (years go), when you have multiple threads of execution in a complex system, you can always have bugs that only revel themselves when a combination of real time events occur. You simply can't rule out a firmware bug just because the incidence of occurrence is rare, but hopefully, it's not; concurrency bugs can be very difficult to find and eliminate. I've encountered and fixed quite a few of these.The autoland was not the cause, it was just coincidental as explained above.
It had nothing to do with firmware.
If it did this would be happening all over the place.
It was due to your choice of launching spot, so Ill ask again (because it's important).
Can you describe your launch spot?
What was the surface you launched from?
Did you place the drone and power up or did you move the drone after powering up?
That really SUCKS but if you can't produce your flight logs this will be labeled as pilot aSo I was flying the other day in an area that has no other NFZ restrictions other than an altitude restriction of 150 meters. Right as I'm about to come in for a landing, the Mavic 2 seems to have a mind of its own, and basically flew a horizontal track at immense speed across the field and struck a tree at high speed before crashing to the ground causing damage to the foot and the battery completely popped out in the process.
View attachment 111986
Why did it do this instead of coming straight down or allowing me time to land it myself? I was handflying it and taking pictures and it was clear day, perfect weather, no winds, and everything was fine (got full GPS lock etc) no obstructions and wasn't flying near buildings or anything and then it started complaining about entering no fly zone, however where I'm at it was an altitude restriction and I was flying WELL UNDER the 150 meter restriction so that shouldnn't have even been a factor or point of contentionn at all...
In any case, what caused the crash was the Mavic going crazy and suddenly decided to basically track horiztonally on the ground at high speed until it struck a tree...
Later I tried to get export of the logs from the aircraft itself but I tried on Windows 7 machine, and two different Windows 10 machines, and all were brand new installs of the latest DJI Assistant app (for desktop PC) for the Mavic 2 version (I also tried the generic old DJI Assistant 2 app etc) but it will just spin and spin and not ever actually show me any logs to even allow me to export to provide to DJI.
I know these logs on the aircraft are encrypted but I should at least be able to export them to send to DJI upon request and its not even letting me do that!
View attachment 111987
That really SUCKS but if you can't produce your flight logs this would be considered pilot error. Possibly compass calibration was not done or not done correctly is the only thing I can think of.So I was flying the other day in an area that has no other NFZ restrictions other than an altitude restriction of 150 meters. Right as I'm about to come in for a landing, the Mavic 2 seems to have a mind of its own, and basically flew a horizontal track at immense speed across the field and struck a tree at high speed before crashing to the ground causing damage to the foot and the battery completely popped out in the process.
View attachment 111986
Why did it do this instead of coming straight down or allowing me time to land it myself? I was handflying it and taking pictures and it was clear day, perfect weather, no winds, and everything was fine (got full GPS lock etc) no obstructions and wasn't flying near buildings or anything and then it started complaining about entering no fly zone, however where I'm at it was an altitude restriction and I was flying WELL UNDER the 150 meter restriction so that shouldnn't have even been a factor or point of contentionn at all...
In any case, what caused the crash was the Mavic going crazy and suddenly decided to basically track horiztonally on the ground at high speed until it struck a tree...
Later I tried to get export of the logs from the aircraft itself but I tried on Windows 7 machine, and two different Windows 10 machines, and all were brand new installs of the latest DJI Assistant app (for desktop PC) for the Mavic 2 version (I also tried the generic old DJI Assistant 2 app etc) but it will just spin and spin and not ever actually show me any logs to even allow me to export to provide to DJI.
I know these logs on the aircraft are encrypted but I should at least be able to export them to send to DJI upon request and its not even letting me do that!
View attachment 111987