Forewarning: this is going to be a rather rambling look at the robotics stuff I did back in the early 2000s. If you need to read something with an explicit point, then you might want to skip this.
Back when I was in middle school, I got gifted a set of LEGO Mindstorms (the original ones with the big yellow control brick). If you’ve never used them or their successors, they were a pretty groundbreaking piece of tech. You not only had a set of easy to use sensors and motors with standardized connectors, you also had software which made it easy to program (using a visual programming language similar to Scratch). LEGO eventually even released SDK 2.0 that allowed you to program in a C-like language (this was a pretty massive improvement for programming complex logic).
My freshman year of high school I found out about a competition called the Trinity College Fire-Fighting Home Robot Contest, held at Trinity College in Hartford, CT. I only ended up competing once, but I built two robots for it, and that’s generally what the rest of this story is about. The gist of the competition is that your robot has to run around a maze, find a candle, and put it out.
The first robot I built was built with LEGO Mindstorms, and I regret that I only have a single picture of it, during the phase where I was building the locomotion setup. That robot was named “Gavin the Destroyer” and it had a tank base, two light sensors that I was using with some IR LEDs to sense distance, a third light sensor for sensing the candle, a fan for blowing out the candle, and a power relay so I could switch between powering the motors and powering the fan. If I can remember correctly, we ended up writing a sweep sampling algorithm where the robot would spin around and sample from the candle-designated light sensor until it got a lower value than the previous, pivot back a tiny bit and then go in that direction, avoiding walls using the IR/light sensor setups at the front. When it found the candle, it would switch the relay and power the fan to blow it out (I had hard-coded a light threshold for this).
It worked great in my basement (where we had a wooden replica of the maze for a while — someone had built it at my school and my friends and I were borrowing it for testing) where the lighting was 60 watt incandescent. Unfortunately, the gymnasium where the contest takes place has terrible lighting that has pretty intense IR output (even worse it has a really ugly flicker too). This basically flooded the light sensors and when we went to do the initial testing/qualification, it just ran straight into a wall and I spent the rest of the contest attempting to get it working to no avail. On the plus side, the person who had inspired me to go to it (his name is Matt) had a ridiculously cool robot that used an OOPIC coupled with an HP Jordana to figure out where it was in the maze and find its way to the candle. I can’t remember if he got it finished/working in time, but it was impressive to say the least. The pic at the top of this paragraph is his robot.
In general, I had found the Mindstorms to be relatively limiting and I wanted to play with harder things/”real” robotics. One of the companies that had a booth at the contest (there were a handful of different companies hawking their robotics bits) was Acroname; based out of Colorado and still in business. They made a board called the Brainstem GP 1.0, which has since been superseded by something significantly more powerful and less janky. The Brainstem is a controller board built around a PIC, some flash memory, and various bits to support the analog and digital IO ports, a GP2D02 IR rangefinder port, the servo ports, serial port, and I2C bus. It has firmware that runs a stack-based VM which makes programming for the chip significantly less horrible than using a raw PIC. It also has configurable interrupts which can run short handlers (called “reflexes”). It was pretty expensive, but the cleanliness of the design and the ease of use (compared to other solutions at the time) made it a huge step up. It is programmed in a C-like language called TEA (or in raw VM assembly). Acroname doesn’t have any of the software packages you need to program this thing on their site anymore. Thankfully, I have a copy of the old linux binaries for it and I managed to scrounge up the reference documentation at another site. I don’t think I’ll ever use it again, but you never know; it’s a really nicely put together board.
At any rate, I got a bunch of parts from them and started learning as much as I could. Eventually, I built a robot that got named “Dora the Explora”. I managed to miss the registration deadline by a couple days the year that I finished it, so I didn’t end up going to the contest. The robot was a “pancake” style robot made of plexiglass. It used a GP2D02 rangefinder to do a left-hand follow of the maze walls and a Hammamatsu flame detector to actually find the candle. The fan mounted on the front was controlled via a relay circuit, and the two powered wheels use free-spinning servos. The general algorithm used was to move along the wall, occasionally scanning for flames and moving toward them. When a certain intensity of flame was detected, the fan would turn on.
The flame detector does a significantly better job at identifying sources of flame due to its sensitivity to a very narrow band of UV radiation instead of infrared. This also makes it immune to the ridiculous lighting conditions in the contest arena. The detector tube itself is basically a discharge tube that has to be operated at around 350-400V. The driver board is a reference design that Hammamatsu manufactured. The board pulls the output high/low momentarily (depending on how it’s wired) when the tube both fires and that signal makes it through the smoothing/filtering logic. To actually use the output, you basically need to count the number of pulses in a given timeframe. This was pretty much trivial to do with the reflexes on the Brainstem. You’d use interrupts on other boards for this same purpose. I don’t currently have any really cool ideas for how to use this sensor, but I’d like to incorporate it in a future project.
This had all happened my junior/senior years of high school and I went to college and haven’t touched my robotics stuff since because I don’t have an interesting enough project to do with them. There’s also much more ridiculously awesome/powerful boards out there these days. I’m currently working on getting back into electronics with a remote sensing/data logging project which I’ll write about once I’ve gotten enough done on it.