Smart Entry System

by Acronym5840 in Circuits > Electronics

353 Views, 2 Favorites, 0 Comments

Smart Entry System

SmartEntrySystem_LockModule.JPG
IMG_5244.jpeg

The smart entry system allows an authorised user to unlock an entry way with a simple button press. It consists of a lock actuation module and a control module. The lock actuation module moves the lock level to actuate the lock, reads feedback from the servo to tell what position the lock is in, and reads a door sensor to confirm the door is closed. It is based on a Particle Argon IoT board which allows for simple programming and wireless management of the device. The lock module is battery powered so that no wires interfere with operation of the door. Manual operation of the lock remains possible so that the door can always be unlocked from the inside - even if the battery is expended.

The control module monitors a camera watching the entry way, and uses openCV to check the faces against the faces of registered users. If a registered user is identified and presses the open button, then the control module sends a request to the lock actuation module to open the door.

Communication between the two modules occurs over the a wireless LAN using the MQTT protocol. The lock module provides state updates to both the local MQTT broker, and to the Particle cloud so that the security status of the door can be simply checked. The lock module can be locked and unlocked either with Particle functions, or using MQTT messages.

This Instructable describes how to build the Smart Entry System. It will describe the mechanical build, the electronic design, and the software that controls the system.

Supplies

  • Raspberry Pi 4B
  • Raspberry Pi Camera Module (V1)
  • Particle Argon Development Board
  • High torque metal gear feedback servo
  • Micro switch
  • Aluminium channel
  • Epoxy
  • Timber/board to make enclosures

Mechanical

IMG_5243.jpeg
IMG_5249.jpeg
IMG_5251.jpeg
IMG_5252.jpeg
IMG_5253.jpeg
IMG_5254.jpeg
IMG_5255.jpeg

The mechanical implementation for this project is relatively simple, and there are many ways it can be accomplished. I chose to make boxes out of timber for both the lock actuator module and the control module as it was simple and I had the tools to hand.

Lock Module

There are a couple of key points for the lock module, as it needs to actuate the lock on the door. To do this, I epoxied and screwed a piece of aluminium channel just wide enough for my lock level onto the servo horn so that when the servo turned the lever would have to turn with it.

The lock module needs to be mounted on the door so that the axis of the servo and the lock lever are aligned. I did this by holding the module on the lock while I manually turned it back and forth so that it seated correctly, before screwing the enclosure directly to the door with screws at an angle.

Finally, make sure you can still manually access the lock so that you can always turn it in case the system isn't working. This will ensure you aren't trapped if something bad like a fire happens.

Control Module

Nothing too this one - a box with a raspberry pi in it. You could get away with just a purchased enclosure if you wanted.

Electronic

ControlModuleWiring.png
LockModuleWiring.png
IMG_5245.jpeg
IMG_5247.jpeg
IMG_5250.jpeg

Electronically this project came with some challenges. The control module is pretty simple - a Raspberry Pi with a camera module and a button attached to a GPIO, but the lock module has some challenges in powering the servo from a battery.

To make the lock module electronics simpler to implement and modify, I used some strip board to make a breakout board for the Argon. This allowed me to remove the Argon and connect it to USB for serial debugging or other purposes. It was also handy as it allowed me to make a 0V, 3.3V and 5V rail that I could use for the sensors, rather than trying to splice wires together to use the single pins for each of those on the Argon. As you can see in the photos, the strip board just had two female headers installed so that the Argon can be inserted. I have then placed male header pins directly next to this so that signal wires can be connected easily.

Below the Argon you can see a 5V power supply. This powers a 5V rail for the servo, as it is not powerful enough when using the Argon 3.3V supply. The LiPo battery directly connects to both the 5V boost converter input and the Argon LiPo input. Make sure you tie their grounds together also, otherwise you will have trouble getting clean signals from the servo!

The Servo caused problems running off the battery. Despite being rated for a stall torque of 1.3 Amps, it would draw over 2 Amps when just given position commands. I am not sure why this is, but suspect it is something similar to the inrush current a conventional motor has on start up. My solution was to add the biggest capacitors I could fit across the battery supply and across the servo terminals, however this didn't work. After some head scratching, and discord questions, I ended up implementing a software fix to reduce the servo movement speed which solved the issue (if the lock is not obstructed).

Software

StateMachine.png
ControlFlow.png

The software implementation was the really interested bit of this project. Both modules were challenging, but ended up with a pretty good result. I will discuss each module in turn.

Lock Module.

We need to start by setting up the Particle development environment. You can use the Particle WebIDE, but I highly recommend the Particle Workbench extension for VSCode as you can take advantage of intellisense and other extensions. The Particle instructions on set up are easy to follow: https://docs.particle.io/getting-started/developer... Particle uses a similar scheme to Arduino where they provide a series of functions that you can use in your system. They also use the Arduino .ino files and setup() and loop() scheme, which I made use of for this project.

The lock module has a series of complex interactions based on different variables, so is well suited to a state machine as shown in the picture. I implemented this state machine by using the setup() function as the INITIALISATION state, and then having a switch statement in the loop that continually called the state stored in the global variable currentState. Whilst less elegant than use of function pointers or class based states, this allowed a simple and reliable implementation. As the states for the system are relatively fixed, the overhead of changing them isn't really an issue.

The default state in the loop is the WAIT state which basically waits for a difference between the desired state of the lock and the actual state of the lock, and then calls the appropriate state to get there. WAIT checks the state of the lock on entry. If it has changed, it is assumed to be a manual lock turn, and both the desired lock state and actual lock state are updated. Then WAIT checks flags for Particle cloud function calls, MQTT requests or button presses and updates the desired lock state to match these requests. Finally, the WAIT state updates the currentState variable to the required state based on the new desired lock state and door status.

The LOCKING and UNLOCKING states are relatively simple. They gradually increment the servos commanded position towards either the Locked or Unlocked target position by calling the SetLockPosition() function. Remember that just calling the target position directly causes the power supply to over current, and the Argon to reset! This function continues to loop until the target position has been reached as determined by the servo feedback.

The CONFIGURATION state simply updates the variables for locked and unlocked command and feedback values, then calculates a threshold between locked and unlocked as the average of the two. These values are stored in EEPROM so that they can be configured once at install time and used persistently.

Finally the ERROR state is simply a holding state while a user fixes whatever error has occurred. Once the error is fixed, a button press transitions the system back to the WAIT state.

Button and door switch reads occur on a timer interrupt that runs persistently. This allows for debouncing the inputs by ensuring they persist for a given amount of time, and detecting short or long inputs. The interrupt handler simply sets a button event flag or door state variable if valid events are detected.

Control Module.

The control module has two key components of software. The first is a local MQTT broker used to coordinate communication between the lock module and the control module program. This is just an instance of the excellent Mosquitto MQTT broker which is set to start on boot. Mosquitto can be installed by following the instructions here:

https://mosquitto.org/download/

The control program relies heavily on a series of libraries to achieve facial recognition. In order to install the OpenCV libraries on the raspberry pi, I followed the instructions here: https://core-electronics.com.au/guides/face-identi...

Finally, the test scripts provided at the link need to be updated to use the raspberry pi camera module by changing the commented lines that initialise the camera. Full credit to the people at Core electronics for providing the tutorial that greatly reduced the time for me to get into the deep end with OpenCV.

Now, we are ready to implement the control program in python. The control program is effectively a combination of the image capture, model training and facial recognition applications shown at the tutorial above. After intialising camera streams, the Detect Identify function continually looks for faces in its field of view. When some appear, it encodes them to facial recognition data, and compares the encodings to those stored as authorised users. If there is a match, then it publishes an MQTT message to unlock the door. If they are not a match, it does nothing.

The register user function uses the camera to take a series of pictures of a new face, then passes those images into the model so that they can be incorporated for future identify detections. Once this is complete it reboots the system. This reboot is predominately driven by conflicts in the libraries used for the Detect Identity and register users functions. There is a bug in the imUtil library that fails to properly release the camera, so we work around it by rebooting the system for a fresh start each time we need it.

The code for both modules can be found in my github repository here: https://github.com/miedda/SmartEntrySystemPublic