I’ve previously written about the Roominator, my project for combating conference room hijacking. In the end, it didn’t work 100%, which was disappointing. However, I learned a lot in the process, both about how to architect a system like this and about doing design projects like this one in general. I think that this project deserves a proper post-mortem so I can share some of the insights I gained.
What went well
Dumb displays, smart application server
Right from the start, we decided we were going to put most of the actual logic in an application server written in a high-level language like Java or Ruby. Even so, it took us a while to embrace this concept fully. As developers who mostly work in high-level languages, we went down the road of making lots of little classes and interfaces in the display code that proved to be distracting overkill.
Once we got past that problem, though, we ended up with our displays doing basically nothing but showing exactly what the app server told them to. This freed us from writing complicated Arduino code for things like what to print on the display and instead focus on the crucial components – communicating with the app server and making it easy to configure the display on startup.
DIY Power over Ethernet
Of all the things that could have gone wrong with this project, our power distribution strategy turned out not to be one of them. Admittedly, it’s a bit basic, but it turns out that sending 12V out over the unused pairs in an Ethernet cable and then knocking it down to 5V in the display unit worked fine. I would however probably add some fuses and protection diodes to each port so that it’s harder to accidentally fry some part of the system.
Professionally produced PCBs are a huge productivity booster
During the first week we worked on the Roominator, I spent at least 20 painstaking hours hand-soldering the circuitry of two display units. Only two! There were just too many connections – and opportunities to make mistakes – for it to be sane to do any more like that.
Before the second hack week, I had the sense to order some professionally-produced PCBs of our circuit, and the difference in productivity was unbelievable. Two of us assembled the remaining 10 displays in one day! And only one or two of them required any rework.
Getting PCBs made can seem kind of daunting when you are starting out, but once you learn your way around Eagle, you can easily get boards produced by BatchPCB or Seeed Studio. Particularly with Seeed Studio’s pricing, I think the threshold of when you should opt for professional boards is pretty low.
What went poorly
I2C over long range
Early on in the planning for the project, I decided to use I2C for the communication between the display units and the central master. Despite the fact that this protocol is built into Arduino devices, this proved to be a bad choice for a number of reasons.
The other problem with using I2C in this fashion is that it’s a truly shared bus, and if one of the nodes had weird behavior, it ends up blocking the whole bus. In practice this meant that the whole system kept working great until I plugged in the one unit that was too far away from the rest and the whole system crashed to a halt. For projects where all the parts connected by I2C are really one logical device, this is OK, since you can tightly control for issues like cable length. But for systems that are distributed over a wide physical range, there are much better tools for the job.
Focusing on the wrong costs
Aside from purely technical mistakes, the overall biggest mistake I made in developing the Roominator was being too focused on the wrong costs in the project. From the get-go, I was very interested in keeping the cost of parts for each individual display unit down as low as possible, since we were eventually planning to multiply the whole thing by 12. I gave myself a target price of $50 each, which I thought was achievable. And my initial design and research led me to believe this was possible.
This reasoning can be extended to a lot of the decisions in this project. I was concerned that display unit PCBs were too expensive (at around $25 for the two prototypes) and so I only bought them after I made the first two by hand. In retrospect, I could have ordered them early, learned firsthand whether they were flawed, and then ordered more, saving me hours and hours of work. Another thing I could have done would have been to use plain old 5-12V wall warts to power the display units instead of doing pseudo-PoE, obviating the master unit altogether.
As dismayed as I am that the system wasn’t a complete success at the end of the project, I am pretty pleased that there was such a general lesson to be learned from it. To restate it another way, when designing products at this stage, you should make design decisions that allow you to focus on the important parts first, and the unimportant parts later, if at all.
Bryan Duxbury's Blog 