PX4: SBus Failsafe handling serioulsy broken

[hsteinhaus]

I just replaced my FASST PPM sum receiver with an SBUS Type (Futaba R6108SB). After that, the throttle failsafe recognition is completey messed up - fly-away is guaranteed on RX problems.

My setup: TX failsafe is configured to a CH3 value of about 950ms, all other channels are set to hold. Minimum normal throttle is about 1100ms. Arducopter is configured to recognize anything below 1000 as throttle FS. Using this setup, everything works as expected with the PPM sum receiver, including RTL on TX power cuttoff.

Behavior after changing to SBus input: All channels show different min/max PWM values: about 1180-1840ms instead of 1110-1930ms. This is nasty, as a lot of Ardupilot functions trigger on 1850ms.

After switching of the TX (Failsafe settings as above) the following values are shown: CH1: 0ms(!!!), all other channels contain the last received value between 1170 and 1840ms, including CH3 which should be well below minimum throttle due to the failsafe setting. This behavior could easily lead to a fly-away during any in-flight failsafe situation. A servo connected to CH3 additionally moves to the correct failsafe position slightly below min throttle, so I expect the receiver to output the correct value for CH3. As a cross-check, I tried a TFR8 SBus receiver from HK, it shows exactly the same behavior.

Versions: FMU 1.7, IO 1.3, Arducopter 3.1-rc5

[MRazgunas]

I have similar problems but, atleast my throttle drops to 900, but if stick mixing is on, the plane banks (roll channel 0 and servo output becomes RC1_MIN.

[rmackay9]

I'm planning to try out SBUS eventually on my Pixhawk because it's pretty important for Japanese users who mainly use Futaba so if I also find it's broken, I'll try and fix it. Of course, you're sure that you're using regular SBUS instead of SBUS2 right?

[billbonney]

I have just tested the SBUS output on the X8R from FrSky (it's supplied with the new Taranis radio). I've also measured measured a descrepency in that I see a range form 1166-1903 on Pixkhawk (its the same reading on MP and AP2 Radio calibratin screen). The radio is indicating an output from 1093-2012. (measuring on APM2.5 with D4R-II and Taranis ie. PPM Sum i get a reading of 1097-2000)

The output does seem to be outside normal tolerances.

PS the SBUS has uptp 16 channels, not sure if it's SBUS or SBUS2

[hsteinhaus]

My initial report is based on SBUS 1, using a conventional one-way FASST receiver in multi mode.

@rmackay9: Almost the same situation in Germany, Futaba (Robbe) has very large market share here. AFAIK there is no genuine Futaba receiver with PPM sum output. There are some from third party products, but lots of them suffer from a poor range - so no real alternative to SBus at all for Futaba users.

[billbonney]

I think with FrSky using SBUS instead on CPPM (PPM Sum) on there new receivers shipped with Taranis radio, that adds to the market as well.

It seems to me that the output is being compressed between two limits. So this may not be a decoding problem, but a output range limitation. Anyway, just idea.

[hsteinhaus]

Just digging through the sources - it seems that the SBus parsing is done by the PX4 IO Firmware, so this bug is probably completely unrelated to Ardupilot. Maybe better close here and continue and reopen in the PX4Firmware project?

The first find: the SBUS driver (src/modules/px4iofirmware/sbus.c) is well commented - but the assumptions stated there seem not to hold. They are talking about a minimum inter-frame gap of 7ms. The code seems to rely on this gap for synchronization. My scope says the gap is excatly 4ms, at least with my Futaba R6108SB.

Maybe somebody should add a word of warning and above SBus into the Pixhawk user guide - especially when advertising it as a feature?

[rmackay9]

Thanks for looking into that. I'm happy for the issue to stay on this list 'cuz it will help me remember that we need to sort it out even if the problem is in the PX4 stack. Of course raising it over there as well would also be good.

[hsteinhaus]

Took a deeper look on that issue and got three insights:

Wrong range of input: there is a very "sloppy" implementation of range conversion in the px4io firmware. I improved that one, currently testing. Will send a pull request these days.

Failsafe problem: the zero value on roll seems to be a "feature" of the original PX4 autopilot. They set the first channel to zero to mark failsafe situation and stop reading any other channels. So APM never gets to know that CH3 went low. I think the PX4 people do not really understand or do not accept the usual concept of throttle low failsafe. Maybe we need to discuss this issue or need to patch in the APM PX4Firmware fork, (which would be very easy to do).

Timing: might work reliably, as long as you do not activate the "digital" servo mode with faster refresh (which I did accidently).

Unfortunately I cannot do any test flying currently, as I am waiting for new props currently due to this issue: http://diydrones.com/forum/topics/falling-out-of-the-sky-during-loiter-reloaded . Maybe you might have a look, Randy ;-)

[hsteinhaus]

Range problems fixed, subject to testing by other users with different radio equipment. Pull request added: https://github.com/diydrones/PX4Firmware/pull/4

Failsafe fix in preparation.

[hsteinhaus]

Did successful flight testing today after re-basing the changes to 3.1-rc7. Would be nice if anybody else with different RC hardware could review and verify.

Do not forget to re-calibrate RC (I did of course) !

[rmackay9]

Thanks, i intend to give this a try in the near-ish future.

[hsteinhaus]

Did a short test on the master branch and latest diydrones/PX4Firmware after some changesets addressed the problem. Current status is NOT WORKING. On RC receiver disconnect a fly-away will occur - be careful when flying with SBus. I will look into this issue.

[rmackay9]

I've tested master a couple of weeks ago (as did Marco) and it seems to be ok. Maybe when testing you were expecting channel 3 to be pulled low to indicate a failsafe? In fact, what happens is that receiver updates stop arriving. If the throttle (aka radio) failsafe is enabled and the copter is armed, it should trigger a failsafe after 2seconds.

[VinceHogg]

Where are we currently with this issue? I have just stumbled into this problem while attempting to set up a pixhawk with Taranis/X8R. In MP radio setup, when TX turned off CH1 vanishes and all others 'hold' no matter what RX failsafe is set. This is a complete stopper as far as I can tell. Any advice welcome.

[rmackay9]

It should be fixed in AC3.1.1-rc1 which is now available through the Mission Planner's Beta Firmwares link.

[VinceHogg]

That appears to have fixed it, Phew

[rmackay9]

Great news. I'd like to hear back from hsteinhaus and then I'll close this issue.

[hsteinhaus]

Can confirm that, works as expected if armed. But I think it is very confusing not to see any throttle response on GCS display when testing my failsafe setup.

[billbonney]

I agree, it should be behave the same when not armed. Its confusing to have to arm to test the failsafe. The current behavior means you need you cannot check failsafe without removing props. I know the GCS warns about that when entering the failsafe view, but i think its much better to support easy verification before flight, in the field, of your setup.

[VinceHogg]

Now is seems to be working ok on the bench I have configured 3 channels that should all give RTL signals when TX is off. CH3 below 1000, CH5 default and CH8 RTL. When disarmed, MP is showing RTL when TX is turned off but it could be one of the other channels causing this and not Thr FS.I guess the low CH3 overrides everything else?

[hsteinhaus]

Another (not too critical) catch of the current timeout-based approach: I would like to put down my retracts on failsafe by configuring CH8 via TX settings to do so (channel passed through APM). This wont work currently, because the PX4IO drops all channel values if a failsafe flag is present.

I am testing alternative implementation right now, but this approach needs some discussion with the PX4 team (protocol change between PX4IO and FMU required). Will stay on this topic.

For 3.1.1, the current implementation should be fine as it brings a huge improvement compared 3.1, and seems not to have any critical problems.

[VinceHogg]

I too would like to retract the zoom lens and level the camera in the event of a failsafe. I will use channels direct from RX with programmed values for this. Cant you do the same with retracts?

[rmackay9]

Ok, great, thanks for the testing & feedback. I'll close this issue now.

@VinceHogg, generally we don't recommend that you set up the receiver so that it modifies channel 5. It's normally better to instead set-up the receiver to pull the throttle channel low (and leave all other channels as they are) or stop sending signals. Some receivers (including some popular frsky receivers) can't do that however. They force you to set a failsafe position for all channels. In those cases, what you've done is the best you can hope for.

@hsteinhaus , @billbonney, I'm not keen to artificially pull the throttle channel low during a failsafe. Instead I'll update the wiki page to clarify how to test depending upon whether the receiver is set-up to pull the throttle low or simply stop sending messages. By the way, there's no need to actually plug in the battery to test the failsafe. Instead plug in only the USB cable, connect with the mission planner, arm and lift the throttle, then turn off the TX and "failsafe" should be displayed on the HUD or in the failsafe page. I.e. the APM/Pixhawk doesn't know that there are no motors attached.

[hsteinhaus]

Hi Randy,

I think it is not absolutely necessary to pull the throttle low, but there must be some absolutely clear feedback for the user, that the failsafe has triggered - without any preconditions like arming. This part of the system setup is to important to allow any compromises in usability (IMHO).

Pulling the throttle low provides this feedback in a very intuitive way. Every user that has previously controlled an RC model (of any type) will understand and expect this type of feedback. What is the cost or negative impact of doing so?

Holger