Posted on

Team Status Report for 4/3

Currently, the most significant risk that could jeopardize the success of the project is the integration between the web application that visualizes the list of user items inside the backpack and the Bluetooth reader that determines whether the tagged item is inside the backpack. Moreover, because we have the interim demo coming in two weeks, we need to demonstrate that this functionality is fully working to ensure our success for the project. To manage these risks, we are doing extensive research on the Web Bluetooth API and communicating with Bluetooth devices so that we can quickly resolve problems that that arise during integration, both from solutions found by other users published online or alternative implementations that are available, such as having an additional Bluetooth reader. In preparation for integration, each of us have been testing each component incrementally and individually. For the web application, Janet has been testing the web application using dummy items and information so that communication with the Bluetooth scanner is not needed. For the Bluetooth scanner part, Aaron has been testing the Bluetooth scanner independently to check the robustness of the tagged item detection. For the item recognition part, Joon has been testing the CNN model on his machine so when the test is correctly done, the integration is done with the item registration part of the web application.

There is a change made to the existing design of the system. As stated in Aaron’s Status Report for 4/3, we have found that the onboard Bluetooth controller is actually disabled if the OS detects a separate USB adapter. Therefore, we have decided not to use the built-in adapter for the distance pruning of the tagged items. Instead, we have decided to use an array of 4 external USB Bluetooth adapters to determine the tag location. While this will require more of our budget to be used and require more power consumption, we believe that this will enhance the accuracy of our distance pruning algorithm and is worth the tradeoff.

The schedule for the item recognition part has been changed to account for the training of the CNN model for the item recognition and the testing plan for the CNN model is pushed back (but before the interim demo) to account for the integration with the web application and the interim demo. Additionally, we have added more time for Aaron to incorporate the additional Bluetooth adapters, and have pushed back implementing the power-saving sleep feature. The updated schedule is found here.

Posted on

Aaron’s Status Report for 4/3

This week I worked on interfacing the Raspberry Pi with the web app over Bluetooth. To accomplish this, I configured the Raspberry Pi to run a Bluetooth GATT Server to which the web app could connect to by Bluetooth pairing. After connecting, the GATT service on the Raspberry Pi presents the list of items ID’s in string format for the web app to read.

The code for the GATT server is written in Python, and it uses the Bluez package’s BLE advertisement example code to run. I used the CPU temperature reporting example written by Douglas Otwell as inspiration for the code. The GATT server works by presenting a reporting “service,” which the web app can connect to via the service’s UUID. The service can then send data to the web app by exposing “characteristics” which can also be read via the characteristic UUID. We haved tested this functionality and have successfully transferred data between the Raspberry Pi and web app.

In addition to working on the app-RPi Bluetooth interface, I also continued to work on improving the RPi-tag interface. With the arrival of a dedicated USB Bluetooth dongle, I began additional testing to determine it’s sensitivity and to compare it with the built-in Bluetooth antenna. Although the reported RSSI values were lower, the USB Bluetooth adapter was still able to detect the iBeacon tags within the necessary range for our purposes.

One issue I encountered with the USB Bluetooth adapter is that the onboard Bluetooth controller is actually disabled if the OS detects a separate USB adapter. Despite various attempts at changing this behavior, including modifying configuration files and disabling certain services, I was unable to stop the built-in adapter from disabling itself. As a result, we have decided not to use the built-in adapter to determine tag distance. Instead, we are opting to use a total of 4 external USB Bluetooth adapters space apart in the backpack to determine the tag location. Having 4 RSSI readings will help improve the accuracy of the distance pruning algorithm, and make it less likely that an item outside of the backpack will be detected as being inside.

For next week I plan on finalizing the RSSI calibration values for the new USB Bluetooth adapter, as the previous values I had for the built-in adapter no longer apply to our system. I also plan on adding time-out functionality so that if a tag is not detected for long enough it is removed from the item list, even if its distance is unknown.

Posted on

Janet’s Status Report for 4/3

This week, I completed the scheduling feature for our web application. Events can now be manually created via a Django Form, stored as an Event model, and displayed in a calendar view. Events can also be edited retrospectively. Additionally, the home page contains a view of upcoming events from these models. Much guidance was received from this blog post. A short demo of the scheduling feature on our app can be viewed here (video is too long to be directly included in post). Additionally, the login and registration functionality is complete (barring the integration with our item recognition module).

Additionally, I began development on the onboarding feature of the web app (i.e. when a new user first registers, they must tag all their items and register these tags). However, since this step cannot be completed until Joon completes the item recognition module, dummy items and information are currently being used. I also began development on the integration of the RPi Zero with the web app using the Web Bluetooth API.

Progress is currently exactly on schedule, as written in our Gantt Chart.

In the next week, per our Gantt Chart, deliverables I hope to complete the final integration between the RPi Zero and our web app as well as the integration between the item recognition and the onboarding on our web app. Additionally, we will all be preparing for the interim demo on the week of 4/11.