V3.1.0 RTL Flyaway crash investigation

ArduCopter Copter 3.1
1

Apologies for the verbose description here. Trying to give full account as known to date.

X frame quad-copter, with an APM 2.5 on V3.1.0 firmware, had been flying in low wind conditions, with some bush fire smoke haze (its summer down here) and overcast conditions. Temp was about 25 C. RTL with auto-land was selected.

All was normal, till the model paused for the landing phase. At this time it started to drift off. The system was initially allowed to drift, but it failed to correct. At this time RTL was changed to STABILIZE, with the drift increasing dramatically, resulting in a damaging collision with an aerial mast and the ground.

It has been determined that

  1. the pilot had been attempting to trim model drift with Tx trim settings, which resulted in abrupt attitude changes when flight modes were changed
  2. he can not be 100% sure that the model orientation was not out 180 degrees, meaning he compounded the error, in lieu of cancelling it.

The current investigations lay in attempting to gain access to the log files, to attempt to verify aircraft attitude / direction of flight, and why it initially drifted.

This leads to the main reason for this post:

When accessing the APM via MP terminal to download the logs, the system locks up and will not ‘dump’ any logs. Reviewing of the logs indicate these are # 70 - 96, with 70 being the newest log file, 71 being oldest and thus circular logging and overwriting data is being completed.

Attempting to download “all logs” locks after some time on the first log (assumed to be #70). Trying to download just log #70 results in no data at all.

Is there any way to access these logs and extract the relevant data of the RTL phase of the flight?

2

Found the answer by using PuTTY.

Connect the APM to MP and verify COM port and baud rates, then disconnect APM from computer USB
Set putty to log all screen data.
Set putty for a serial interface using the above com and baud rates
Connect the APM to the computer USB
Open the putty session
When you start to text on the terminal screen hit [enter] 3 times

You should now be connected to the APM interface. Go to your logs and attempt to ‘dump’.
When you find a corrupt value that ‘locks’ the interface, no worries, putty has captured all the data in its screen logging file.

Repeat process as many times as you need to get all your log files.

Review a ‘normal’ MP log file output to reformat (delete) unnecessary lines from the PuTTY capture. You now have your ‘corrupt’ log file and possibly many uncorrupted files.

On my APM I had log files numbering from 70 to 94, with corrupt files in 70, 72, 73, 74, 75, 76. The remainder were just fine. (71, 77-94)

3

Hope you get the logs, but until then, as for point #1:
The pilot was apparently completely unfamiliar with how such flight modes, and radios work.
Autopilot have no chance of differentiate between stick input and trim, any auto mode that leaves the operator authority, like Loiter, OF_Loiter, Land, Drift and other assisted modes, would treat a trim as continuous stick input. - As it did, once RTL entered to land mode. (and you thought of it as “drift”)

RC channel trim is simply not something should touch. basic autopilot understanding. :slight_smile: