Quantcast
Channel: SparkFun Tutorials
Viewing all articles
Browse latest Browse all 1123

How to Build a Remote Kill Switch

$
0
0

How to Build a Remote Kill Switch a learn.sparkfun.com tutorial

Available online at: http://sfe.io/t532

When Things Get Out of Control

The remote control kill switch

Kill Switches: It’s not a question of if, but when.

I highly recommend building something that scares you every once and awhile. In this case, I’m planning to enter an autonomous vehicle into the AVC in 2016, and it’s pushing my limits of comfort. A 1,000W motor with a large battery pack behind it mean that if things go wrong, it could be dangerous. For that reason, one of the new safety requirements of the AVC is a remote kill switch that allows the user to remotely power down the vehicle. This tutorial is my solution to safely disconnecting the motor from the motor controller in case things get out of control…

Here’s a quick video showing the kill switch controlling the 1kW motor (that just happens to be attached to a blender).

System Requirements

Here are the design requirements for my system. These should fulfill the kill switch safety requirements of the A+PRS rules.

  • If user presses the green button the system should energize the cut-off relay allowing power to flow to the motor.
  • If user presses the red button the system should de-energize the cut-off relay shorting the + and - of the motor causing the motor to brake.
  • If user presses the yellow button the system should assert a signal pin. This will be connected to the master controller to let it know that the race is in “yellow flag” mode.
  • If the vehicle fails to hear from the remote after a certain length of time the vehicle should go into safety-shutdown (de-energize the cut-off relay causing engine to brake).
  • If the remote fails to hear a response from the vehicle (out of range), then go into disconnect mode (blink all three LEDs).
  • If the link is re-established, then start in safety-shutdown mode.

I broke the killswitch system into two parts: the Vehicle Control Unit that lives on the vehicle and the Remote Control Unit that the human holds in their hand.

Remote control electronics

The electronics in the hand held remote (RCU)

Vehicle Control Electronics

The electronics on the vehicle (VCU)

VCU Parts List

Vehicle Control Unit Electronics

Click on the image to see the electronics without highlighting

The Beefcake Relay can be seen next to the larger, blue, 24V/80A relay. The VCU itself (the Pro Mini connected to the RFM69 breakout board) can be seen in the lower right corner.

Parts used on the Vehicle Control Unit:

I use our SparkFun RFM69 Breakout for a variety of reasons:

  • Encryption: This allows me to rest easy that no one else (ok I’m sure someone could hack it) will power up/down my car.
  • Software Defined Radio: The AVC has nearly 100 teams, all with their own radios and telemetry systems. It’s excellent to be able to sit in the 434MHz or 915MHz spectrum rather than the very crowded 2.4GHz arena.
  • Data Rate Scaling: The data rates can be reduced and frequency changed so that range can be increased quite significantly. UKHASnet has even setup a network of RFM69 based repeaters across Europe with transmission ranges pushing 65km (40miles)! I plan to be within sight of my autonomous power wheels at all times, but it’s good to know the 100mW transmission power of the RFM69 can do the job.
  • Library Support: The community has been writing various libraries to support the RFM type modules for years now. The latest I use for this project is RadioHead by AirSpayce. It does everything I need with some decent documentation to boot.

Vehicle Control Unit

Vehicle Control Unit Electronics

RFM69, Arduino Pro Mini, and two relays make up the VCU

The Vehicle Control Unit (VCU) sits between the motor controller and the motor. The VCU only connects the motor to power if the Remote Control Unit (RCU) is powered up and transmitting the ‘User pressed the green button, go for it’ signal.

I’ve decided to run my PRS vehicle at 48V, which is the higher end of allowed system voltages. Luckily, there are some really nice DC to DC buck converters to get 48V down to 24V (to control the cut-off relay) and 5V (to power the 3.3V Pro Mini). See the parts list for links to the particular ones I used.

Relay up close

Under load and at top speed, the motor controller will be putting out 10’s of amps at 48V. The VCU needs a substantial relay big enough to handle that load. Some of the lowest cost, highest current relays I could find were 24V relays. Because my 3.3V/8MHz Pro Mini can only turn on/off 3.3V, I decided to use a two relay setup.

Bootstrapped two relay setup

The relay setup

This is an example of a ‘bootstrapped’ relay system. Bootstrapping allows a small signal to control big loads. The 3.3V signal from the Pro Mini can’t control the large 24V relay directly, so I used the 3.3V signal to control a 5V relay to activate the 24V relay.

When we want to allow power to the motor, the Pro Mini activates the Beefcake Relay with a 3.3V signal (KILL_LOW goes from 0 to 3.3V). This signal grounds the Q1 transistor allowing current to flow across the coil in R1. Next, the reed on R1 moves from the normally closed position (where it is connected to nothing) to the normally open position. Current begins to flow freely from 24V through the R2 coil to ground. This flow causes the reed on R2 to move from the normally closed position to the upper position connecting the + lead of the motor to the +M on the motor controller. In real life, this whole process produces a most satisfying thunk. Note this does not power the motor; rather, it allows the motor controller to control the motor. If the motor controller is outputting 0% power, the motor will just sit happily still.

48V / 24V / 5V Subsystems

You may be wondering why I am running a 24V subsystem? For my A+PRS entry, I am controlling the steering with a 12V linear actuator that I am over-driving with 24V. The actuator is very strong but slow, and the extra voltage drives the actuator much faster. The 24V cut-off relay (R2) fit nicely into this design as well.

Motor Braking

When R2 is in the normally closed (unactivated) position, the + and - of the motor are shorted together. This is called motor braking. To see what this feels like, find a large DC motor, and try spinning the axle. It should be relatively easy. Now, short + and - of the motor together; the axle will be considerably harder to turn. By setting R2 up this way we have another layer of safety in that, if everything goes wrong and the Kill Switch goes haywire, the system should fail safe, turn off all the relays, short the motor and brake to a stop. It is not yet clear to me how aggressive this braking power is. If the braking is too abrupt (as in it ejects the human rider) it could be more dangerous than it is helpful, in which case I will disconnect the MOTOR- from the lower pin of R2 and let the motor freewheel in the event of a safety shutdown. That way the human passenger has the ability to control braking with the brake rather than something they cannot control.

RCU Parts List

Inside the kill switch

Inside the remote control unit

Parts Used on the Remote:

Remote Control Unit

The remote control kill switch

The remote control kill switch

The RCU is the thing that the user holds in their hand and jams the red button in case the autonomous vehicle becomes sentient, or is just doing something it shouldn’t.

Schematic for kill switch

Schematic for kill switch

Let’s start with the simple bits: The LEDs are simply on/off and don’t need PWM pins. I chose to connect the LEDs to pins 3, 4, and 5 because it allowed me to solder in a 3-pin JST connector. The three buttons within the switch station are the Normally Open (NO) type. I wired them to pins 6, 7 and 9 with 8 serving as the ground pin. I did this because I ran out of GND pins on the Pro Mini. You can use a GPIO as ground, you just set it as an output and LOW. Also, by creating a bank of four pins it allowed me to solder a 4-pin JST directly to the Pro Mini.

The RFM69 is wired according to Mike’s excellent hookup guide. Note: The connection from pin 2 on the Pro Mini to DIO0 on the RFM69 is required and serves as the interrupt from RFM to Pro Mini. You cannot use a different pin on the Pro Mini because pin 2 is a hardware interrupt pin, and the library depends on interrupts.

The remote needs to have a battery! I used the 3.7V 850mA LiPo. The average current draw is about 42mA, so this should last for around 20 hours on a charge. I didn’t do any power minimization efforts because 20 hours was plenty for my purposes. To avoid having to open and close the enclosure to charge the battery, I installed a LiPo charger with miniB connector. Plugging a miniB cable in will charge the battery any time, and pressing S4 (a latching switch) will turn on/off the remote. Note that if the remote is turned off, the vehicle will go into automatic safety shutdown (a good thing).

I really enjoy the quality and feel of the three buttons in the Switch Station, but they are very big and packing all the electronics into the enclosure is a challenge. If I were to build another remote, I would look for a better trade off of more room vs quality (there are many low quality switch stations on Amazon with more room inside the enclosure).

Code

You can find the code for the RCU and VCU in this github repo. Here is the code via Codebender as well:

Above is the code for the VCU

Above is the code for the RCU

The RCU waits for the user to press a button and monitors the link to the VCU. If the link is not detected, the RCU flashes all three LEDs letting the user know the VCU is offline (either unpowered or out of range). Once the user presses the green button, the RCU turns the LED to green and begins transmitting the ‘Ok, go for it’ signal. Once received, the VCU sets the KILL_LOW pin to high, thus activating both relays and connecting the motor to the motor controller.

Certain settings can be changed in the code for your specific application:

  • MAX_DELIVERY_FAILURES: It turns out that the RF link will drop a packet every once and a awhile, so the MAX_DELIVERY_FAILURES is set to three. If we don’t get a valid send/response after 3 tries, the system goes into disconnected mode. Setting this lower than 3 means the car may shutdown prematurely because we had some RF traffic/collisions.
  • CHECKIN_PERIOD: The remote will broadcast the system state every 25ms.
  • MAX_TIME_WITHOUT_OK: The vehicle will shut down if it doesn’t hear from the remote after 250ms.

These settings worked well for me and created a responsive, dependable link that shut the vehicle down within 250ms if things went pear-shaped. You may need to adjust these settings for other, longer-range applications.

Future Improvements - Reverse!

The kill switch is working nicely over a long range and I have moved on to other challenges on the vehicle. Testing will tell if motor braking is a good thing or not. I’m also pretty sure Mr. Auto is going to drive me into the barrier quite often during testing and I’ll need the ability to stop and back up. As designed, the system doesn’t have the ability to reverse. For that I’ve looked into continuous duty solenoids. These are common on golf carts and other small DC vehicles. I’m waiting to find a cheap, used one somewhere to keep from going over the $500 PRS budget.

I hope you can learn a bit from my setup. If you have similar projects please link them in the comments. One of the great aspects of the AVC is all the great stuff I learn from other people so please let me know how you did your kill switch!


learn.sparkfun.com |CC BY-SA 3.0 | SparkFun Electronics | Niwot, Colorado


Viewing all articles
Browse latest Browse all 1123

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>