Alex Nguyen’s Status Report for 10/26/24

Personal Accomplishments
  1. Mobile App Development (7h): Worked on further developing the skeleton of the settings and statistics pages. Testing for dummy data for AnyChart has not begun yet, but will likely begin by the end of this week at the latest.
  2. Mandatory Lab Meetings (4h): received valuable feedback from TA and Professor Bain regarding our design report.
  3. Ethics Assignment (5h):  read important articles on engineering design ethics and wrote about several ethical considerations regarding our own project using this newfound knowledge.
Progress
  1. Progress is on schedule. This weeks tasks will be done more in conjunction with Jubi so that we can begin integrating the database into the app to begin testing.
Next Week Tasks & Goals
  1. Mobile App Development: Integrate session history page with Jubi’s database system, and begin testing of AnyChart API calls from dummy session data.

Team Update for 10/26/2024

General Update

This week Josh spent time programming the esp to interface with the haptic motors and tuning motor placement on the hand. He also worked processing readings from multiple sensors at once and comparing them to a threshold value via ADC. Alex and Jubahed primarily worked on developing the android app in Android Studio, specifically on the overall architecture of the app and interactivity within the app (no connectivity to the wearable device yet). Also got version control working properly.

Risks and risk mitigation

A risk our project faces is reliability of Bluetooth over the two components of our project. Since we have yet to implement connectivity between the two components, we plan to mitigate this risk by

  1. Starting Simple: Once the app is more fleshed out, we will test basic connectivity this week before adding more complex interactions. We will begin by ensuring that the ESP32 and the Android app can connect and exchange basic messages (like status messages or simple text).
  2. Using Established Libraries: We won’t venture out to obscure Bluetooth connectivity methods, we will try to stick with ESP32’s BluetoothSerial library and Android Studio’s builtin Bluetooth API to prevent any low-level issues and hopefully ensure that any bugs we may have are purely high level (easier to fix).

 

overall design changes

Most design changes were finalized last week while writing the design report, this week we have been following the design set forth and have not found the need to make any major changes.

schedule

The schedule remains the same as we are on track.

GANTT Chart

Joshua Ramos’ Status Report for 10/26/24

Personal Accomplishments
  1. Mandatory Lab Meetings (4h): During our lab meetings, we received and provided great feedback from our advisor and TA, allowing us to identify vague aspects of our project design and clarify/finalize them.
  2. Programming ESP32 (4hr): This week I spent time installing the esp toolchain and getting several example files running to verify functionality. I also setup ADC reading and force threshold identification for multiple sensors on the esp.
  3. Testing Haptic Motors (4hr): This week I spent time testing the placement and generated vibration of the haptic motors. I found that placing the motors behind the base of the finger and each at a constant current whenever that finger encroaches the threshold works very well since it is very noticable to the climber.
Progress
  1. Progress is a little behind since our sensors came in this week. So the prototype is still in development since we need to sow the sensors into the glove and maneuver the wiring. However we are on track to begin qualitative tests next week.
Next Week tasks & goals
  1. To perform qualitative tests of a design prototype.

Jubahed’s Status Report: 10/26/2024

PERSONAL ACCOMPLISHMENTS
  1. Mobile App Development (5h): Tested and verified that the database can only store data that we need, that it can store data at a fast rate (almost instantly the minute it is received), and that it is fault tolerant. Chatted with Alex about Android Studio page layout and navigating the IDE / how to design pages.
  2. Mandatory Lab Meetings (2h): I actually missed Tuesday’s lab meeting due to a medical issue I was facing where I had to go to my doctor for treatment. I reached out to staff accordingly. I attended Thursday’s session where Josh and Alex caught me up with updates from the course staff.
  3. Ethics Assignment (7h):  Read the two articles, watched the video, and wrote my report for the ethics assignment this week. I really liked the Winner reading and I thought it was an important read!
PROGRESS
  1. Progress is on schedule. Alex and I have been connecting frequently this week to get the app in shape. Backend is set up and over the next two weeks, we will create pages to interface with it.
NEXT WEEK TASKS & GOALS
  1. Mobile App Development: Work with Alex to integrate app backend into frontend elements like the chart displaying APIs. This can include creating some dummy data, debugging the database if any problems arise, etc.

Jubahed Qayum’s Status Report for 10/20/24

PERSONAL ACCOMPLISHMENTS
  1. Mandatory Lab Meetings (4h): My team and I got insightful feedback from our lab meetings (e.g. tuning our circuit to adjust for a voltage offset for finer granularity on sensor resolution).
  2. Design Report (16hr): I spent the bulk of my time last week compiling together the design report. Most of my contributions went to the use-case requirements, design requirements, and how they intertwine with each other (defining how the concrete aspects of our design hit our target ergonomics, durability, and safety metrics). I also spent a lot of time on the design trade analysis (breakdown between the different MCU platforms),  app implementation section, and compiling references.
  3. App backend / data querying (5hr): I came up with a first draft of SQL queries to create the initial tables defined in the design report, to insert into each relevant table when prompted, and to filter / retrieve individual data based on relevant workout.
PROGRESS
  1. The process of working on the design report significantly narrowed down misconceptions I and my team members had around certain components in our system, and I feel like it was a great way to get everyone on the same page of what we were each individually working on. After this, I’m on track to integrate my database queries into Alex’s initial framework this + next week.
NEXT WEEK TASKS & GOALS
  1. Integrate data query systems into app framework
  2. Start looking deeper into communication between the two components: how to sync Bluetooth transceiver on ESP32 to mobile device, how to open a communication medium / establish a TTY between the ends through the app

Alex Nguyen’s Status Report for 10/19/24

Personal Accomplishments
  1. Design Report (16h):  A large portion of my time was spent working with my team on the design review report. Specifically, I wrote the Android Application Implementation, Sensor Calibration Implementation, Data Visualization & Analysis, and Wearable Fabrication sections. I also contributed to the Design Trade Studies section and wrote about our decision to develop our mobile app in Android Studio using Kotlin. I also wrote the Introduction, Bill of Materials/Budget, Schedule, and Summary sections. I also spent some time updating the original mockup documents to reflect design changes we made between our proposal and design review, specifically the addition of haptic motors to the wearable device and the replacement of login functionality on the mobile app with a User Settings/Threshold Update page.
  2. Mobile App Development (8h): We decided to continue development with Katlin, not Flutter. While we were writing the design report, we had an important discussion where we were able to establish the intended interactions between our mobile app and wearable device. I was able to setup a homepage for our mobile app and am working on testing for data visualization using AnyChart API. Since we are not integrating with the wearable device yet, the next feature I would like to setup is the questionnaire and settings page (currently without the ability to communicate with the  wearable device.
  3. Mandatory Lab Meetings (4h): received valuable feedback from TA and Professor, especially regarding our testing strategy.
Progress
  1. Progress is mostly on schedule, though I would like to have the mobile app more fleshed out. The front end is currently very bare bones with not much time spent on making it look nice. I will likely work on improving the front end when the base functionalities are established and working.
Next Week Tasks & Goals
  1. Mobile App Development: Create a settings/threshold update page that works independent of the required connection to the wearable device. Additionally, finish testing of data visualization on the home page using dummy data.

Joshua Ramos’ Status Report for 10/20/24

Personal Accomplishments
  1. 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.
  2. Design Report (20hr): Spent time finalizing our design and writing the report. I worked on the abstract, use-case requirements, hardware architecture, design requirements, hardware design trade study, system hardware implementation, system verification and validation, risk mitigation plan, and related works sections.
Progress
  1. According to the schedule, I am working on testing the haptic drivers, however, our order just came in this weekend over the fall break, so I will be picking them up first thing Monday morning to get on top of it! Besides that, everything is on track!
Next Week tasks & goals
  1. To test the haptic drivers using a pre-set threshhold value to determine the strength of the vibration.

Team Update for 10/20/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.

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

Guidance Questions
Part A. Global FactoRS written by Alexander

Our product aims to be used by climbers of all skill levels, regardless of prior experience. As an injury prevention device, our device should be accessible to all users, otherwise it would not achieve our goal of protecting the health of all climbers. As a result, we want our system (consisting of both the wearable device and android app) to be as straightforward to use as possible, with little room for confusion on the part of the user. We achieve this by ensuring that the wearable device is sturdy and has clearly marked labels to indicate how it should be worn to best prevent pulley injuries. Additionally, the app is designed to show the climber the most important information first, while providing an experience that is easy to navigate and adjust to the user’s preferences. Additionally, a lack of biomechanical knowledge should not inhibit the user’s ability to correctly adjust their own alarm thresholds, so we have included a questionnaire which will assist the user by suggesting alarm thresholds based on their responses to carefully selected questions. 

Climbing is a sport which can take place both indoors and outdoors. As a result, the environment in which our device is used must be considered and accounted for in our design. It is important to note that climbing is inherently rigorous, especially on the fingers, so our device will need to be able to withstand physical wear and tear exerted by the climbing wall. Our initial goal is for this device to be used in indoor climbing, where there are less outside factors that could impact the device’s effectiveness (dirt, wind, temperature, sand, water). Ideally, our product is meant to provide protection for climbers both indoors and outdoors, and as a result, geographic location of the climber could impact the durability and effectiveness of the device. We will consider the extremes of these factors during testing. One more thing to note is that outdoor climbers are often in locations where there is little to no internet connection. We solve this problem by sending data from the wearable device to the mobile app (and vice-versa) via Bluetooth, which can be used at any geographic location regardless of internet strength.

Part B. Cultural FactoRS written by joshua

One aspect of climbing culture that our product solution slightly pushes the boundary of acceptable on is the notion that the hands must be bare while climbing. Most climbers would agree with the idea that “a glove could never be as good as a really exceptional climber’s hands are” or “strengthening your hands is what climbing is all about”. This is a mindset common in rock climbers. Unfortunately, our product does cover a small portion of the hand, in particular the area under the finger joints. As a result, climbers at first may be hesitant to utilize our product, however, one of our product’s goals is to emphasize the utility of relatively unobtrusive on-hand climbing gear.

Our product aims to broaden the horizons of climbers with their regard to on-hand climbing gear by demonstrating its benefits (safety, healthcare costs) and minimized drawbacks (obtrusiveness, taking away the ‘rawness’ of climbing). In all, our product aims to eliminate the cultural mindset of “not going bare-handed is bad/weird”, by demonstrating that it is actually very beneficial and not too different!

part C. Environmental FactoRS Written by jubahed

Our product’s main consideration of environmental factors is that it is ineffective towards the environment. Most climbing gear, depending on how it is used, can have adverse effects on the environment. Some examples are improper disposal of gear material like nylon and aluminum mid-climb, climbing chalk altering the pH of rocks and harming organisms, and the production of rock-climbing shoes emitting more carbon dioxide than the rest of the gear. In contrast, our product aims to have zero effect on the surrounding environment by using eco-friendly fabric, being securely strapped to the individual to avoid accidental disposals, and using zero chemicals to avoid potential harm to surrounding organisms. The need our product solution fills is the lack of eco-friendly gear in the field. By introducing gear like our product, we can emphasize this alternative of eco-friendly climbing products and move the field towards a more eco-friendly rock-climbing experience.

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

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.