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

Posted on

Joshua Ramos’ Status Report for 9/21/24

Personal Accomplishments
  1. Sensor research and ordering (5hr): I looked into viable solutions to our sensors problem: how can we efficiently and effectively measure force being exerted at multiple pulley joints on a finger? I found the FlexiForce A301-100 Sensor that can measure up to 100 lbs of force. I researched videos to identify if this sensor would be sustainable for our use-case, since it will be bent in many different angles. I also called the FlexiForce help-line to speak with a representative, for which I asked if the sensors would be a reliable solution for our product. I also scoured the campus ECE labs for operational amplifiers and other electrical components that we will need for our system. Lastly, I ordered the sensor and the recommended electrical components necessary to test and calibrate it.
  2. Proposal Presentation (4hr): I spent time researching existing solutions to our problem, modelling the requirements, formulating the challenges, and diagraming the implementation/testing plans. I also spent time practicing the presentation to prepare for delivering it this past Monday.
  3. Mandatory Lab Meetings (4h): During our lab meetings, we recieved great feedback. We were able to discuss our product’s intended purpose, describe its functionality and mechanics, and review our implementation approach. It was very rewarding.
Progress
  1. My progress is on schedule, except for initial testings which is a little behind due to ordering delays.
Next Week tasks & goals
  1. Build testing environment (stm32 + breadboard) for the A301-100 sensor, and verify its reliability and functionality for our product.
Posted on

Jubahed Qayum’s Status Report for 9/21/24

Personal Accomplishments:
  • MCU Platform Research (3h): I spent around 3 hours researching for potential platforms regarding the micocontroller the team should use for data collection and sensor readings. I came to the conclusion that we should use 1 of 3 platforms for data:
    • Arduino: This is likely what would be best for our device prototype, as it is the easiest to set up, gather readings, and basic compute.
    • Raspberry Pi: This is a very strong option and allows for significantly more compute. It may make it easier to communicate wirelessly, should we focus on that later beyond MVP.
    • ESP32: Probably the best option of the three, due to reduced power and better IoT capabilities than the Arduino. However, this is more complex to setup.
    • Based on these, I narrowed down to starting with the Arduino. It seems totally enough to run the tasks we are asking of the controller (send data to mobile device every few ms or so, and alert for over-exertion)

This video demonstrates that Arduino can actually reliably communicate over bluetooth . This makes me feel like it should be OK for us to stay on that platform for the foreseeable future of the project.

  • Mandatory Lab Meetings (4h): Listening to other groups helped me narrow down ideas regarding future planning and potential improvement plans (I didn’t think about the ESP32 until another group mentioned it). It was also valuable receiving feedback from other students.
  • Proposal presentation (5h): I spent a lot of time with Alex breaking our project future down. This went into making the GANTT chart (including making it as functional as possible, modifying it over time to make it more precise) and integrating it into the slides. I intend this to be a living chart and change with agility throughout the project as its needs evolve.
Progess:
  • I’m on schedule. This week, beyond the team tasks we wanted to work on, I did what I wanted to do. This should keep me ready to start integrating data collection into the prototype, with the ability to read and display sensor readings, within the next 2 weeks.
Next Week Tasks and Goals:
  • I’ll have to continue MCU research into the next week. This is because of the fact that for our MVP / initial prototype, communication is less of a factor. Therefore, as we start to build the device together and potentially go beyond MVP, we may have to worry more about compute capabilities on the controller.
  • I also want to try to start the assembly of first demo with actual sensor readings. Josh has been researching the sensor, and Alex has a good mock-up of the physical design. All that is left is integration via the MCU.
Posted on

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

Personal Accomplishments
  1. Device Design and Mobile App UI Mockups (5h): I drew design mockups (shown below) for each component of our project, the wearable device itself and the mobile app that will receive and analyze force readings from the wearable. I designed each mockup based on conversations that me and my team held regarding our vision for the features and use cases of the device.
  2. Wearable Device Prototype (5h): I created a prototype (shown below) for the wearable device part of CLIMB based on the wearable device mockup created earlier in the week. This prototype is constructed of cardstock and masking tape, and should be durable enough to conduct basic testing with A301 sensors and our microcontroller before creating the final product. The prototype can also help our team make the necessary revisions to ensure that the final wearable design accomplishes our goals regarding comfort and usability of the user. 
  3. Mandatory Lab Meetings (4h): We received valuable feedback from TAs and professors regarding our project ideas, and afterward I further researched several interesting points brought forth during the meetings (e.g. potential for IMU integration). During last week’s lab meetings, I listened to other group’s proposal presentations and provided feedback.
  4. Proposal Presentation (3h): Worked with Jubahed to break down our project into task groups and subtasks and create a Gantt chart to both plan and track our progress over the course of the semester.
Progress
  1. My progress is currently on schedule. I added biomechanics research to the schedule/Gantt chart for my personal tasks so that I can finalize the sensor placements in our design.
Next Week tasks & goals
  1. Mobile App Frontend: I intend to begin programming the page architecture/model of our web app based on the intended features and UI mockup (no functionality yet).
  2. Qualitative Testing of Wearable: I will be conducting some ease-of-use testing of the wearable device prototype with climbers and collecting feedback on any improvements that can be made for the next revision.
  3. Biomechanics Research: I also intend to finish researching the ideal placement of sensors for pulley ligament injury detection and finalize our sensor placement in our design.