I just upgraded to 4.1.2 on a PixHawk mini clone. I see in the logs that just after takeoff there were many messages about radio failsafe, I’ve now just seen the reports on here about the bug in radio detection on these boards, which Tridge has now fixed in 4.1.3-rc2.
Anyway, because of the radio failsafe the copter went into RTL. But it disarmed pretty much right where where it was, about 2m off the ground. I’ve flown this copter a lot on previous firmwares (mostly 4.1 beta) and it’s never had a problem with landing detection before.
@Qiotek dont believe that’s related, it was on a traditional helicopter and had collective set up in a way that it thought was idle. @tridge is this related to the mini pixhawk rc in?
No, they are similar. They all appear (Landing_gear_deployed land_ complete land_ complete_ maybe) in the log then throttle turned off in the air. @geofrancis
what is really strange is that he had control when it was getting radio failsafe errors, the channels didnt flatline stop like I would expect during a proper radio failsafe they look like connection was getting lost and regained about once a second. that being said it should still not have disarmed before it was on the ground and unfortunately there isnt a way to override and hold it out of RTL.
That may be. But in this case, the aircraft disarmed in flight before land complete. In fact, it declared land complete because it was disarmed.
The in flight motor shutdown for the heli was different. Due to the collective being lower than H_COL_MID, the autopilot thought it was landed and that cause the land_complete flag to be set which then initiated the automated shutdown process.
sorry to say it shows the machine disarmed using the disarm switch on channel 7.
My guess is that because it was rapidly going in and out of failsafe so fast that you never got control back for long enough to make it move. I think If you had manually set the flightmode to rtl it would have probably landed on its own since it wouldnt be trying to change between modes. But the reason the motors stopped was the arm/disarm switch being switched quickly off and back on again.
This is not at all related to the issue seen on heli
You can tell what caused a disarm using the ARM message:
2021-12-23 12:28:42.657 ARM {TimeUS : 72017808, ArmState : 0, ArmChecks : 0, Forced : 0, Method : 2}
in this case it has Method 2, which you can lookup here:
that shows method 2 is AUXSWITCH, which is disarm using a user controlled switch.
@tridge yes but if you look at the rc channels it doesn’t look like they ever actually stopped moving. it went into failsafe 6 or 7 times in 10 seconds. radio issues?
Hi all. Thanks for looking into this. Sorry I have been offline for the last 1.5 weeks. Happy new year to you all.
Yes it was odd, I did have partial control, initially I was still trying to convince it to climb and trying to figure out what was going on, before the crash.
@tridge Regarding me hitting the disarm switch… I don’t think I did this (I know, that’s what they all say, right!). The only thing I can offer by way of evidence is that there are step changes in the RC3 throttle input which are exactly coincident with the RC7 transitioning low and also back high again. My RC7 and RC3 are both operated by the same hand and I am not quick enough to release the throttle and toggle the switch in one time quantum nor back the other way a second later. Perhaps garbage SBUS frames were somehow admitted during all the shaninigans?
I had the same problem with Futaba 6202SB receiver on an APM and a pixhawk. Changing to futaba 7008SB as well as to Frsky TFR4SB solved the problem. Must be an issue with that receiver.
