i have opened discussion within “Log analysis” topic file. because Log Analyser can’t read my log file then I have requested assistance.
quad copter crash today while running a very short mission
I am running apm3.4RC2 and Mission Planner 1.3.39 - 13-7-2016
Strange event during mission : At WP #4 quad start to climb up keeping same position. It climbs for 5 minutes till i could not see it anymore.
No answer to RTL when i have actived mode
No answer to radio Failsafe when I shut down radio
But power issue make the Quad down.
I have attached camera under the quad so I got film and sound to listen for pixhawk beeping
Please look at log file attached in above discussion
Your opter never engage AUTO mode, you have ERR mode 6 in your log but I can’t tell you if related to firm, in case check your pwm values if they aren’t near limits.
hummm thanks for you feed back.
I am a bit disapointed because pb occurs approx on WP 4. At the begin it seems to me that Copter was running mission.
any how i ll check pwm value firts thing in the moning .
GPS is zubax and it is supposed to work normaly. I ll check configuration.
Bad vibration ==> OK i have noticed a non usual roll, pitch (during land phase)
Battery are new. but i have to deal with 2 type of LIPO 3S. one is 3DR 3S 5100mah other one A2PRO 6000mah. During the flight used battery was ne A2PRO 3S
6000mah. do you think that switching from one battery to another could disturb system ?
Thanks for your help. How did you get your graph ?
Regarding batteries: If all are standard LiPo, ie nominal charged tension of 4.2v per cell you must calibrate your tension/current sensor to get better readings - 3x4.2=12.6V - As a failsafe, I would go to 3.7V per cell 3x3.7=11.1V . Also when swapping different capacity batteries there’s a parameter that can be adjusted to tell the firmware how much can use.
I think maybe “47.BIN” is the wrong log file? It seems extremely short to me. It’s only 453KB and there’s only 36 seconds of data after the vehicle is armed.
Ah, there’s one bad thing here though… which is that MOT_THST_HOVER is really high. It’s 0.992189 (which would mean the vehicle hovers at 99% throttle) and I’m sure this is not correct. This points to the automatic hover learning code being tricked somehow.
I’d recommend lowering that to 0.4 before any further flight and you might want to set MOT_HOVER_LEARN to 0 to turn off learning.
When we get the logs we may have a better idea of what to do and whether the hover-learn is the problem.
According to previous comments (thanks to all of you), i found that my “Pre-Arm Safety Check” parameter was set to “disable”. So i gess pixhawk did not check for COMPASS, GPS, … before arming and starting mission.
I have changed parameter to “enable”. It could probably block arming process, but it would be more safe.
But still some questions. How copter could start with AUTO flight mode without GPS signal? If RTL function is invoked but could not be excuted for any reason (GPS signal off) , why not proceed with LAND function?
I have lowered MOT_THST_HOVER to 0.4 and set MOT_HOVER_LEARN to 0.
Weather is nice and little windy. So i decided to try new flight.
Quopter crash once again. hopefully without any damage!
Attached is log file (copy from embeded memory card)
Would it be due to the wind? i have noticed PITCH and ROLL. I believe that flight conditions are differents according to altitude. do you confirme that i shall turn off learning?
The 5.BIN log is from another flight which crashes most likely because of a bad/dead battery. Is it possible the battery was not fully charged? The battery starts at only 11.5V and drops very quickly to 10V. I wonder, have you flown this vehicle with Copter-3.3.3? It’s best to test Copter-3.4 with a known working vehicle so that we don’t muddy the water between frame issues and software issues.
Below is a graph showing the initial voltage is only 11.5V.
Here’s a graph showing the end of the flight in which the motor outputs go to full. This desired roll/pitch vs actual roll/pitch also diverge. This is the classic sign of a mechnical failure (including battery failure).
BTW, 47.BIN is the same file as I looked at before and I don’t think it’s the log from the initial crash that led to raising this issue. The log is really short and the vehicle doesn’t get off the ground. So I don’t think we have a log file from the climb-up-till-battery-run-out issue.
As a side note, from the 5.BIN log, the vibration levels seem pretty normal (always less than 20m/s/s) so that wouldn’t explain the climb-forever problem.
