Copter uses last seen RC from SBUS in spite of receiver settings to the contrary

ArduCopter Copter 4.3
, , ,
1

Running Copter 4.3.7 (with a custom motor mixer so I can’t easily upgrade right now).

With an X8R FRSKY receiver configured in “no pulses” failsafe mode, and with a saleae logic analyzer hooked up to the sbus lines going into the cube, I can see proper RC commands make it on the wire and read by the cube. When I turn the transmitter off, I see 0’s go out on the wire and the failsafe bit set, but the cube sees the last input RC channel. Is this some kind of known bug for 4.3.7? FS_THR_VALUE is set lower than the lowest possible input throttle value via stick, but the flight controller sees the last real throttle value instead of what is on the sbus wires. It seems to ignore the FS bit as well (or else is still seeing the last FS bit). When the Receiver is ultimately unplugged from the cube, the cube seems to detect it’s loss and trigger the failsafe.
I have used the receiver manual to reset it’s failsafe mode to “no pulses”, but it doesn’t matter what I do, it seems that when the receiver goes into failsafe mode, the readings are no longer respected by the cube.

I have also started a Discord chat for this issue here

2

Provide a .bin log where this is happening.
You can set LOG_DISARMED,1 for bench-testing.

3

Log

Thanks, not sure why I didn’t think to post the log before. In spite of RC_OPTIONS set to include logging, there are no RCDA messages present in the log.

When plotting, you’ll see input on channel 3, then a flatline, this was when we shut the transmitter off. We turned it back on, changed the throttle again, and turned it off for a second time.

Let me know if more or different logging is necessary. Thank you for your help

4

When we disable the scripting interface, the problem goes away. I’m not sure if it is a specific script or if it’s a consequence of running the whole scripting engine.

5

The culprit is a lua script designed to toggle a relay. Below is the original script

-- example of overriding RC inputs

local RC14 = rc:get_channel(14)
function update()
   RC14:set_override(1900)
   return update, 10
end

return update()

When I add a delay, the RC Failsafe from the SBUS is respected. Whenever this command triggers, the RC Failsafe is ignored. This behavior is present in 4.5.7

Still, without this script, when the receiver is in failsafe mode, the rc channel values seem to be ignored, and I’m not sure what to do about that

6

Rather than overriding the RC input channel, why not just set the GPIO/ relay ?

7

I tried several things before I arrived at this approach. Ideally, that would be what I would do, but it wasn’t clear to me how to get that to work…

Edit:
Also, what is the expected behavior when there’s 0’s for the channel readings and the FS bit is set on SBUS? Should the RC channels be recorded as 0’s (or the appropriate pwm signal), or are all channel readings invalidated?

8

This is a simple script I use to turn on and off a video transmitter that would overheat if left on.
There might be something there you can use.

--[[
 Script to toggle relay pin
 from arming status
 so the VTX can be automatically
 powered on and off

 Set 
 SERVOx_FUNCTION,-1
 RELAY1_FUNCTION,1
 RELAY1_PIN,55 (to match the chosen Servo channel)
--]]

-- set a bad value so the armed test is gaurnteed to be run
local last_armed = 3;

-- check for a relay
if relay:enabled(0) then
	gcs:send_text(5, "VTX power under scripted control")
else
	gcs:send_text(5, "VTX power incorrect config")
	return
end

function update () -- periodic function that will be called

	local armed = arming:is_armed()

	 -- only make changes if the armed status has changed
	 if armed ~= last_armed then
		if armed then
			relay:on(0)
			gcs:send_text(5, "VTX power on")
		else 
			relay:off(0)
			gcs:send_text(5, "VTX power off")
		end
		last_armed = armed
	  end
	return update, 1000   -- request updates every 1000 milliseconds (1 second) after script is loaded
end

return update, 1000
1 Like
9

I’ll try this and report back

10

https://ardupilot.org/copter/docs/common-lua-scripts.html

Use your script to get the RC channel PWM, then set the Relay accordingly.
In parameters don’t set the relay to operate directly from an RC channel, but the LUA script instead - therefore no override required.

11

Any chance you can speak to this?

12

Unsure - all I can suspect is that overridding the RC channel input was also overriding the RC lost status. The RC failsafe bit in SBUS should override everything else in theory.
I’ll see what goes on in the code and let you know - but I believe the correct way to proceed is to operate the relay solely via the LUA script.
You can even put something in the script to ensure desired relay action during RC failsafe.

1 Like