Posted on

Michael Chen’s status report for 10/31/2020

This week, I met up with Alex and Alex to go over the Raspberry Pi side of the locking mechanism. I also wrote up a short Python test script that connects to the WebSocket and sends some test messages to ensure that we can receive messages from the “server”. Since WebSocket requires a persistent connection, I’ll have to migrate the code later on once we get the other features up and running so that the WebSocket connection is properly maintained.

I also did some extra research on the security architecture of the system and was able to conclude that using IAM keys to authenticate the Raspberry Pi to the server was the best available solution, as AWS API Gateway does not support mutual TLS for WebSocket APIs. Many of the articles that I read such as this Heroku one (https://devcenter.heroku.com/articles/websocket-security) suggest having the user authenticate with secret information such as a username and password to retrieve a token that will authenticate all future requests. However, since the RPi is handling the server communication and the user is not able to directly interface with the RPi, we decided that we would need to use the IAM keys since the user would not have to enter them and the permissions on the associated IAM role would only allow any adversary to invoke the API if the keys were compromised.

There aren’t any major risks at the moment. My work has been pretty straightforward and standalone, so integrating with the other code should be simple. Next week, I plan to work with both Alex’s again to get all of the server communication set up on the RPi. I also plan to work with Alex Li to get the WebSocket communication up and running on the Android.

Posted on

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

This week I wanted to debug the locking mechanism and determine as a group what we wanted to do about using an Arduino in our design. On that latter point, it seems that Alex Li was able to get the Raspberry Pi working with the NFC Shield module directly without needing an Arduino middleman. It invalidates some of the work I’ve been doing on the Arduino, but overall this is a gain for the group. A lot of latency and redundancy concerns stemmed from the inclusion of the Arduino in our design (as it was simply acting as a controller between the NFC Shield, the Raspberry Pi, and the locking mechanism), so removing it will allow the system to be more lightweight.

As for the former issue about the lock, I demonstrated the mechanism in person to Alex and Michael, and the problems we currently faced in getting it to work. We determined that while there may be enough torque in the small servo motor to operate the lock, we would most likely need a 3D-printed cap that fits the door lock tailpiece and the servo motor, but doing so would require some extra design time. In the meantime to be safe, we’ve decided to get a stronger motor that preferably will have a better way to interface with the mechanism we want the motor to turn to avoid needing to spend this extra design time. Hopefully we’ll be able to put in an order request by Wednesday by the latest to get it as soon as possible.

I also went down to TechSpark in person on Wednesday to open discussions about our design plans, and we’ve received a general go-ahead with the estimated dimensions of parts we’ll need. The overall casing looks to be a 6-8 hour job in the self-serve 3D printers, so we can begin the CAD on that side too.

Open issues: finding this mystical lock that works for our design. I’m doubtful by what I’ll be able to find online. We may need to proceed quickly with the 3D designs should I fail to find something that fits our tailpiece.

Next week will be about determining if it’s more possible to find a fitting motor endpiece or if we need to manufacture one ourselves. I also need to finish a purchase request. Finally, I just received the extra Raspberry Pi, which I’m thinking of setting up so we have a backup. No photos from me this week, but next week we’ll hopefully have more to show.

Posted on

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

This week I primarily focused on working with the locking mechanism and started with some basic Arduino code to familiarize myself with the board. Unfortunately, I realized that the tailpiece of the exterior-facing lock cylinder is in an awkward position to be operated on by the motor. I had originally wanted the motor and the lock tailpiece to interact naturally, but I’ll have to make modifications to either the tailpiece or look into a stronger or different motor (one with more rotational power, perhaps). On the Arduino front, I’ve been doing some basic code compilations to make sure the main pins and ports on the Arduino Uno function correctly. I’ll look into hooking more components up to it next week.

Open issues: figuring out a solution to the locking problem. I’m fairly certain I can adapt the current design as it stands to make it work, but I’ll do some more research into lock tailpiece alternatives and stronger motors. I’ve attached a picture to show what the situation currently looks like.

Next week will be finalizing my locking mechanism solution and getting the Arduino to output signals to a breadboard. With spare time, I’d like to look into how an Arduino interfaces with a Raspberry Pi and potentially look into cutting out the middleman.

Pictures: locking mechanism, basic Arduino setup (breadboard not pictured).

Posted on

Team status update for 10/24/2020

This week, we were able to work on each of our individual parts. Michael got the AWS infrastructure set up, Alex Li worked on the Android app development, and Alex began to test the motor with the Arduino as well as researching how to send information between the RPi and the Arduino.

One of the more significant risks that we had identified in our design report was that the speed of the unlock process would primarily be affected by both the wireless latency and the physical motor contraption. This week, we struggled to adapt the motor to our lock mechanism use case, and may need to figure out alternatives to interface with the door lock. We are currently looking up alternate motors or rotating mechanisms that would suffice in this operation, and we will be ready to discuss alternative options to substitute in the mechanism.

Next week, we plan to continue our individual work and meet up later in the week to figure out how each of our parts will interact with the others. Now that we are designing the physical lock, we are also beginning to work with CAD tools to design the physical container that will hold the actual lock components.

We made some updates to our schedule. Michael swapped the order of developing the AWS server and developing the software on the RPi since we haven’t received our RPi’s yet.

 

Posted on

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

This week I worked a lot on understanding Android App development. I am behind on schedule due to recent interviews, but I will have this whole week to catch up. I think the challenge for me was that although the design and conceptual parts of the app and development were easy to think through and develop, actually working in Android Studio has a steep learning curve. Trying to compile even a simple app can cause a lot of errors if you don’t understand the Android development framework. For example, without refactoring, using the XML tool (view the app’s GUI while editing) to add or remove a simple button can cause a lot of dependency errors. The great thing about the Android Studio though is that there are a lot of visual tools like the XML tool, or even an Android emulator whenever you run the code. For Android app development, I learned a lot more about Java, fragments (behavior or portion of UI), and activity (general term for single thing users are focused on) lifestyle. Finally, I put together some draft app layouts (with the add button for the home screen) and routed it to a lock registration screen. I am still working on how to save the data using text input with the developer tools I have. In summary, there were practical challenges that I didn’t expect to have, but I expect to be back on track next week because I will have a lot more time.

Posted on

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

This week, I finally managed to get back on track with the schedule. I was able to complete the Lambda that handles all of the request logic and set up the WebSocket API. I tested each of the different API endpoints and Lambda handlers using the wscat tool and the Lambda successfully integrates with the DynamoDB tables. There may be small tweaks that I need to make later on, but those changes should be very simple since all of the infrastructure is already in place.

There are a couple of changes of note that I made to the AWS infrastructure. One change that I made to the system is that I picked up the Serverless framework (https://www.serverless.com/) to manage the AWS deployments. Serverless greatly simplified the deployment process since it manages API Gateway and Lambda configuration in an easy-to-edit configuration file. I also did not use the pynamodb library as originally planned because boto3, the Python AWS SDK, already has methods that allow me to read and write to DynamoDB tables.

Now that all of the AWS functionality works, I need to begin working on the integration with the RPi and Android phone app to ensure that they can communicate with AWS. Since we plan to use IAM authentication to secure our API requests, I need to figure out how to set up the access keys on the RPi and the Android app so that they can make requests to the API. I plan to meet up with both Alex’s to figure that out. One risk associated with this is that it may not be possible to actually manage the access keys securely. In this case, I would likely have to change the authentication method to use a Lambda authorizer instead, which would add additional work of writing the authorizer.

Posted on

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

This week I ended up working quite a bit with my group on the design document due at the end of this week. We decided that that would be the main task for the week, as it was the most pressing concern with a hard deadline. I believe we’re still attempting to track a few parts down that are currently unaccounted for, but this shouldn’t have any impact on my parts of the project.

Open issues: catching up to time. Like last week, I’m confident we’ll be able to get back on track. I’ve looked at a few tutorials on how to get the hardware working (both on the Arduino side and on the locking mechanism side), and I think that even though I don’t have a tangible progress update I think I’m in good shape all things considered.

Next week will actually be about getting back to work. I don’t think there’s a report for a while, so progress should pick up.

Posted on

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

This week was busy with working on the design document, so I wasn’t able to spend as much time on working on AWS as I had hoped. I did more research into API Gateway and set up a simple WebSocket API that I connected to a test Lambda. After setting up the AWS CLI on my Mac, I was able to query the API and invoke the Lambda function.

Next week, I plan to start writing the actual Lambda function that will control all of the information processing between the RPi and the phone app. I will also start working on the DynamoDB integration with the Python Lambda using the pynamodb library. I’ll need to do some research on how the pynamodb library works as well.

Posted on

Alex Li’s status report for 10/17/2020

This week I worked on the design presentation and report for the App and NFC portion of our project. There was a lot of NFC specific research I needed to do in order to figure out how our project was going to work. NFC on Android has some specific tools and functionality to assist with peer to peer NFC communication such as the tag dispatch system and host based card emulation. I also drew up the wireframes for the app, worked out app to server communication, and sketched a plan for app to NFC interaction.

Next week I will be working on early development of the Android app. I was going to work on development this week, but we had to do the design presentation and the design report which took up more time than expected.

Posted on

Team status update for 10/17/2020

The biggest risk right now is how long our power supply is going to hold up. Right now we do not yet have a power supply (just configuring lock and RPi with USB connection), but depending on how long the power supply will last with motor, NFC, and web connection, we may need to find a better solution. We will be testing this in the near future.

We spent most of this week working on our design presentation and report. There are currently no changes to our block diagrams/design or schedule from our design presentation (has only been a few days). We will be working on early development stages in the next few weeks.