A week ago, we published the first instalment of our Bulletproof Escape Fridge from the AWS Summit Sydney. If you are following our blogs, this week we will uncover the locking mechanism we’ve used for our Escape fridge. Read on to learn about the details.
The locking Mechanism
Searching for a locking mechanism that was versatile and reasonably priced was actually a lot trickier than I thought it would be.
We had a couple of sessions with different people and a white board but mechanical engineering was very clearly a short coming for all of us. None the less a few ideas arose and a solenoid based solution was decided. Jaycar had what looked to be a good solenoid, and the original plan on the fridge was to use it to unlock the door. Funnily enough apparently 2KG of force is not enough for the locking mechanism (We really needed a force gauge to decide what size solenoid we’d need).
The next idea was to use a hasp and staple. Though this presented a couple of issues. The solenoid wasn’t sprung in anyway, and so would just completely fall out if not energised and any spring I tried was too strong (apparently 2KG of force is not a lot). The next problem was that the solenoid was too big for the staple. This actually ended up being a positive. When the solenoid wasn’t energised it would fall out and sit on the staple. We just needed something a bit smaller to fit in the staple, something round so it would assist falling in the hole. It turns out that plaster board nylon plugs are easily squashed, round, and even a bit pointy.
This all worked when on a flat piece of timber as a prototype. Moving it to the fridge proved to add some complexities with the curve of the fridge and different levels. A few nylon and flat washers soon had things flat.
After repeated testing it was seen that the solenoid sometimes got stuck in the energised position. This was not due to residual current, but was purely mechanical in some odd way. (Let’s not tell anyone that I had remove potentially a crucial rubber stopper at the front of the solenoid as it kept getting caught on the hasp and staple.) The solution to this, was to neatly cut the end off a foam dart from a Nerf gun, so that it sat at the back of the solenoid housing and thus the pull rod couldn’t get stuck in the housing.
Pretty boring stuff here, and not much to say execpt that one is an actual real strobe and one is emulated (with white L.E.Ds). I really wanted a green strobe, not blue, but green wasn’t available at the time of purchase and time was against us, so blue it was.
The Raspberry Pi
Using a Raspberry Pi as the “Thing” was a no-brainer as it let’s us run Linux so we don’t have to think about writing anything too complex in a RTOS or similar. We wanted to include a USB camera, but we found quickly that the Camera that was available to plugin to the Pi would be more than suitable. Of course we needed a housing and we found one that was able to also hold the camera. Bonus!
We chose to use raspbian for the OS as it seems to have a big community behind it and we figured any issues we encountered would’ve been covered by someone before and thus hopefully a quick google would resolve our issues. Which of course there was one.
The camera has to be setup in a particular way so that Chromium would use it correct at the full resolution.
The Raspberry Pi has a 40 PIN set of headers that are designated GPIO. GPIO stands for General Purpose Input Output. You can find further details about the their use at the RaspberryPi website. But for the purpose of this experiment they are basically being set “high” (1) or “low” (0) in software to switch external entities. This is the same pin structure as an IDE cable. So if you find yourself trying to put together a project and you don’t have any headers, an old IDE cable can fit the bill. Another thing to note about the GPIO ports, is that they operate at 3.3v, not TTL (5V) and this made interfacing with a MOSFET a bit tricky. More about this later.
To reduce the risk of component disruption, I was very keen to put the circuits on to a prototype board (this is the pre-printed circuits that you can cut the tracks), and then put this into a ‘jiffy’ box (a plastic enclosure that houses prototype or project electronics). But it was agreed the raw look of the breadboard would be more appropriate. So what was prototyped on the breadboard, basically become production. (nothing is ever temporary is it…). I did clean up the layout a little and mounted everything on piece of plyboard painted black.
By brillian design decisions (complete fluke) the plypoard base can slide into the fridge for easy transport. I call that a win!
Designing a circuit was something I hadn’t done seriously for, let’s say a number of years where number is between say 15 and 20 and while it took a little while, I did start to remember.
I had a few thoughts about how to drive what I thought would be a high current, e.g. the solenoid (turns out it wasn’t massive in the end), and wanted to ensure I protected the digital circuit from any issues. I first looked at a relay, but most needed more than 5V to drive them, and let’s be honest, they are slow and clunky. In previous projects I have switched mains (230v) with solid state relays, and I thought that might be an option. But reading up lead me to the conclusion that really they are only capable of switching AC.
As with most things in electronics that you need to switch, you use a transistor. They are everywhere. There is some insane number (in the millions or billions) in your computer, cellphone or tablet that you are reading this on, albeit much smaller than the ones we used, and much faster. But I had the idea that I needed to switch a high current. I remembered that I could use a MOSFET to switch high currents. So I looked into MOSFETs. The first challenge was the switching voltage. Most MOSFETS require a high voltage to switch, e.g 12v, but we only had 3.3v. After some more investigating it seemed there were some MOSFETs you could switch with lower voltages.
I found one, and the quickest supplier (Jaycar, they are in the CBD) used to have this specific type, but didn’t stock it anymore and instead had a replacement. I promptly added this to my list and my quick skim of the specs suggested it would work. (These things are hard to read if you aren’t doing it everyday and it took me a while to decompose what I was looking at).
Once I started prototyping it became clear these were TTL and not 3.3v MOSFET (sigh…). The Pi does have a 5v rail available on the GPIO pins, so I figured I could use a common BC558/BC559 to do the switch (those are basic NPN and PNP transistors).
My first personal attempt at a switch circuit worked, but the logic was reversed. (Give me a break, it’s been a long time OK). Some googling presented an alternative idea (which I think is actually quite clever) and I revised my circuit similar to the one I found (different transistor and thus, different resistor values).
This little circuit is a poor mans 3.3v to TTL driver. It’s not perfect, in that if your input is floating, it’s technically pulled high by the the 3.3v supply and associated voltage divider resistors.
I’ve had a few thoughts on how to fix this, but since we’ve set the Pi up to initialise the used pins to low it gives a good indication everything is “ready”. It also gave a small buzz every time the server software restarted which was a good indication the reload was successful!. I’ll go with it for now.
So we now had a circuit that could switch a reasonable high current on 12v to drive the solenoid, strobes and buzzer.
As with any circuit where you are switching mechanical devices these can induce back currents, and you don’t want that destroying your precious digital circuit so a power diode was added across the load, to reduce this risk.
The Emergency Override
During testing, I got a bit sick of the buzzer (oh my it is so loud). I also figured that if I wasn’t around and everything exploded we needed a manual overide. This was a simple switch in the 12v line. John also suggested a visual indication that the 12v rail was live, and so a nice big yellow L.E.D was added.