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.