ESC Fail

[sar104]

I'm going to call @sar104 on because he has more experience reading these and can hopefully teach me a little about esc failure.

It's not an ESC issue - that may have occurred after the event due to the crash. The problem, as mentioned above, is a serious (though unreported) compass error.



If you compare the flight record to the video then it is apparent that the video starts at around 47 s. The problem is indicated by the yaw value of 115°, because the camera view is SW on a heading of 235° (measured on Google Earth). That discrepancy of approximately 115° causes the aircraft to apply corrections that are nearly orthogonal to the correct direction in order to try to hold position. This leads to the classic toilet bowl effect and loss of control as shown by the out-of-phase velocities north and east and the resulting position plot:



The problem was most likely due to taking off from a location with magnetic distortion. After the yaw was initialized at 280° before takeoff (when it should probably have been around 35°), there was an initial rudder command at 22 s (not in the video), while hovering just off the ground, that resulted in an appropriate CCW rotation, but it did not fix the incorrect yaw value:



The problem would have been detected if the OP had compared the indicated yaw on the map to the actual direction that the aircraft was facing. This is an important check before takeoff as it is the most direct indication of magnetic interference and the subsequent risks of loss of control or a switch to ATTI. Had the aircraft switched to ATTI mode then the aircraft would have stabilized (although with drift), but in this case it did not do so before the crash.

 

[Jameslavis]

@sar104 ok peanut gallery here, what checks should you do to watch for mag interference? I check all interference in the app I can find. What checks do you perform?

 

[Keule]

What checks do you perform?

When you put the Mavic on the ground, be sure that the aircrafts direction matches the GO4 indicated direction.

A sample:
Your Mavic is placed on the road:


then your GO4 map should indicate:


** But ** if you are seeing this:

then you have most likely a compass problem.
(i.e. a magnetically distorted environment, such as a manhole cover where your MP is placed on)

 

[sar104]

@sar104 ok peanut gallery here, what checks should you do to watch for mag interference? I check all interference in the app I can find. What checks do you perform?

As I said in my post, and @Keule illustrated, check that the heading arrow on the map agrees with the direction that the aircraft is facing. Credit for this should go to @BudWalker who, I think, originally recommended it as the most robust and simplest check for magnetic interference.

 

[MavicCF]

It's not an ESC issue - that may have occurred after the event due to the crash. The problem, as mentioned above, is a serious (though unreported) compass error.

View attachment 33915

If you compare the flight record to the video then it is apparent that the video starts at around 47 s. The problem is indicated by the yaw value of 115°, because the camera view is SW on a heading of 235° (measured on Google Earth). That discrepancy of approximately 115° causes the aircraft to apply corrections that are nearly orthogonal to the correct direction in order to try to hold position. This leads to the classic toilet bowl effect and loss of control as shown by the out-of-phase velocities north and east and the resulting position plot:

View attachment 33916

The problem was most likely due to taking off from a location with magnetic distortion. After the yaw was initialized at 280° before takeoff (when it should probably have been around 35°), there was an initial rudder command at 22 s (not in the video), while hovering just off the ground, that resulted in an appropriate CCW rotation, but it did not fix the incorrect yaw value:

View attachment 33917

The problem would have been detected if the OP had compared the indicated yaw on the map to the actual direction that the aircraft was facing. This is an important check before takeoff as it is the most direct indication of magnetic interference and the subsequent risks of loss of control or a switch to ATTI. Had the aircraft switched to ATTI mode then the aircraft would have stabilized (although with drift), but in this case it did not do so before the crash.

Thanks @sar104, looks like I have a ways to go yet. I'll have to go try to re-create what you did and figure it out. Would an actual esc failure result in a situation similar to a prop loss with an obvious loss of motor thrust? You are amazing! -CF

 

[sar104]

Thanks @sar104, looks like I have a ways to go yet. I'll have to go try to re-create what you did and figure it out. Would an actual esc failure result in a situation similar to a prop loss with an obvious loss of motor thrust? You are amazing! -CF

I think I've only seen one case of ESC failure. I certainly leads to loss of thrust. It will be distinguishable from prop loss in the DAT motor record because the motor stops rather than spinning up. In the yaw data there should be a kick in the direction of that motor's rotation because, unlike prop loss where the prop angular momentum is trapped and leaves with the prop or stays in the motor, in this case the entire motor/prop angular momentum is immediately transferred to the aircraft.

In this case the motors were fine but the aircraft lost attitude control in trying to correct for drift with the wrong motor inputs. This situation, where the FC yaw value is completely wrong but it has not yet abandoned its attempts at positional control, are just about the only remotely common example of total loss of control. It's just about impossible to fix with user intervention if you don't have an ATTI switch available, and illustrates three things:

1. That the FC really can't do positional control if it doesn't have a trustworthy yaw value;
   
   
2. Always check for magnetic interference before launch;
   
   
3. That the often-experienced ATTI switch on compass errors is the only thing it can do to avoid completely uncontrolled flight.

Thanks for the compliment but, once you have seen enough of these cases, you will find it's generally pretty obvious what is going on.

 

[Geek]

So basically it's just like an airplane - you slave the directional to the mag compass or make sure it's reading right before flying.

Thanks to all for the inputs here. Good to know what went South (almost literally) here. Going to be interesting to hear what DJI says when they get it and look at the same data.

G

 

[sar104]

So basically it's just like an airplane - you slave the directional to the mag compass or make sure it's reading right before flying.

Thanks to all for the inputs here. Good to know what went South (almost literally) here. Going to be interesting to hear what DJI says when they get it and look at the same data.

G

Correct - the IMU yaw value, which is the value that it uses for yaw in flight, is initialized to the compass heading before takeoff. Thereafter, the IMU yaw is updated by the rate gyros with the compass heading being used as a low-gain correction for rate gyro drift and bias.

Let us know what you hear from DJI. Usually they seem to do a fairly thorough job with the logs.

 

[MavicCF]

I think I've only seen one case of ESC failure. I certainly leads to loss of thrust. It will be distinguishable from prop loss in the DAT motor record because the motor stops rather than spinning up. In the yaw data there should be a kick in the direction of that motor's rotation because, unlike prop loss where the prop angular momentum is trapped and leaves with the prop or stays in the motor, in this case the entire motor/prop angular momentum is immediately transferred to the aircraft.

In this case the motors were fine but the aircraft lost attitude control in trying to correct for drift with the wrong motor inputs. This situation, where the FC yaw value is completely wrong but it has not yet abandoned its attempts at positional control, are just about the only remotely common example of total loss of control. It's just about impossible to fix with user intervention if you don't have an ATTI switch available, and illustrates three things:

1. That the FC really can't do positional control if it doesn't have a trustworthy yaw value;
   
   
2. Always check for magnetic interference before launch;
   
   
3. That the often-experienced ATTI switch on compass errors is the only thing it can do to avoid completely uncontrolled flight.

Thanks for the compliment but, once you have seen enough of these cases, you will find it's generally pretty obvious what is going on.

I guess I'll just start building my file of cases and learn as I encounter new situations. What do you think are the most common problems you see?

 

[sar104]

I guess I'll just start building my file of cases and learn as I encounter new situations. What do you think are the most common problems you see?

Good plan. I need to be more organized with my records. Without trying to count them up I would guess: compass errors due to takeoff location, pilots who don't know how to fly ATTI mode, high winds preventing RTH, prop loss, battery disconnects, badly planned Litchi missions.

 

[BudWalker]

So basically it's just like an airplane - you slave the directional to the mag compass or make sure it's reading right before flying.

Thanks to all for the inputs here. Good to know what went South (almost literally) here. Going to be interesting to hear what DJI says when they get it and look at the same data.

G

There is probably more that could be known about this incident by looking at the .DAT file from the tablet. Look here to see how to do that. It will contain the magnetometer and IMU data. It looks like you launched next to a building and the problems developed once it rose above the building. This would be consistent with the building being the source of the geomagnetic distortion. The .DAT would show us if that happened.

 

[Geek]

There is probably more that could be known about this incident by looking at the .DAT file from the tablet. Look here to see how to do that. It will contain the magnetometer and IMU data. It looks like you launched next to a building and the problems developed once it rose above the building. This would be consistent with the building being the source of the geomagnetic distortion. The .DAT would show us if that happened.
View attachment 33936

The pic was interesting. The actual launch point was actually in the middle of that square area in front of the housej (probably about 20' away from the house). The drone was also on a 4'x4' piece of white cardboard that I don't see so I am thinking this is superimposed on a "maps" photo. But be that as it may, I would agree that the house could be a source of magnetic distortion. Especially when it has siding and a roof that is metal. The first time I launched from that same area (literally the first time I flew the drone) it did give me a compass warning and required me to calibrate it. Sure seems to be a lot of issues this thing is sensitive to.

 

[BudWalker]

The pic was interesting. The actual launch point was actually in the middle of that square area in front of the housej (probably about 20' away from the house). The drone was also on a 4'x4' piece of white cardboard that I don't see so I am thinking this is superimposed on a "maps" photo. But be that as it may, I would agree that the house could be a source of magnetic distortion. Especially when it has siding and a roof that is metal. The first time I launched from that same area (literally the first time I flew the drone) it did give me a compass warning and required me to calibrate it. Sure seems to be a lot of issues this thing is sensitive to.

The directive to calibrate most likely means that the launch site is geomagnetically distorted; not that a calibration is actually necessary. That's really saying that you need to move the launch point.

I would've thought that a geoInclination of 69° at the launch site and 20 feet distance would be enough. But, the fact that you've had problems here before is really compelling. It really depends on a lot of variables and can't be predicted. Any chance you can retrieve the .DAT from the tablet?

 

[Geek]

T.........Any chance you can retrieve the .DAT from the tablet?

I can but will have to wait till I get home which won't be until next Sunday. Stay tuned.......

 

[MavicCF]

It's not an ESC issue - that may have occurred after the event due to the crash. The problem, as mentioned above, is a serious (though unreported) compass error.

View attachment 33915

If you compare the flight record to the video then it is apparent that the video starts at around 47 s. The problem is indicated by the yaw value of 115°, because the camera view is SW on a heading of 235° (measured on Google Earth). That discrepancy of approximately 115° causes the aircraft to apply corrections that are nearly orthogonal to the correct direction in order to try to hold position. This leads to the classic toilet bowl effect and loss of control as shown by the out-of-phase velocities north and east and the resulting position plot:

View attachment 33916

The problem was most likely due to taking off from a location with magnetic distortion. After the yaw was initialized at 280° before takeoff (when it should probably have been around 35°), there was an initial rudder command at 22 s (not in the video), while hovering just off the ground, that resulted in an appropriate CCW rotation, but it did not fix the incorrect yaw value:

View attachment 33917

The problem would have been detected if the OP had compared the indicated yaw on the map to the actual direction that the aircraft was facing. This is an important check before takeoff as it is the most direct indication of magnetic interference and the subsequent risks of loss of control or a switch to ATTI. Had the aircraft switched to ATTI mode then the aircraft would have stabilized (although with drift), but in this case it did not do so before the crash.

How are you getting the velocities? I can't seem to figure out which trace your using or what your doing to it.

 

[Jameslavis]

@sar104 what pilot errors do you find with pilots and ATTI mode?

 

[sar104]

How are you getting the velocities? I can't seem to figure out which trace your using or what your doing to it.

From the txt log those are OSD.xSpeed and OSD.ySpeed, which are velocities north and east in the earth frame of reference.

 

[MavicCF]

How are you getting the velocities? I can't seem to figure out which trace your using or what your doing to it.

never mind, I think I found them in the X and Y speeds.

 

[MavicCF]

From the txt log those are OSD.xSpeed and OSD.ySpeed, which are velocities north and east in the earth frame of reference.

Lol, thanks! I think you must have told me telepathically.

 

[sar104]

@sar104 what pilot errors do you find with pilots and ATTI mode?

It's not so much pilot errors - it's just that most pilots who have not practiced in ATTI mode, which is hard to do with a Mavic unless you have reprogrammed the mode switch, have no idea how to control the aircraft.