For an engineering design course, we were taught the process of identifying a community, finding a problem in that community, discussing the problem with stakeholders, and proposing a solution to solve the problem. Of course, there was a lot more to it than that, but the reason I really enjoyed the course was because it was a great opportunity to experience the design process in its entirety. From finding a problem to building a working prototype of the proposed solution, the end result was very rewarding. My biggest role in this project, as you may have guessed, was to build the actual system. To address the problem we were given, we came up with the design for a safety perimeter for use in the construction industry. Essentially, this perimeter consists of an invisible laser based boundary. When this boundary is breached, the workers within the perimeter are notified through a wireless communication system. More specifically, the workers have an audible alarm inside their helmet, bright LEDs directed toward their peripheral field of view, and LEDs embedded inside their reflective vests as well (to warn others). This system can actually be used anywhere where you need to setup a perimeter which alerts you or sets off an alarm. This design was inspired by the safety systems installed alongside most automatic garage door systems.
Check out a video of it in action!
How does this system work?
As magical as this may seem to some (and to others, kids stuff), the way this whole setup works is fairly straightforward. So as demonstrated in the video, there are pretty much two parts to this setup: the ground based boundary creating nodes, and the helmet/vest nodes which are alerted. These two systems are connected wirelessly over a 2.4 GHz radio link. I used the Nordic NRF24L01 based wireless modules because they are extremely cheap ($3 for two pieces!), and the RF24 library found here made interfacing them an absolute breeze. I experienced some minor problems, but otherwise these chips worked great. I’ll describe the way the two systems work below:
Ground Based Boundary Generators and Signal Transmitters
For this project, I used matching black acrylic sheet to make enclosures for the electronics. One enclosure contains a laser module (5 mW, 632 nm) and a 250 mAh 3.7 V LiPo, and the other contains a slightly more complex device.
Above is the transmitter module. It is comprised of an ATmega328P microcontroller, the NRF24L01 wireless module, a L1117 3.3 V voltage regulator (the NRF24L01 only supports 3.3 V), and a LDR. That’s it! So in order to get this part of the whole project working, all I do is flick on the laser, position it so that it points right into the baffle containing the LDR, and constantly read the value picked up by the LDR. The microcontroller is programmed to interpret the value generated by the laser module as a nominal value. This means that there is nothing blocking the path of the laser, and the system is armed and ready. However, as soon as someone/something intercepts the laser’s path, the LDR detects this because, well, it is sensitive to light. The microcontroller is programmed to interpret this perturbation as a cue to warn the people within the perimeter that something has breached the it – so watch out! It does this by sending a single byte (I know, encrypting it in some way would be ideal). The ground based system’s role is complete, so we move on to the helmets/vest.
Personal Warning Device (Signal Receiver)
For this project, I installed warning mechanisms in a helmet and vest. The helmet contains two LEDs and one annoying buzzer, and the vest is equipped with four LEDs (the 6 LEDs in total are wired in parallel). So now, the helmet receives that single byte which indicates that the ground based sensors have detected an anomaly. The helmet and vest now kick it into high gear, and begin flashing/buzzing at a rate of 3 Hz, in an attempt to grab the attention of whomever may be wearing the devices, as well as anyone else nearby.
The electronics are actually very similar to those described earlier.
The receiver is also controlled by an ATmega328P, which receives the signal through the same wireless module (the modules are completely interchangeable, an aspect I took advantage of and will be described in my design decisions section). Since I had 6 LEDs and a buzzer, one pin of the MCU obviously could not supply enough power. So I used a 2N3904 transistor (I probably have a million lying around) as a switch, and connected all the peripherals directly to the power source (also a 250 mAh 3.7 V LiPo). So the MCU provided the signal with a duty cycle of ~33%, and everything worked beautifully. I also had to use a L1117 voltage regulator for the receiver’s wireless module. That’s all! Notice how simple the electronics are for this project?
Oh right, you probably also noticed that I soldered everything onto perforated boards to make sure nothing moved out of place. I’m beginning to find myself getting very frustrated with solderless breadboards. They have a tendency to cause lots of random issues, and end up wasting a lot of time.
Key Design Decisions
1. Using Sound and Light as a Warning
Initially, I designed the device to be based solely on visual warnings (i.e. just lights flashing). I soon realized that during the daytime, they are hardly noticeable. At nighttime, however, the lights look absolutely brilliant. You could probably notice them from a mile away. But things could go wrong during the day too, so warning the wearer is equally necessary. That is why I affixed a buzzer to the inside of the helmet – kind of as a fail-safe mechanism.
2. Using LiPo Batteries
LiPo batteries have pretty much become a staple in all my projects – but they are particularly important here. The reason I chose LiPos was because of their miniscule size and modularity. I mean, if you’re carrying something on your head, the last thing you would want is to be swinging around an extra 200 grams of weight. LiPos, at under 15 grams coupled with their excellent (and flexible) form factor became the obvious candidates based on what I had on hand. They also provide a lot more power per unit mass than something like AA or 9 V batteries, recharge extremely quickly, and are cheap as chips.
3. Using the ATmega328P
Realistically, I would not use this MCU for a project like this. The only reason I chose this one was because I had about 2 days to put this entire project together, from scratch. The fact that I could flash code written for Arduinos to these little guys made them very attractive for this project. Also, I tried the RF24 library, and it functioned perfectly. I really did not have the time or desire to try anything funky at this point, especially with a truckload of exams around the corner. The biggest motivator and driver for this decision was time (or rather, the lack thereof). If I had more time, I would use something which consumes less power (i.e. MSP430 by Texas Instruments).
4. 632 nm Laser
The reason for this choice was obvious – if I could not see the laser, I would have a hard time aligning the laser dot with the LDR. In reality, garage door safety systems use infrared. They have a lot more leeway, and may be better suited for this project. I will have to look into that a little more though, but I made use of what I had.
5. Design of the Tx/Rx
One thing you may have noticed by now is that the transmitter and receiver circuits look extremely similar. Well, that’s done for a reason. I designed this device with economics in mind. Check out one of my earlier prototypes of this system:
Among many other flaws, one key drawback of this version of the system was that the transmitter and receiver circuitry were relatively dissimilar (in comparison to the current version). So if I were to actually mass produce these devices, then I would have to produce two different sets of electronics. What’s advantageous about the current design is that the circuit schematics are almost identical, and therefore would only require a single manufacturing process to produce. You’re probably wondering how that may be if the transmitter has a LDR attached, whereas the receiver has a bunch of LEDs and a noise maker. All I would do is design a base circuit with an expansion port. That expansion port can allow either the LEDs/buzzer setup to plug in, or the LDR. In fact, they can share the same pin on the microcontroller too! Pretty neat if you ask me. A small switch would allow the user to change between tx/rx modes, as the code is also quite similar. Designing for manufacturability is a concept I was introduced to quite recently – and only now am I beginning to understand its importance.
Thankfully, this was a very straightforward project and I did not encounter any serious problems. Of course, the lack of time always poses problems as recently all my projects have been subject to very tight deadlines – but this problem is innate. Technically speaking, I only encountered one suspicious issue, which I have yet to solve.
This issue baffled me for four straight hours. I whipped up the code for the transmission side of the project. I always check if it works on an Arduino board before flashing it to a standalone MCU. Check this out:
- If I hooked up the wireless module to the Arduino with the transmitting code flashed to it, it wouldn’t work
- The Arduino worked just fine if I flashed the receiving code to it – without physically altering/touching any part of the circuit
- I tried a different Arduino, exact same problem and results (so it couldn’t be the one Arduino)
- I then discovered that if I lightly touched the 16 MHz crystal on the wireless module, the code worked as expected (this was replicated on both Arduinos)
- What made things more confusing was that when I placed the wireless module into the sockets I soldered for my actual prototype, flashed the transmission code to the standalone 328, and let it run, everything worked fine!
- When I ran the sample code provided in the RF24 library, transmission worked fine with the two Arduinos (so it couldn’t be loose wiring or anything)
This is probably the most bizarre problem I have ever seen. It can’t be the code, because it works just fine in an identical microcontroller. It can’t be the Arduinos, because both experience the exact same issues. It can’t be wiring, because the exact same wiring allows the Arduinos to transmit just fine with the “Getting Started” sample code. So what could it be? I had to give up and move on, but if anyone has any ideas, let me know!
That’s all folks! Thanks for reading.