Posted on

Caitlyn’s Status Report for 10/25

Accomplished

This week I received the actual IMU (ICM20948) that we will use on the glove kontroller. I have started looking into existing ESP-IDF drivers for this IMU and am currently experimenting with setting up the IMU with SPI.

Progress / Schedule

I am a bit behind schedule, but will be back on track next week.

Deliverables / Next Steps

Next week, I will:

  • finish setting up the new IMU with SPI and Kalman filtering.
  • 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

Enrique’s Status Report for 10/25

Accomplishments

This week, I worked on adding an LED characteristic for BLE on the STM32. This allowed me to verify that I could send data from the ESP32 to the STM32 besides simply establishing a GATT client/server connection. Additionally, I spent some time reading the Donkeycar’s documentation to begin writing code to move the brushless DC and servo motors.

Contrary to what I thought, the STM32 doesn’t directly send the PWM signals to the motors. The Donkeycar’s expansion board has a PCA9685 controller that sends servo signals to the motors via I2C. I then spent some time modifying the STM32 IOC file to provide the HAL for I2C with 7-bit slave addresses.

Progress / Schedule

Currently, I am on track with my tasks. I’ll ensure to have functional motor code this week, so that Caitlyn can integrate her IMU logic with the system once basic movement recognition is finished. In parallel, I will be trying to flash my code onto the board’s as Nick finishes verifying them.

Next Steps / Deliverables
  • Finish writing I2C setup code to move Donkeycar’s wheels.
  • Integrate simple IMU motions for forwards/backwards movement on the car.
  • Flash STM32 and ESP32 code on PCB boards after verification is done.
Posted on

Team Status Report for 10/25

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

Nick’s Status Report for 10/25

Accomplishments

This last week I began assembly of our PCBs. I was a little delayed in getting started on assembling them, as the Digikey order did not arrive until Thursday. The glove PCB is around 50% completed, and after I finish it I will move onto the Kar PCB.

Progress/Schedule

Given the new re-arranged schedule the team came up with (discussed in last week’s team report, I am still on schedule. I hope to finish all of the assembly for the PCBs by next weekend so that there is plenty of time to test software on our actual finalized hardware before the interim demo.

Next Steps

I will continue to assemble, and hopefully finalize assembly of, our PCBs in the coming week.

Posted on

Enrique’s Status Report for 10/18

Acomplishments

The past 2 weeks, I worked on and completed the P2P BLE setup between the STM32 and the ESP32 microcontrollers. In our BLE communication architecture, the STM32 is a GATT server, and the ESP32 is a GATT client. At a high level, as a GATT client, the STM32 advertises and exposes its services; the ESP32 scans and connects to the server and writes/reads data. Both devices initialize the BLE stack on their second CPU core, which support a variety of low power modes. This is ideal, given that our filtering/processing tasks are likely going to consume a significant amount of power.

As for our implementation/process, we ended up not using an RTOS on our STM32. The BLE setup code included on STM32CubeIDE uses a sequencer for BLE that conflicts with some of the tasks on FreeRTOS for example. While we found a workaround for it, we thought it would be more productive to simply not use an RTOS, instead of going through the hassle of fixing linker errors and carefully managing task priorities between sequencer and RTOS tasks. Additionally, there are relatively few subroutines that the STM32 has to execute compared to the ESP32. We were, however, able to get BLE working on its own FreeRTOS task on the ESP32. Fortunately, not much new code had to be written for both microcontrollers. Most time was spent properly configuring the IOC config file for the STM32 and editing a few things like UUID and advertising name. For the ESP32, I was able to reuse most of the GATT Client example code from Espressif. I simply had to modify it so that it would scan for the server with the proper device/characteristic UUIDs and the correct remote device name.

For verification, I used multiple debug logs and redirected them to UART for verification of the existence of the successful case logs. I was also able to set a supervision timeout of 2000 ms for the connection and got the correct disconnection status codes when I disconnected the ESP32 from power.

Progress / Schedule

I’m currently on track with my schedule. The next step would be to integrate Caitlyn’s work with the IMU sensor data, and to test the BLE code once Nick is able to verify the PCBs. During the following days, I will be using an oscilloscope to test BLE latency and taking measurements, so we have something to compare against once we start implementing optimizations.

Deliverables / Next Steps
  • Take latency measurements for BLE and SPI/I2C.
  • Flash code into PCBs once they’re verified.
  • Write mock code to simulate sensor activity and communication.
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

Enrique’s Status Report for 10/04

Accomplishments

This week, I worked with Caitlyn for some of the FreeRTOS integration with the STM32WB55RG Nucleo board. However, I spent most of my time working setting up P2P BLE communication between the STM32 and ESP32.

We’re using the STM32CubeIDE for development on our STM32 board. This allows you to autogenerate configurations so that you don’t have to manually do things like writing a bootloader/RTOS, writing drivers for GPIO and communication protocols like UART, I2C, SPI, BLE, etc. However, there was an issue with getting both RTOS and P2P BLE communication working on the STM32. This is because the P2P code uses a sequencer that conflicts with the RTOS’s scheduler, and therefore the IDE cannot autogenerate code to support both. I saw that at least 2 ST employees have acknowledged this limitation in these 2 ST community forum posts: see post 1 and post 2.

Regardless, with the help of some of the documentation from one of the ST employees, I was able to replace the P2P sequencer code with similar RTOS kernel function calls. So far, the code at least builds and compiles fine. I have documented some of my learnings along the way, as well as the communication architecture for BLE between the ESP and STM in this Google doc.

Progress / Schedule

Currently, I would be a bit behind schedule. The FreeRTOS and P2P setup on both devices has been a challenge, as well as getting accustomed to the new development environment for the microcontrollers. However, I have learned how to debug on both devices via UART and GDB (at least the STM32IDE has a pretty decent GUI for GDB+print debugging), and I have also learned more about the BLE protocol.

In parallel, Caitlyn and I will be testing out some of the IMU sensors and haptic motors.

Deliverables / Next Steps

Next week, I will:

  • Work on sending a stream of bytes from one MCU to another and validating with UART with minicom on my machine.
  • Test BLE latency between the 2 devices using an oscilloscope via a sequence of GPIO set commands.
  • Help with the setup and integration of sensors/motors.
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.