Trinity University

Digital Commons @ Trinity

Mechatronics Final Projects Engineering Science Department

5-2022

Electronic Fingerprint Safe

Bryton Flecker
Trinity University, [email protected]

Carlos Bucheli
Trinity University, [email protected]

Tristan Arias
Trinity University, [email protected]

Follow this and additional works at: https://digitalcommons.trinity.edu/engine_mechatronics

Part of the Engineering Commons

Repository Citation
Flecker, Bryton; Bucheli, Carlos; and Arias, Tristan, "Electronic Fingerprint Safe" (2022). Mechatronics Final
Projects. 15.
https://digitalcommons.trinity.edu/engine_mechatronics/15

This Report is brought to you for free and open access by the Engineering Science Department at Digital Commons
@ Trinity. It has been accepted for inclusion in Mechatronics Final Projects by an authorized administrator of Digital
Commons @ Trinity. For more information, please contact [email protected].
Final Report
Electronic Fingerprint Safe
Bryton Flecker, Carlos Bucheli, Tristan Arias
Project Group 4

ENGR-4367 Mechatronics | Trinity University

May 16, 2022

Table of Contents

I. Design Summary 1

II. System Details 2

III. Design Evaluation 5

Output Display Device 5

Audio Output Device 5
Manual Data Input 5
Actuators, Mechanisms and Hardware 6
Logic, Counting, and Control 6

IV. Partial Parts List 7

V. Lessons Learned 7

VI. Appendix 8
 I. Design Summary
The objective for this project was to create a lockbox storage solution which used
a fingerprint sensor (3) as the mechanism for locking and unlocking the device. A user of
the device would have the ability to add or remove up to four fingerprints from the device
while it is unlocked. As a backup measure for the event that a fingerprint is no longer
recognized, the lockbox will have a preprogrammed PIN assigned to the device which
the user can enter to unlock it. User input was implemented via a series of buttons (5) on
the front panel of the lockbox. Then, to display information about the state of the lockbox
and communicate any other UI information, an LCD display (4) was included on the front
of the device. A stepper motor (1) positioned under the lid was also used as the
mechanism for both opening and closing the lid of the lockbox via a connected lifting arm
while a solenoid latch (2) also positioned inside the box was used to lock it. A buzzer will
sound an alarm should a tilt sensor detect movement of the box above a certain
predefined threshold.

Figure 1. Labeled Final Prototype

ENGR-4367 Page 1
 II. System Details
In order to implement the design described in the previous section, the team
created an initial hardware sketch as seen in Figure 2. This schematic shows the general
placement and distribution of key features of the lockbox.

Figure 2. Initial Hardware Sketch

The primary structural features of the lockbox were made out of medium-density
fibreboard (MDF) wood due to material availability, ability to be laser-cut, and structural
stability. The MDF was laser-cut and glued into an interlocking assembly providing the
overall structure to exterior faces, allowing for securement holes for the various
electronic components, the support and securement for the fingerprint scanner, and the
stops and latch for the lid. The higher-stress components of the brackets for the servo
motor and servo horn extension arm were laser-cut from ⅛” thick black acrylic. A simple
hinge was used to allow for lid rotation, and a small brass tube with masking tape stops
pinned the lid slot to the servo horn arm extension.

As the first step to start programming the box, a software flowchart was created
and can be seen in Figure 3.

ENGR-4367 Page 2
 Figure 3. Software Flowchart

ENGR-4367 Page 3
 Additionally, a wiring schematic showing all components and their respective
connections can be seen in Figure 4. The team chose to use a PIC microcontroller as well
as an Arduino UNO to implement the lockbox code.

Figure 4. Circuit Schematic

ENGR-4367 Page 4
 III. Design Evaluation
Output Display Device
The output display device used in this project was an LCD Display using I2C
communication. Although it worked smoothly once configured, the task of making it
functional required a significant amount of research to set up properly as it was not
covered in any of the course materials. We eventually managed to find a library for the
Arduino which supported I2C communication with an LCD display, but it was poorly
documented and required a non-trivial amount of trial and error to determine how it
functioned. However, once set up it was relatively simple to use as it was designed to
imitate the API for a traditional LCD display and thus this category likely scores as a
[15/20] on the design evaluation scale.

Audio Output Device

A buzzer was used as the audio output device for this project as we simply
needed a loud alarm for the case that the lockbox detected suspicious movement. It did
require some minimal research to determine why it seemed to work in some circuit
configurations and not others, however it was minimal as we rather quickly discovered
that the buzzer we selected was directional and simply needed to have the connection
pins oriented properly for it to function as we intended, thus resulting in a [10/20] on the
evaluation scale.

Manual User Input

There were two methods for manual data input used in this project, the first were
four simple push-buttons while the second was an optical fingerprint scanner. Although
the push-buttons required practically no research to implement, the fingerprint scanner
was quite complicated and required extensive research to determine what model to
purchase, how to interface with it, and many additional hours to implement the code
required to have it interact with the remainder of the system. In summary, the final
implementation of the scanner included authenticating up to four separate users,
adding/editing user fingerprints, and removing user fingerprints from the database. A
combination of factors including debugging hardware failure mean that this category
should likely score a [20/20].

Automatic Sensor
The automatic sensor in this project was a tilt sensor which did not require
considerable research to implement as the output could simply be interpreted as either a
high or low signal by the PIC processor. However, there was some difficulty implementing
the device as the sensor actuation wasn’t initially detected by the PIC. We eventually
discovered that it wouldn’t register an activation without the addition of a pull-down
resistor, however as this took only minimal research to discover, this category should only
score a [10/20].

ENGR-4367 Page 5
 Actuators, Mechanisms and Hardware
The actuators used in this project were a solenoid latch and a servo motor.
Implementing these devices took additional time and research than the audio and tilt
sensors mentioned previously as there were several challenges we encountered when
attempting to get them functional. One of the major issues that we encountered was the
power consumption required to get them operational. We originally believed that all our
systems could be powered either directly from a 12 volt battery or the 5 volt power
supply from an Arduino, however it was discovered that when we needed to activate the
solenoid latch and servo simultaneously, there was enough power draw to starve the
Arduino of energy and force it to restart. We were eventually able to circumvent this
issue by creating a separate power supply circuit, but the amount of time invested in
making these systems function properly would likely score a [15/20] on the rating scale.
The mechanisms and hardware could largely refer to the mechanical design of the
lockbox itself. The design of the lockbox proved robust, clean, and reliable, with the only
apparent flaw in the design being the poor spacing for the 12 volt battery, resulting from a
lack of account for the battery’s flex in the middle of its height. The box’s design was
begun early, and in such a way as to allow for adaptability in the position and size of
components placed within it. This provided the team the flexibility to adjust component
position to optimize cable routing and interface intuitiveness. The space taken by the
various planned components was also mocked up during the design process to ensure
proper fits and margins. The combination of these considerations resulted in minimal
redesigns after initial print and assembly. Only one redesign was performed, to add an
on/off switch for box power, and reprints were made of the servo brackets and servo
horn arm extension due to breakage and subsequent replacement with stronger
material. Due to the final quality of the build, lack of connection to available textbook and
lecture information, and the degree of effort expended in precise measurement and
robust and adaptable design, this category would likely score a [15/20]. This does not
score higher because the design did not require much research apart from part
schematic retrieval for proper dimensioning and it possessed a flaw in the dimensions of
the battery slot.

Logic, Processing, and Control

This project was very logic and processing intensive despite not having any form
of traditional feedback control system. Implementing the functionality of the fingerprint
scanner alone was a significant challenge given the limitations of the user interface.
Designing an LCD interface to instruct the user how they should interact with the lockbox
was difficult due to the limited number of characters that can be shown on a 16x2 display.
Furthermore, ensuring that button presses were properly debounced so they didn’t
trigger multiple events was surprisingly difficult to get working consistently. Surprisingly,
the code for the fingerprint scanner was not as challenging to get working as the user
interface and menu logic once I found an Adafruit library to interface with the device,

ENGR-4367 Page 6
however, finding the library took a considerable amount of time since the original library
that we attempted to use, never managed to let us login to the scanner. Overall, due to
the challenge and extensive research required to get these systems functional, I would
say that this category deserves [20/20] on the rating scale.

IV. Partial Parts List

- Fingerprint Scanner: R307 Optical Fingerprint Module
This component integrates a fingerprint algorithm chip with functions such as
fingerprint input, image processing, feature extraction, template generation, template
storage, fingerprint comparison and fingerprint search. It had a cost of $22.59.

- Latch: Electromagnetic Solenoid Lock

This component was used as a latch mechanism, it uses 12 VDC and is normally
closed. It had a cost of $7.99.

- Actuator: Metal Gear Servo Motor

This component is a high torque motor with 270 degree control angle. It had a cost of
$21.99.

V. Lessons Learned
One of the major difficulties in finishing this project was burnout. We originally
anticipated that this project would require a considerable amount of time to complete
and tried to factor that into the project schedule, but there were even more issues that
came up than we originally accounted for which included partial redesigns of the system,
needing to reorder parts due to the hardware failure, team members falling ill, amongst
other problems. This culminated in a rush to complete the project which ended up
requiring a non-trivial amount of time past the original deadline which naturally resulted
in fatigue and burnout amongst the team.

Part of the reason for this was caused by a lack of realization about which parts of
the project could bottleneck progression and thus, when certain problems occurred, they
had a more dramatic impact on progress than was originally anticipated. One good
instance of this occurring was with the fingerprint scanner. A full day was spent
attempting to get the device working before it was realized that a small connection had
failed in the scanner’s power supply that we were unable to repair. As a result, a
considerable amount of the programming and testing and assembly was delayed for
several days as we waited for a replacement to arrive. Furthermore, due to the time
frame, we were unable to order from a reputable supplier and were thus unsure whether

ENGR-4367 Page 7
the new device would even be functional, which was a non-trivial concern since any
additional sensors we purchased would likely arrive only days before the project
deadline if they were required. As it turned out, the new scanner arrived in good
condition and due to the extensive amount of time spent trying to get the first scanner to
work, it was not too difficult to verify that the second one worked as we expected.

In hindsight, there were parts of the project related to coding that could have
probably been completed during this downtime, but due to the time pressure and other
assignments that required attention at the point in the semester when this occurred,
nobody realized that these options were available. We would thus make several
recommendations in terms of planning any future projects.

First, try to test hardware as soon as possible, and thus, order parts as soon as
possible. It is probably best to assume that the first and perhaps second part that you
order of each component will be defective so that you have time to react and aren’t
pressured by any component failures as they have been accounted for in the schedule.

Second, we would have wanted to integrate all project components into a final
assembly at least two weeks before the project deadline for something on this scale. Our
group and other groups found that although their project components worked fine
individually, that they interfered with each other in ways that were not accounted for.
These issues were largely related to voltage regulation and power supplies and required
multiple days of intensive effort to try to fix. In our case, we found that our solenoid latch
was somehow drawing almost half an amp of current even though we were under the
impression that it shouldn’t have any current draw while engaged and ended up needing
to design a completely new circuit to use as a power regulator so that our the power
requirements wouldn’t exceed the amount that our Arduino could provide.

Finally, it would have been much better to determine what systems we could
implement simultaneously to improve work efficiency. We simply didn’t anticipate how
difficult it would be to reprioritize tasks towards the later end of the project. There was
much more time available to discuss options earlier on in the process which could have
been leveraged much more effectively. It was overly optimistic to assume that we could
determine how to handle these issues while also trying to balance out work for other
courses towards the later part of a semester and dealing with burnout due to the
workload.

VI. Appendix
No appendices are provided with this report.

ENGR-4367 Page 8