Posted on

Audrey’s Status Report for 11/1

This week, I worked on getting the motors to move. Unfortunately, I found out the H-Bridges for the motor control are not working. I believe it is an issue with the shipping or manufacturing of the component. I received the H-Bridges with the same electrical components on the board, either capacitors or transistors, bent flat. I bent them back into an upright position, but I think this bending loosened the connections. When I was testing my code, the H-Bridges were making a buzzing sound and heating up significantly. Thus, I ordered new H-Bridges and am hoping this will fix the issue. If this doesn’t work, I will consider buying a robot car kit online to remove the risk of compatibility issues between components. Other than this issue, I worked on wiring the robot and connecting all the components together, as well as further developing the Arduino code for the robot. 

 

Overall, I remain behind compared to the Gantt chart. Next week, when the new H-Bridges arrive, I hope that the motors will work and that I can continue to regain progress so that other aspects of the project can be implemented and tested according to the schedule in a timely manner.

Posted on

Elly’s Status Report for 11/1

I worked on experimenting with the LiDAR sensor to see what outputs it produces. We are using the SLAMTEC RPLIDAR A1. To get started, I used the provided software development kit which contains starter code to get the inputs from the sensor and prints out the angle and distance of an obstacle in reference to the sensor. We plan to use D* Lite as the global navigation and the virtual force algorithm as the local navigation. I focused on implementing the virtual force algorithm first while referencing a Python implementation of the algorithm. Since we have not had the chance to integrate the LiDAR with the motors or the UWB connection, I decided to test the algorithm by creating a Pygame simulation to see if the cart could steer clear of obstacles. The simulation shows how the cart moves and changes direction as obstacles appear into its view. In the video, the red dot represents the shopping cart and the yellow line indicates the front of the shopping cart and the direction it is moving in. The blue points all represent obstacles that the LiDAR has sensed. 

I am behind schedule since I haven’t had the opportunity to test the LiDAR with the motors, so I am unsure about the complete implementation and integration details. I plan to help out with other aspects to try and catch us up to a point where we can integrate all the parts together. 

Demo 

Code (can be found in app/simple_grabber)

LiDAR Datasheet 

Python Implementation 

Virtual Force Algorithm

Posted on

Team Status Report for 10/25

Overall Progress

  • Finished database integration for app
  • Finished UWB connection with live location updates
  • Assembled robot car kit
  • Setup Teensy 4.1 microcontroller
  • Wrote PWM module and found source code for UART module

 

Risks & Management 

We are still catching up on work, however, tasks are taking longer than expected and we are not making progress as quickly as we had hoped. In the upcoming weeks before the interim demo, we plan to work extra hard to ensure we are back on track. We will also need to spend time integrating each of our individual parts to create a working prototype – this will include the merging and quality checking of the capabilities of the mobile app, and integrating the software to interact with the hardware on the robot.

 

Design Changes & Justification

No design changes have been made.

Posted on

Audrey’s Status Report for 10/25

This week, I worked on getting the robot car to move. I assembled the robot car kit and set up the Teensy 4.1 Board. I had to solder pins onto the Teensy board, as we plan to use jumper wires for the connection points. I followed a tutorial from the PJRC website (https://www.pjrc.com/teensy/first_use.html) to set up the Teensy board, as this was my first time working with it. I also worked on developing the PWM and UART modules. For the UART module, I referenced source code from the PJRC website (https://www.pjrc.com/teensy/uart.html). Although there was no C source code for the PWM module, I used the detailed documentation provided on the PJRC website (https://www.pjrc.com/teensy/td_pulse.html) and wrote the module in Arduino code for simplicity. Since this was my first time using Arduino, the process took longer than expected. I have not tested either module, but I plan to do so next week. I also spent time completing the ethics assignment, which took longer than anticipated and limited the time I was able to dedicate to testing.

As mentioned in last week’s status report, due to the communication error regarding ordering parts, my timeline in the Gantt chart was pushed back a week. I am still about a week behind schedule, and the limited time available for testing the modules I’ve written has contributed to this delay. I plan to catch up on this work during the slack week we allocated for ourselves before the Intermin Demo.

Posted on

Rose’s Status Report for 10/25

This week, I have officially finished establishing the UWB connection between the two iPhones. After establishing a connection, the two iPhones can now transmit live position data to each other, representing their relative locations. This is currently in the form of 3D coordinates (x, y, z), logged onto my computer’s terminal. 

The code for the UWB live location updating can be found here, in a new branch: https://github.com/rosel26/basket-buddy/tree/uwb

I’ve also started working on the server that connects the receiver iPhone and the Raspberry Pi. I plan to use Bonjour and TCP. The planned process is as follows:

  • Pi runs a TCP server, accepts the TCP connection, and receives the JSON position data
  • iPhone receiver discovers the Pi via Bonjour, sends a new payload every update 

According to our Gantt chart, my progress is still behind schedule, as I should have the preliminary person following functionality working by this point. A challenge I faced was establishing a stable connection between the two iPhones, and it took more time than I expected to research the frameworks I had to use. 

For this week, I will focus on integrating the UWB output with the Raspberry Pi to start inputting position data into the cart control system. This involves establishing a communication link between the receiver iPhone and the Raspberry Pi as specified above. Once that connection is established, the next step will be to translate the location data into motion commands. If the robot control system and Teensy interface are ready, I will look into and work on converting position coordinates into velocity and directional commands to enable the Teensy to control the cart’s movement to start following the person (and their iPhone).

Posted on

Elly’s Status Report for 10/25

This week I worked on getting the product scanning with a local database to work. To do this, I used Core Data and created my own product entity with the barcode string, product name, and product price. For testing purposes, I used products that can be found online from Amazon’s Whole Foods Market by referencing the product names and prices and used the Open Food Facts website to get the barcode for these products to test. In addition to integrating the database, I also fixed the UI, so the app updates the total price and number of items and has buttons to increase or decrease the quantity of a product. I also worked on creating the checkout barcode generator, but it still contains a bug where there is an error with showing the image in the app.

Based on this progress, I am behind on work as I should be at the stage where I am working on the pathfinding algorithm. I have done preliminary research on D* Lite and found a Python implementation of the algorithm online that I plan to use and reference for Basket Buddy. In the next week, I will experiment with the LiDAR sensor and find a way to convert the LiDAR coordinates into information that can be used as an input for the pathfinding algorithm.

Product Scanning Demo

Product Scanning Code

Core Data Documentation

Creating a Barcode in Swift

D* Lite Code

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

Audrey’s Status Report for 10/18

This week, I focused on the design report. I finalized all aspects of communication and physical connections between all hardware components on the robot. I also roughly laid out where all hardware components will be on the robot in the robot’s block diagram. I redid all calculations for numbers in the design report, and I rechecked these numbers with my previous work I used in the design presentation.

Due to the robot car kit, Teensy 4.1 microcontroller, and H-Bridges being ordered last week and the following week being a break, I am behind. This upcoming week, I plan on working extra hard to finish assembling the robot car kit and finishing the core programming of the robot. This includes the communication between the Teensy 4.1 and Raspberry Pi (UART communication) and the naive movement of the wheels (PWM module). I plan on pushing the encoder module and PID control back a week since it isn’t a part of the key functionality of the robot car. Pushing these modules back a week ensures that Rose and Elly can work on their parts without falling behind due to my error.

Posted on

Elly’s Status Report for 10/18

I worked on finishing the design report for this week and finalizing design choices and implementation details for the software. We decided to use a local database with Apple’s Core Data framework instead of the Open Food Facts API because having a database without the proper product name and price would lead to a bad user experience as certain details could be missing if we rely on an open source database. Thus we chose to create our own database with products from a local grocery store or an online store such as Amazon to simulate the database that a grocery store would have. Another detail we finalized was the pathfinding. We will be using D* Lite due to its strengths in dynamic environments and its simplicity compared to D*. The LiDAR coordinates will be converted into a cost matrix that will be fed into the algorithm as an input. In terms of resources, there is pseudocode and a few Python implementations of the algorithm that we will be referencing for this project.

I am behind schedule as last week as I planned to have the mobile app finalized, but I was unable to work on it due to finishing up the design report. To get back on track, I plan to spend this week finishing up the mobile app by creating the local database and finalizing the UI of the app. Unfortunately, this means that I will need to push back the implementation of LiDAR and obstacle detection, but since there is a slack week, I should be able to get it done by the interim demo.