Over-The-Air Updates and RTOS Multitasking BLE Communications
It was at this point in the project where I decided to start this blog, and migrated it from the StanceWorks discord server.
June 18, 2024
I’ve implemented and enabled over-the-air software updates. Don't have to disassemble everything to update the build anymore. Did not anticipate how annoying that would be during development.
To do this I’m using the ArduinoOTA library, a simple walkthrough of the code is here. The code is very simple, and the handler is the only thing running in my main loop currently. If you’re using tasks that execute outside of the main loop, you need to make sure their priority or interval does not lock the main loop (Priority 1) from executing.
July 18, 2024
Have been spending most of my time after internship hours writing up blog posts rather than development. It’s been very fun so far, and seeing people interact with my posts brings me joy.
Priorities at the moment:
Convert BLE logic from Arduino-style loop to RTOS tasks and allow chip to juggle BLE comms, Gyro input and motor output.
Self-stabilization PID code
Forward/backward lean to adjust speed
Turning
Figure out RTOS task scheduling scheme necessary to maintain accurate distance calculations while still maintaining balance with a decent fidelity in motor control. Currently all tasks are sharing the same priority level, but I’m not sure that’s ideal.
Adjust speed based on distance calcs
July 20, 2024
Very happy with progress today. BLE logic has been converted from a Arduino-esque loop structure into two RTOS tasks for sending and receiving messages, at different intervals and different priorities. Receiving is higher priority than sending, because the timing is most critical on the latter half. We can wait a couple ms to send another packet, that just increases the time to get a good average, but any delay in reading and processing incoming packets drastically reduces the accuracy of our distance calculations. Super slow interval of 250ms currently so I can actually read the debug logs as they're printing, so the timing and distance calculation is all off. I'm gonna do some work to clean up the logging, add some more additional error handling and noise suppression, and look into what more can be done to get as accurate a timestamp as possible assigned to packets as they're received.
If you've done a bit of programming before you'll notice the first three timestamps are the max value of an integer, so I need to look at the code on the Android side and make sure it's correctly responding with timestamps on those messages as well.
I’ll end this blog post with a clip of the main chassis rolling. You’re correct, we’ve had this before, but now we’re doing it with RTOS events rather than a simple loop. Really, really exciting!
