Some time ago, I was deep cleaning the house; sifting through a plethora of old boxes which sat untouched for years. Through all this, I uncovered several software projects from my high-school days. So many memories came flooding back. I already wrote about one such project previously: Flappy Muscles, a simple video game which used gym equipment as a controller. It was a project that I did not put much time nor effort into; however, it sparked a surprising amount of intrigue throughout the school on the part of fellow students and teachers alike. I always found this ironic, but it did teach me something: how people respond to your work is reflective of how it impacts them regardless of the amount of effort you put into that work.
Indeed, I do have other projects which I’ve spent a significant amount of time and effort on that hardly went noticed at all outside of a small niche group. Perhaps the best example of such a project is a telemetry system that I developed for my school’s moonbuggy team. From a technical perspective, that telemetry system was an objectively much more impressive project than the Flappy Muscles game. However, few people outside of the moonbuggy team cared about it. That was a shame, but it was very understandable why: it was only meaningfully impactful within the moonbuggy team.
I spent my sophomore year of high school at different school, living in a different state than I did my freshman, junior, and senior years. The reason for this came down to life circumstances that were completely outside of my control; that’s not something to unpack here. This different school did have something awesome that my school back home didn’t have: a so-called “moonbuggy” team. In a nutshell, students from all around the world would build pedal-powered rovers, then meet in Alabama compete on an obstacle course which was designed to simulate the surface of the moon. This competition was hosted by NASA as part of their Human Exploration Rover Challenge, which was designed to commemorate the Apollo moon landings. Of course, the pedal-powered rovers took varying degrees of inspiration from different aspects of the Lunar Roving Vehicle.
Some of the rovers which competed in the challenge were equipped with telemetry systems, normally developed by the students themselves with varying degrees of technical assistance from outside institutions. All of these systems had a similar conceptual layout: data from sensors onboard the rover would be transmitted via a data link to a base station. Although it was a simple layout shared by most of the competing systems, the technical implementations by each team greatly varied.
Our system was relatively basic. On the rover itself, a GPS receiver was connected to an Arduino microcontroller, which then sent the data in packets to a HAM radio transmitter. Our base station was equipped with a HAM radio receiver which fed the data packets into a computer. The data was then displayed on the computer screen. The software which processed and displayed the telemetry data was the most interesting part for me, since it was where one could do so many things with such a minimal amount of raw sensor data.
While I was a part of the moonbuggy team, we participated in two major races: the first in 2014, and the second in 2015. Therefore, in the time between the two races, I did have some time to make improvements to the software. The first version of the software was very barebones. It served mainly as a proof-of-concept for the rest of our telemetry system. It featured only a speedometer and a simple tracemap. Data for both was derived from the GPS receiver mounted on the rover. The software also only had the ability to work with live data; it didn’t have any way to record data nor replay it.
After the first race, we had the whole next year to improve upon this concept and develop something more advanced. In hindsight however, that year actually didn’t give us much time to develop much in terms of hardware. Between day classes and homework, not much time was left over for working on the telemetry system.
Still, on the software side, I had a few new ideas that I wanted to implement. These included graphing the speed and altitude, and 3D tracemap which was rendered using DirectX 9. In addition, it was also capable of recording telemetry data and playing it back.
Although we ultimately stuck to the GPS receiver on our telemetry system, we did also experiment with a couple other types of sensors. One idea we had was to measure the rotational speed of the wheels using an arrangement of a hall-effect sensor and a magnet. This would allow us to measure the rover’s speed and distance travelled. Another of our ideas was to measure drivers’ heart rate. We had simple optical pulse sensors which were designed to connect directly to the analog input pins of an Arduino.
In our experimentation with the other sensors, we had some major issues. The HAM radio-based data link only worked at 1200 baud, so the amount of sensor data we could send was severely limited. The hall-effect sensor and pulse sensors would end up producing more data than the data link could handle. Additionally, we also had trouble getting the sensors to reliably get accurate readings. The hall-effect sensor would often fail to detect the magnet passing over it, which would cause the speed and distance readings to fall short of reality. We also had trouble getting the pulse sensors to stay attached to the drivers’ bodies. Given how much the drivers move around though, that wasn’t surprising. Even when the pulse sensors did stay attached, the amount of motion would interfere with the sensors’ readings, rendering them useless. With the reliability and stability issues we experienced with these other sensors, we decided to simply stick with the GPS receiver.
I was about 16 years old when I developed the telemetry software. Back then, I lacked some very important knowledge about the fundamentals of computer science. As a result, the code I wrote for the telemetry software was very poorly optimized. It worked well enough for the relatively small amount of data that we would need to work with, but it was quite clunky. If I were tasked with developing such telemetry software today, I would approach its development very differently. In the next articles, we’ll dissect the code I wrote all those years ago and talk about some of the lessons learned.