Upon closer examination of the sequence of events, it appears the problem is in your RC, which caused the throttle signal to go to 1100 pwm. At 608.465 seconds the radio failsafe was cancelled after ~4 seconds of no signal from the RC. The collective value came back to 1547 pwm, but throttle signal (RC8 IN from the receiver) stayed at zero.
So at this point the controller did was it was told to do by the RC. There is no radio failsafe, the RC8 IN is at zero, hit throttle hold (disable the motor interlock). A few fractions of a second later the throttle signal came back on from the RC. So the controller once again did was it told to do - re-enabled the throttle signal to the ESC. Now the ESC made things worse by not re-initializing (possibly due to range calibration problem, autorotation window set, etc.).
I also notice that normal range for RC8 IN should be the full range of your RC cal on channel 8. Your cal is 1099 to 1901
But the signal only goes to 1500:
So this brings up a question about having inadvertent mixes in the radio that may be causing a problem with why the throttle signal did not come back at the same time as the collective signal when the radio failsafe was cancelled upon re-bind.
@ChrisOlson I am concerned that there is more going on here that we don’t understand. From what I can tell, his controller is not set up to hold last value on all other channels when transmitter link is lost. However looking at the logs, you will see that RC8in goes to zero during the time of lost link however the interlock never switches. It only happens just after the link comes back because RC8in is still zero for a fraction of a second which causes the momentary interlock toggle in one instance halfway thru the flight. I was trying to look thru the code to see if during transmitter failsafe events that the software is doing something different with the RC inputs. No luck yet.
Yep, that’s why asked if this is a FrSky radio with OpenTX. It sometimes takes 4-5 frames during rebind from lost signal to get all the channels back.
If you recall, back in Copter 3.3 Rob had a patch to prevent this, as the SBus would go to 874 with zero output
We had Rob’s patch in ArduHeli 3.3.3. When 3.4 came about all this code changed, and I had thought we put Rob’s safety enhancements in ArduHeli 3.4 and 3.5. But I don’t recall if this stuff ever made it to master, or into the mainstream code?
I think this is definitely related to the RC thing on rebind. But we question whether we should put patches in ArduPilot for what is obviously a defect in the RC or RC firmware.
Because when you set the RC failsafe to no frames, I think that’s the way it’s supposed to work. At least that’s what it does with my Taranis. So with no frames the controller goes into failsafe and it keeps the throttle on by itself. No frames means everything goes to zero. This is supposed to be the most modern way to handle failsafe.
It didn’t trigger the “motor interlock” until it got RC signal back with normal on Channel 3, and no signal on Channel 8. So now the RC failsafe is cancelled, and we have the same thing as the pilot commanding throttle hold in flight. So it shut down the engine for a bit, then re-enabled it when Channel 8 came back. And then the ESC didn’t re-initialize.
With setting a RC failsafe value on Channel 3 for radios that don’t do “no frames”, then you have configure your RC to hold last value on Channel 8.
Like in the Taranis you can set a model to “no pulses” (kills everything), Hold (holds all channels at last value), or Custom (have to set each channel for what you want it to do).
No pulses (or no frames in ArduPilot) is supposed to protect from the receiver coming unhooked in flight. The other options won’t protect if the receiver comes unhooked.
@bnsgeyer this can also happen if you put your flight modes on a aux channel instead of mode. Since mode has priority over aux. So if you have your flight modes on channel 7, it can cause a flight mode switch on re-bind.
But this never was PR’d to Copter. And then the code changed so radically with 3.4 and on that the whole series of safety enhancements we did in 3.3 were either addressed by new code in 3.4, or never got carried forward.
That being said, I’ve flown plenty of auto flights with 3.5 with total loss of RC and never have had an issue with it. Flown with both my FS-i10 and Taranis X9D+.
I’m using a Spektrum satellite receiver connected directly to the Pixhawk to the spektrum port, the Tx is a DX8 and the binding process was done via Mission Planner.
Yes, my ESC is calibrated to this range and was not set for autorotation.
My default endpoints in the Spektrum DX8 are 1100 to 1900, I prefer to do all changes or setup in the Ardupilot and leave the Tx to stock values.
I’m using a Castle Creation in governor mode, 1500 is set to target a specific headspeed.
I double checked and the Tx has all the parameters set to its defauld, no mixes are active in the radio, everything was configured in the Ardupilot. When the signal was lost, I see all RC Inputs going out at the same time as well as coming up at the same time, please see graph below. That indicates me that the signal was completly lost and no other action was made from the Rx, if not, we should see the RC IN going to that specific value (for example if the Thr failsafe in the Rx was set to Idle, then we should see the Ch 8 going from 1500 to 1100 in the RC IN values, am I correct?)
I completely agree that if the autorotation windows was set to enable, in this particular case it might have prevent the crash, but if Tx signal loss continued for a couple of seconds more, it will have ended the same way.
No, they didn’t all come back at the same time. Where the RC failsafe cleared you got the Channel 3 signal back. But RC8 remained at zero for several seconds.
So at this point the controller does exactly what the RC tells it to - there is no RC failsafe, there is no throttle signal - shut the engine down. This is a radio problem.
If you intend to fly BVLOS and hobby grade RC range on a regular basis I think I would recommend purchasing a more robust RC system for long range links. In the US anyway, BVLOS must be approved by the FAA for commercial operators and is illegal for hobby/recreation. For commercial the FAA requires that the pilot retain complete control of the aircraft at all times, including being able to demonstrate avoidance of manned aircraft when operating BVLOS.
There is various long-range RC systems available but all them require licensing.
Ch 8 was the only one did was not back on at the same time as the other channels, di you think that it might have something to do with Spektrum giving more priority to the lower channels?
I’m not totally sure, as I haven’t used a Spektrum radio for many years. I have a Spektrum DX-6i that I could test with a satellite receiver and see if I can figure out how it handles RC loss and rebind, looking at the channels on the scope. But it would be this weekend before I could get to that.
I mainly do operations in Dominican Republic, here we must have license and registration with local aviation authorities and for BVLOS flights, special permits are needed were a box in the airspace is reserved for this specific UAV operation.
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.
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.
@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.
