Posted on

Caitlyn’s Status Report for 10/18

Accomplished

This week, I worked on setting up the initial framework for development on the ESP32. This included updating the README on GitHub to document how to connect to the ESP32 for development and setting up the file directory structure. We will modularize our code by creating files for each task or subsystem on the ESP32, with the main.c handling creation and scheduling of all tasks.

Another task I worked on this week was getting raw IMU data from the MPU6050 (which we are currently using as a substitute for the actual IMU we will use). Once we order the actual IMU, I can ideally quickly update the code to process the new IMU’s data since most of the interface will be the same. I also implemented the FIR filter which simply outputs filtered data of the most recent raw gyro data.

Progress / Schedule

I am still a bit behind schedule, but now that I have implemented one filtering method (FIR), I think implementing Kalman Filtering will be a bit more straightforward. I have also started thinking about how to translate the gyro z-axis into the kar’s steering/rotation, which will have to be done through integration of the z-axis rotational acceleration.  I have updated the Gantt chart, and believe that I can still catch up with my goal of finishing up the IMU subsystem by next week.

Deliverables / Next Steps

Next week, I will:

  • implement Kalman filtering for IMU.
  • figure out optimal mapping between IMU and kar steering/rotation.
  • begin twiddling with the haptic controller and experiment with generating different types of feedback.
Posted on

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

Caitlyn’s Status Report for 10/04

Accomplished

This week, I worked with Enrique to set up FreeRTOS on the NUCLEO-WB55RG board that we will be primarily using for kar prototyping. We followed a tutorial that I linked two weeks ago, however instead of setting up FreeRTOS in VSCode which I worked on last week, we decided to set it up in STM32CubeIDE. After setting up LEDs, redirecting printf to Serial Wire View (SVW), and FreeRTOS, we were successfully able to create two tasks where one toggles an LED and the other prints to the serial monitor. We decided to stick with using the ST IDE for setting up the environment because there are more resources online using this setup, and we will probably stick with using the ST IDE for the remainder of the STM32 development.

I also worked on a more complete architecture diagram of our system that was used in the design presentation. For this diagram, I communicated with Nick on where the hardware is and communicated with Enrique on what the communication protocols look like between components.

Progress / Schedule

I am a bit behind schedule, since I was supposed to finish FreeRTOS setup for the STM32 last week and finish up researching IMU algorithms this week. Since I have just received the ESP32-S3 microcontroller and found an additional MPU6050 that I can use, I will focus on getting the IMU reliable, accurate, and consistent. I have updated the Gantt chart, and believe that I can still catch up with my goal of finishing up the IMU subsystem by next week.

Deliverables / Next Steps

Next week, I will:

  • learn how to use the ESP32-S3 for IMU.
  • research the FIR and Kalman filters for the IMU.
  • collect measurements from the IMU and process them through filters.
  • set up FreeRTOS on my own Nucleo STM32 (not the NUCLEO-WB55RG) on STM32CubeIDE since it looks like we will be doing all development on there.
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.