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.

 

Posted on

Jubahed Qayum’s Status Report: 9/28/2024

Personal Accomplishments
  1. MCU Refinement (2h): While in last week’s update I mentioned using Arduino for the controller, after discussing with my team members and learning more about the STM32 ecosystem (more specifically about its compatibility with Arduino modules / bluetooth), we decided to pivot that MCU. It’s nice because these are a lot more powerful than Arduino’s, but still relatively simple to write code for and deploy to.
  2. Design documentation, slides (8h): I spent the bulk of my week working on the design presentation slides, as well as relevant diagrams that went into that slideshow. This involved a variety of subtasks, namely:
    1. Backend app information: I did some research into various database management systems that would be relevant for our application. Originally, I wanted to check out DBMS’ like PostgreSQL, as it is very popular in the open-source community, and I think it would be a good learning experience to dive deeper into it. However, after filtering our device and app use cases down further, I realized that we would want to avoid an internet-connection required system. All computation should only happen on the STM32 ARM core (mostly for motor vibration controls), or the app (data store and analytics). With this in mind, I shifted my focus toward looking into app-embedded DBMS’ that worked best with Android Studio, and SQLite seemed to be the best option. Plus, we don’t intend to do any crazy workloads beyond bulk data store and retrieval on a time-bound (for displaying on charts), so SQLite is more than enough.
    2. Block diagram slide
    3. General slide tidying, rehearsal, prep (I am the student presenting the design documentation this week)
  3. Mandatory lab meetings (4h): Meeting with Jim and Tjun Jet, discussing with Josh and Alex on future steps toward integration.
Progress
  1. I’m on track accordingly to my GANTT Chart. I didn’t add this task to the chart, but I did spend some time looking into Kotlin. This is because I didn’t realize initially that Android Studio used it. I haven’t worked with this language / framework before, so I have some more learning to do.
next week tasks & goals
  1. Work with Alex to build first run of Android app: more specifically, set up SQLite backend
  2. Look into Bluetooth modules for STM32 and how they connect with Android. This video seemed really useful and relevant for our project, so I will dive deeper into this. At the same time though, I will probably work with Josh to at least get data to send over a wire at the start. We will move to wireless over time, that is less important than data send / receive and data storage.
Posted on

Joshua Ramos’ Status Report for 9/28/24

Personal Accomplishments

1. Ordered and acquired components (1hr): I ordered an MCP6004-I/P op-amp to construct the recommended circuit as described in the FlexiForce A301-100 datasheet. I also scoured the ECE lab rooms to acquire other components (with TA permission of course) such as 100k potentiometers, resistors, wires, capacitors, oscilloscopes, digital multi-meters, and power supplies.2. Sensor setup & ADC setup & sensor calibration (further testing required) (7hr): After constructing the recomended circuit in the A301-100 datasheet, to obtain  -Vref and Vsupply,  where Vref == Vsupply, I used two power supplies, one supplying 0.5V and -0.5V. Then, I hooked on a multi-meter to the Vout of the op-amp and pressed on the sensor with varying force to observe the output change. I did observe a change, however, Vout reached 0.5V with insignificant force. Realizing that I needed to modify the circuit to allow for a larger voltage range and tune the gain accordingly, I requested Alex’s help, for which he computed and provided me with the proper component values necessary to achieve this. After testing, the sensor functioned as predicted, and we we’re able to obtain readings  ranging from 0 – 2V, where grams of force correlated with mV of change and extreme force encroached on 2V.

Then, I booted up an STM32 Nucleo board, configured its ADC to use a 12-bit resolution, and measured the Vout pin of the MCP6004 to verify the sensor reading using a multi-meter. Lastly, I performed bend tests on the sensor while reading, for which there were no obvious differences via inspection in measurement. Further testing is required where we will place the sensor on scale and measure weights on it to calibrate. We will perform the same test on a bent sensor to identify changes in sensitivity. Side-note: during this testing, I identified that we will require a Negative LDO (Negative Linear Regulator) to produce -Vref in our final design (as we won’t use power supplies). I will investigate eligible components.

3. Mandatory Lab Meetings (4h): During our lab meetings, we recieved great feedback. We were able to discuss design corners in our project and identify areas of ambiguity. One very useful point made by our advisor was the tuning of our gain for our sensor readings. We applied this feedback in our sensor testing this week, it was very helpful! We also had time to meet with our team to perform schedule reviews and work on the design presentation.

Progress
  1. My progress is on schedule,  my next step is to continue calibrating the sensor and testing it using a scale and weights, along with more bend testing.
Next Week tasks & goals
  1. Test the A301-100 sensor with weights and tune the ADC and/or voltage range/gain if necessary. Also test the haptic driver, which will be used to alarm users.
Posted on

Alex Nguyen’s Status Report for 9/28/24

Personal Accomplishments
  1. Piezoresistor Sensor Testing (4.5 hrs): Together with Josh, I helped test our current piezoresistor model (A301) to determine if it was viable for our project goals and use cases. While Josh built the circuit (and testing environment) and set up the STM32 ADC, I calculated the AC and DC gain of the amplifier to assist us in adjusting the values of the supply voltage (Vdd), reference voltage (Vref), and the feedback resistor (Rf) to attain an ideal range of outputs that we can use to accurately track force placed on the piezoresistor sensor.  Currently, we have found that the following values yield the following output range: Vdd = 2V, Vref = -2V,  Rf = 220 kOhm, C1 = 47 pF, Output Range = (approximately) 10mV – 2000mV. Further testing with standardized weights will be conducted to further determine accuracy and initial calibration of the sensor. We have placed an order for the remaining sensors following our test results.
  2. Android App Development (4h): I created a template for our CLIMB mobile app in Android Studio as well as the landing page, however I have not implemented the login page yet. I have not programmed in Kotlin before, so I have spent considerable time learning it over the past several weeks, but I have plenty of experience with similar programming languages and have no reason to believe it will cause any delay in the development of the rest of the app.
  3. Biomechanics Research (3h): I conducted biomechanics research on the physiological relationship between the A2 and A4 pulleys and the respective tendons that they are responsible for.  I determined that the initial placement of our sensors will likely suffice for prevention of pulley injuries. Additionally, I have found that typical A2 pulleys can generally hold up to 380N to 400N of force, so for safety and testing reasons we will likely use approximately 75% of that value (85.4 lbs to 90.0 lbs) as our alarm threshold for the A2 pulley sensor during integration testing. In our piezoresistor testing, we have found that bending of the sensor does not appear to affect the accuracy of the force readings, and as a result this should not impact our intended force sensor placement. Additionally, the A301 sensor data sheet states that the sensor can withstand forces up to 4400 N (1000 lb), so it should be more than able to handle the range of forces we intend to measure with our product. 
  4. Mandatory Lab Meetings (2.5h): Met with the professor and TA and received valuable feedback about our presentation and project implementation. One especially valuable piece of information that I received from the professor was to begin thinking about amplifier circuits as well as bridge circuits while tuning the output of our piezoresistor. After the meeting I researched the Wheatstone Bridge design of a piezoresistor which helped me gain an understanding of how it would fit into our circuit as well as how the piezoresistor worked internally.
Progress
  1. My progress is currently on schedule according to our Gantt chart. I believe learning Kotlin for app development will take some time and will allot additional time as needed for this task in next week’s schedule.
next week tasks & goals
  1. Android App Development: Create sign-in page for the app, ideally with OAuth google account sign-in. Additionally, some time will be spent learning Kotlin and additional features in Android Studio.
  2. Additional Piezoelectric Sensor Testing: Now that we have determined that we will be moving forward with the A301 sensor, we will test the sensor with standardized weights to begin calibration of the sensor and determine corresponding force readings with voltage outputs.
Posted on

Team Status Report for 9/28/24

General update
  1. This week we were able to test the A301-100 sensor and identify that it will be a viable component for our product, further testing is required.  We also have performed research into the biomechanics of our device in regards to sensor placement. We also performed a design review and worked on a presentation desribing our review.
POtential risks and risk management
  1. We plan to use the 316040001 vibration motor as the haptic for our system. In the case where this motor is too aggressive or too subtle, we may need to redesign the alarm of our system. In this case, we will utilize another method of alarm via noise, or search for more suitable motors. Other factors that will influence this potential redesign are motor current and supply voltage, as our system will limited on resources. We will perform a trade-off analysis of our options accordingly to determine the choice.
Overall design changes
  1. Based on the results of our sensor testing this week, no design changes will be necessary. Next week, the haptic sensors will come in and we will determine if they will be suitable for our device.
Initial Schedule

  1. No updates have been made to our schedule, we remain on schedule as of this status report.

CLIMB Gantt chart

Additional Week-specific Items

Part A (Alexander)

Our product is designed with one goal in mind: to ensure the personal safety of climbers. This applies to both the mental and physical well being of the user. Since our product aims to help climbers prevent and rehabilitate from pulley injuries, there are several clear health, safety and welfare considerations that we made. Pulley injuries can be (and often are) incredibly painful, especially when they are severe Grade III or Grade IV ruptures, which are injuries in which the pulley itself is fully disconnected from the tendon. Recovery from these injuries requires surgery and months of rehabilitation and is a significant detriment to the victim’s overall health and wellbeing. Since our product is an injury prevention device, it will be beneficial to the safety of climbers who use it. An additional use case for which it can be used is in the rehabilitation of climbers who have suffered a pulley injury. As they ease back into climbing with partial physical ability, our device aims to be able to set lower thresholds so that the climber can avoid reinjuring themselves, thus ensuring their physical safety and wellbeing as they recover. 

There are also several psychological considerations we made in the course of designing our product. By having a device which will alarm users when they are approaching dangerous force distributions on their fingers, users who are anxious about climbing can have assurance that they will be physically safe. This could be especially important to both new climbers who are anxious about the seemingly dangerous activity of bouldering as well as experienced climbers who have previously experienced pulley injuries and are thus aware and afraid of reinjury and the pain and rehabilitation that goes along with it. Finally, being scared or stressed on the wall can increase the danger associated with climbing, since smart decision making is key in this type of activity, so our device can help users be worried about one less thing while climbing and thus increase the psychological and physical safety of the climber. Overall, our product aims to keep users at peak physical and psychological condition and keep members of the climbing community healthy and safe.

Part B (Joshua)

During rehabilitation or injury-based-suspension, climbers rarely visit the climbing gym, nor do they go on outdoor climbing excursions as often. Unfortunately, this not only results in a pause of one’s favorite hobby and/or career (professional sport climbing ie. Olympic), it also steals away a social outlet. Typically, it is easier for one to meet others over shared interests, this is what makes a social outlet beneficial for making new connections. And when a climber loses this social outlet, they’re either forced to find another, or wait until they can use it again. CLIMB aims to mitigate this scenario. No climber should have to suspend themselves from the climbing gym or their outdoor excursions with friends. By preventing the most common injury in climbers (pulley injuries), our product aims to create a world where climbers don’t have to worry about an accident taking away their main social outlet.

Besides this scenario, our product does not have any other social influence. Our product’s main use-case is for pulley-injury prevention and rehabilitation in rock climbers. The only social implication of a pulley-injury is the indefinite suspension from a favored social outlet. This product does not meet the needs of other social factors because it specifically aims to improve an individual’s safety and welfare, regardless of social standing.

Part C (Jubahed)

There are many ways that this product can make economic impacts via its production, distribution and/or consumption. One main scenario that comes to mind is the financial incentives on the side of a fitness business, more specifically a gym that offers climbing services or a club/society for climbers. Through the widespread use of our product, these businesses can more easily attract new customers, as well as retain existing ones. Firstly, because our device is aimed toward injury mitigation, the potential fear of getting hurt through climbing will lessen, therefore making interested people more likely to make the jump toward purchasing a membership. Secondly, many climbers may consider quitting or significantly reducing their frequency to climb if injured. However, with increased ease of rehabilitation through our product, I can see this injury window being smaller, therefore encouraging climbers to retain their relevant memberships to these gyms.

Other economic benefits through our product are related to the broader society, outside of the fitness / personal wellness industry. Firstly, by simplifying and increasing access to reliable rehabilitation for injured individuals, we could potentially lessen the financial load with respect to healthcare services. So, an injured person can save money by needing less professional rehabilitation. Also, because this product could shorten the rehabilitation process, an injured individual could end up needing less time off from their day-to-day work, potentially increasing their economic productivity and prosperity.

Posted on

Team Status Report for 9/21/24

POtential risks and risk management

  1. A301 sensor failure / incompatibility: Due to our planned application of this sensor, it may be exposed to conditions too harsh, which may result in either partial or total failure. In this case, we will re-evaluate the positioning of the sensor to reduce the amount of sheer force applied to the sensor, mitigating potential damage. Our plan for verifying the sensor’s reliability is to measure readings in a controlled environment where it is applied to extreme physical scenarios.

    FLX-Datasheet-A301-RevI

  2. Op-amp incompatibility with sensor: We found several op amp models in ECE labs however their specifications were not exactly the same as those listed in the A301 documentation. To mitigate any adverse effects this could cause while testing the sensor, we have ordered the exact op amp model specified in the documentation to use in testing, and ideally in the final product if everything works as expected.

Overall design changes

  1. Since we are currently in the stage of testing each of our initial design choices, we will make design changes based on the results of our testing this week (no major changes have been made).

Initial Schedule

  1. We have created an initial schedule which breaks down all the tasks we intend to complete on our way to finishing our project. No updates have been made to our schedule, we remain on schedule as of this status report.

CLIMB Gantt chart – 4/21