I can’t arm the copter, because of “Prearm: safety switch” message
I have no safety switch installed and BRD_SAFETYENABLE disabled.
The motors keep beeping endless (so i guess they don’t get any signal). The only way to get out of this endless loop is to powercycle the pixhawk
The strange thing is: That happens only approx. one in ten times.
Firmware = Copter 3.6.0; ChibiOS
Couldn’t it be something similar to my endless esc beeping 1 out of 10 boots?
On my copter i have BRD_SAFETYENABLE disabled too.
Never noticed Prearm: safety switch tough.
Corrado
Corrado_Steri,
Could you arm the copter during your "endless esc beeping ? Probably not. You should see a message in Mission Planner that tells you, why arming isn’t possible. That means: You see the message only if you try to arm.
Maybe here’s a workaround:
Set BRD_SAFETYOPTION to 0 and BRD_SAFETY_MASK to 16383
I’m not sure whether that’s a working solution, but i haven’t seen any endless beeping loop since i made these changes.
It shouldn’t do this anymore if both BRD_SAFETYENABLE and BRD_SAFETYOPTION are set to zero. I found this issue some time back and @tridge fixed it.
The confusing part is that BRD_SAFETYENABLE does not truly disable the safety switch. BRD_SAFETYOPTION must also be set to zero to disable it. I’m not fond of that logic, but it’s the way it is right now.
Just tried both options at zero as adviced and in 30 boots it never did the continous beep.
Corrado
Same here.
Chris Olson’s answer seems to be correct. Thx to him.
Honestly i don’t understand why BRD_SAFETYENABLE exists at all ? Isn’t BRD_SAFETYOPTION = 0 meant to do the same ???
I am not sure how BRD_SAFETYOPTION works. Mine was set to 3 (number 3 is not documented on the full parameters list in the arducopter docs), now is 0 and looks like it works.
Corrado
The BRD_SAFETYENABLE only sets the boot-up state of the I/O. The SAFETYOPTION was put in to prevent hardware fault from shutting down the I/O in flight, and to set how you want the safety switch to work. But then I found it didn’t work anyway. tridge looked at it and he wrote a small patch that looks at the state of the I/O and the desired setting, and if a hardware fault causes it to try to shut down the I/O in flight, and if the SAFETYOPTION is set to zero, it will not shut it down.
I tested tridge’s patch and it works.
This does not address the somewhat confusing logic of these settings, as most people are going to think that if BRD_SAFETYENABLE is set to zero that it should be disabled totally. But at the present time that’s not how it works.
There is still a bug in that code that causes the intermittent self-enabling of the switch circuit. tridge’s patch prevents it from being a problem with the proper settings. It is not related to ChibiOS. It happens with NuttX too. But IMO tridge’s patch made it so it’s not a serious problem for 3.6, and the rest of that code and logic can be looked at later.
Tridge has found the issue and fixed it (in master) so we are going to add this to the 3.6.1 beta testing which I think will start on Monday.
Ok great, so what parameters should we use to have switch disabled on 3.6.1?
Corrado