Servers by jDrones

Unexpected Heli RSC to Idle while in Auto Mission, FS_THR was correct?

(Chris Olson) #20

The Dominican Republic has at least one 440 ham repeater hooked to Yaesu Wires II, as I’ve talked to operators there on it before on the 440. So that means that if you hold a ham license you could use a more robust system like DragonLink on the 440 ham band. I use DragonLink on my long range heli’s and with the antenna on a 15 ft poke it can communicate with the heli on the ground at 10km and 20km is no problem with the heli in the air.

Investing in a more robust RC system like that, IMO, is worth it for safety if you fly long range. It does require the licensing issues, but realize that hobby-grade equipment does have limitations.

(Carlos Sanlley) #21

Sure will do but I have my concerns on how the ardupilot should have handled a 0 pmw signal in the ch 8 (Heli RSC) input regardless of the Tx/Rx range or limitations.

(Chris Olson) #22

I guess I’m not exactly sure why it’s doing that. Since I know the failsafe works with both my Taranis and the DragonLink I just fired up the Synergy with the DragonLink and hovered it. Then shut down the transmitter. It was within the range of “home” so it didn’t go into RTL and it just landed and shut down. But when the system went to “no pulses” and radio failsafe executed it held last value on all the channels.

(Carlos Sanlley) #23

Is it posible to assign Ch 8 as the channel that triggers the Radio F/S?

(Chris Olson) #24

I don’t believe so. Only the Channel 3 can be used. The code would have to modified to use Channel 8.

(Bill Geyer) #25

@ChrisOlson and @carlosanlley I spoke with Tridge about this. In 3.5.7, there is no fix for receivers that don’t update all channels in the same frame. He said that Spektrum receivers are known for this issue. He said that he put a fix in for spektrum receivers in 3.6. So this should be fixed for 3.6.3. As for the reason that the motor interlock doesn’t disable during the failsafe event, there is logic that hold switches at there current position during the failsafe events. That explains why the motor interlock didn’t disable during the failsafe event.

(Chris Olson) #26

I found this out last night. I did an experiment on the bench by arming, release throttle hold and bring the collective up, but didn’t start the engine in the heli. So for all practical purposes the system thought it was maybe flying. I pulled the wires out for the receiver so it wasn’t even hooked up. Let it do the failsafe and disarm by itself. Look at the log, and even without the receiver being hooked up it held the last value on all the channels for RC in.

I did not realize ArduPilot does that.

(Rob_Lefebvre) #27

Hi, this is a known problem that has never been fixed in Ardupilot-Master. I’ve just been porting fixes through my fork over the years. I just have never had time to fight the battle to get this pushed into Master.

The smoking gun is if you see 874 as a raw PWM value on Ch8 immediately after the Radio Failsafe clears.

(Chris Olson) #28

I was looking thru the code in master on this and I think it is a problem with the radio setup or firmware, and not in ArduPilot. It appears SBus 0 is 874. SBus 874 equates to channel blank.

Tested with OpenTx 2.2.2 on a Taranis X9D+ with both X8R and RX8R receivers, if the no pulses is selected at receiver bind, and the receiver is properly configured for no pulses, it rebinds all on the same frame every time. If only the transmitter is configured, but the receiver is not configured for no pulses, then some channels will show 874 on rebind and it takes a few frames for them to return to the values sent by the Tx.

So there may be problems with other radios too, such as Spektrum. But the question is, do we patch the code to cover third party hardware or setup problems? It is not ArduPilot’s fault that the RC channels don’t all come back at the same time. That is in the radio setup.

It appears ArduPilot does use the SBus failsafe flag

The problem would be if your receiver is not configured to set that bit if the SBus fails.

(Rob_Lefebvre) #29

Where is the documentation on how to set the failsafe in the Rx vs the Tx? I always set it in the Tx, and never knew anything different needed to be done in the Rx. I suspect you’re implying the FS has to be set in the Tx, and then bind the Rx. That’s what I do. I still get this problem anyway.

Regardless, it’s a common mistake. It’s not well documented. It’s not easy to test for. You can have 100 “clean” failsafe exits on the bench, and then 1 “dirty” exit that destroys your aircraft.

I wouldn’t leave something like this unfixed. The fix is easy.

(Chris Olson) #30

Hi Rob,
The instructions are in the documentation for the various receivers. This is an except for the popular X8R - note Option-2. It is important to do this or the receiver will put out strange values on some channels.


I don’t think this is a problem in ArduPilot at all. But I see thru an email I got that @rmackay9 patched it anyway and the patch went out in the 3.6.5 release candidate.

(Fi156) #31

Thanks for clarification!

If I use this option and set the FS positions at the Receiver (X8R) level.
Is Ardupilot able to distinguish between the failsafe mode of the receiver and the normal state, when those sticks are in the appropriate position?

(Chris Olson) #32

If you use last held value it must be able to detect channel 3 going below a pre-set failsafe value upon lost signal. This method also works fine. But with no pulses if the receiver is not configured for it I was able to duplicate the issue with no problem. If the receiver is configured for no pulses I could not get the issue to happen, although I only tried it maybe a couple dozen times. I was concerned about it, did not want to lose a helicopter to some weird anomaly. But I think the main problem is people forgetting to configure the receiver for no pulses - they configure the transmitter but the receiver stays at the default and doesn’t rebind cleanly.

(Rob_Lefebvre) #33

So how is this different from binding the Rx with the Failsafe already set?

To be clear: the Rx is outputting no pulses on FS.

Where do you see the connection between this step, and the problem of random “dirty exits”? What testing have you done to show it? Because I’ve been dealing with this for years, and it’s almost impossible to replicate in the shop.

(Chris Olson) #34

Because the default on a rebind of the receiver is to set the receiver to last position, not for no pulses. In other words, you can do the binding procedure in OpenTX. Set the Tx for no pulses, but not configure the receiver for no pulses. Now you have a broken setup for loss of RC. Thanks to a hint from an experienced user on RunRyder I didn’t discover it myself until I read the instructions for the receivers. I have DragonLink, X8R, RX8R and XSR receivers, and they’re all the same.

It’s easy to test right in your back yard. Just hover the heli and force shut the radio off (if the girl in it complains about the link being present from the receiver for telemetry). Turn the radio back on before it lands. See what happens. But do it only in Stabilize and make sure Stabilize is the first pwm segment of the flight modes, or it will switch flight modes on you too. It will shut a turbine engine down due to the FADEC getting a zero signal. A piston engine will momentarily “sag” and then come back. Don’t know what it does with electric - don’t fly those anymore.

(Chris Olson) #35

@Rob_Lefebvre I put a X8R receiver on the scope this morning to see what has transpired since we did the special builds for 3.3.3 that had a fix in it, and then subsequently got dropped. What I’m seeing is that the SBus protocol is kinds of like a voltage inverted RS232. It sends two packets alternately with 8 channels per packet. Actual data update rate appears to be 18ms (9ms per packet).

There is also a failsafe bit and a frame lost bit (flags byte) that goes inverted (1 to 0) about one second after the Tx is switched off. It appears that ArduPilot holds last received value on the aux channels when this flags byte is set for the SBus failsafe. How it exits from that when the flags byte is unset remains unclear to me. On the scope I can definitely get a corrupted frame on channels 1-8 if the receiver is set for programmed values instead of no pulses. Then get a “clean” frame on channels 9-16. But the next frame is “clean” also. And it’s 18ms from the “dirty” frame to the clean one.

So I got several different receivers, some of these I updated with the latest firmware thru the serial port in the Tx, some haven’t been updated. I didn’t keep track of which ones I had updated. But I got a XSR that I found in a box of stuff that I know has not been updated. I tried that XSR and amazingly that receiver will fail to set itself to “no pulses” following the procedure unless you turn on the Tx after setting the failsafe option in it. The other X-series ones I got (X8R and RX8R) it don’t seem to matter. I don’t have a X4R to test.

I cannot get it to send a “dirty” frame if the receiver is set to no pulses. But there also is no way to know if the receiver has actually accepted the “no pulses” failsafe option other than to follow the procedure and hope for the best. And as noted above I can defeat that with the XSR.

So it seems kind of amazing to me that ArduPilot can react in an undesired fashion with one “dirty” frame in a SBus failsafe when that flags byte is switched off. But evidently it can. Or maybe in some cases it takes more than one bad frame after it exits to cause it to react to it. I can’t see how ArduPilot is converting the serial protocol to PWM values on the scope. But there may be a bug in FrSky’s receiver firmware in unsetting that flags byte before it puts out “clean” frames for channels 1-8. This problem may exist with other radios too. Futaba originally invented this protocol and everybody else copied it, and the copies may be less than perfect, or Futaba’s original implementation may have a flaw. So I think this pull that @rmackay9 pushed into 3.6 will fix it:

I think I would still recommend setting the receiver failsafe as recommended in the manuals for the receivers, though. But based on what I found with the XSR, I think I would add the step to turn on Tx after the F/S button is pushed, otherwise it doesn’t appear to save to the Rx in some cases. I think the radio manufacturers designed these things to shut the model down and crash it in the event of failsafe, and they never considered that they may be used on more advanced flight controllers that can take over in the event the SBus flags byte is set, then unset, and continue to fly the model. And on the fringe of RC reception this could potentially happen several times in quick succession, and get corrupted frames anyway.

(Mac mcentire) #36

I just crashed a helicopter the other day due to this exact problem. I was unaware of making sure to set no pulses on the receiver as well and reviewing the logs I saw where my RSC channel dropped to 874 as well as my flight mode channel when the system rebound. I’m glad I read this thread because I was questioning what I was seeing!

(Rob_Lefebvre) #37

Hi Chris,

So as you see, the problem is very complex, and it can’t be expected that users are capable of doing the work you’re doing to diagnose their Rx.

Randy’s commit will not stop helicopters from crashing, as they specifically need the fix I developed 2-3 years ago for the RSC. And as Willy indicated, there’s been another crash due to this bug. I think it’s time it’s fixed.


(Chris Olson) #38

Hi Rob,
I think this is the fix we put in 3.3.3?

(Chris Olson) #39

Rob, I think @rmackay9 fix will cover it, because it looks at all the aux channels and not just the traditional RSC channel for heli

const uint16_t radio_in = RC_Channels::rc_channel(chan)->get_radio_in();
if ((radio_in <= 900) || (radio_in >= 2200)) {
    return false;

The RSC can now be assigned to any channel - it is not tied to Channel 8 anymore in 3.7 so if somebody has an old Spektrum DX-6i or something and they want to fly their micro with it they can when 3.7 comes out. As the user can assign the RSC to channel 6 if they want. So this made it necessary to check all the aux channels instead of just channel 8 specifically like we did in the original fix in 3.3.3.

I went thru the history on that from 3.3.3 to 3.4, and I’m still not certain as to why that got missed in the changes we did to heli, and why it didn’t get into Copter. It was probably my fault in failing to pursue that. It somehow slipped thru the cracks when we started fixing broken features in 3.4 and newer. I was responsible for bringing the changes into the new code as we moved forward with fixes, and I neglected that one. I think I had tried to do a rebase and it was a nightmare. And I somehow skipped that one in the cherry-pick list.