This was a class project for MSE 101 at SFU. The task was to design a product or system, build a prototype, and complete a series of reports on the project as development progressed.
Beyond being the designated team leader for this project, I was the sole team member responsible for the design of the system, as well as its construction. One other team member contributed the CAD files for the final prototype’s case, though they were heavily modified to make the parts fit together correctly.
WiFi was chosen as the wireless technology because a web backend could be used, as opposed to bluetooth which would’ve required the creation of a smartphone app. WiFi also created the potential for the lock to be actuated from anywhere, as opposed to just local operation. An ESP 8266 WiFi module was chosen because at the time, it was relatively new and experimental, and very inexpensive.
I made a video of the project here, which goes into detail about a lot of the design decisions and has closeups of the components.
MCU: ATmega 328
WiFi: ESP8266 module
Motor driver: L298
A custom designed optical encoder to determine whether the door was locked or unlocked.
The motor driver chip was chosen because of my familiarity with it, as well as the fact that I had multiple on hand. Throughout the entire electronics design process, components we already owned were picked to keep the project under budget.
Control of the system was handled by the ‘328, which communicated with the WiFi module over serial, and took inputs from the pushbutton and optical encoder. Feedback was provided to the user through an LED, a beeper, and through the web interface itself. Power came from a wall adaptor, as none of the components for the prototype were optimized for low power operation. In the future, the firmware should put the WiFi module to sleep, which would result in considerable power savings. And given that the ESP8266 has an internal ARM microcontroller, we could do all of the control from the module, negating the need for the ATmega 328.
The lock was controlled by a web interface. When buttons on the interface were pressed, the lock would open or close depending on its current state. The state of the lock was checked before every movement and always kept up to date in a MySQL database that the interface had access to. The backend was written in PHP, and database entries were also updated when the physical button on the lock was pressed. States were saved with a timestamp so users could see when the lock was last actuated. Live user feedback was mostly implemented, using AJAX.
All of the mechanical components for the lock were designed in SolidWorks and 3D printed. Two prototypes were created, and parts were carried over between prototypes to keep the project under budget. Here are the main components:
- Coupler between motor and lock lever
- Optical encoder wheel
- Encoder mount
- Main case with integrated PCB and motor mounts
- Pushbutton extender (prototype #2 only)
- Case lid/front panel (prototype #2 only)
I designed everything but the main case for prototype #2, though I did modify it with my own motor and PCB mounting bosses. The entirety of the lock was assembled in CAD to check fit before printing, and 3D printing constraints were considered throughout the entire process. By creating two prototypes, we were able to nail the tolerances for the final prototype, enabling us to create very reliable friction fits for some parts, reducing BOM cost.
This was an incredibly rewarding project to complete. I got the opportunity to utilize many sub-modules that I’d had experience with from previous projects (motor driver, power supply, etc), but also the chance to use new modules, like the ESP8266 WiFi board. Programming the web interface was an interesting challenge as I’d never communicated with a MySQL database through PHP before, or set up databases and handled GET requests.
In the future, it’d be fun to revisit the project and take more time to design it for low power and make it physically smaller. There are many approaches to this – sleeping the WiFi module, getting rid of the external MCU, or communicating over Bluetooth to a WiFi base station. There was also a lot of empty space inside the prototype. While it looked impressive, the empty space was really just a waste. A case redesign, coupled with a custom PCB (instead of a protoboard one-off) would allow the device to be a lot smaller.
The web interface could also do with a security overhaul. I’m no security expert, and it likely shows in the code for the backend, which is obviously not a particularly good thing for a lock connected to the internet. Luckily for the prototype, it can only be actuated by devices on its own local network, which provides a good amount of intrinsic security to the system.