Posted on

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.
Posted on

Caitlyn’s Status Report for 09/27

Accomplished

This week, I followed multiple tutorials to set up FreeRTOS and the beginning of what our team’s workflow would look like on the STM32.

Using an STM32 Nucleo board that our team had on hand, the STM32F401xE, I used the STM32CubeMX software to enable FreeRTOS on the board. This software has a user interface for easily using methods in the FreeRTOS library, which I experimented with to create two simple tasks. I was able to change the priority of tasks and figure out other settings like configuring the heap size. Since STM32CubeMX is more for configuration and code generation, I couldn’t figure out how to compile and deploy the code without installing STM32CubeIDE, so I moved onto setting up the STM32 development environment on VSCode.

Recently STM32 developed an extension on VSCode called “STM32Cube for Visual Studio Code” which integrates build systems like CMake so users can compile STM32 projects within VSCode. With this extension, I was able to compile and deploy the STM32CubeMX-generated FreeRTOS firmware onto my STM32 Nucleo board.

Progress / Schedule

I will need to spend a bit more time making the STM32 development workflow more seamless and integrated, since it took me some time to install and debug drivers for the STM32 Nucleo board. This way it will be easier for the team to work on different parts of the STM32 software concurrently.

Otherwise, I am mostly on schedule but will have to prepare and do some research for collecting IMU measurements and experimenting with different filters, namely the FIR and Kalman filters.

Deliverables / Next Steps

Next week, I will:

  • push the STM32 development environment up to the team GitHub and work with Enrique to set up a more seamless workflow for working on the STM32.
  • outline and plan what types of tasks we will need on the TX and RX MCUs. This will include identifying what initialization and run will look like for each task, as well as task priority.
  • research the FIR and Kalman filters for the IMU.
Posted on

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.
Posted on

Enrique’s Status Report for 09/20

Accomplished

So far, I have confirmed the use of the XIAO ESP32S3 as the ESP32 platform for this project. The board supports Bluetooth Low Energy (BLE 5.0), which makes it a good candidate for communicating with the STM32Wx family (I have a XIAO ESP32S3 of my own and have tested BLE services with my laptop, with some starter code from the Arduino IDE). On the STM32 side, I have searched the avilable options and identified that the STM32WB series is most relevant, since it includes an integrated BLE stack and has development boards such as the Nucleo-WB55 that provide convenient debugging and GPIO access through STLINK. I have also set up development enviornments for both platforms: Arduino IDE / PlatformIO for the ESP32S3 and STM32CubeIDE / CubeMX for the STM32. In addition, I have reviewed documentation and example projects for BLE communication on both chips to understand their capabilities and constraints. I also found this video to be helpful with BLE  / firmware drivers setup for the STM32WB55.

 Progress / Schedule

At this point, the main task underway is finalizing the STM32 board selection and preparing for proof-of-concept testing. The Nucleo-WB55 is the leading candidate, as it is well-documented, actively supported (frequent posts in ST Community forums), and includes the BLE middleware needed for this project. Once the hardware is secured, I will be able to begin prototyping a minimal BLE connection. The plan is to first establish a simple communication channel where one device (likely the ESP32) advertises a BLE service and the other (STM32) connects to it. This milestone is targeted for completion within the next couple of weeks to stay aligned with the overall project schedule.

Devlierables / Next Steps

The immediate deliverables will include (1) finalized hardware selection of the STM32Wx board, and (2) a working BLE proof-of-concept demonstrating connectivity between the ESP32S3 and STM32. The proof-of-concept will serve as the foundation for the kart’s communication features, such as streaming IMU/flex sensor data or sending control commands. Documentation of the configuration steps, code, and test results will also be included as part of upcoming deliverables to ensure reproducibilty and staying on track with our schedule.

Posted on

Caitlyn’s Status Report for 09/20

Accomplished

The high-level architecture of our project will involve the ESP32-S3 acting mainly as the data source and an STM32W series board acting as the data receiver. Both of these microcontrollers will need some sort of RTOS running to manage complexity and ensure the system is responsive and reliable

This week, I looked into how we would set up FreeRTOS on each microcontroller. We want to use FreeRTOS since it is a small and open-source real-time operating system that can simplify task management and scheduling for both of our MCUs.

I found that the development framework for ESP32-S3 is already built upon FreeRTOS, so it is possible to just use features like tasks, queues, and semaphores in our code development. FreeRTOS also already supports use on certain development boards such as STM32s, so I watched a video on how we would begin writing tasks and handle scheduling on STM32 after some setup on STM32CubeIDE, which is an IDE for STM boards.
Here is the link for the tutorial for next steps.

Progress / Schedule

My progress is on schedule, as we wanted to spend this week investigating FreeRTOS compatibility and setup on the microcontrollers. This will end up extending into next week of actually setting up our development environments and FreeRTOS on the hardware.

Deliverables / Next Steps

Next week, I will:

  • follow the tutorial to setup FreeRTOS for an STM32 board that we have readily available such as the STM32F401xE.
  • outline and plan what types of tasks we will need on the TX and RX MCUs. This will include identifying what initialization and run will look like for each task, as well as task priority.
  • set up a Git repository for the team so that we can begin collaborative development.