Posted on

Team status update for 10/10/2020

The most significant risk as of now is catching back up to speed. Due to shipping delays, we are currently a few days behind what we’d originally planned.

To reiterate on last week’s update, we’re still going forward with the NFC tag and implementation as opposed to the Intel RealSense depth camera. Alex Li is looking more into its implementation and making sure it will work in our updated design.

The most pressing concern for us at the moment is making sure our design presentation is fleshed out. While at the moment we don’t have much in front of us, we have a pretty good idea of how everything will be connected. We’ll need to do a little bit of research to provide good block diagrams, but for the most part it should be doable.

Posted on

Alex Xu’s status report for 10/10/2020

This week we encountered a few hiccups in what we’d originally planned to do. I wanted to get a head start on interfacing between our parts (specifically the motor and doorlock), so that way the hardware be able to support the back end software/code, but our parts ended up taking a while to get delivered (arrived late on Friday). As a result, I instead focused my efforts into the design presentation that we’ll be doing on Monday. I have a good enough idea as to how things will connect, so I decided to focus on just making sure the presentation would be okay.

Open issues: catching up to time. I’m confident we’ll be able to get back on track. I also need to get some of the basic interfacing done, and read through the servo motor instructions and look at tutorials on disassembling the door lock so we can get started with everything. Finally, there were some hardware issues with the Arduino, so I wasn’t able to get it tested as of this week. I’ll also look to do basic debugging by next week.

Next week will target these three open issues to get back on track and start working.

Posted on

Team status update for 10/3/2020

The most significant challenge for now are figuring out how to prototype the mechanism that locks and unlocks the deadbolt. None of us have any experience with 3D printing or CAD tools, so designing the actual locking mechanism that is driven by the servo motor will require a lot of learning how to use the necessary tools. We plan to mitigate these risks by doing research in how to operate the 3D printer in the TechSpark space, as well as how to design using CAD tools. In the worst case, we can ask a staff member to operate the 3D printer for us so that we only need to worry about the design itself.

After the proposal presentation, we made a pretty large change to the design of our project. Instead of using a camera to do facial recognition on any approaching person, we pivoted to using a NFC reader that users can touch their phone to. We decided on this shift because the facial recognition approach would require 100% accuracy to ensure that no unauthorized person could open the lock, which is extremely difficult to attain in our project timeline. In addition, using a NFC reader speeds up the door opening process, since the logic behind authenticating the NFC tag is much simpler than any facial recognition algorithm we would be running. Pivoting to the NFC approach means that we will have to do additional research on how the technology works, since none of us are familiar with it. However, this will be well handled, as we will simply be reallocating the time we would have used researching facial recognition algorithms to researching NFC instead.

 

Updated Gantt Chart:

https://docs.google.com/spreadsheets/d/11u0CH7wN9QSDZPVNC4fUqijgiDlvcCUx_7uLzX8Nlr4/edit?usp=sharing

Posted on

Introduction and Project Summary

Hello everyone! We are group A5 (Alex Li, Michael Chen, Alex Xu) and we are currently working on a project called HoverLock. Our project idea is basically using NFC technology (something sort of similar to Bluetooth or RFID) in phones to be able to unlock locked doors. With just a hover of your phone, the NFC reader and the lock terminal will interact, and the terminal will correctly authenticate the user or maintain the lock if the user doesn’t have the right credentials. We got our idea from Apple Pay, which is a pretty popular payment system where customers can just tap their phone to a payment terminal and the payment would go through. We wanted to do something similar to the lock system for doors, effectively making unlocking doors a lot faster and seamless. Besides speed and convenience, we also wanted to make it a goal to have our prototype be secure and marketable, so people would actually be willing to use it.

 

We expect to use an NFC reader for our lock terminal, which means we would only need to process the information from the NFC reader through a Raspberry Pi. We will be building the lock system including motorizing a deadbolt lock and connecting the Raspberry Pi to a web server (for authentication purposes). The phone and the NFC reader would interact, and information is authenticated in the Raspberry Pi, triggering a motor to unlock or do nothing.

 

Our project proposal describes an initial design using a camera and facial recognition technology instead of NFC. We realized this would have too many security and speed issues, so we pivoted to the NFC idea. Everything in the project proposal slides is relevant except we replace the camera and facial recognition with an NFC reader.

 

Project Proposal: https://docs.google.com/presentation/d/1EV785WM7kQUi_hsCS9XF-ETQ25k-Rp5TGLilCU5PcmI/edit?usp=sharing

Posted on

Alex Xu’s status report for 10/3/2020

This week was essentially the official start of our capstone project. While we did some project pivoting, the core of what I intend to do remains the same, as a lot of the interconnect between the motors, circuits, and other electronic parts remain unchanged. However, as of right now we’re still in the ordering phase of the project. We’re in the process of talking to Jiaqi and Quinn, and hopefully we’ll start getting our parts ordered so we can begin tinkering with them. Until then, I plan on looking into a few Arduino tutorials so I can start interfacing between the motor and the circuitry. Scheduling-wise, we’re doing pretty well so far as we’ve taken into account the time to order parts into our Gantt chart. In terms of deliverables, I think I’d like to hook up an Arduino to a breadboard and get some kind of LED output to make sure that the Arduino isn’t broken.