Transforming a box of Lego into a CI build monitoring robot
A story of CI build monitoring and creativity at play.
Background
Ten years ago, I had an idea. I wanted to use a Lego Mindstorms NXT 2.0 kit to build a robot that could continuously monitor our software development builds. The following is the story of what happened and how things worked out. Along the journey there were failures, successes, lessons learned and a lot of joy and smiles.
Who is responsible for monitoring broken builds?
When a software development build breaks, who is responsible? The obvious answer is the developer who broke the build. Another answer is the entire development team. Who is responsible for letting the team know that the build is broken? One answer to this question has been to use “automation” to shorten the feedback loop. Continuous Integration (CI) builds run any time a commit is merged to the main branch or on merge quests. When these builds break, how does the team discover that a break has happened? The team would need to continuously monitor the build to know that something has happened.
Some development teams use visual and visible cues to keep the team alerted to problems in the build. These visible cues include solutions like attaching large build monitors to shared wall spaces where the team can look to see the current status of important builds. The problem with a build monitor is that it requires line of sight for all team members. I once sat in a team space where a build monitor was located in an office window right behind the cubicle I was sitting in. So if the build broke, I wouldn’t know, as my back was facing the monitor.
There are other options like using a Build Light Indicator of some sort. All the options I had researched suffered from two problems — requiring line of sight or requiring a physical hardware connection. The reason a physical hardware connection was a problem was because the USB ports on all of our machines at work were disabled due to security policies. We couldn’t plug in a lava lamp or any other light indicator.
I had this crazy idea that my team could build a robot to monitor our builds. The robot would have to look at a screen and alert us when the build breaks. I went to my nearest Lego store and bought a Lego Mindstorms NXT 2.0 kit.
Team Building Exercise
I initially thought that building a Lego Mindstorms robot would be a good team building exercise. Things did not go exactly as I expected. My team started out attempting to build the Lego Mindstorms standard Shooterbot design during some lunch time meetings. We ordered take out food so we could multitask and eat while we built. The first thing I learned was not to mix lunch and lego building. We did have fun eating lunch and even made it through a few pages of the lego building instructions, but it was clear that it was going to take many meetings to finish the robot at this pace.
I decided there was an easier way forward.
I asked my seven year old son if he would like to build the robot at home. Lego Robot + Seven Year Old = Yes. He was finished with the standard build for the Shooterbot in two and a half hours. I brought the finished robot to work and began working out how we could get the robot to monitor the build.
Vision for my vision
I originally had planned to use the Lego Mindstorms Color Sensor to detect color changes on a screen. Unfortunately, the Color Sensor could only really detect colors printed on some solid surface like paper. I tested out the sensor on different monitors, and it wouldn’t work.
I did some research and discovered there was a third party sensor market for Lego Mindstorms. There was a Vision Subsystem option for the NXT 2.0. So I spent some more money and bought the Vision Subsystem and hoped it would work. It worked great.
From Visual Programming to Java
Now I needed to program the robot. At first, I experimented with the visual programming environment that came with the Lego Kit. I was able to control a lot of the sensors and make the robot move, but for more complex tasks it felt like a non-visual programming environment would be a much more productive option. After a bit of searching I discovered the leJOS JVM that could be loaded on the Lego brick and would allow Java code to control the robot.
A member of my team at the time (Craig Motlin) wrote around three hundred lines of Java code to keep the robot continuously monitoring our builds. It was a lot of fun seeing the robot shooting plastic balls when it detected red builds on the screen of my MacBook Air.
Bang a Gong!
Now we had a shooter robot that could detect build failures as well as build success and shoot plastic balls out at high velocity. It was great fun to watch, but was missing a key component that I was looking for. An audible alarm to go along with the visual and physical queues that a build was broken. I was sitting at home one night puzzling about what we could do to have the shooter robot make a noise that could be heard all around a floor.
Then it hit me. Sitting on my desk was a Feng Shui Desktop Gong that my kids had bought me. Along with the gong came a little mallet with a plastic ball attached to the end that was the same size as the plastic balls that the shooter robot was loaded with. Light bulb!
The noise that the gong made when the shooter robot shot the plastic ball and struck the metal gong was loud and piercing. It was so loud and piercing it could be heard all over a huge and noisy exhibit floor at a conference (spoiler alert!).
Measuring Success in Smiles
For a few years, BilBo the Build Bot was one of the simplest and most smile inducing demos around. BilBo had one clear Key Performance Indicator (KPI) — Smiles.
Anyone who saw BilBo when visiting or walking by our team area asked for a demo. Each demo took less than 30 seconds after the Lego brick was powered up, or 5–10 seconds if it was already running.
Power Failure
One problem that persisted with Bilbo was that it was powered by four AA batteries, which had a lifespan of several hours if left running. I did some research on a persistent power source for BilBo but was unable to find anything that I thought would work. It turns out the BilBo demos were so amazingly popular, it wasn’t so terrible that we couldn’t find a persistent power source option. We were able to generate hundreds of smiles using just four AA batteries at a time.
BilBo at JavaOne 2014
In 2014, I brought BilBo to San Francisco with me to demo at a booth that my former employer had at JavaOne. BilBo was running Java on the brick so was a great demo at the conference.
Only the Beginning
Nikhil Nanivadekar would attend his first JavaOne in 2015. He would later evolve the shooter robot idea and turn it into another smile inducing demo with two Twitter controlled robots at JavaOne 2016. Nikhil was building using the upgraded Lego Mindstorms EV3 kit. We would give a talk twice at JavaOne 2016 titled “Robots for the Kind in All of Us”. There were many more smiles measured.
For JavaOne 2017, Nikhil would build a small army of standing shooter robots that would take aim at six of the Desktop Gongs.
The robots were amazing, but it was arguably the gong that was the key to success for all of the demos. The gong gave the robots a goal to achieve, and an audible way to make people smile. Anyone who witnessed the demo, knew immediately on the exhibit floor, regardless of where they were at the time, what was happening when they heard the gongs — robots were banging gongs and making people smile. Just hearing the noise would make folks who were “in the know” smile :)
I hope this blog inspires some great ideas that brings more smiles to the world.
Thank you for reading, and hopefully smiling! :)
I am a Project Lead and Committer for the Eclipse Collections OSS project at the Eclipse Foundation. Eclipse Collections is open for contributions. If you like the library, you can let us know by starring it on GitHub.
