5 replies to this topic

[agrath]

Hi Guys

I read about this on the arducopter site, and thought it was a good idea.
If it was possible to toggle a spare channel regularly (say 2hz) via a simple bit of circuitry inside my TX and the CC firmware was monitoring this channel for PWM changes, then it would be completely possible to configure the failsafe options in the GCS.
In the event that your designated failsafe channel didn't change (since 1 sec for example) you could set some values on the various outputs with perhaps a transition time from current values.
Is this viable?
A lot of us are using the cheaper TX/RX combos which don't seem to come with failsafe options (e.g. low throttle when signal lost) and as a result our expensive toys like to fly further away rather than closer.
In lieu of automatic RTB (return to base) could this be an easily implemented option?

Gareth

[dankers]

There is a much better way to do this, far more elegant and without special circuitry.

Set one of your channel to be outside the normal range as a fail-safe value, I would suggest throttle as some TXs only have fail safe on this channel.

A way to do this would be to bind or set the failsafe of the throttle with the end points set to max and the trim full down, once bound, change the end points and trim back to normal and then calibrate your TX in the GCS. This sets a failsafe value outside normal operation of your TX, if the CC see that value on throttle it knows the RX has gone in to failsafe.

Its how we planned to do fail safe for a long time, it is a good idea but we just don't have enough developers to implement this feature, it needs a tab on the GCS called failsafe where the failsafe channel can be selected, the value CC needs to see for failsafe and then a bunch of actions, for example:

Channel values to set on fail safe, such as setting throttle for a slow decent or bring down landing gear, lock camera gimbal etc
If CC should attempt to bring the airframe level after a failsafe
The amount of time the CC must see the failsafe channel value before it does these actions.

Hope I explained this well enough, it's clean, simple will work now with all TXs that can set failsafe values on at least 1 channel and a much better idea than some special circuitry.

Anyone want to make a Jira for this? Even better would be some that will implement it!

[agrath]

Sounds good, however my current tx/rx doesn't allow a failsafe value to be set (as far as I can tell, it's a HK-T6A), it just leaves the output at whatever it was set to, so if I'm fully pitched forward, full throttle flying away from me and I go out of range, that's what the quad keeps doing.
Less than ideal, this is why I was suggesting a 2hz toggle circuit that could replace one of the channel 'switches'.
I thought that other people might also have this issue.

The turnigy 9x which has just arrived (2 days ago) does reportedly allow me to set failsafe values, however I am not sure if that's implemented by the RX I'm using (in the case of out of range or TX battery problem etc

Maybe both as an option?

I'd really like to get involved and add this feature but I feel there'd be a pretty steep learning curve (I know C# but not c++ or QT, let alone the firmware stuff) and I'm not sure I can find the time to invest as I'm already contributing to another OSS [software] project.
If someone was available to work with me to get up to speed on the project I could give it a shot

[agrath]

Actually, an extra thought,

During normal flight, does the PWM change at all? Obviously if you're maneuvering/moving around however if you were flying in one direction constantly for a period of time.

Even if I'm flying constant in one direction, surely the PWM will be fluctuating +- 1 or 2 u
Does this state still exist (the fluctuation) if the TX is turned off or goes out of range?

[dankers]

Quote

During normal flight, does the PWM change at all? Obviously if you're maneuvering/moving around however if you were flying in one direction constantly for a period of time.

That really is not a good metric, especially with things like position and altitude hold.

Please please buy a radio with some failsafe features, they are not expensive, and could save your model.

[agrath]

(I have already for that exact reason, I've got a t9x here that I haven't switched to yet)
I guess what I was trying to suggest is potential ways we could capture or detect a failsafe condition and handle it more gracefully than the RX just setting values, and you've identified that.
The idea of the circuitry or detecting pwm fluctuations was more of a "hey what if this worked" type idea