Mavic 2 Pro Fly Away

[slup]

...The nose was pointing towards the trees . Can you recall if this is correct ? From the behaviour of the drone, it seems that the drone was actually pointing to the opposite direction.

Magnetic Interference makes the most sense with the Yaw errors and the arrow it pointing the opposite way on the drone as you noted

...the Home Point had just registered in the air and was already compromised.

Doubt that this have anything to do with magnetic interference ...

If reading the OP's initial description ... he says "- a recent incident where the M2P began to fly forward immediately after Take Off"

Meaning that the indicated heading from start in the log is probably correct ... the odd thing is the indicated tilt direction, that doesn't work well with the heading & travel direction.

And to say it again ... the HP wasn't in any way "compromised" it was properly recorded 0,5sec after motorstart with the AC still on ground with 17 satellites locked & with a navhealth of 5 of 5.

 

[Phantomrain.org]

Doubt that this have anything to do with magnetic interference ...

If reading the OP's initial description ... he says "- a recent incident where the M2P began to fly forward immediately after Take Off"

Meaning that the indicated heading from start in the log is probably correct ... the odd thing is the indicated tilt direction, that doesn't work well with the heading & travel direction.

And to say it again ... the HP wasn't in any way "compromised" it was properly recorded 0,5sec after motorstart with the AC still on ground with 17 satellites locked & with a navhealth of 5 of 5.

But we know from past experience that Yaw errors are noted with Magnetic Interference and this is typical behavior of what Magnetic interference can do to a drone. Its hard to rule out .

 

[boblui]

P

... he says "- a recent incident where the M2P began to fly forward immediately after Take Off" Meaning that the indicated heading from start in the log is probably correct ...

I missed that part. Thats really weird indeed.

 

[slup]

But we know from past experience that Yaw errors are noted with Magnetic Interference and this is typical behavior of what Magnetic interference can do to a drone. Its hard to rule out .

You're fully correct ... with straight or toilet bowled flyaway paths, the first thing you should look at is just that, do we have a yaw error & is it likely caused by magnetic interference at the power on moment.

With only the TXT log at hand the most indicative is that the OP's description regarding fly & yaw direction isn't matching what's seen in the log.

That's not the case here unfortunately ... the AC flew forward according to the OP & that's what the log show also. So this was most probably not a flyaway caused by a yaw error at all.

With the DAT available it's easy to check off how magYaw, magmod & IMUYaw behaved from power on & later after take off ... & fully prove a yaw error due to magnetic interference.

Magnetic interference isn't the only cause for a yaw error (yaw error like the FC don't know in which direction the AC points). IMU failures midair usually cause yaw errors also --> FC don't have the correct yaw knowledge.

So far in this case the only thing that stands out beside the uncontrollable flight itself ... is the clearly wrong tilt direction, the AC should have been tilting into the direction it was flying but it wasn't according to the log, it was tilting approx 180 degrees wrong ... this is a strong indication of a IMU error where the IMU reports faulty angle values to the FC.

If ... as in this case the pitch angle is reported positive instead of leveled as it should ... the consequence would be that the FC commands the rear motors to spin up to correct that and get the AC leveled ... in reality that means that it pitches down & start to move forward.

It's easily seen here in the chart ... the red graph shows that already approx 3sec into the flight the AC starts to pitch nose up & the light blue graph shows the heading speed increase ... all uncommanded. If this would have been correct, the AC should have flown backwards back to the launch point ... but it wasn't it went forward.

(Click on the chart to make it larger) (and take the heading speed times 10 to get the correct value)

 

[Phantomrain.org]

View attachment 120480

So your saying interference on the ground to affect the IMU but not enough to affect the compass .
Or are you saying that IMU is maybe just going bad. ? Thanks for the details on this .

 

[slup]

So your saying interference on the ground to affect the IMU but not enough to affect the compass .
Or are you saying that IMU is maybe just going bad. ? Thanks for the details on this .

In this case the IMU most probably reported wrong angle values to the FC ... so I would pick "IMU going bad" from your 2 alternatives.

 

[Phantomrain.org]

In this case the IMU most probably reported wrong angle values to the FC ... so I would pick "IMU going bad" from your 2 alternatives.

I see that with the tilt but what causes that IMU to report the wrong angle values that is where I am lost.

I made a video on the IMU error and how at different angle I cannot start the Drone when I get the IMU error such in this angle but the second i level it off just a bit I can Remote start again and the IMU error goes away. Thus im trying to figure what else causes the IMU to fail.. ..

 

[slup]

I see that with the tilt but what causes that IMU to report the wrong angle values that is where I am lost.

In order to pinpoint the reason more precise the DAT log is needed ...

 

[Phantomrain.org]

Are you sure about that ? My M2P prior to taking off :

View attachment 120459

Lol - No we have not see that yet in any of our flights , I have been waiting and wanting to see it on the smart controller as I have been collecting all the different warning and messages that can show . Thank you for this.

 

[MoneyMonk]

Good Afternoon

I'm after some help if possible with getting to the bottom of a recent incident where the M2P began to fly forward immediately after Take Off.

The aircraft was powered up and it began its self diagnostics. There were no error messages displayed and the aircraft had a GPS lock and displayed the message “GPS Safe to Fly”. The motors were started by pushing both sticks diagonally downwards.
A manual take-off was instigated with the intention to initially climb and carryout flight
control checks. The initial climb was carried out to 7ft in order to check the controls before climbing higher.

A collision avoidance message was displayed on the IPad screen despite there being no objects near the drone. The
aircraft then without any control input began to fly forward at a height of 7ft above the ground. I immediately applied
full right stick down in an attempt to retard the forward movement of the aircraft. This had no effect whatsoever. I could see that the drone was heading directly towards a fence line with trees beyond. I then attempted to force the drone to land by applying full downward left stick. This also had no effect on the drone. Believing the drone was unresponsive to control input I attempted an emergency engine stop by pushing both stick diagonally down and
inwards to stop the motors. This again had no effect of the control of the aircraft and that a collision with the approaching fence line was imminent.

I continued to attempt an emergency shut down but this was not working. The drone again without input began to yaw right about 120 degrees and the rear left propeller collided with the fence. The aircraft then shut down.

An inspection of the drone revealed it had sustained damage to the rear left propeller on both tips and damage to the trailing edge of the propeller. There appeared to be no other damage to the aircraft.

The drone was recovered to the take off point and a function check carried out. The function check revealed at fault with the rear left motor. The motor was not spinning freely when manually trying to rotate it and appeared to be ceasing of jamming. It is unclear if this was as a result of the collision or a fault which had resulted in the loss off control of the aircraft.

No injury was caused as a result of this incident and no damage to any other property. This incident could have
been more severe if the aircraft had initially climbed to a height which meant it was clear of the fence as the drone had 100% battery and this could have resulted in a substantial flyaway.

At the time of the incident the weather was clear with broken clouds and sunshine. There was 19% cloud cover,
with a temperature of 6 degrees. The wind was from the south west with a speed of 5mph. Humidity was 85% and
visibility excellent at 16km.The flight lasted a total of 11 seconds with a maximum height of 7ft.

The aircraft travelled a total distance of around 30m. I had a clear unobstructed view of the drone at all times.

6 degrees that could be the issue. 32 degrees is lowest you should fly in

 

[Fly Dawg]

The HP was set 0,5sec after the motor start so that had nothing to do with this ... use the CsvView signal HOME:isHomeRecord to check that.

I did look at that and you are correct in that data point. The event log is what I referenced, which stated 2.7 seconds after motor start. That is what was odd to me.

2.7,HOME POINT RECORDED. RTH ALTITUDE:Â 30M.

 

[slup]

6 degrees that could be the issue. 32 degrees is lowest you should fly in

The OP is from UK ... they use Celsius degrees & not Fahrenheit there. Flying in 6C degrees wouldn't be any problem what so ever as the specified operating temp is -10C to +40C degrees.

 

[BudWalker]

@Aaron1906 there is something very odd about the first 2.5 secs of flight. The data shows that the M2P was losing altitude until throttle was applied. Did that actually happen? Was it hand launched?

The red plot is the height and the blue is the throttle.

The tilt calcs are computed by CsvView and depend on Yaw, roll and pitch. An incorrect Tilt:direction would be caused by either an incorrect Yaw or incorrect roll and pitch values. AFAIK, it's always Yaw that is incorrect. If there were problems with roll and pitch I would expect the M2P would have a hard time staying in the air.

Another possibility is that there are no sensor problems and Yaw is correct. The data is consistent with a strong wind coming from the SW. Either that or the M2P was in ATTI mode even though the data says it was in GPS_ATTI mode. As the M2P began to rise it started to move NE - this can be seen from the North and East velocities. At 4.6 secs negative elevator was applied which arrested the forward movement and actually moved the M2P backwards a bit at 6.8 secs. When the elevator was released at 7 secs the M2P resumed it's NE course and reached a velocity of 3.2 m/s before crashing into the tree.


Was it windy?

 

[BossBob]

The .kml file indicates Tursdale and I was able to match the satellite photo. Indicated wind gusts during daylight maxed at about 14mph according to Dark Sky for the 22 of December.

 

[boblui]

... Either that or the M2P was in ATTI mode even though the data says it was in GPS_ATTI mode.

This has come across my mind as well because it can explain why the craft moved forward but tilted backward. The travelling direction of the drone also matches the OP's report that ".... The wind was from the south west with a speed of 5mph ... "

However, the data does not support this theory because in ATTI mode, the drone will just go to the commanded tilting angle and doesn't care about the position or ground speed. When the stick is released, the craft will not attempt to brake. This is from the log of my M2P in ATTI mode :



The following is from the log provided by the OP. The pitch did not change when full backward elevator was applied . As obstacle avoidance warning messages has appeared at the beginning of the flight. Is it possible that the craft detected some obstacles at the back so it refused to move backward ? However as soon as the stick was released, the craft attempted to "brake" by tilting forward a lot. If the drone has not picked up any speed, why need to brake ? Very weird ...



Anyway there was clearly something wrong with the sensors because the position seen by the FC ( reflected by OSD:xSpeed and OSD:ySpeed I believe ? ) did not agree with that indicated by GPS but it cannot explain everything.

 

[BudWalker]

This has come across my mind as well because it can explain why the craft moved forward but tilted backward. The travelling direction of the drone also matches the OP's report that ".... The wind was from the south west with a speed of 5mph ... "

However, the data does not support this theory because in ATTI mode, the drone will just go to the commanded tilting angle and doesn't care about the position or ground speed. When the stick is released, the craft will not attempt to brake. This is from the log of my M2P in ATTI mode :

View attachment 120541

The following is from the log provided by the OP. The pitch did not change when full backward elevator was applied . As obstacle avoidance warning messages has appeared at the beginning of the flight. Is it possible that the craft detected some obstacles at the back so it refused to move backward ? However as soon as the stick was released, the craft attempted to "brake" by tilting forward a lot. If the drone has not picked up any speed, why need to brake ? Very weird ...

View attachment 120544

Anyway there was clearly something wrong with the sensors because the position seen by the FC ( reflected by OSD:xSpeed and OSD:ySpeed I believe ? ) did not agree with that indicated by GPS but it cannot explain everything.

View attachment 120540

I agree it wasn't in ATTI mode. And, the theory that it was being carried away by the wind isn't compelling. It's almost like a sluggish GPS_ATTI mode.

I'm not entirely convinced the IMUCalcs stuff is valid. The paths were parallel after about 5 secs. And the velocity diffs did reach 0.0 after about 9 secs. It's not uncommon to see initial position differences followed by parallel trajectories. This flight didn't last long enough to see if that would happen.

It's unclear what xSpeed represents. Is it the VelN determined by the GPS receiver using the Doppler shift? Or, has it been "corrected" by fusing it with IMU and magnetometer data?

Maybe there is a problem with one or more of the sensors...

 

[Badgersurfer]

For what it is worth I had a similar issue when I first used my M2P and discovered it was because I was taking off to close to myself and the avoidance sensors were trying to move it away from me in a forwards direction. I also had similar when I was away from the drone taking off from an orchard and it was being distracted by the trees thus wouldn't hover over the TOLP. All part of the learning curve...

 

[Tenko]

I had a similar thing happen yesterday, which i have just literally posted on here about, but it wasn't straight after take off, it was mid flight. I was indoors so I'm suspecting some mag interference, not sure as to why it would cause it to shoot off, but the fact it shot off on its own (at what appeared full speed) and was non responsive seems very similar. Luckily an empty factory, so the only damage was to the drone thank god, which is a right off, but could of been a hell of a lot worse.

Ah you going through DJI for a replacement or through the insurance?