Change mode in flight

I flight sky suffer X8,yesterday for the first time with pixhawk ,I transfer to autotune mode after take off above 150M hight .the plane suddenly climb in 90 degrees several seconds then become nose down ,I transfer back to manual mode immediately and keep flight in manual.in order to find out what happen to to flight controller,I try to transfer to the autotune mode again after climb up to about 200 hight ,but the plane keep nose up in 90 degrees then become nose down again,so I try to transfer back to the manual mode ,but the plane didn’t come back to manual mode ,and the plane crash!
I analyse the Tlog and dataflash log ,and find out that it’s because pitch servo out reverse.but the question is that why I can’t change back to manual ? I found the RSSI is OK in the data flash log,and the telemetry control signal is OK ,the plane is away from me just about 500M
Do anyone have any suggestion to analysis this accident ?
by the way the channel 5 is mode change and it works good in the ground .

Can you give us the dataflash log?

https://drive.google.com/file/d/1Ae66omTarz0i1cpHk3cM3gf_tMbnkWwB/view?usp=sharing thank you,please download the file in the link.

https://drive.google.com/file/d/1lhLIVs2sIyMN8YjcFJan2Zmq8NiM6pQ_/view?usp=sharing this is the tlog download link

I am looking at your log. Are you sure this is the right one?

It looks like you crashed in LOITER mode, but that doesn’t match how you described the flight. From this, it seems that you never climbed to 150m altitude, you never entered AUTOTUNE mode at all. Here are some plots during the log.

APM20180909_crash_latlng

The top altitude plot is the entire flight, and the bottom is zoomed-in on what appears to be “the crash”. The blue line is Altitude, and the black-lines-with-circles indicate the flight mode switches: The value is 5*flight_mode_number. So the majority of the log was in MANUAL (mode_number=0) at an average altitude of 30m. There was a mini-flight around 01:55:00 and the major-flight takeoff was around 01:59:30.

To understand the plane’s position, I have also plotted the latitude and longitude of the flight path. The GREEN area is the entire log BEFORE the main takeoff at 01:59:30. The blue line is the main flight before the crash, between 01:59:30 and 02:02:20. The RED area is “the crash” from the LOITER command at 02:02:20 to the end of the log.

We see in the bottom plot that at 02:02:20, the mode is changed to LOITER (mode_number = 12, so the plot-circle is at “60”). While in LOITER, the plane appears to crash, going to -20m altitude. Around 02:02:22, the fight mode is changed to MANUAL (mode_number = 0), and then later, at 02:02:38, the flight mode is changed to RTL (mode_number = 11, so the plot_circle is at “55”).

So… am I misunderstanding something? Does anyone see that I’ve made some mistake in the log analysis, perhaps?

hi hunt,thank you for analysis my log,I’m sorry about that i upload the wrong log file which is another crash several days before(09-09-2018),i want to change to the autotune mode,but change to the loiter mode.the reason of crash may be the pitch servo out reverse.the plane should come back to level when I change to any stable mode if the servo out is setting right ,but I ignored the preflight check and set the pithch servo out reverse,thant means the plane’s elevator goes up when plane nose up ,normally the elevator should goes down when the plane nose up in order to come back to level .
I didn’t realize this mistake until the second crash at the day of 22-09-2018 .After second crash,I check the plane and found out the problem,because of pitch servo out reverse ,the plane climb up in 90 degrees when I change to autotune mode,but the problem is why I can’t change back to manual mode after I found the plane is out of control in autotune mode?i check ch5 in the dataflash log ,it indicated that the mode has change several time ,but I quiet sure I just change the mode twice !
the below link is the second crash log file which I describe above yesterday
https://drive.google.com/open?id=1Yd_uYa992XBZNswPRSCyhVD1XiMRCYVX
https://drive.google.com/open?id=1lhLIVs2sIyMN8YjcFJan2Zmq8NiM6pQ_

after I pick the plane back home ,I reconnect the power again and find out when I change the mode in my transmitter,but the mission planner tell the mode change until several seconds delay ,then I reconnect the power again and the mode change work OK!but I connect the power last night ,the pixhawk LED is no bright and no any sound after start up.I remove the pixhawk from the plane and connect to PC via USB cabble ,the pixhawk can be detect in the PC ,I guest this is maybe the hardware inop,so I send back to seller right now .but I’m not sure if it’s the hardware inop that lead to crash?

I am looking at the new log file. I have attached a plot of the plane’s altitude, and overlaid on it both the flight mode, and the RC Input Mode Channel (Ch 5) which should control the mode.

APM20180922_crash_altmode

The top plot shows the whole flight, while the bottom plot is zoomed-in on the crash event. I plotted 10*MODE so that AUTOTUNE (Mode=8) will show up as a value “80” and MANUAL (Mode=0) shows up as “0” in the black line. I also plotted RCIN.C5 as the pink line, but had to shift-and-scale it to fit on the same axis.

The log shows that you took off in manual, and switched to AUTOTUNE around 00:53:00, but switched quickly back to manual after seeing the plane lose altitude. You flew back up to above 200m altitude, and switched again, which began the crash, around 00:54:33. You remained mostly in AUTOTUNE mode as the plane crashed, with a very-brief switch into MANUAL, but then back into AUTOTUNE as the plane was descending rapidly. The plane crashed in AUTOTUNE mode.

Does my analysis agree with your memory? If yes, would you please re-state your question? (Sorry, I’ve gotten confused about what you’re asking.)

hunt,thank you for the analysis.

your analysis is quite agree with my memory, only one things i confused is that i change back to manual after seeing the plane decent before crash, but i can’t control the plane, so i just whatch the plane to crash. i take the plane home after crash, reconnect the power, and find out that the plane chang the mode until seval seconds delay, i still don’t know why?

—Original—

Is the “delay” you’re seeing between changing Ch5 of your transmitter, and seeing the new Mode on your Ground Control Station? If yes, the major portion of that delay is in the telemetry-communications between the GCS and the plane.

There is only about 0.2 sec delay between you switching Ch5 and the plane reporting a mode-change. (I zoomed in on my plot to verify it’s 0.2 sec)

hi hunt, you are really good at log analysis,.which software do you used for analysis?log analysis is really hard for me, I have read the tutorial in ardupilot website, but have a lot of things confused, where can I found the abbreviation in the log? how to plot the time in X axis? we can see a lot of abbreviation from the attached photo, i presume this is some sub systems in pixhawk. understand these whole system schematic and figure out each item in the system that great help to analysis the log. unfortunately,i didn’t find the right doc about this, the tutorial in ardupilot is not detail enough. do you have any suggestions about this?

thanks

simon.

—Original—

I co-wrote some log analysis software in MATLAB with @Georacer. I use that, but I don’t recommend it to anyone who isn’t very familiar with MATLAB.

Search these forums for other log analysis tools… I know of DroneePlotter, Mission Planner, and APMPlanner.

You are asking the right question… but the answer is not helpful. Unfortunately no one maintains documentation for what data is logged. To figure it out, you need to know how to find that information from the source code, and that requires being proficient at c++ and knowing how to search a code-base for information. If you want some hints about a particular abbreviation, take a look at libraries/DataFlash/LogStructure.h, libraries/DataFlash/LogFile.cpp, and ArduPlane/Log.cpp.

Or you could ask here, usually someone like me can answer quickly about some abbreviations.