Throttle goes low when failsafe is triggered, causing some altitude loss.

[ghost]

Current Behavior

When a signal loss failsafe occurs. The Auto Throttle will reduce as low as 1%. For a period of around 1 second.
This will cause the Quad to drop and loose altitude. Which is bad if the quad is close to the ground at the point failsafe occurs.
I have seen the altitude drop up to 10 meters, during this time. And its real bad, if multiple failsafe events occur in succession!

But if failsafe is triggered with the mode switch. Auto throttle maintains the same throttle that it had before failsafe was engaged. So the quad looses NO altitude, before it begins to climbs to RTH fly home altitude.

Expected behavior

Auto Throttle should hold the present throttle Output value it had before the signal loss failsafe condition occurred. This way, the quad will not loose any altitude.
Or at the least - Allow the throttle to revert to hover throttle in this period of time.

---

master - diff

set looptime = 2000
set gyro_hardware_lpf = 188HZ
set gyro_lpf_hz = 100
set gyro_stage2_lowpass_hz = 220
set acc_hardware = MPU6000
set acczero_x = 173
set acczero_y = -10
set acczero_z = -137
set accgain_x = 4120
set accgain_y = 4114
set accgain_z = 4036
set align_mag = CW270FLIP
set mag_hardware = QMC5883
set mag_declination = 1180
set magzero_x = 280
set magzero_y = -69
set magzero_z = -300
set baro_hardware = BMP280
set pitot_hardware = NONE
set receiver_type = SERIAL
set min_check = 1020
set max_check = 1980
set rssi_min = 59
set rssi_max = 4
set serialrx_provider = SPEK2048
set rx_min_usec = 940
set rx_max_usec = 2060
set min_throttle = 1010
set max_throttle = 2000
set min_command = 980
set motor_pwm_rate = 1000
set motor_pwm_protocol = ONESHOT125
set failsafe_delay = 15
set failsafe_throttle = 1475
set failsafe_procedure = RTH
set failsafe_stick_threshold = 0
set align_board_pitch = -4
set vbat_scale = 1080
set current_meter_scale = 321
set current_meter_offset = -20
set bat_voltage_src = SAG_COMP
set yaw_jump_prevention_limit = 220
set model_preview_type = 3
set small_angle = 120
set disarm_kill_switch = OFF
set auto_disarm_delay = 0
set gps_provider = UBLOX7
set inav_reset_home = FIRST_ARM
set nav_disarm_on_landing = ON
set nav_extra_arming_safety = OFF
set nav_auto_speed = 1390
set nav_auto_climb_rate = 555
set nav_manual_speed = 1390
set nav_manual_climb_rate = 400
set nav_landing_speed = 220
set nav_land_slowdown_minalt = 400
set nav_land_slowdown_maxalt = 1000
set nav_emerg_landing_speed = 240
set nav_min_rth_distance = 400
set nav_rth_alt_mode = EXTRA
set nav_rth_abort_threshold = 20000
set nav_rth_altitude = 3500
set nav_mc_bank_angle = 22
set osd_video_system = PAL
set osd_rssi_alarm = 85
set osd_time_alarm = 7
set osd_alt_alarm = 120
set osd_dist_alarm = 1500
set osd_neg_alt_alarm = 1
set osd_artificial_horizon_max_pitch = 40
set osd_coordinate_digits = 8

• INAV version string: 2.0.1 and 2.1.0

[giacomo892]

Do you mind attaching the blackbox file?

[ghost]

Here is the log that I got those screen shots from .
LOG00007.zip

[giacomo892]

You or your radio is setting throttle low

[ghost]

Its not me. Im in the middle of flight.

I always set RX throttle failsafe to low position. Isn't that the normal RX failsafe procedure?
Would that cause the problem?

[giacomo892]

You should not do that.

[ghost]

Thank you for your time and replies.

I'm using Spektrum serial. With the RX failsafe, as stated.
Switches are presets to trigger Alarms and Mode switch Failsafe. Control sticks are centered and throttle is set low.
Plus I also have the failsafe outside pulse boundaries in inav setup, to trigger it, if an RX connection comes loose. etc.

I can understand how this would have caused the problem. If the FC see's the RX failsafe condition before it see's the outside pulse boundaries limit.

It seems a better practice to rely on two failsafe procedures. And not just the outside pulse boundary limits.

I have never tried this scenario..... But if a preset low throttle RX failsafe will shut the throttle down. Then wouldn't activating mode switch failsafe and lower the throttle manually. Make the quad fall from the sky too?

I would think it be better and safer if the code for this procedure waited for a second (maintaining the last throttle setting) after it see's a possible RX failsafe trigger. Until it then see's the outside pulse boundary failsafe.
Then it can initiate RTH procedure. Otherwise it lands.

I don't see the reason that the FC takes notice of the RX failsafe mode switch, that will triggers RTH/Failsafe. Then would shut the throttle off, in response to that RX Failsafe as well.
This would be a contradiction. Surely the code writer would have know that it can't RTH with no motors spinning : )

Why does it take notice of the throttle position, when the Failsafe mode switch it triggered. Either manually or by RX failsafe?

If the answer is - not sure. Then I consider this a bug.

Thanks again

P.S.
Was looking through the inav CLI wiki. And found this -

rx_nosignal_throttle - HOLD

Defines behavior of throttle channel after signal loss is detected and until failsafe_procedure kicks in. Possible values - HOLD and DROP

I wonder how this is connected? Konstantin, do you know more about this?
MSP_RX: throttle does not return to zero in case of "lost signal" #1558

[giacomo892]

Can you make the throttle hold it's position instead of going low? you will be fine then.

[ghost]

@giacomo892
I can set the RX failsafe Hold function with the throttle at 1500uSec (hover throttle). And as you said...I'm sure it should work then.
But I'm far from convinced that this is a good practice.
Its more like an un-safe work around, to make up for code inadicquacicys.

[giacomo892]

Issue is that you set the throttle to low before you trigger FS.

[ghost]

I understand that's what it looks like.

Here is a picture from the DVR. That I pause framed, between all the video breakup.
This FS occurred as I flew through a long line of tree's, that caused signal loss.
The image shows that the throttle went to 1% under Auto Throttle. Not manual.

[wx4cb]

what's your cruise throttle set to? I had a similar thing (14%) then i realised that i'd fat fingered the cruise throttle

…

On Mon, 21 Jan 2019 at 16:02, kardon18 ***@***.***> wrote: I understand that's what it looks like. Here is a picture from the DVR. That I pause framed, between all the video breakup. This FS occurred as I flew through a long line of tree's, that caused signal loss. The image shows that the throttle went to 1% under Auto Throttle. Not manual. [image: fs in auto throttle] <https://user-images.githubusercontent.com/43928973/51498720-bddf7780-1e1b-11e9-8b3b-f05e03594c51.PNG> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4240 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABbRAdSz-VWKg_uuZrjp36yfJD_Wtyfrks5vFirXgaJpZM4aKUCt> .

[digitalentity]

Found a possible issue in the code. Will submit a fix ASAP (it's not too late to get it into RC2)

[digitalentity]

The issue is triggered because of manual throttle going to zero BEFORE failsafe activates. And the bug triggers "take-off" mode where we start from negative climb rates and heavily rate-limit the ramp-up. If your remote would keep throttle - this bug won't be triggered

[ghost]

@wx4cb
I'm sure that only applies to fixed wings. Its default 1500uS

@digitalentity
Thank you for looking into the problem Konstantin : )

[ghost]

The issue is triggered because of manual throttle going to zero BEFORE failsafe activates. And the bug triggers "take-off" mode where we start from negative climb rates and heavily rate-limit the ramp-up. If your remote would keep throttle - this bug won't be triggered

That's an odd one. It must have taken a bit of finding.
Thank you once more.

[wx4cb]

Dang. Yea i only have inav on fixes wings. But as an aside, im glad that something was found

[digitalentity]

Actually, that part of code is kind of hacky. I'll relax the constrain of rate-limiting the velocity to be more safe, but the final fix will require too much of an overhaul. It will happen eventually, but not during release-cycle.

[digitalentity]

This was a non-trivial one. Quite rare set of conditions to trigger the issue. Should be fixed with #4245 - will be part of RC2 which is going to hit the road tomorrow morning.