Team Status Report for 10/18

Progress
  • Finalized orders for manufacturing all of our PCBs, and additionally ordered all the components required for assembling each PCB.
  • Set up initial ESP32 development framework.
  • Collected raw values from MPU6050 and processed them through FIR filter.
  • BLE integration and communication working between ESP32 and STM32.
Design Changes
  • The STM32 will no longer have a custom layout on the Kar PCB, the PCB design has been changed such that the STM32 Nucleo board will instead mount into header pins on the Kar PCB. This reduces manufacturing costs significantly, reducing our PCB spend and therefore the amount of money tariffs are siphoning from our budget.
  • The STM32 no longer has FreeRTOS as part of its software stack. We are only using the BLE sequencer. Nothing has changed on the ESP32 side.
Risks & Risk management
  • Due to needing to assemble all the PCBs in-house, Nick’s scheduled slack has been wiped out. In order to manage this risk, some of his non-PCB tasks have been reassigned to other members of the team.
Part A: Impact of Product on Global Factors-written by enrique
  • Our project aligns with global trends in human-robot interaction, wearable technology, and assistive robotics. There is an increasing demand for more intuitive and accessible control systems that reduce reliance on traditional interfaces such as joysticks or keyboards. This technology could benefit applications beyond entertainment such as remote vehicle control and industrial robotics, where ease of control and safety are priorities.
Part b: Impact of Product on Cultural Factors-written by Caitlyn
  • Culturally, our design promotes inclusivity since it emphasizes intuitive and  gesture-based control that transcends language and literacy barriers. Instead of requiring users to interpret text or symbols, like the ones on controllers, our controller operates on natural human movements, making it adaptable across communities with varying cultural norms or levels of technological familiarity. By valuing ergonomic comfort and safety, our project aligns with global cultural trends toward more accessible use of technology.
part c: Impact of product on environmental Factors – Written by Nick
  • As we are creating an electronic entertainment product, our product is in a category of items which are a very frequent and common contributor to worldwide electronic waste. Generally, discarded entertainment products are disposed of due to not adequately meeting the consumers needs or due to janky/improper functionality. As such, to ensure that our product will not be a contributor to this global environmental issue, we must ensure that it has the proper and correct functionality that we have outlined in our users requirements such that our products are not also wantonly discarded.

Team Status Report for 10/04

Progress
  • Found/ordered all main components need for breadboarding and prototyping, so that we can begin development and integration of the sensors ahead of when we get the hardware. These components include the MPU6050, haptic motor controller, and the DonkeyCar.
  • Moved development for the STM32 onto the STM32CubeIDE and development for the ESP32 to Arduino IDE. Got FreeRTOS running on the STM32 that was able to print debug messages and blink LEDs in different tasks.
Design Changes
  • Due to the higher-than-expected costs of PCB manufacture, we have decided to cut the PCB for supporting the IMU attached to the user’s finger. It is simply much cheaper to use a SPI-enabled adafruit IMU breakout board, and connect that to our custom glove PCB than to make both ends custom.
Risks & Risk Management
  • There seems to be a conflict with enabling both FreeRTOS and the WPAN BLE Stack on the STM32 that could be due to both the Sequencer (ST’s bare-metal task scheduler) and FreeRTOS running on the same core (Cortex-M4). We may need to look into another microcontroller or research additional workarounds to get an RTOS and BLE enabled on the kar.

Team Status Report for 09/27

Part A: Nick (public health, safety or welfare)

The one major health/safety concern for our product is the concern of a haywire car driving around without control. In order to address this, we are implementing engineering solutions to ensure this will not occur. The three major solutions we are planning are 1) keeping the Kar in an enclosure will doing our demo, 2) allowing a user to easily put the Kar in a stopped idle mode, and 3) implementing timeouts between the glove microcontroller and the Kar such that if there is no communication between the two over a certain length of time, the Kar automatically switches into its idle mode. We believe these solutions will be sufficient to ensure Kar safety at all times.

Part B: Caitlyn (social factors):

Our glove controller and kar meets the need for more natural and immersive interaction by allowing people to drive a kart directly with their hand movements. Unlike a 2D driving video game, the experience is physical and tangible, enabling the user to feel the kar’s motion rather than only seeing it on screen. Compared to an RC kar with a traditional controller, the glove is more intuitive and inclusive, since it removes the learning curve of joysticks or buttons, allowing anyone to pick it up quickly. This project lowers the barriers to driving RC kars for everyone, making it more accessible, engaging, and fun. It also supports community interests in interactive driving, collaboration, and friendly competition.

Part C: Enrique (Economic Factors)

Our Mario Kar system balances performance and affordability by leveraging widely available microcontrollers (ESP32 and STM32) and low-cost IMU sensors. These components are mass-produced, making them economically viable for both prototyping and potential scaling. Using Bluetooth as the communication channel avoids the need for specialized hardware and reduces distribution costs, since wireless modules are integrated into the ESP32. From a consumption perspective, the design is energy-efficient and powered by inexpensive batteries, minimizing recurring costs for users. Overall, the project demonstrates how accessible embedded hardware and open-source software can be combined to deliver an interactive system that is both technically capable and economically practical.

——————————————————————————–

Nick wrote section A, Caitlyn wrote section B, and Enrique wrote section C.

——————————————————————————–

Progress

  • Worked on the Design Presentation, which addresses how use-case requirements will be addressed through design requirements. Also designed out the system-wide and individual subsystem architectures and flows.
  • Purchased multiple components, such as the DonkeyCar for PCB layout and microcontrollers for initial prototyping and breadboarding.
  • Setup FreeRTOS on the ESP32-S3 and STM32 Nucleo board and began setting up development workflow.
  • Completed the component selection, schematic, and layout for both the glove/controller and kar PCBs.

Design Changes

  • Beyond our MVP, one of our stretch goals is to add a first-person camera to the kar. However, if we continue using Bluetooth or Bluetooth LE for communication between the controller and the kar, receiving the camera feed may be difficult. Therefore, we may need to reconsider our current communication methods to support future camera integration.

Risks & Risk Management

  • An ongoing risk is meeting our use-case requirement of 30–50 ms round-trip latency between the glove controller and the kar. This latency includes sampling IMU measurements, transmitting them over Bluetooth to the kar, mapping them to movements, and sending haptic feedback back to the controller. The main challenges lie in the IMU sampling frequency on both devices and the reliability of Bluetooth communication in both directions. We can mitigate this risk by optimizing IMU sampling rates, minimizing Bluetooth packets, and exploring more efficient communication protocols.

Team Status Report for 09/20

Progress

  • Wrote and presented the Proposal Presentation to the class. We provided information such as our target user, user requirements, possible technical challenges, as well as proposed solution from a high-level. After the presentation, we got some good feedback regarding how the user will control the kart.
  • Investigated how FreeRTOS would be setup on the ESP32-S3 and STM32 microcontrollers, and made plans to implement them next week.
  • Investigated how BLE would be etup on the ESP32S3 and STM32WBx. Tested some starter code on Arduino IDE for ESP32 BLE services, downloaded/installed environments for STM32 firmware and debugging, and read through documentation and community forums for ST.
  • Began the Order List and will finish ironing it out by the end of next week.
  • Mostly completed component selection + schematic for both the glove and kar PCBs.

Design Changes

  • For hardware on the controller, instead of sticking with IMU sensors for inferring user command, we will also investigate flex sensors to detect motion on the user’s fingers. This will enable us to explore more controls that the user can do with their fingers, in addition to the tilt/rotation of the user’s hand.

Risks & Risk Management

  • One of the current risks that the team thought about this week is getting an accurate and reliable reading from the IMU. When creating the Order List, we will need to research extensively and explore a variety of IMUs online. To mitigate this concern/risk, we will order a few different types of IMUs and experiment to see which can provide the best measurements.
  • Another risk is that the PCB development is already behind schedule, but due to the team taking a moment to evaluate IMU and flex sensor options, this is to be expected; it is fully expected that the team will be back on track once this design decision is resolved.