I used pixhawk2 coptr3.5.2 helicopter. I used AUTO mode to let the heli fly autonomously. The heli climbed more than 100 meters following the waypoints, then suddenly out of control and crash directly.
From the log, both the height data and the sensor data seem to suddenly stop recording in mid air. However a short time later the EV event ended up recording a landing event, and then the label ‘Crash’. We cannot see the altitude drop in the log.
This log makes me feel very strange Ask for help
I attach the source file of this log for better judgment
Thanks！https://drive.google.com/file/d/1AIZRBgxa3SHCIwwwvvHU_dL68i501kQK/view?usp=sharing
1 Like
According to the log you were flying Copter 3.6-dev. It’s hard to say what happened. Probably lost power to the flight controller and it shut down and possibly rebooted.
If the flight controller rebooted, wouldnt the log stop immediately? It seems that this log still contains the final part detected the crash.
It seems to me that the flight controller has some fatal error that cause all computations to stop, but I am not sure…
It is very hard to tell from the log. I would best guess to be loss of power or brownout to have the logging suddenly stop and the aircraft lost all control. I had one recently where the power connector came loose from the board in flight and it would’ve done the same thing if not for the Power2 port being hooked up to a backup battery. Inspection of the board after the fact revealed cold solder joints on the power connector. And the Power2 connector was not any better.
you are reading it wrong:
What happened is that you had severe trouble controlling pitch, and the actual vs desired pitch diverged by >30° for over 2 seconds, which triggered the crash detection , and it simply disarmed. (and stopped logging most data as LOG_DISARMED=0)
- for some funny reason (maybe because it’s a dev build) it continued to log MSG,PARM, EV and ERR - but nothing from the sensors, hence you won’t see the descent.
So the “crash detected” you see is at top altitude, due to inability to reach desired attitude and not enough acceleration (it assumed it was stuck somewhere)
That’s weird. When I loaded that log file last night the data just stopped prior to the crash and it didn’t show the mode switches. Now, I re-downloaded it and loaded it in a different computer and I see the collective is maxed out.
Thank you for all reply，At first I also thought it was a power problem，But I’m connected to two sets of power，Power1 and Power2.
@Andre-K I looked at the log closer and that’s not what happened. This is a helicopter, and heli’s have the attitude controller active, and all the servos operate, even when the FC is disarmed. You can disarm in flight with a heli, switch to stabilize and autorotate the helicopter to a safe landing, flying it just like normal with the RC. A disarm in flight is not catastrophic for helicopters.
The heli was in auto mode and something failed but I can’t tell what it is. If you expand the timeline for the log the GPS quit first. The baro quit next and in between that the last message was received for system internal voltage. IMU’s, servo outputs and RC inputs continued right up to the crash, which is consistent in helicopters with the controller being disarmed.
Something caused the navigation system and sensors to crash and put the flight controller into a disarmed state (for heli’s) where the attitude controller and I/O continue to work. Instead of taking over manual control the pilot just watched it crash when the heli was still completely flyable in autorotation. The only control input I see made was on the collective after the hardware shut down. Flight mode was not switched from Auto to Stabilize where the heli can be autorotated. And the collective does not respond to pilot input in Alt Hold, Loiter, or Auto. Only Stabilize and Acro provide normal collective control for heli’s, and are the only two modes the heli can be autorotated in.
What the failure was is impossible to determine. But the sequence of when each piece of hardware shut down and logging stopped, but IMU’s, servos and RC is still logged to the crash is consistent with a disarmed controller in heli’s - and the system obviously shut the engine down when it happened. A power brownout could cause it, which is still my best guess even though the voltage messages show it to be ok before the logging on that stopped.
ok, if you don’t like my conclusion, feel free to stick to whatever alternative explanation that makes you happy. I won’t argue 
I have to ask, what is this software you are using to analyze these logs. The UI looks a lot better than in MissionPlanner, ie. these messages/flight modes are shown smartly.
APMPlanner2 , simply best for analysis, it has very powerful presets grouping/scaling options too.
Well, the graph you posted didn’t make sense with the heli is basically in a nose on the horizon attitude and the attitude controller calling for ~30 degrees nose down. Helicopters require forward airspeed to autorotate, or a lot of negative pitch. The control inputs are identical to airplanes in translational lift. The autopilot is a little “dumb” in that as soon as the engine quits it increases pitch to try to maintain altitude. Forward airspeed is lost, so the autopilot attempts to push the nose over (which is proper), but it already stalled the main because it didn’t reduce pitch when headspeed dropped.
I realized when I saw what the attitude controller was calling for when the nose is on the horizon that the engine in this helicopter wasn’t running. She was autorotating with a stalled main and not enough cyclic authority to push the nose over. The attitude controller called for increasing nose down in the fall but with the pitch maxed out it’s not going to happen.
What caused the engine and all the navigation sensors to shut down in flight remains a mystery. The heli was definitely was able to be autorotated successfully from that altitude - I’ve done it before. But you have 1-2 seconds to get into the negative pitch to get the main turning again, push the nose down and build airspeed. Once you get airspeed you can feather the pitch and the helicopter is flying again - it’s all a matter of angle of attack of the wing. BUT -you have to switch to Stabilize (or Acro) flight mode to do that.
2 Likes
The other thing I noted in the log is that the helicopter was using Mode 1 throttle, so the autopilot didn’t have control of the throttle. The throttle signal remained good and there’s a step in the output from 1719 to 1739 pwm, which corresponds with the same output from the RC and looks like the pilot switched into an idleup mode once the helicopter was airborne.
The fact that the throttle signal never glitched right up to the crash could mean the engine simply quit and the nav logging stopping before the crash was just coincidental. Regardless, the engine in the heli was definitely not running based on what the autopilot was trying to do.
(Like I wrote before, I won’t argue with you)
Just a hint: you zoomed it way too close, that’s why you think you “lost sensors” - if you zoom out a bit, you’ll see that the IMU messages are often updated at an interval that matches that “missing” data, moreover the EV and ERR messages have priority, and are written to SD ahead of the queue.
Yeah, it’s likely the logging sequence and why I said it’s just coincidental so the altitude loss didn’t get logged. I thought about a servo failure but the SERVO outputs aren’t consistent with that. When a servo quits the other two can still control the heli sort of and it doesn’t just suddenly fall from the sky. When the engine quits the autopilot is an expert at setting up a blade stop auto - except for the fact it doesn’t know how to recover from it