EZUhf Failsafe with APM

Does anyone know how to setup failsafe on the ezUHF system?

Documentation on the web states the data below but that looks like it will just move to the throttle 0 position which is not low enough.

"Failsafe
If, for any reason, the UHF link is broken, the receiver will wait for approximately 1 second for the link to be restored, and then will enter failsafe mode.
The failsafe servo positions are programmed using the button on the transmitter.
To set this up, two phases are recommended.
1) With the plane on the ground, and servo positions neutral, throttle cut, hold down the transmitter’s bind/failsafe button until the transmitter beeps. This will set a reasonable default failsafe ready for the first flight
2) With the plane in flight, set the controls in a suitable position for the failsafe, and re-program the failsafe. In most cases, ‘suitable position’ means throttle cut, and a gentle turn radius, to let the plane circle gently until it lands, but of course every application is a little different."

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • Failsafe will set to whatever you set it to.  What many do is use the trim to bring the throttle all the way below zero, then press the bind button for 2 seconds to set it, and then bring it all the way back up to no-trim.  Then in your GCS you set the failsafe PWM value to a value that is passed when the transmitter is off.

    For instance, let's say when your throttle is Zero you have a PWM value of 1050.  When you use the trim to push the Throttle value below that, you get a PWM value of 960.  You then press the bind button for two seconds and it'll beep, and that value is now stored in the receiver.  You can set your Failsafe-PWM level in Mission Planner to say you want to invoke Throttle-based failsafe at 975-980 and then when the transmitter is off, it will go past that point to 960, putting the autopilot in Throttle-failsafe.  FWIW the autopilot will also detect the failsafe condition due to a lack of packets coming from the EzUHF Rx and also go in to failsafe, but always test this to make sure.

    • The problem you have is with EZUHF. Regardless of what you send it from the transmitter, the receiver will not output PWM or sbus anything less than 1000uS. The head developer there is sort of arrogant and believes this is correct even though any other RC system can go down to 850 or 900uS, or whatever the TX is sending.
      So to deal with this you have to change the range that you use for throttle. Basically the strategy is:
      * set your throttle failsafe at 1000uS on the receiver
      * adjust the throttle range on the TX to go from 1150 to 2000uS
      * use mission planner to RTL below throttle of 1050uS
      This works, and I solved the same problem by doing this. For reference I am using a Taranis, JR style ezUHF tx, 8ch Rx, into a pixhawk.
    • Thanks for the detail.one question. On the taranis, how do you adjust the throttle range per your description above ?
    • Click menu, then go to page 7 "servos", select "ch3" which is throttle then reduce the -100 and 100 to something suitable for your system. On openlrsng I have it down to -90 and 90.

      May not be "The" way but it works for me.

      Just remember to redo the radio calibration on mission planner and recalibrate your esc's for the new throttle range.

    • hi,

      is it fair to say that by doing this i am losing resolution on my throttle channel?

      thanks

      Damo

    • 850uS is plenty of resolution, but you can also start with 1100 on the bottom and go to 2000 on top with no concerns.  You just want to make sure you'd never enter the failsafe area accidentally, but the Taranis doesn't flutter around more than 4-10uS anyway so you should be fine with 50uS separation. 

      re: the deadband - in 3.2 you can tighten that up with a parameter now, thankfully.

    • In theory, yes. I don't know what the resolution of the Taranis and EzUHF is exactly, but we are probably losing the equivalent of 1 bit of resolution by doing this. I think other things going on i the flight controller are going to mask this anyway. For example, the deadband in the throttle center for loiter and alt hold modes is quite large by comparison. 

    • I have done this now. Thanks for the help!.

    • This does not work. When the throttle is set to minimum and i reduce the trim to it's minimum, the pwm does not reduce from the throttle pwm position it is at zero (i.e in my case it remains ~ 993. Interestingly if i move the trim to the max value the PWM does increase (goes from trim centre 1976 to trim max 1996). 

      So i must be doing Something incorrect. On my Futaba T6ex i was able to set zero throttle really low temporarily in the settings and then set this as the failsafe value. Then change it back to normal afterwards.

      Can you confirm my findings with the taranis with the JR module? Both the Taranis and the radio are calibrated.

      is a similar function available on the taranis?

    • It does work, however I know what you're talking about.  Since the EzUHF goes in to a failsafe mode that the ArduPilot software recognizes, I don't fuss with Throttle Failsafes anymore.

      But to the issue, I think the Taranis (the issue is the Taranis not the EzUHF at this point - the EzUHF is simply signalling the PWM values) is already swinging the PWM values so low that you can't subtrim much more out.  One thing you can do is set up the normal amount of Taranis end-point adjustment to only go to 90-95% of its max throw, re-do your RC calibration (or just observe the new min and max PWM values in Mission Planner and update the RC3_MIN and MAX values accordingly) and then re-attempt the throttle failsafe procedure from above.

      Another option though is to have your copter set up w/o the props on, get everything plugged in, and turn off your Taranis and observe the copter's mode in Mission Planner.  It should begin the failsafe process.  If it doesn't let me know as I may need to go in and reconfirm my settings :)

This reply was deleted.