Uncontrollable altitude, drone goes above 500m

[BudWalker]

Looking at this from a slightly different perspective. The ctrl_acc_vert_debug:acc_fdbk shows an abrupt decrease at the begining (262.6 secs) of the incident. The response is to increase and hold the ctrl_acc_vert_debug:acc_cmd causing the AC to gain altitude. Don't see a reason for ctrl_acc_vert_debug:acc_fdbk to decrease. Possibly a hardware glitch. IMHO.

 

[boblui]

During hover AccelZ will be 0.0. But, it won't be 0.0 when there is horizontal acceleration and the AC is tilted. The Z axis dips down into the horizontal acceleration and AccelZ = sin(tilt) * horizontal acceleration. Since flights are typically flown in the positive X axis direction IMUCalcs:totalAccelZ:C will show a positive bias. If a flight were flown backwards then IMUCalcs:totalAccelZ:C would have a negative bias.

I see....

Just a suggestion, since there are already the fields PosN :C and PosE:C in IMUCalcs, it will be very useful if an additional field to indicate the vertical position ( PosV:C ) can be included to complete the data set.

 

[@RYZPHOTO]

Thanks for all the help guys!!!
Should I just replace the IMU?

 

[boblui]

Thanks for all the help guys!!!
Should I just replace the IMU?

It is unlikely that you will be able to find the IMU board. Just send it back to DJI for repair. The drone is clearly defective. Hope it is still under warranty.

 

[@RYZPHOTO]

It is unlikely that you will be able to find the IMU board. Just send it back to DJI for repair. The drone is clearly defective. Hope it is still under warranty.

Unfortunately it is out of warranty and I'm also stuck in Bali until who knows when.
I have found a local repair place that says they have stock of the IMU, I'm just worried that it might not be the IMU causing the issues...

 

[Fred Garvin]

...I have found a local repair place that says they have stock of the IMU, ..

If they're a repair facility with parts in stock, shouldn't they be able to diagnose the issue and fix it?

 

[@RYZPHOTO]

Money is super tight so I need to replace it myself, I have watched a tutorial on it and it seems pretty straight forward.
I have repaired my old Inspire 1 and Phantoms in the past without issues so it should be fine, I just want to be sure its the IMU causing the issues as its a $100 part here.

 

[sar104]

IMUCalcs:totalAccelZ:C has been increasing throughout the flight. ie, the craft was sensed to be going downward / backward on average throughout the flight. Looks like the IMU has sever bias but the OP has already calibrated the IMU for multiple times. Can't figure out why.

View attachment 108358

During hover AccelZ will be 0.0. But, it won't be 0.0 when there is horizontal acceleration and the AC is tilted. The Z axis dips down into the horizontal acceleration and AccelZ = sin(tilt) * horizontal acceleration. Since flights are typically flown in the positive X axis direction IMUCalcs:totalAccelZ:C will show a positive bias. If a flight were flown backwards then IMUCalcs:totalAccelZ:C would have a negative bias.

Note that AccelZ will be -1, not zero, in hover, due to the constant 1 g acceleration upwards in the gravitational field.

 

[BudWalker]

Note that AccelZ will be -1, not zero, in hover, due to the constant 1 g acceleration upwards in the gravitational field.

Yes, of course. I had forgotten that to make totalAccelZ more meaningful the ImuCalcs package biases accelZ before integrating; i.e. totalAccelZ = time integrated (accelZ + 1.0).

 

[sar104]

Yes, of course. I had forgotten that to make totalAccelZ more meaningful the ImuCalcs package biases accelZ before integrating; i.e. totalAccelZ = time integrated (accelZ + 1.0).

With the added subtlety that accelZ is in the frame of reference of the aircraft, not earth FOR, so simple integration of accelZ isn't physically meaningful. I think we discussed before that the accelerations and rate gyro data should really be transformed to the earth FOR before integrating.

 

[BudWalker]

With the added subtlety that accelZ is in the frame of reference of the aircraft, not earth FOR, so simple integration of accelZ isn't physically meaningful. I think we discussed before that the accelerations and rate gyro data should really be transformed to the earth FOR before integrating.

I haven't forgotten. The discussion at the time was about transforming gyro data to the earth FOR. totalGyro[X,Y,Z] in the AC FOR is still useful, but it'd be better if it were earth FOR. I just haven't gotten around to implementing it.

From recent experience it's clear that totalAccel[X,Y,Z] in the AC FOR is pretty useless. It really needs to be in the earth FOR. Since I'm not going to be able to get to it soon I'm thinking I'll just remove the totalAccel[X,Y,Z] stuff until I can get to it.

 

[sar104]

I haven't forgotten. The discussion at the time was about transforming gyro data to the earth FOR. totalGyro[X,Y,Z] in the AC FOR is still useful, but it'd be better if it were earth FOR. I just haven't gotten around to implementing it.

From recent experience it's clear that totalAccel[X,Y,Z] in the AC FOR is pretty useless. It really needs to be in the earth FOR. Since I'm not going to be able to get to it soon I'm thinking I'll just remove the totalAccel[X,Y,Z] stuff until I can get to it.

I have the numerical routines to do those transformation that I implemented in Igor Pro, if you want to use them, although they might add significantly to the computational load in DatCon.