Description
Every week in ESE111, the TAs walk around with a computer and a card scanner in order to take attendance. We created Fingerprint Attendance in order to create a better solution to attendance. Instead of requiring everyone to take out their PennCards, our device only requires a finger to sign in! After each class, the attendance data is automatically uploaded to the cloud to be accessible by all TAs over time.
How We Built It and Technical Specs
We were able to immediately identify the fingerprint sensor as the major unknown in this project. Luckily, our initial idea to integrate a fingerprint sensor with and Arduino and a computer ended up working rather well.
We used a SparkFun Fingerprint Scanner (GT-521F32) to scan fingerprints and connected it to an Ardunio Genuino Uno via a Qwiic Cable and a Bi-Directional Logic Level Converter. The device is turned on and off via a standard switch, and we also added a Wifi Shield to the Arduino in order to allow it to upload to the cloud.
Fingerprints are read and stored by the fingerprint scanner. On the first day of class, the TAs will need to enroll all the fingerprints and associate them with a PennKey, all of which can be done through the Arduino Serial Monitor. This information will be stored in the scanner, and when the device is in Attendance Mode, it will try to match the given fingerprint with a stored fingerprint. If there is a match, it will output the PennKey of the student in the Serial Monitor and mark him/her as present. This information will be stored in ThingSpeak to be accessible by all TAs.
Overall, the project was rather technically challenging, but the SparkFun website provided many resources that helped significantly. Along with a hardware hookup guide, they also provided a library that served as a starting point for our code. After working out a few issues and following the given resources, we were able to get a working device.
Issues and Challenges
In general, we were rather pressed for time in that our needed parts arrived late. We did the best we could by creating the groundwork for our circuits and writing the basic code, and once the parts arrived, we hit the ground running. In addition, we encountered a problem where the Ardunio could not use both the SoftwareSerial and Wifi libraries at the same time. According to online resources, this was a common problem that Ardunio has been trying to fix. In the meantime, we have written the necessary code to implement the online aspect of the device.
What We Learned
Due to the time constraints and the technically challenge aspect of this project, we had to work efficiently and quickly. We learned to consult existing resources and information before spending too much time on something that has already been figured out by someone else. In addition, we were able to split the work very efficiently, learning to use individual strengths in order to create the best possible device.
What's Next
We will certainly take the lessons we learned and apply them for all engineering projects in the future. As for the device, possible future iterations could include swapping out the Ardunio for a Raspberry Pi, as well as integration with Canvas.
Log in or sign up for Devpost to join the conversation.