Posted on

Team Status Report for 2/22/2025

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

This week we received the sensors that we ordered and Kaitlyn and Lilly tested them each individually to ensure that they work. This upcoming week we are beginning to connect sensors and microcontrollers and start small amounts of integration, which if unsuccessful will be the thing that will jeopardize our project the most. These risks are being managed by slowly doing integration, i.e. one device at a time so if there is a problem then we can more easily determine where it is coming from. On the software side of things, the most significant risk at the moment is not being able to run the opencv library due to security issues with the browser extension (i.e. Chrome’s disabled running remote code in Manifest V3). A contingency plan in place and that Cora is currently exploring is running the blink detection code on a web app then having the web app communicate the data to the browser extension.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

We do not have changes on the hardware side. For the browser extension we will likely have to slightly change the flow of data: web app will run remote code (i.e. opencv.js library) -> store data in cookie -> browser extension reads cookie -> extension displays data which is different from our original plan of having the browser extension both running our blink detection script and displaying data. This change does not incur costs but may affect latency delays which is of concern to us since we do not want there to be too significant of a delay between the time when the user exhibits poor posture/eye strain to when they actually get a notification that they are exhibiting these symptoms.

Provide an updated schedule if changes have occurred.

We do not have significant design changes thus our schedule remains the same.

Posted on

Cora’s Status Report for 2/15/2025

This week I worked on making a prototype browser extension. Specifically, I made a Chrome extension which I’m running in Chrome’s developer studio (this is where I’ll be testing it until we are finished then I will upload it to the Chrome Web Store so that others can download it). Currently the extension consists simply of a button which when pressed creates an alert in the user’s system tray. In the finished extension, the alert will occur when the data from the sensors indicate poor posture, but right now I just have the user press the button to demonstrate the system tray notification functionality. In addition, I created a script which allows the user to grant camera permissions in the options menu of the extension. This is important because we need the camera for the CV eye strain algorithm. This unfortunately must occur in the options of the extension and not in the extension itself because this is not an innate function of Chrome browser extensions.

My progress is on schedule. Next week I hope to add the CV script and see if we can run it in the extension (I know that Lilly has the CV script working locally but we have not yet tested it via the extension). I also want to set up the local server on the raspberry pi since we recently got possession of the pi we will be using.

Posted on

Cora’s Status Report for 2/8/2025

This week I focused on researching the browser extension. The browser extension is going to be used in order to allow the user to easily interact with our project and give them an intuitive UI to view their data and make changes such as toggle options for their camera being on/off and whether sound notifications are on/off.

I researched which browser would be best to make our extension for. I came to the conclusion that Google Chrome would be the best because of the thorough documentation that’s available, the APIs that Google provides, and its straight-forward development process. I researched what type of permissions we will need to ask the user for since the user being aware of what they’re installing is important to us. I wanted to establish the most minimally invasive permissions necessary so we’re not asking for more than what we need and compromise the user’s security. I established we will need at least the following Chrome permissions: audio (for audio notifications), notifications (for on-screen alerts), activeTab, and scripting (in order to adjust brightness of screen). These permissions will be listed in the manifest.json file which is part of the family of files that make up the extension. Note that the user must accept to all these permissions at installation time even if they later choose to disable related features. Otherwise, some permissions can be declared “optional” which is something I would like to discuss with my team to see if this makes more sense for our project.

My progress is on schedule for this week. Next week I hope to have a prototype extension ready in order to test out the basic infrastructure of our extension. I also want to begin with setting up the RasPi hosted server.