Crash due to immediate downward pitch on RTH activation

Hey Folks,

I’ve been using an APM for about 9 months now and been quite happy with it. I had a big crash today where I launched my Skywalker 1880, switched to FBWA then RTH to let the plane circle while I put on my goggles. This is a new airframe but I have a few flights on this setup and had already used the RTH just moments before where it worked fine and landed to change batteries but this time as soon as I selected RTL the plane plunged into the ground.

I’m reviewing the log and .kmz file. I’ve never done this before so it’s a bit of a learning curve

Firmware: Ardupilot 2.78b
Hardware: RCtimer 2.5
uBlox CN06 GPS PLUS (mag not used on this unit, only GPS)
3DR current sensor

I can see in the .log that my ALT_HOLD_RTL is set at 12500
My alt on GPS peaked at 73.09, a few lines later MODE changes to RTL and ALT decreases in the next GPS lines and keeps decreasing until impact.
I think the pitch is increasingly negative on ATT then peaks positive as I switch back to manual mode to pull up at the last minute. I checked the direction of travel caused by movement on the ailerons and elevator in FBW mode in my preflight and it was correct.

Is there any chance anyone could look at my log please? See if there is anything I’m missing?

dropbox.com/s/voyxb0ou3yxzj … 009-51.log

This is the track:
i.imgur.com/BAOnx2x.png?1

This is the track from 20 minutes previous:
i.imgur.com/Z5Q7jQE.png?2

Ok, I’m assuming that this is a bit of a known issue and none wants to touch it at this stage… :confused:

That’s fine, but can someone recommend a stable version of Arduplane for me to use?

I hate to break it to you Matty but the 3DR tech support people are are paid to support customers who purchased hardware from 3DR. I suggest you see if you can get some support for your board from RC Timer.

I didn’t realise this was a hardware support forum and what you’re saying sounds quite reasonable.

I wouldn’t be here if I suspected the hardware. :confused:

I appreciate that you’re just doing your job, but at the moment I’m feeling a lot less guilty about not supporting 3DR in my purchase and will be much (much) less likely to buy 3DR gear in the future (some of my electronics are 3DR currently).

Thank you for your assistance.

Heya Matty,

You wouldn’t happen to have a .tlog of that flight, would you? As it is, the .log file isn’t much use, as it doesn’t contain any of the relevant data. Try enabling all the logging before your next flight, maybe with the exception of attitude_fast, because that hogs space and is not really needed for this sort of analysis. Be aware that the dataflash for logging will only accept about 20 minutes of data before it starts overwriting itself…

No, I didn’t really know about logging before this incident so hadn’t turned on my extra logging options. :unamused:

I have turned them on now though and have started to realise that the logs I have aren’t very helpful. Next time I shall be better prepared! It would be very helpful for me though if you would be able to cast a quick eye over the settings in the log I posted to see if anything is amiss!

Thank you! :smiley:

Two questions:

Do you have an airspeed sensor on your plane?

Are you using a ground station/telemetry?

No airspeed sensor.

I was not using the ground station for this flight.

I realise the profile makes a stall a pretty likely culprit but i’m reasonably sure that there was enough airspeed by considering the GPS airspeed and accounting for wind (if that’s even possible). I was launching into approx 25km/h wind. I know stalls in moderate winds are much more likely without an airspeed sensor.