Everything's On Track (Literally)
This week started with the arrival of the linear bearing block which finally meant I could get my robot completely assembled for the final time and fixed to the track which will be its home from now on. While it did take a couple of hours of de-greasing the rail (thanks again Alex for your help with that!), the robot is now fully integrated and can slide along very smoothly with much less friction than a gunky greased track would provide.
It's always immediately following a major milestone though that you tend to notice new problems. During the limited testing I've been able to do so far, I've been using the Pimoroni board's integrated button to start the program running. Now everything's fully integrated though, the button on the board is now rather inaccessible – and no, poking it with an Alan key as I had begun doing was never going to be a viable long-term solution. Doing so brought to mind a comparison with nuclear scientists testing the so called “demon core” with a screwdriver, and while my robot probably wasn't going to kill me, my actions could certainly result in damage and/or minor injury – those thrusters are no laughing matter.
Health and Safety Gone Sensible
While it technically would have been possible to design and print some kind of mechanism to enable pressing the button on the board or just wired a new switch to it that was more accessible, the more desirable solution would be to not have to touch the robot at all. Luckily the Pi Zero W has both wifi and Bluetooth capability built in. Since wifi would rely on more external components like a router or access point, and would involve hard-coding an SSID and password (bad practice security-wise, even if it technically doesn't matter here, and also makes the robot less portable) I instead decided to look into the Bluetooth side of things.
I've never developed anything with Bluetooth before and I wanted to learn about it as well as feeling it was probably the most appropriate solution for the situation. I began looking into the docs for Bluetooth from both Pimoroni and the raspberry pi foundation themselves and quickly found references to the aioble library (that stands for All In One Bluetooth Low Energy). Documentation for this library is... okay I guess, there are a few official examples, but in my opinion, they don't make good practices or patterns for more complex applications super clear, and while it was relatively easy to program a way to send a single packet of data from my laptop to the robot to start the program, replacing my start button, once I tried to get telemetry streamed from the robot back to my laptop I began running into problems and cryptic error messages (Seriously guys, how am I supposed to know that [errorno 22] EINVAL means “You tried to publish a notification but the central device wasn't subscribed to the notification channel yet”??!)
In addition to the Bluetooth control, I also added another important safety feature to the robot this week – a small (but very loud at max volume) speaker. This allows the robot to make sounds when it does, or is about to do something so everyone knows to get their fingers out of the way before it accelerates. I also added some sounds which are helpful for development too, giving me vital information about the robot's state without having to have a USB cable attached. Currently I've implemented sounds for the following events: – Power up – Bluetooth connected – Bluetooth disconnected – About to move – Stopped
Here's a video demonstrating the wireless Bluetooth control and the speaker sounds
So What About the Control Algorithm?
So the algorithm that sits at the center of everything still hasn't really been implemented or tested. The events of this week have definitely been needed to get me there though, getting remote telemetry from the robot is especially important for helping to tune the algorithm once it's actually making the robot move.
As for the algorithm, or should I say algorithms, themselves though, I've locked in on a class of algorithm called a Kalman Filter. This is a sensor fusion/localisation algorithm that should tell the robot where it is along the track. How I translate that into thrust values for the fans though, is definitely still TBD and requires more research, but I do feel confident I'll figure it out soon, especially when looking back at how much progress this project has made in the last 2 weeks.
