Project Hub
Making things is really fun. I’m excited to share some of my creations on GitHub. Now to be fair, the term ‘IoT’ is more narrowly used for small devices that interact with the physical world and communicate with the cloud. I’m using the term more broadly to encompass any small programmable device that interacts with the physical world.
I have a nice music collection on MediaMonkey that I play over my stereo amp and speakers. Unfortunately the amp was pretty old and produced an annoying hum from the speakers when nothing was playing. This also annoyed my guests. I looked into replacing the suspect electrolytic capacitors in the power supply, but that would have been time consuming. The easiest solution was to turn the amp off. I didn’t want to have to walk over to the amp - I wanted to be able to do that wirelessly. This was my first ESP8266 project.
There are now a number of very cheap commercial solutions. But it’s more fun to DIY, isn’t it?
A friend and I were exploring NeoPixels to create wearable devices with dazzling visual effects. The idea was to control animated visual effects and text messages via a wireless link from a smartphone.
This project is a POC, which allows both WiFi and Bluetooth connectivity. It’s also got an object oriented framework to easily plugin custom animations.
I’d seen a lot of Stack Overflow posts about how to detect if the smart phone was being shaken. Most of the solutions proposed ad-hoc heuristics like integrating the accelerometer output and threshold detection. I figured, wouldn’t this be simpler to solve using signal processing. What the problem really boiled down to was whether the accelerometer signal was around 2 Hz.
The approach I took was a digital recursive band-pass filter to detect spectral energy near the “shake” frequency. The resulting code is very simple, thanks to a bit of signal processing engineering.
I have adopted test-driven development as an essential practice for developing clean, flexible code. After an initial experience with JUnit, I have successfuly used it with other languages as well. Here are some projects and katas where I explored different testing techniques in different languages.
In another one of my projects, I wanted to use a GIF decoder in a low-power, constrained MCU. I think that a GIF decoder is not only non-trivial, but in the case of an MCU, it would call for some optimizations. Having solid unit tests would make such optimizations far easier. And to pile on a bit more challenge, I wanted to try out “comprehensible testing”, something I’d learned in the Etappe project.
This project is in C, but I didn’t want to use the gtest framework I’d used earlier. I wanted to use a C/C++ framework in line with “rspec” which would produce a much more readable test report than gtest or xunit. I found “ccspec” and have give that a try.
The project is not yet completed, but the results are very promising.
Can IoT applications be developed with TDD? Of course they can! This was a simple POC, but it illustrates how the hardware can be mocked.
I wanted to learn about HATEOS and found a nice little kata. This explores doing TDD with JavaScript, NodeJS, and Mocha.
On occasion, I have opportunities to do some programming in Perl. I’ve usually done TDD with Java and JS, so this was a way to learn how to do it in Perl. It wasn’t too hard to do, although I’m more comfortable with tests based on JUnit, RSpec, Jasmine, etc.
I came across the Boggle kata during some interviewing. It is a challenging puzzle and I wanted to make sure I could master it.
Classic game developed with TDD. Yeah!
I have an interest in developing web applications that run within a browser and use web services as a backend. These are typically single-page apps (SPAs) that afford navigation without reloading the web page.
This app was inspired by a particular public transit commute I was taking. It was a two-leg trip, but the waypoint between the “etappe” or stages was a rather unsavory location. I wanted to use a strategy to minimize the time I had to wait there. Consequently, I developed an SPA (single page application) that used the public MUNI and BART APIs to help me optimize this. The first version was rather crude. It was written in JavaScript with JQuery. Its was however, my first dive into mashing up APIs and dealing with asynchronous programming.
The second version uses AngularJS and TDD. There is both unit testing with Karma and integration testing with Protractor. I also used the handy Mountebank “imposter” technique to provide API test fixtures for the integration tests.
Here are some Java projects.
Some time ago I was looking into content management systems. JCR was an interesting one. There were some existing GUIs, but I thought I could do better. This is partially working and sketches out a few ways to navigate JCR with a Swing TreeView.
Software that interacts with the physical world is a strong interest of mine. Here are some projects in that regard.
I picked up a cheap wheeled, battery powered chassis, Raspberry Pi Zero W, RPI camera, PWM motor driver, and servo-controlled arm. Along the way I also started using Yocto to build the Raspberry Pi Linux image. It’s a bit ambitious, to say the least. But someday I’ll get it to roam my rooms autonomously.
The goal is a ready to run Linux SD card with Bluetooth, WiFi, and other robotic support software. I developed this in a VirtualBox VM that is provisioned from scratch via Vagrant. The source code is on the host operating system so I can use my handy IDE for development and debugging. I wrote a custom Python script to assemble the Yocto output onto the SD card.
Lately, I’ve focused on operating the two-axis servo arm via the acceleratometer in my phone.
My first Arduino project from a few years back was designed to control an N scale model railroad. Not content with a “boring” circular track, I extended it with a wye so that the train could be turned around. This added the challenge of sensing the train’s location, sequencing the positions of the turnouts, and controlling the polarity of two isolated track sections.
The hardware controller is based on an Arduino Mega2560, a PWM motor control shield, and CdS photoresistors. I also built a custom board that uses solid state relays (SSRs) to control the 12 VAC turnout relays without burning out the Arduino.
After some prototyping, I developed the controller software in C++. Some of the interesting challenges were the state machine for various scenarios, a driver for the motor shield and a driver for the turnouts. The latter was very interesting because it involved a multiplexer, queue, and timing safety to prevent damage to the turnout relays.