Team Weekly Update | 3/8

---

Accomplishments

The past two weeks were focused on finishing up the design report and design review presentation. We spent a lot of time making sure everything was clear, well-organized, and covered all the technical details. We also did some force sensor testing to check accuracy and response.

On the admin side, we wrapped up some last-minute product purchases and cleaned up the website to keep things organized before the break.

Progress Status

We’re on track. The design report and presentation are done, and we’ve started testing key hardware components. The weeks following break will be focused on creating a more cohesive system and testing.

On the mobile app development side, research on Swift was prioritized prior to break. Following the break, the mobile app will see lots of progress now that we have a greater understanding of Swift development as a whole.

Next Steps

Next week, we’ll work on integrating the camera and force sensors together, along with getting data to communicate with the app. We want to finish unit testing before we fully integrate, but can start thinking about printing bike attachments.

Risks and Mitigation

One of the biggest risks for the project is hardware integration issues, especially making sure all components communicate properly. The force sensors and camera need to work reliably with the Raspberry Pi, and if there are issues with data transmission or accuracy, it could slow us down. To manage this, we are testing each component individually before full integration and keeping backup sensors in case of failures.

Another risk is time constraints, debugging could take longer than expected. To stay on track, we’re prioritizing critical tasks first and breaking up testing into smaller steps to catch issues early.

Design Changes

There haven’t been major changes to the system design, but some small adjustments have been made. One change was refining the data processing pipeline for the force sensors to improve accuracy. This adjustment meant spending more time on software calibration, but it should help reduce errors in the long run.

Additionally, we had to make last-minute component purchases to ensure we had everything needed for testing. While this added some cost, we’re managing it by only ordering essential parts and reusing materials where possible.

Additional Considerations

Part A: Global Factors

Written by Zoe
Our product is designed to address a need that extends beyond just our immediate environment. By focusing on accessibility and ease of use, we aim to make the system functional for a wide range of users, including those who may not have advanced technical knowledge. The design also takes into account supply chain considerations, ensuring that the components we use are widely available and not dependent on a single region. This improves scalability and adaptability in different global markets.

Part B: Cultural Factors

Written by Carolyn

Our product can be designed to consider integration among different regions, ensuring it can appeal to a broad range of users. For example, cycling culture varies from country to country. In some regions, cycling is a primary mode of transport while in others, it is more of a recreational activity or sport. In this case, Cyclify could be made to serve two different purposes – as a performance enhancer or a way to improve comfort during transportation rides. In addition, we recognize that is some cultures, group cycling activities are popular, while in others, individual cycling may be more common. Peer influence can play a big role in how people approach cycling thus Cyclify could also seek to incorporate features that encourage social interaction in the future to motivate users with a supportive social context.