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.

Michael Chen’s Status Report for 10/10/2020

Due to the upcoming design presentation, I wasn’t able to get much work done on setting up any AWS infrastructure. I was able to upload some sample code to Lambda and test it out in the console. The next steps for this week are to set up the API Gateway configuration to route all requests from that WebSocket URL to the Lambda and to familiarize myself with the pynamodb library in order to manipulate DynamoDB data from the Lambda.

No major open issues to report for this week. One thing to note is that our parts arrived somewhat late, so setting up the communication between the board and AWS will be slightly delayed, but it shouldn’t have too big of an impact on our schedule. I’m confident that I’ll be able to get the AWS setup working next week so that we can test communication from the board.

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.

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

Michael Chen’s Status Report for 10/3/2020

This week, I created the AWS account that we will be using for the communication between our phone app and the RPi that we will use for the door lock. Given the scope of our project, we should be able to use the AWS Free Tier account without going over the associated limits or even needing additional credits from the ECE department. I’ve been doing some research into how to use API Gateway, Lambda, and DynamoDB. This week, I’ll be working on getting some skeleton code uploaded to the account to make sure that we can invoke our Lambda through a WebSocket connection and return data from our AWS account.

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

Alex Li’s Status Report for 10/3/2020

We changed our project idea from Webcam activated lock system to an NFC activated lock system. This week I did a lot of research on NFC, basically trying to understand everything surrounding it, mainly using a book called Beginning NFC (found in O’Reilly books from the website). No development yet because we do not have our parts yet and I still need to understand how NFC would work in our system because of a recent pivot from facial recognition to NFC. A problem I have found out this week is that although iPhones have NFC technology, iPhones cannot emulate an NFC tag except for the case of Apple Pay. No other development tools are provided for peer to peer NFC. iPhones can only read/write to NFC tags. Android, on the other hand, has a lot of developer resources for peer to peer NFC. I am doing research this weekend on how I can workaround the iPhone peer to peer NFC problem, possibly looking into developing a separate app for this purpose. Next week I will do more research and start working on learning Swift and how to develop the app we are going to use.