Weird Auto mode beep and throttle cut, crash. Pixhawk 2.1 S1000 TFmini

Hi everyone. Was in auto mode and lidar terrain-following waypoint mission about 1/3mi away then lost telemetry and rssi due to an obstruction, so the copter was just hovering since I had all failsafes turned off (dumb I know). I flicked the RTL switch on my tx and set RTL in the GS actions tab, no response. I ran down the hill to try and get a signal, then suddenly telemetry updated and showed the copter was upside down on the ground in stabilize mode. Reviewing the video footage, I could see it hovering in loiter, then it beeps after receiving auto command and flies to the left towards waypoint 4 for 8 seconds and finally beeps again and the motors shut off resulting in a freefall crash. This was in a remote desert area, no wind, about 95deg F, 2nd flight of the day. In both flights during auto mode I had terrain failsafe which engaged RTL due to not high enough RNGFND_MAX_CM, default was 600 but due to uneven terrain it would cause vert pos mismatch when I passed over a deep ravine. It’s supposed to switch to baro alt hold but doesn’t seem to, but that’s a different problem… Thus I continued in manual mode north along the formation, then tried to re-engage auto mode when I lost signal and the crash happened.

Reviewed the logs and nothing obvious, VCC stable so no brownout/reset, 19-20 sats GPS 3D fix, commanded roll pitch yaw all matched actual, sonarrange was reading correctly till the end. no indication why ThrI was reduced and the drone fell since RC Channel 3 was at 1500 and waypoint alt is set at 5m. It is odd that stabilize mode changed after the throttle cut. Could this be a receiver failsafe command (running EZUHF 8ch PPM)? I have Stabilize (1000), Loiter (1500), and Auto mode (2000) on ch. 5, RTL on ch. 7 (2000 is RTL engaged), and motor interlock on ch. 8, (1000 is disarmed) tlog RC Channels doesn’t show that they switched off before the crash. Ugh, so frustrating. Here are the full dataflash and telem logs, crash occurs at 46:00-46:08, the tlog contains two flights, signal loss/crash is at 82% in the playback). Waypoints map here.

Super grateful for any insight on this, thanks in advance!!

Just a couple of observations.
Your logs don’t have Rain or RCout, which makes it a bit hard to see what is physically happening.
Your flight modes were constantly switching out of Auto into stabilise or loiter.
You only reached command#1 in auto
You had a FS:Terrain Data Missing
The only thing I can see from the .tlog is that when you switched to Auto and the RCout went to zero

It matches the RCin where channel 3 goes to zero.

So maybe you have struck a combination of things where even though you switched to auto it followed the RCinput.

1 Like

Hi Mike! Thank you so much for the feedback, been super busy so sorry for the delayed reply. I believe you’re right, that it had to have been the EZUHF receiver failsafe which I forgot about, since motor interlock are off and mode switch defaults to stabilize that would make sense. What doesn’t make sense is no alarm “NO RC RECEIVER”, tlog doesn’t show channel 8 or 5 going to 1000, or any other indication it actually did a radio failsafe. But since it didn’t log RCIN/OUT in the dataflash log, I can’t really be certain. It’s just odd that RC3 went to zero first, and mode switched to stabilize after, which seems the opposite of a motor interlock kill switch. smh.

The terrain failsafes are certainly from being at the end of the TFMini outdoor range (5-6m) when we encounter a valley or dip, it goes out of range and Vert Pos Variance triggers the terrain failsafe. We tried replacing with the Lidar Lite v3HP which has 40m range yesterday. Sadly that unit (in I2C at least) won’t hold altitude in loiter, it increases vertical oscillation slowly till it’s 3feet above and below and I return to stabilize. Increased RNGFND_GAIN to 1.0, 1.8, improved at first but eventually starts oscillating. Reset that back to 0.5 and increased Alt Hold P value incrementally, that didn’t do jack. The Lidar Lite raw value only varies by 1-2cm every few seconds when measuring statically, so maybe that is the source of the “toilet plunger” effect haha. We installed in with 1000uF cap on the power lines, but no pullup resistors on the data/clock lines since others reported it wasn’t necessary on the latest v3 and HP. Will keep testing and post that in a new thread with logs on Monday. Thanks for your support!!!