Posted on

Team Update for 10/19/2024

General Update

This week, Josh, Alex, and Jubi produced a design report detailing the use-cases, requirements, trade-off-analyses,  implementation details and more.

…More details TBD by 10/19

Design Report

Risks and risk mitigation

One potential risk is identified in the sensor amplifier circuit. Our goal is to amplify the sensor output to enhance our systems force-reading precision by providing a larger voltage range for the sensor output. Failure to obtain fine-grain readings may result in innacurate readings, which may fire alarms unecessarily or fail to fire alarms upon force-threshold excession. To mitigate this, we are working to determine the best amplifier circuit model (gain, phase, etc.) to obtain sufficient sensor output ranges with respect to our power constraints.

overall design changes

Instead of the STM32F4E Nucleo Board, we will be utilizing the ESP-WROOM-32 board as our controller because of its size advantages, built-in peripherals (more ADCs, Bluetooth), and ease-of-use via Arduino ESP32 libraries, as compared to bare-metal development on the STM.

schedule

The schedule remains the same as we are on track.

GANTT Chart

Posted on

Team Update for 10/5/2024

General Update

This week, we each worked more individually on our assigned parts of the project. Josh and Alex met with team StrideSense to discuss several common hardware challenges that we are facing with our projects since we both intend to use sensors and analyze data collected from these sensors. Alex worked mostly on the mobile app in Android Studio, and completed an implementation of the initial startup sequence for the app. Jubahed worked on implementing the SqLite-based database that backs our mobile application. Josh worked on testing the sensors with precise weight measurements, as to validate its functionality for our project. Next steps are to test multiple sensors on a hand. 

Risks and risk mitigation

One potential risk is sensor failure. If the sensors are damaged and lose sensitivity during use, we plan to cross-reference other surrounding sensors to validate sensor readings. We plan to look into other sensors that can be used in this cross-referencing, we are considering temperature sensors, shear-force sensors, pressure sensors, IMU, etc.

overall design changes

We are considering using Dart and Flutter for development of our mobile app over Kotlin and AS. However, if we do not find it significantly easier to develop in Dart/Flutter we intend to stick with AS. Additionally we have made the decision to remove Google OAuth sign in as a feature of our app because it does not fit our intended use case.

schedule

The only changes that have been made to the schedule is added time for mobile app frontend/backend integration. Otherwise the schedule remains the same.
GANTT Chart

Posted on

Joshua Ramos’ Status Report for 10/5/24

Personal Accomplishments
  1. Design Review Presentation (5hr): Spent time creating the use-case, technical requirements, system specification (HW), and unit testing slides.
  2. Mandatory Lab Meetings (4h): During our lab meetings, we received and provided great feedback from our peers, allowing us to identify questionable aspects of our project and see the kinds of methods and technologies other groups are using.
  3. Cross-team meetings (0.5hr): Me and Alex met with Vansh from team A3 to discuss our product design apporach in regard to which technologies we’re using  since our products are very similar. During our meetings, we discussed which controllers we’re using, sensors, communicatons protocols, and web development environments and tools. The exchange was very fruitful, and provided both teams with valuable exposure to technologies they hadn’t considered prior to this interaction.
  4. Further sensor testing (4hr): Spent time testing the sensors using precise weight measurements using a gram-scale. Through this I was able to determine the precision and sensitivity of the sensor, and can conclude its viability for the project. I will use the recorder value to set thresholds on the device such that an alarm can be fired when the threshold is broken.
Progress
  1. My progress is on schedule,  my next step is to callibrate the other incoming sensors and test multiple sensors on a hand at once.
Next Week tasks & goals
  1. Test multiple A301-100 sensors on a hand and measure via ADC.
  2. Look into other options for the controller board we are using. Looking for something more simple to use.
Posted on

Jubahed Qayum’s Status Report: 10/05/2024

PERSONAL ACCOMPLISHMENTS
  1. Backend database setup (6h): I spent most of the week learning how to use SQL more robustly (this is the querying language for SQLite). I think I’ve gotten pretty good with it! SQLite comes pre-installed on macOS so I messed around with creating tables, storing data, querying data, and general analytics (like aggregation, JOIN / WHERE / HAVING clauses), as well as style guidelines. This allowed me to solidify the app database backend on Android Studio and input those queries into it. I did run into a challenge with Alex of potentially migrating to a different framework outside of native Android Studio, but I’ll build on this more later.
  2. Design Review Slides / Presentation (5h): I worked as part of the team to build finishing touches on the design review slides, as well as rehearsing for a few hours and improvising changes along the way to make sure my presentation went as smoothly as possible!
  3. Mandatory Design Review Feedback Meeting (2h): I went on Monday to the Design Review meeting and presented + gave feedback to other groups that presented. I found it very valuable that the audience seemed to agree that the use of bluetooth / solely-Android reliant database+compute without cloud services was a good idea in this project! It really affirmed the research I did last week. I missed the Wednesday meeting and didn’t do much work on Thursday sadly, but I was feeling ill, and I contacted the course staff about this.
Progress
  1. Alex and I discussed the potential of migrating our app framework to Flutter, rather than purely Android Studio, because of its more cross-platform agnostic features. However, for the purpose of backend, it doesn’t put me too behind, as the concern for me is less about writing code and more about the general data storage and retrieval ideas (which I have solid). I would have to take some time aside to learn Dart, however, if we do this change, but this should not take me long. I still feel like we’re in a good place here.
Next week task & goals
  1. Alex and I will be touching base frequently throughout next week to finalize the framework we will choose for the frontend and backend components, as well as how they will integrate together. I want to start unit testing the HC-05 bluetooth module, but this will require it to be delivered first. This will allow me to see what it’s like receiving real-time data (even if it is junk for now) so Alex can start testing the AnyChartAPI. We have a lot to do this week!
Posted on

Alex Nguyen’s Status Report for 10/5/2024

Personal accomplishments
  1. Mobile App Development (7h): Several changes were made to our initial plans regarding the mobile app. We have decided not to include google OAuth sign in because session data will be stored locally on the device and thus there is likely no need for multiple users to be using the same mobile phone. After watching other team’s presentations during the design review, I found that Flutter SDK may also be a viable option for creating a cross-platform version of the mobile app. I am currently experimenting with using the Flutter plugin in addition to Android Studio IDE to create the frontend of the app. This decision may still change since Flutter is written in Dart as opposed to Kotlin. My main accomplishments regarding the mobile app this week was creating the initial landing page of the app which takes you to the first-time startup questionnaire in Android Studio (which may need to be modified when introducing the Flutter plugin).
  2. Meeting with Vansh (0.5h): Met with another capstone team whose projects had some similar challenges and use cases as our project, and discussed how we were dealing with some of these issues. Also learned about Flutter as a possible solution for our mobile app development, and will give it a try before fully committing to Android Studio.
  3. Design Review Slides (2h): Helped the team work on the block diagrams and design review slides for this week’s design presentation.
  4. Mandatory Lab Meetings (4h): Watched design review presentations from other teams and received important feedback on our own project. One question that was raised during our presentation was regarding the usage of our device during dynamic (dyno) moves in climbing (which typically is defined by moves which require a jump off the wall where you lose all points of contact during the move). I did some research and found that dyno moves can typically double the force of the same climber on a similar static move, so that will have to be taken into consideration during our stretch goals. Our current MVP is for the device to take accurate readings during static moves (or hang boarding sessions), since this well have a less likely chance of breaking sensors and also because most climbs consist of mainly static moves rather than dynamic moves.
Progress
  1. Depending on what decision we make regarding Flutter/AS, I will be a little behind on mobile app development if we decide to switch to Flutter. However if we stick with AS, I am on schedule for mobile app development. Me and Judi will make that decision soon so we can move on to integrating the frontend and backend of the app. We are meeting on Sunday to make this decision, so by the end of the week we will be back on track as far as the mobile app goes.
Next week task & goals
  1. Mobile App Development: I plan on meeting several times with Jubi over the next week to begin planning integration of the frontend and SQLite database. We may also start looking at how to integrate bluetooth pairing and communication into the mobile app. I plan on finishing the home page such that I can integrate AnyChart API calls to begin testing of dummy data on the data visualization side of the app.