If you’re testing radio failsafes on the bench then that’s the normal reaction for Copter. Plane and copter don’t react the same when ground testing radio failsafes.
From the wiki:
If the copter is disarmed, no failsafe will take place.
If the copter is armed but has landed, the copter will immediately disarm.
If the copter is armed in Stabilize or Acro modes, and the throttle input is at minimum, the copter will immediately disarm.
Otherwise, the copter will take the actions as configured in the parameters described below.
Allister,
Thanks for the refresher on the failsafe docs. I bench retested the copter failsafe with the transmitter throttle >0 and indeed it uses Land as the failsafe mode and not immediatley disarm. I think it went to land instead of RTL because I was at my home location. At least I am confident now to test the failsafe in flight.
I also have this problem with an almost identical setup. I did 3 flights and it occured in 2 of them, about 50m away. 1st time within 30 seconds of flight, other time within 2 minutes of flight.
I’m definitely no expert but… Try updating to 6.17. So far I’ve been successful with that after my disaster of a summer.
I had micro failsafes when I had dynamic power on and the Rx not fixed to 50hz or 150hz on 6.13 & 6.14
Another tip is to have SD logging enabled on your TX. I’ve got it combined with my arm switch. Another vector to assist with fault finding.
I just want to note that I experience regular RC failsafes using an ExpressLRS receiver. There seems to be some underlying issue regarding the CRSF implementation, this happens from a few cm away to long distances so rssi is not a problem. I know ELRS isn’t 100% the same, but getting the CRSF implementation to be robust enough to handle this should be possible and should be a goal.
Hi all,
Just checking in here to verify some things regarding CRSF & random failsafes (when running CRSF protocol, in AC 4.0.x).
Under the open issue list for 4.1.0 - this specific thread is mentioned;
RC failsafes with KakuteF7 & CRSF & Yaapu telemetry during mode changes (discussion, discussion2) – fixed with “latest” (should become beta2)
I was wondering if this fix is a “general” fix for the CRSF protocol across all autopilots or only for the specific issue with CRSF + Yaapu + Kakute FC.
I am running a CRSF 8ch Diversity unit, with Cube orange (with taranis + CRSF JR module, and no yaapu) - and have seen multiple of these failsafes when the receiver is connected over CRSF protocol.
It has never occurred when using the receiver connected via SBUS. This is occurring using AP4.0.7 (and with CRSF V6.17 on the receiver, which states that CRSFv3 protocol has been disabled).
I had those issues in the past, but none this year. Using Nano/Pro or Diversity RX, latest or stable, plane or copter, not a single failsafe with FW 6.17 on Lite Module - so far.
I remember reading a statement by TBS stating that telemetry should always be wired even when not using it. But I guess that doesn’t apply to people using Yaapu.
I’ve also had a couple of failsafes recently. Very close range, I’d say less that 30m away from me. I’m running AC 4.2.1. The crossfire module is running 6.x. Can’t remember exactly the version. I’m travelling right now so I’m not sure I’ll be able to check for a while. I’ll try and post a log if I can.
Maybe it’s related to a type of FC/processor? I think everything I flew recently had F405 (CTR, SE, WING) in it. No problems so far. Craft with F7 seem ok CRSF-wise on the bench, but not flown yet this year.
Any recent failsafes are down to CPU load rather than actual radio failsafes. We relaxed the time constraint in 4.1 to make this less likely to happen. My expectation is that 4.1 is better than 4.0 and 4.2 is better than 4.2. I have looked through the code to see if there’s anywhere that the passthrough code is taking more cycles than it should, but I can’t see anything. Note that there are a couple of fairly significant CRSF bugs fixed in 4.2.2:
b) CRSF protection against watchdog on bad frames
c) CRSF reset in flight handled
and (c) includes any changes for CRSFv3 that appeared in 6.17
Since updating to 6.17 and keeping up with the stable Ardupilot builds I haven’t had a bind loss or failsafe. Close to 100 flights last month. Some out past 20km with no issues.
I’m not game to move to 6.19 whilst I’ve been having good luck. I got stung hard with previous CRSF versions. Has anyone tried 6.19?
Andy @andyp1per -Do you know if the CRSF Nano Rx’s support v6.19 or is it just Tracer? The Micro Tx updates but then no more bind to the Rx so trying to update the Rx has proved futile so far.
@dkemxr I took the plunge and have 2 vehicles on CRSF6.19 running Copter 4.2.3 on Matek 743 slim boards. I have both the older and newer chip designed CRSF Nano RX’s for RC link. So far so good! Weather has been sub-optimal so I have not had an opportunity to conduct robust testing to build my confidence with the link.
Well, OK. The “Golden Firmware” completely screwed my on the Nano Pro I have and they sent me a new one. The standard Nano diversity wasn’t a walk in the park either. It’s disappointing that the information for v6.19 is from some 3rd party website. The newer TBS Agent Web seems to be unpredictable also. It’s a big sigh for me as I have Frsky R9 stuff that is a Pain in The Ass too. It’s all flying and functioning but it shouldn’t t have to be so painful.
