Enrique’s Status Report for 12/06

Accomplishments

This week, I worked with Caitlyn and Nick on user tests. We conducted multiple user tests and had them fill out feedback surveys on intuitiveness of the Kar and the haptic feedback. While we did some of these user tests, we noticed multiple bugs. For example: the Kar would keep running after Bluetooth disconnected, the BLE supervision timeout would be too high (and therefore the Kar would keep running for a while after it disconnected from the Kontroller), and the Kontroller wouldn’t reconnect/try to scan to connect to the Kar after a reset was triggered on either device. We addressed all of these issues, and we will continue polishing our system until demo day.

Finally, we conducted some BLE roundtrip and end-to-end latency tests. We met our end-to-end latency target of <50 ms. Here is a graph further showing our round-trip latency. Of course, there is some variance with latency as distance between the BLE devices increases, but the connection and latency of packets is reliable for a distance within 10 m.

Progress / Schedule

We have reached our MVP. We are now adding finishing touches, and polishing as much as possible before our demo day.

Next Steps
  • Perform more user testing and collect more feedback.
  • Fine-tune Kar reverse movement and program switch for reverse motion.

Team Status Report for 12/06

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.

Nick’s Status Report for 12/06

Accomplishments

This week I worked extensively with Caitlyn and Enrique on performing user testing, and fine tuning our control scheme. I also re-soldered the Kontroller board a couple of times as weak joints broke during testing. Overall, I’ve strengthned many of the solder joints on our finger IMU which should allow for stringent use during our demo.

Schedule

We have completed our MVP.

Next Steps

We are refining our project experience as much as possible, tuning according to user feedback.

Caitlyn’s Status Report for 12/06

Accomplished

Over the past two weeks, I worked with Enrique and Nick to fine-tune the driving and steering behaviors of our Kar. The first thing we worked on fine-tuning was the haptic feedback, where the haptic intensity is determined by the drive throttle. If the driver is accelerating at full throttle, they will feel considerable haptic feedback on the hand compared to if they only slightly accelerating.

We also worked on developing and fine-tuning user control, experimenting with driving with and without backwards, and the different hand motions/gestures that users could test with for feedback. I created our user feedback form and we have started receiving responses regarding the intuitiveness, haptic feedback, and overall performance of our system.

Progress / Schedule

Our team has finished MVP and are now focusing on fine-tuning and improving current controls based on the user feedback.

Deliverables / Next Steps

Before demo day on Monday:

  • perform more user feedback tests.
  • fine-tune Kar steering and acceleration control and haptic feedback.
  • integrate user feedback into Kar and Kontroller.

Team Status Report for 11/22

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.

Enrique’s Status Report for 11/22

Accomplishments

This week, I completed some preliminary code that detects crashes on the Kar. Essentially, a crash is detected when the derivative of the IMU acceleration values reaches a threshold. This can be adjusted. Additionally, Caitlyn and I have completed haptic motor driver code for the Kontroller. We worked on mapping the range of motion for speed (0º to 90º) to an 8-bit value that varies the oscillations of the haptic motor. This was achieved via linear interpolation.

Progress / Schedule

We’re on track, and making progress with our Kontroller. Soon enough, we’ll have the PCB fully set and we’ll move away from the breadboard implementation.

Next Steps

Next week, I’ll be doing some testing on the haptic motor system, to ensure that it responds properly in edge case scenarios. Additionally, I will work on optimizing the BLE code, and take measurements throughout, to be ready to discuss tradeoffs.

As you’ve designed, implemented and debugged your project, what new tools or new knowledge did you find it necessary to learn to be able to accomplish these tasks? What learning strategies did you use to acquire this new knowledge?

Becoming familiar with the STM32CubeIDE was a new tool that took some time to getting used to, but it paid off in the end. It’s easy to want to create your own development environment because some of the IDE features are questionable and unorthodox for an IDE, but the autogenerated code for the HAL (Hardware Abstraction Layer) is very robust and easy to use for user programs.

Additionally, it takes some time to learn how to properly set up the debugger for the IDE. For example, you need to specify the debugging interface (JTAG/SWD), modify some syscalls (like sys_write and sys_read) so you get UART redirection for print debugging, ensure you carefully set compiler flags so you have the necessary debug symbols, etc. But once everything is fully set up, debugging becomes very streamlined.

Finally, version control support on the STM32CubeIDE isn’t the best either. STM32 projects could become quite bloated (especially if you have multiple peripherals and wired/wireless communication protocols enabled). Therefore it becomes hard to keep track of what files to push to a shared repo. Additionally, the STM32CubeIDE is picky with the IO configuration files, and it has prevented us from easily continuing someone’s work on another machine. Thankfully, we’ve learned over time exactly which files to commit, and how to commit IO configuration files so that we don’t get error messages like “Error: this project is already open” when opening up projects.

Caitlyn’s Status Report for 11/22

Accomplished

This week, I started integrating the haptic motor controller on the glove controller. Since both the haptic controller and the MPU6050 communicate over I2C, I had to ensure that both worked individually after porting over the code and checking that they worked together as well. I worked on translating IMU speed to haptic buzz intensity while Enrique worked on crash detection on the Kar.

Progress / Schedule

I am on schedule to completing the MVP. Enrique and I have begun working together to integrate haptic feedback and the Kar IMU.

Deliverables / Next Steps

Next week, I will:

  • implement a mapping between the Kar IMU’s gyroscope values and haptic feedback.
  • fine-tune Kar control.
  • help bring up firmware on the glove PCB.
New tools and new knowledge
For bring-up of the STM32 development environment and STM32 board itself, we watched Youtube videos of people setting up on STM32CubeIDE and enabling peripherals such as FreeRTOS, I2C, and bluetooth. Whenever we ran into compiler or code errors, we also consulted STMicroelectronics Community Forums in case developers had run into similar issues before.  For development on the ESP32, we utilized a lot of pre-existing packages and libraries made by developers on ESP-IDF, which helped to confirm the functionality and save time when implementing our IMUs and motor controllers.
For the IMU, I looked at a lot of resources online (Youtube, GitHub, websites) regarding how we can sample IMU data effectively with FIR and Kalman filtering, and how we can calculate the yaw, pitch, and roll using different algorithms, such as the Madgwick Filter.

Nick’s Status Report for 11/22

Accomplishments

This week I completed soldering of the Glove PCB. Specifically, I soldered the finger PCB to the connector coming from the Glove PCB. This now lets us perform tests with the completed glove controller. Below is an image of the fully-soldered IMU. We are still keeping the IMU on our breadboard for testing right now.

Progress/Schedule

We are on track given our updated schedule from our interim demo. We are making good progress towards streamlining our controller and solidifying our control scheme.

Next Steps

Next week I will be working collaboratively with the rest of the team to make improvements to our control scheme and to close the loop between Kar and Kontroller.

As you’ve designed, implemented and debugged your project, what new tools or new knowledge did you find it necessary to learn to be able to accomplish these tasks? What learning strategies did you use to acquire this new knowledge?

A new manufacturing technique that I had to learn was how to solder SMT components to a PCB without a stencil, and where the component pins were on the bottom of the IC. This required me to watch a YouTube video on the topic, which demonstrated a technique of mixing flux and solder paste together on the board before using a hot air gun to solder. I successfully used this technique to solder our buck converter to the Kar PCB. Additionally, I had to learn more PCB rework skills for this project, due to the manufacturing issues with our PCBs. This was mostly self-taught, as I messed around with techniques of sticking wires and components to the boards until they worked properly.

Team Status Report for 11/15

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.

Caitlyn’s Status Report for 11/15

Accomplished

This week, I worked with Enrique to implement logarithmic scaling for IMU control on the glove. Previously, we had linear scaling which gave us too much precision at lower angles, which is where the motor deadzone was. This means that it was harder to start the motor at lower speeds. To resolve this issue, we applied a logarithmic function so that movement is more “snappy” at low inputs and gradual at high inputs.

We also worked together to enable the BNO055 IMU on the STM32 on the Kar over I2C. This required enabling I2C on the STM32 and writing up a driver to read the IMU inputs to be converted into roll.

Progress / Schedule

I am on schedule to completing the MVP. Enrique and I have begun working together to integrate haptic feedback and the Kar IMU.

Deliverables / Next Steps

Next week, I will:

  • come up with and implement a good mapping between the Kar IMU’s gyroscope values and haptic feedback.
  • fine-tune Kar control.