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.
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.
Is it posible to assign Ch 8 as the channel that triggers the Radio F/S?
I donât believe so. Only the Channel 3 can be used. The code would have to modified to use Channel 8.
@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.
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.
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.
1 Like
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.
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.
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.
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?
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.
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.
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.
@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.
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!
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.
Rob
Hi Rob,
I think this is the fix we put in 3.3.3?
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.