Alex Nguyen’s Status Report for 11/30/24

Personal Accomplishments
  1. Programming ESP32 (5h) – I programmed the calibration routine for the ESP32, such that upon session startup (and immediately following a confirmed bluetooth connection) the calibration routine will launch and take the average of the next 10 seconds of force readings for each sensor, storing that value as the normalization value for the rest of the readings taken during the session. This can be seen below, as the normalization values for each sensor are displayed upon completion of the CR at 10 seconds, and then the device proceeds to take readings for normal data collection. 
  2. App & Bluetooth Integration (12h) – I worked with Jubi to integrate the front end with bluetooth and database. Once Jubi established a working bluetooth connection between the device and the app, I realized that our current code was overly reliant on disconnected Kotlin coroutines, and was able to simplify them into two larger Kotlin coroutines and suspending sequential coroutines until prior ones had finished which prevented many of the bugs that were occurring when two coroutines overlapped or attempted to access data at incorrect timings.  When I completed the calibration routine on the ESP32, I synchronized the bluetooth connecting screen and calibration timer screen to match the events occurring on the ESP32 (with the bluetooth connecting screen staying until either it was connected or timed out and the calibration timer matching the timer of the ESP32).  This can be seen below where the light to indicate bluetooth connection is blinking before the session starts, then turns solid when a connection is established (matching the changing of screens in the app). 
  3. Android App Development (frontend) (10h) –  Since the last update, I implemented the rest of the frontend that was remaining. This included the threshold settings page, questionnaire, and session history selection page. I also attempted to query Jubi’s database for the max sensor reading values recorded for each pulley during a session, however it is currently inconsistent and returns either the same values or random values, which is something I will work on further. Assuming this is not an issue with the database, I believe this is most likely an issue with data sharing between the MainActivity and the HomePage, potentially caused by uninitialized key-value pairs in sharedPrefs.
  4. Integration Testing (5h) – Went to the climbing gym with Josh and conducted a series of tests on different climbing apparatuses (hangboard, pullup bar, campus wall, bouldering wall). We were able to verify several key factors, including bluetooth connection between the app and device, as well as test the reliability and consistency of the sensor when doing various climbing movements. Additionally we were able to test the usability of the device, both by climbing on routes with the glove on as well as surveying several climbers who were also at the gym.
  5. Final Presentation (8h) – I am presenting this week, so I worked on the presentation slides and prepared to present during this week’s lab meetings.
  6. Mandatory Lab Meetings (6h) – Presented intermediate demos to professors and TAs and received valuable feedback, especially regarding the data visualization and analytics components to our mobile app.

As you’ve designed, implemented and debugged your project, what new tools or new knowledge did you find it necessary to learn to be able to accomplish these tasks? What learning strategies did you use to acquire this new knowledge?

Before this project, I had never used Android Studio or Kotlin before, and I was pretty unfamiliar with app development model. As a result, I had to spend a lot of time at the beginning of the semester experimenting while building the app, even before our team had a concrete plan as to what features we wanted to have as part of the mobile app. I found tutorials online very helpful for learning the building blocks of app development, and learned a lot through tinkering with different interactions between frontend and backend elements in dummy applications that I created just for the purpose of testing out potential interactions I could want in the final app.  This learning process was a lot of trial and error, so git version control was incredibly important as there were several instances where I had to rebase after creating an error whose origin I was unable to identify.

Additionally, I learned a lot about the design process for an embedded system mobile app. Prior to this project I had never had to consider both factors when designing a product, so there were many new challenges that I had to consider (along with my teammates). While we were writing our design report, we realized how much of our design we had not considered regarding the interactions between each of our individual parts. Sitting down and talking through the overall interactions between the hardware, frontend software, and backend software, was immensely helpful, and while it took a long time, it proved to be invaluable to the success of our process later on when we began integrating. This skill was developed further throughout the semester, as we made sure to revisit (and modify if necessary) our overall integration design plans each time we made major changes to any one individual part.

Finally, designing thorough unit and especially integration testing was a skill that I found very important to learn throughout the project. While I have conducted unit testing for software projects before, the addition of a connected embedded system communicating via Bluetooth added an extra dimension of testing needed between all three systems (embedded device, BT communication, backend database, frontend UI/UX). This skill was learned on the go, as we each performed our own tests on our individual parts but had to figure out how and what to test during integration. Figuring out the many aspects that needed to be verified and validated was a process that often happened accidentally, as one of us discovered a factor that had not yet been considered (things like finger placement affecting sensor readings, BT connection failure during a preset sequence, race conditions occurring when a coroutine terminated early). Finding new factors that could adversely affect the optimal performance of our product taught me both how important it was to design tests for as many of these potential issues as possible as well as how to design appropriate tests to ensure our goals were met.

Progress
  1. Progress is on schedule.
Next Week Tasks & Goals
  1. Data Visualization and Analysis: Work with Jubi to retrieve data from database and display based on session number.
  2. Dual Glove Additions: Make any additions necessary for Bluetooth and Mobile app with the introduction of a second glove (likely frontend additions, some communication changes)
  3. Final Report: work on final report with teammates.
  4. Testing: continue testing as the final product comes closer to completion, especially with regards to new additions or aspects that were modified. Additional reliability tests and real-world application tests (in climbing gym).

Leave a Reply

Your email address will not be published. Required fields are marked *