Posted on

Team Status Report for 10/18

Overall Progress

  • Finished design report
  • Finalized implementation details for project
  • Ordered robot car kit

Risks & Management 

The design report took longer than expected, causing all of us to be behind in our work as we dedicated last week to the report. Therefore, we will have to make up for last week’s work this week. 

Due to a communication error, we realized that our robot car kit, Teensy 4.1 microcontroller, and H-Bridges were never ordered. We found this out on Wednesday and promptly ordered the parts the same day. Unfortunately, due to Fall Break, all group members were out of town when the parts arrived. Thus, we have been unable to make progress on the hardware aspect of this project. This communication mistake poses a significant risk to the overall Gantt Chart as it will delay the work by a whole week. However, we scheduled a slack week right before the interim demo, so as long as we continue to stick to our schedule, we should have a working prototype for the interim demo.

Design Changes & Justification

There were no changes on the hardware side, but on the software side, we decided to use a local database for product barcodes, names, and prices instead of an API. This change was necessary to improve the user experience and does not incur any additional costs.

Additionally, all hardware and software connection methods have been researched and are detailed in our design report. We have collaboratively created this block diagram:

Product Solution Meeting Needs

A was written by Rose, B was written by Audrey, and C was written by Elly.

Part A: Global Factors

Around the world, grocery shopping can be physically demanding and time-consuming, especially for people with limited mobility, older adults, or parents managing children while they shop. Basket Buddy addresses this by reducing the effort needed to push and steer a cart, making shopping more convenient and enjoyable for everyone.

In addition to making shopping more accessible, Basket Buddy also fits into the global trend of automation and smart retail technology. As more stores move toward self-checkout and contactless shopping, our project contributes to this shift by introducing a smart, user-friendly cart that improves both convenience and safety. With UWB and LiDAR-based navigation, it should have reliable performance in many types of indoor retail environments, making it adaptable to stores of different layouts and sizes around the world.

Part B: Cultural Factors

Basket Buddy showcases cultural values such as independence, community care, and accessibility. Many cultures view assisting others as a moral good; Basket Buddy supports this viewpoint through assisting people with their shopping. Basket Buddy also reflects cultural beliefs in equality and inclusion, allowing everyone to shop without stigma or dependence on others. Additionally, through the built-in safety measures, Basket Buddy respects both the moral and legal expectations of being safe in most communities.

Part C: Environmental Factors

The environmental impact of Basket Buddy is mainly in the manufacturing and energy consumption of the cart. Unlike a standard shopping cart, Basket Buddy requires additional electronics, sensors, motors, and batteries. The manufacturing process of these components is resource-intensive, and relies on the sourcing of more materials and an increased carbon footprint compared to a traditional cart. Furthermore, if a company wanted to incorporate Basket Buddy into its grocery stores by replacing traditional shopping carts, the company would need to use a lot of energy to maintain the carts. Basket Buddy would require constant charging, becoming a significant consumer of electricity, or new parts if electronic components break down, causing more waste to be produced. If Basket Buddy were to be adopted by stores, these stores would need a plan for charging and maintenance to prevent carts from producing excess waste.

However, Basket Buddy also provides the opportunity for people to be more environmentally conscious about their purchases. Being able to view your items in the mobile app can guide shoppers to make more sustainable choices, and a digital checkout process eliminates the need for paper receipts. More features can also be added to Basket Buddy such as expiration dates to prevent food waste or highlighting products with eco-friendly packaging or local sourcing.

Posted on

Rose’s Status Report for 10/18

This week, I primarily worked on finishing the design report with my teammates and finalizing several of the software-side design choices related to the UWB functionality. I decided that the best way to send information from the iPhone receiver to the Raspberry Pi would be through a local Wi-Fi HTTP bridge. In this setup, the Pi runs a lightweight HTTP server on the local network, and the mobile app on the receiver’s iPhone sends JSON packets containing UWB position data using HTTP requests.

I also conducted additional research into LiDAR drivers for the Raspberry Pi to understand better how sensor data will be processed in our system. Our RPLIDAR will connect to the Raspberry Pi via USB, and its driver allows the Pi to read and process distance and angle data from the sensor. This data is then converted into a 2D map showing nearby obstacles and open spaces. I explored various software options for running the RPLIDAR on the Raspberry Pi, including the official SDK, a lightweight Python library, and a ROS-compatible driver for real-time mapping. This research helped me better understand how the LiDAR subsystem will integrate with the rest of our navigation and obstacle-avoidance software.

According to our Gantt chart, my progress is behind schedule, as the goal for this stage was to finalize our mobile app and have the beginnings of shopper tracking over UWB. I was unable to dedicate as much time to these goals since we were working extensively on the design report. 

To get back on track, I plan to finalize the mobile app next week and ensure the UWB session is fully functional between two iPhones. I will also focus on establishing the connection between the receiver iPhone and the Raspberry Pi, which involves setting up the Wi-Fi HTTP server on the Pi and linking the iPhone to it. Once this is in place, we’ll have a clearer understanding of how the data transmission and processing will work within the overall system.

Posted on

Rose’s Status Report for 10/04

This week, I focused on integrating UWB technologies into our iOS app to enable shopper location tracking between devices. I set up the Nearby Interaction framework in Xcode, adding the required capabilities and permissions (Nearby Interaction, Local Network Usage). Then, I implemented code to initialize an NISession and use MultipeerConnectivity to exchange discovery tokens between iPhones. This allows two devices to establish a UWB session and start getting distance and direction information, acting as the foundation for the indoor location tracking we are aiming for.

I also built out the flow within the app so that tapping the “Connect” button on the Welcome screen initializes the UWB session. After this, I deployed the app onto two iPhones. The app now builds and runs on the two devices, simultaneously advertising and browsing for peers. Terminal and Xcode logs confirm that peer discovery and UWB session initialization attempts are working, meaning I’ve created that initial communication layer.

According to our Gantt chart, my progress is on schedule, as the goal for this stage was to establish a working UWB connection between two devices.

Next week, I plan to finalize the app and get the UWB session fully functional between two iPhones. My immediate goal is to have the devices successfully exchange discovery tokens and run a stable session, then output real-time distance and direction data so that we can use that data to start building code for the Raspberry Pi and the controls on Basket Buddy. Additionally, if I have additional time, I’ll look into how we can integrate LiDAR sensors into our system. 

Mobile App Local Network Connection on Two iPhones:

Posted on

Rose’s Status Report for 9/27

This week, I created the Figma mock-ups for the mobile app, expanding on the initial layout Elly developed last week, and used those designs as the basis for the app framework in Xcode. I now have the app running on my personal device in developer mode. For this, I learned the basics of SwiftUI, and I also explored how Apple’s Nearby Interaction framework can be integrated to support UWB-based tracking. I also began researching how to add a barcode-scanning feature, which will require using the phone’s camera and requesting the appropriate permissions.

My progress is on schedule and slightly ahead of plan. I have already started experimenting with the barcode-scanning functionality earlier than expected, having gotten camera permissions and am now preparing to find ways to have the app read barcodes.

By next week, we will be done with our design presentation and will have chosen all of our parts. I aim to have the barcode scanner working within the app and to complete a more detailed UI that incorporates all of the elements outlined in the Figma prototypes. Although the development of the Nearby Interaction feature depends on the arrival of the UWB module and Raspberry Pi, there is still plenty of mobile-app work to finish first, so this dependency is not a concern at this stage.

Figma Design:  https://www.figma.com/design/ilDMCTtHt1EF02QuBBTmXb/Basket-Buddy?node-id=0-1&t=qWuDfUQTPLnCH1fg-1

Mobile App: https://vimeo.com/1122556942?share=copy

Mobile App Repository: https://github.com/rosel26/basket-buddy

Posted on

Rose’s Status Report for 9/20

This week, I focused on figuring out how we would implement our shopper tracking system. In particular, I researched how we could use Bluetooth and GPS-based location tracking within a mobile app environment. On the hardware side, I identified that we would need to connect a Bluetooth module, a GPS module, and a compass module to our chosen controller (the Raspberry Pi). On the software side, I explored how our mobile app would need to function as an IoT application, constantly collecting data from and sending data to connected devices. This included reviewing how IoT applications manage real-time communication, data flow, and maintain reliable connections

According to our Gantt chart, I’m on schedule. The goal for this week was to complete the proposal presentation and begin researching different mechanisms of our system to prepare for finalizing the design and ordering our hardware components – which I’ve done.

Next week, I plan to:

  • Experiment with existing IoT software platforms, including Blynk, to test Bluetooth connections (using components I already own).
  • Work with the team to research and select the specific hardware parts we need to order (Bluetooth, GPS, and compass modules).
Posted on

Team Status Report for 9/20

Overall Progress

  • Created and presented our Project Proposal Presentation.
  • Researched more about hardware and software components 
  • Drafted a general layout of our project

Risks & Management 

We received a question during our proposal presentation asking what happens when the user is out of range. We have decided on the following steps:

  1.  The cart detects when the user is out of range → We decided that the maximum range the user can be away from the cart before it goes into a safety stop is 6 feet, but the cart should try to maintain a distance of 2 feet from the user. 
  2. If the user is outside of the six-foot range, the cart stops → User receives a phone notification that they left their cart behind and to return to within 6 feet of the cart
  3. To reinitialize the cart, the user must return to the six-foot range.

In addition to the cart having a safety stop when out of range, the mobile app will also have an option to manually stop the cart and manually resume the cart when the user is back within the six-foot range. This allows users to pause the cart while entering crowded areas where it might not be able to navigate, and resume cart operation upon exiting the crowded area. 

Another question we received is whether the cart’s route is mapped to a pre-determined grocery store layout:

  • We designed the cart to follow the user, so the route is not based on a predetermined grocery store layout. Ideally, the user should be able to use this cart in any grocery store.

Design Changes & Justification

  • We added new features to the mobile app based on questions from the proposal (explained above). This helps catch edge cases where there might be unexpected behaviour from the users and ensures safety for users and bystanders, and should not add any additional costs to the project.
  • Other than that, no major design changes were made to the system.