Announcement

Collapse

Welcome to the RoboNation Forum!

Welcome to the home for the RoboNation Community! This is where you'll see exciting announcements and features all for the community. Join the conversations below!
See more
See less

Kill Switches

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Kill Switches

    Hi Everyone,

    Can anyone out there share a little on how you implemented the remote kill switch? We were looking at several low-tech options as well as some commercial applications. What has worked for you in the past?

    Thanks in advance for any input!

    Michigan RobotX
    USA

  • #2
    Hi Michigan RobotX,

    If you have the engineering capacity I would suggest you develop your own kill system and architecture instead of getting it completely off the shelf lest you get locked into OEM supply chain and allows for customisation for the reliable architecture that you would need for safe continuous ASV operations.

    For us, our kill system is a custom independent daughter board which communicates directly to its own dedicated radio. It directly controls a contactor switching circuit which controls the power to the power controllers to drive the OBMs. The kill system communicates with the rest of the system over CAN Bus. The other thing that is shared is power. We have provisions for a short range kill box and long range kill over the Operator Control station which has a long range base station antenna system.

    In contingency cases we have designed the following:
    Loss of control over any of the other daughterboards or to the SBC -> Kill system is not affected, the hardware kill will continue to function
    Sudden Power failure to kill system only- default state of contactor is Normally Open, thrusters will deactivate
    Short circuit of power to the kill system with undetermined state on the MCU output-> Thrusters can be deactivated via remote controllers or over the datalink(basically via the rest of the system)
    Short circuit of everything: Hopefully we will never reach such a state because that would mean we need a third redundancy system haha

    Hope this helps!




    Comment


    • #3
      James,

      They just released some info on this, and there are some things that I need to clarify, but assuming ours meets their requirements, which I imagine it should, We would be happy to share some details on this. We take great care to design our safety systems for robustness and dependability. We would love to help any team to do the same. Safety is the first thing we should be collaborating on.

      For now, here are some Principles to follow:
      There should be no software (including embedded software) in the loop. meaning, there should not be any critical part of the safety circuit that depends on software. An MCU could tell it to kill, but it should never be able to override any other source that is also wanting to kill the boat.
      The Wireless link should be a hardware solution not a software solution. AUVSI has posted a great circuit doing this with a standard RC signal on their IARC website. There are also solutions like TORC's SafeStop that work as well. Remember, mosfets are hardware not software. They are safe to use on the control signal if done right
      The actual cutoff should definitely be a hardware relay.

      As soon as we have some clarification on the rules to verify that our system meets the requirements, I will update with more info on our system.

      Comment


      • #4
        Hitesh Patel The kill switch specs state "The engage/disengage button should be red in color and have a ‘press to activate and turn to reset’ feature.", and there is a link to a sample button. We purchased the buttons that were from that provided link, but they are not turn to reset, but rather pull to reset.

        Can we have a clarification if these are okay (since we purchased from your provided link, http://www.mcmaster.com/#6785k21/=rjy8d1), or do we need to purchase new ones that match the written description?

        Comment


        • #5
          Originally posted by jcoller View Post
          Hi Everyone,

          Can anyone out there share a little on how you implemented the remote kill switch? We were looking at several low-tech options as well as some commercial applications. What has worked for you in the past?

          Thanks in advance for any input!

          Michigan RobotX
          USA
          In case you missed it, our team asked a similar question at one of the RobotX video calls. We asked specifically if we were allowed to map one of our remote transmitter switches ("channels") to our remote kill system. In our case, we are using a FrSky QX7 (https://www.frsky-rc.com/product/taranis-q-x7-2/), but there are many different similar alternatives one could use. So basically we're putting the kill switch on the same transmitter that we use to control the boat manually.

          The answer from Hitesh Patel and Bill Porter was that this is OK, as long as the receiver on board the WAM-V that receives the kill signal from the transmitter goes directly into a microcontroller (no computer--we do not want "software in the loop"); in our case, we're using an Arduino. You also need to make sure that your system has the appropriate fail-safes in place, e.g. if the transmitter battery gets pulled, your boat should kill; if the microcontroller loses power, the boat should kill; if primary power system loses power, boat should kill (despite the weirdness of that statement...).

          This is the system we will definitely go with--high-quality off the shelf transmitters have excellent self-healing signal properties, frequency hopping, take up very little bandwidth in the spectrum (they're typically built for drones that fly, sometimes for miles). If you were to use another wireless device like an XBEE transmiter, that's another potential point of failure, and also more spectrum that your team is occupying, increasing the odds of interfering with someone else. Our team in particular had a lot of problems trying to get an external XBee-based system robustly communicating across the channel at the competition site.

          I would be happy to share more details on the electrical side if your question was posed in that direction.

          Comment


          • #6
            Hi brennan , thanks for following up. We were able to get our remote system figured out. We originally build a system with XBEEs, but we found them to be too unreliable and have since switched to an industrial remote system by Humanistic Robotics.

            Comment

            Working...
            X