1 of 2 < >

2018 Registration

Register today for the 2018 Maritime RobotX Challenge! Registration officially closes on September 1, so don't let it pass by!
2 of 2 < >

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

  • 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

  • #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!


    • #3

      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.