weixin_39692761
weixin_39692761
2021-01-10 16:04

Safer arming condition checks

Adds an arming condition that requires, after arming is allowed (i.e. arming disable flags == 0) the arm switch must be off before arming will happen.

Also adds a condition that will not allow arming within a certain period after the board boots (default is set to 5 seconds).

The combination of the two protect against accidental arming due to: - bad RX failsafe/initial state (default arm position unsafe) - arming switch left in on position and no prearm configured during boot - arming switch accidentally switch to on whilst carrying radio and not level quad (where the quad would arm immediately arm when positioned level) * - arming switch left on and other control input preventing arm is rectified (e.g. throttle, prearm) *

Those marked with * would not be prevented by #3706

该提问来源于开源项目:betaflight/betaflight

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

9条回答

  • weixin_39692761 weixin_39692761 4月前

    It is for the situation where an RX takes a long time (longer than gyro calibration) to establish an RF link to the TX and the arm switch is left on.

    Without the grace time if the RX receives its first data from the TX after gyro calibration has completed and the default state of the RX is safe (throttle low, arm off) then by the time the RX gets the unsafe command from the TX, the FC will be in a state that it permits the arming command, even though it was not from the user.

    This diagram should show the issue (I hope): img_20170813_134238

    点赞 评论 复制链接分享
  • weixin_39852491 weixin_39852491 4月前

    But doesn't this just mask rather than solve the problem. No matter how long the delay, it is, in principle, possible that the link is not established until the delay has elapsed?

    点赞 评论 复制链接分享
  • weixin_39623713 weixin_39623713 4月前

    Agree delay time may need testing but the way I read this two features together should prevent auto arm in a high percentage of cases. I think this would help reduce risk for new or average pilot. But suggest these features and settings be clearly indicated in release notes until stable.

    undesirable example: I recently experienced a faulty connection on battery cable where 3.1.7 was able to quickly reset and re-arm several times before I could return for landing (w/ set small_angle = 180 -another good feature that could have ruined my day in this case).

    点赞 评论 复制链接分享
  • weixin_39609620 weixin_39609620 4月前

    What about the case when Tx is off at FC power on. And possibly turned on at some random time, within or outside the grace time. With arm switch on or off. Have not read the code, just asking instead.

    点赞 评论 复制链接分享
  • weixin_39853155 weixin_39853155 4月前

    : I don't think there is anything that can be done to prevent unintentional arming from happening in this case for certain RX models / protocols. After all, some RX are designed to send default values to the flight controller before they are bound, and from the flight controller's perspective there is no difference between a 'not bound default' signal and the signal from a TX that is not being used.

    On the other hand, none of these cases should lead to dangerous situations if the users act in a prudent way (e.g. use latched switches on the TX and/or check that the switches are in the right position before they turn on the TX, do not plug in batteries with props on in places where this could be dangerous).

    点赞 评论 复制链接分享
  • weixin_39692761 weixin_39692761 4月前

    ad540d8 adds another test to ensure that the arm switch is off after recovering from an RX loss, this will prevent accidental arming when powering up the TX at any time (assuming the RX protocol supports it).

    This won't affect in flight behavior in failsafe stage 1 as arming disable flags do not disarm the craft if it is already armed.

    Yes, you are right in that the delay is a bit of a "catch all" fix. If we are confident the additional check mentioned would catch most cases then I'm happy to remove it (I'm not familiar enough with all RX protocols to say, as long as rxIsReceivingSignal() is reported correctly it will work).

    点赞 评论 复制链接分享
  • weixin_39853155 weixin_39853155 4月前

    : I think the delay is still needed, at least for a lot of PPM RX. The default behaviour there seems to be to send valid default values after startup, and before a valid signal is received for the first time, so there is no way that rxIsReceivingSignal() can be correct for that case.

    点赞 评论 复制链接分享
  • weixin_39609620 weixin_39609620 4月前

    Tried this PR with a couple of basic sequences on DYSF4PRO, arm switch on and off at FC power on. Looking good, works as expected.

    For the record:

    Betaflight / DYSF4PRO (DYS4) 3.2.0 Aug 13 2017 / 17:14:22 (cd64d94)

    点赞 评论 复制链接分享
  • weixin_39852491 weixin_39852491 4月前

    I'm not clear about the grace time. Can you explain how it works?

    点赞 评论 复制链接分享

相关推荐