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

Nick’s Status Report for 10/18

Accomplishments

These least two weeks (the week before break and the break week), I finally sent out the orders for our PCBs to be manufactured, and then additionally sent out orders for all of the surface mounted PCB components from Digikey for each PCB. The original plan was to have both PCBs manufactured and assembled (having components placed for us), by PCBway. However, with shipping restrictions caused by tariffs we were forced to switch to JLCPCB. Therefore, I made changes to our PCB designs so that we could get cheap manufacturing from JLCPCB, but found out that with the new increase in tariff percentages getting assembly for our Kar PCB alone would incur $100 of purely tariff cost, which would wipe out the rest of our budget. As such, I changed the orders such that we are now purely paying for PCB manufacturing, and I will now perform all the assembly for the PCBs myself.

Progress/Schedule

The requirement for me to assemble the PCBs myself will undoubtedly have impacts on the schedule, not to mention the amount of delays encountered in actually ordering them. The one saving grace is that due to the PCB fabs not performing assembly, the PCBs will be delivered much quicker, meaning I can start assembly quite soon. Regardless, this will likely wipe out the time I had allocated for slack in my personal schedule.

Next Steps

Our PCBs will be delivered by EOD this coming Wednesday. As such, my plan for the coming week is to perform assembly on the PCBs and at minimum finish assembly for the glove PCB, and the finger attachment with the Adafruit board.

Posted on

Nick’s Status Report for 10/04

Accomplishments

This week I first modified the Kar PCB shape to match the one that originally ships with the Kar. Now they have virtually identical footprints and mounting holes, meaning ours should be able to slot right onto the Kar. I also worked on getting quotes from various PCB manufacturers for the manufacturing and assembly of our custom PCBs. This led to me making many small adjustments to the PCB designs to hopefully secure lower quote prices, as we only have around $300 of our budget left. Currently, the quotes from the manufacturers total around $210, but we expect that to increase once the PCB designs and BOMs are reviewed; especially with the impact of current tariffs. As such, if the final quotes for the PCBs are too high I will make a couple more optimizations and/or forego assembly on the boards to drive the prices even lower, at the cost of extra bringup work in a couple of weeks. I also soldered some sensors which the team scavenged from various sources around campus for breadboard-level testing.

Progress/Schedule

The PCB ordering process is a little behind schedule due to delays in waiting for finalized quotes, but if they are received early within the next week I believe this to have a negligible impact on overall progress.

Next Steps

This coming week I will work on finalizing the quotes for the PCBs and getting them ordered. As stated, if the costs are too high, I will instead work on PCB reworks to bring manufacturing costs down: one proposed option is mounting our nucleo debug board on our Kar PCB to vastly simplify the PCB manufacturing requirements. Otherwise, I will be working with the rest of the team on breadboard-level implementation and debug testing in preparation for deployment of our code onto our PCBs.

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

Nick’s Status Report for 9/27

Accomplishments

This week I worked on completing the preliminary layouts for all of the boards. With our chosen design for our hand controls, we were able to solidify our IMU choices and get back on track for our board design schedule. Now that we have decided to use two IMUs for the hand controller, two boards were required for the glove: one for the primary microcontroller on the back of the hand, and one for the IMU on the fingers. This required some extra work like selecting connectors and a cable for connecting between the two boards, so that the power, ground and SPI lines could reach the IMU. The one bottleneck for board design is that the Kar PCB sizing is still a little bit uncertain, as we do not yet know where the holes for the Kar PCB will be. This will be solidified when the Kar arrives and is measured; it has already been ordered.

Progress/Schedule

Progress is essentially back on schedule, although ideally all the layouts would have been done by now. However, adding holes to the PCB should be a very quick process once the Kar arrives.

Next Steps

This coming week I will be working on purchasing many of the components we need for the boards, as well as potentially putting in orders for the PCBs + assembly as well. I will need to see what the order process is for boards in order to do this.

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.