Category: Team Status Reports

Progress

• Performed and finished bluetooth latency test.
• Began user feedback tests for use-case requirements.
• Integrated haptic feedback on the glove.
• Debugging backwards movement on the Kar.

Unit tests

• PCB functionality: Verified power rails, continuity, and component bring-up. Fixed solder mask and test-point issues discovered during initial probing.
• Servo: Tested PWM control and steering response. Noted slight mechanical nonlinearity and added angle clamping in software.
• Motors and ESC: Checked throttle ramping and stability under load. Soft-start curve adjusted to avoid current spikes.
• IMU: Evaluated noise, drift, and gesture responsiveness. Improved filtering and thresholds after detecting inconsistent finger-IMU readings.
• Haptic Motor Controller: Confirmed vibration patterns and intensity. Rebalanced waveform strengths to improve clarity of subtle feedback.

Bluetooth & Latency Test

Measured ESP32 to STM32 communication delay by logging timestamps when packets were sent and when they were received, then plotting the round-trip time across varying distances. Findings showed that at increasing data ranges, RTT would experience latency spikes, leading us to slightly refine packet size and filtering to keep end-to-end delay within requirements.

overall system test

Evaluated the complete driving experience through extensive user-feedback testing, including navigating obstacle setups, gesture-control trials, and haptic-feedback evaluations. User responses helped tune gesture sensitivity and adjust control mappings.

Progress

• Finger IMU soldered to Glove PCB
• Began implementation of the bluetooth latency test
• Began integrating haptic motor controller on the glove, along with crash detection from the Kar IMU and speed from the glove IMU

Design Changes

• The haptic motor controller will control haptic feedback from two types of input. The first input will be the IMU controlling speed on the glove controller, which will be mapped to a buzz vibration on the hand. Similar to how we translate IMU angle to PWM, we will also convert angle to a buzz intensity that the user will feel as they accelerate. The second input will be a crash detection from the IMU on the Kar. When the user crashes into something, they will feel it as a strong click or multiple clicks of vibration on the hand.  Previously, we considered taking in input from only the IMU on the Kar, but for simplicity, we decided to use the IMU on the Kontroller for speed haptic feedback.

Progress

• IMU for haptic feedback loop added to Kar.
• Begun reading roll from the IMU on the Kar.
• Finished prototyping the glove so the Kar successfully steers and drives from two IMUs connected to the ESP32.
• Implemented logarithmic scaling for the IMU to steering PWM values.

verification/Validation

End-to-end latency measurement

• Ensure that the latency of a command originating from the ESP32 to the receiving STM32 is less than our use-case requirement of 50ms.
• This will be done by timing how long it takes to send a GPIO command to toggle an LED from the ESP32 to the STM32.
• The metric being measured is how many milliseconds it takes between an LED lighting up on the glove and an LED being lit up on the Kar. May conduct 20 trials, success is quantified on end-to-end latency <50ms on 95% of the runs.

Control scheme viability

• Verify intuitive control and real-world usability with users navigating an obstacle course.
• Ten or more participants will navigate a classroom obstacle course, and we will log collisions and collect subjective Likert scores.
• Average Likert score >4 for comfort and intuitiveness, and the collision rate needs to be below an acceptable threshold (<1 collision per run).

Entering the safety/reset state

• Ensure the Kar enters the safe idle state within 50ms on communication loss or reset.
• Forcefully disconnect Bluetooth communication or power to the Kontroller during operation and measure stop time using an oscilloscope or motor motion.
• Success is quantified by the Kar successfully entering idle within 50ms in 95% of trials, may conduct 20 trials.

Progress

• Kontroller PCB assembly completed
• Kar PCB assembly completed
• Kar + Kar PCB integration completed and drivable with a prototype Glove Kontroller that can transmit steering and speed.
• Haptic motor controller prototyped and ready to be integrated with Kar.

Design Changes

• The Glove Kontroller will have 2 IMUs and the Kar PCB will have 1 IMU. The rotation/steering control on the glove will be done using the MPU6050, since it can measure pretty reliable and non-drifty roll/pitch values. The Kar’s forward/backward speed will be controlled using the ICM20948 breakout since we have a SPI connection for it. The Kar PCB will use the MPU6050 as well, and we might not need absolute yaw as long as we can figure out a good way to map relative yaw or rotational velocity to haptic feedback.

Risks and risk Management

• Even though stopping the Kar via BLE is very responsive, the Kar can still accelerate quite rapdily. We will consider doing some more testing with the Kar on the ground to clamp the PWM max/min values so users have better control over acceleration.
• Right now the Kar could continue moving/steering, even if it receives invalid BLE data or no data at all. We will consider adding a watchdog timer to trigger a system reset to decrease amount of undefined behavior.

Progress

• Half of the Kontroller PCB has been assembled, and general assembly of all PCBs is well underway.
• Beginning to experiment with kar motor control development with the board that the DonkeyCar came with.
• ICM20948 development is in progress on ESP32S3.

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.

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.

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.

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.