I let a friend borrow my iris+ last week and it crashed seconds after lift-off.  The front left arm sheared off completely and the the gimbal was ripped off too.  I am trying to review the data log to determine if it was user or hardware error.  Can someone help me make sense of the attached data log?

Views: 746


Replies to This Discussion

I had a similar experience with IRIS+ last year.  Turned out to be an accelerometer failure.  You might look at data from that sensor.


How do you analyze the accelerometer sensor data?  Looking at the graph the IMU.AccZ graph looks drastically different, but I have no idea what that is telling me.  Thank you.

Looks like operator error.  See no sign of malfunction.

What did you do to the power mananagement.  See no battery voltage or current readings.  Copter looks like it shutoff in mid flight.

Why was it flying on top of building.

Not sure I agree with you Michael.  Check the RC inputs on roll and pitch and then check the roll and pitch outputs.  While it appears that the roll stick is slightly out of calibration, as the trim on the roll stick in the parameters is 1500us but it appears center stick in the logs is closer to 1540-1550us (which is outside of the 30us deadzone), that should not be enough to command a 25 degree tilt on the roll.  It appears that the roll and pitch start to tilt more and more but the stick input does not.  Could be a drifting gyro though if the Iris was not held still while calibrating gyro on bootup.

Thank you so much for the feedback. I want to make sure I avoid this problem after I make all the hardware repairs. I was not there for the flight and the pilot was pretty new to flying. I do have a constant problem with the sticks being off center on the controller, but I showed him how to calibrate on the rc remote. I do not know how to fix it any other way. He took off from a roof that had a lot of rocks and seemed to think it got stuck on a rock, but it was still able to get airborn. Once it started banking hard he hit the RTL in hopes of recovering. Is there a quick explanation how you analyze the flight log data to come to your conclusion? I am an engineer by profession, but I do not understand how to sift through the data.

Once you get it fixed, fly it in a non-GPS mode first to make sure the IMUs are good before adding in GPS.  It could have been a simple GPS glitch.  So being able to really analyze the logs is not a simple task.  Requires an understanding of the log parameters, flight parameters, sensors and what the sensor data means, how the code uses the sensor data, and general understanding of how all of the components work.  So if you look at the ATT parameters, you can see that the Roll and Pitch both started to bank pretty immediately and pretty hard.  If it was a mechanical failure like getting stuck on a rock, you would see the desired roll/pitch deviate from the actual measure roll/pitch.  The fact that the desired roll/pitch and actual roll/pitch tracked really well, means that it thought it was supposed to be tilting that much.  So then you ask, why does it think it was supposed to tilt that much.  First answer is because it was commanded to tilt that much.  So you check the RCIN parameters (PWM inputs read from the receiver).  Channels 1 and 2 are pitch and roll.  If you scroll down through the parameters (not log parameters but the parameters that you set to configure flight capabilities), you will see the RCx_MIN, RCx_MAX, RCx_TRIIM, RCx_DZ.  Those are the parameters that get set when you calibrate the radio in Mission Planner.  They are the min, max and center PWM values that the radio/receiver operates at and the DZ is the dead zone in which the pixhawk uses to allow fluctuation from center trim.  So if center is 1500 with deadzone of 30, then as long as the PWM signal is between 1470 and 1530, the pixhawk considers it center stick.  So you can see your values are essentially 1000-2000 with 1500 center.  If you look at the log, channel 1 stays at roughly 1500 but channel 2 is steady closer to 1550.  So the 1550 on channel 2 would command a small amount of tilt, but not nearly as aggressive as it did tilt.  Had it been closer to 2000, I would have expected full tilt.  So now you have to wonder why did it tilt so hard uncommanded.  Usually this happens for 2 reasons...it is trying hard to reposition itself (trying to hold GPS position in hard wind or get to a GPS position it thinks it's supposed to be at) or the sensor data it is receiving is telling it that it's tilting one way and it's trying to tilt the other way to level out (gyro drift).  So this is why I say fly it in something like AltHold or Stabilize mode to rule out the GPS (possible glitch).  Gyros read rate of change.  So if a gyro is drifting away from zero, the pixhawk thinks that it is accelerating along a given axis and if that wasn't commanded, it will try to tilt the opposite direction to stop it.  So if a gyro drifts, it will try to tilt in the opposite direction to negate it and will tilt to max and crash.  It wasn't a failed IMU, as that usually shows up as a flatline in the gyro or accelerometer data.  So my guess it was either gyro drift caused by not keeping it perfectly still during gyro calibration during bootup or it was a GPS issue.  That's my educated guess.  What firmware are you on? Because the latest firmware looks for bad gyro calibration and won't let you arm.

Thank you for explaining in detail; that really helps me out. Unfortunately, I don't have it with me this weekend so I will have to wait until early next week to evaluate based on your response. I do not know when the latest firmware was released, but I am sure that it is not up to date. Everything was working so I left it alone; it seems like it would be a good idea to update after the rebuild and debug. Thanks again and I might have more questions next week!


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service