While creating an Arduino-based art project, Guido Bonelli realized there was a need for a special test shield to help debug his system. A Kickstarter project was born.
Almost a year ago, I was shopping for a unique piece of artwork for a main feature wall of my new home. Unfortunately, the closest I could come to "unique" was something from a box store that was, well, not that unique. In fact, there were probably thousands of these pieces in homes throughout the world. "Well, that's not very special," I thought. At that very moment, I decided I wanted to make something that was truly one of a kind -- something that would invoke a feeling of "Wow! What is that?"
I wanted something very abstract that would be a talking piece for my guests. I've always had a fascination with clocks, especially mechanical ones, so I knew my creation had to move. Also, as an engineer, I've always been fascinated with lights, so LEDs were a must-have. But there was still something missing -- something that I wouldn't realize until I was almost done creating the piece.
Armed with my 3D rendering program and MakerBot Replicator 1, I began to make countless variants of a spinning artwork. I wanted an exposed cog that would indirectly drive multiple rings. This piece also had to encompass my love of trees. After months of toiling, my amazing kinetic artwork, Orbis, was ready for fabrication. I used Pololu's wood-cutting service to have all the pieces made. I worked for weeks, carefully staining each piece.
When things finally started coming together, I thought, "I better get moving on the electronics." As someone who has a BSEE an MS in software engineering and who has worked in the industry for more than 15 years, I began to look at the plethora of random kits I've accumulated, each with a promise of "I'm easy to use, so use me, use me." But I realized that each of them had some shortfall, whether it was poor tools, a lack of certain hardware features, or the fact that it simply didn't work. In each case, something screamed quite contrary to the vendor's claims.
Then I remembered all those Arduino articles I've read. So I ordered my first Arduino kit. Much to my surprise, it was as the vendor suggested -- easy to use, fun to play with, and (most importantly) hassle free.
I dug right in with the exuberance of a child on Christmas morning. Within minutes, I had the compiler running and a LED blinking. If I had done this with any of my other tools, forget it. Installing the compiler alone would have taken hours. What a great platform. Over the course of the next few weeks, I began to write increasingly complex code. Arduino effortlessly swept away my ones and zeros into a delicately balanced light show, which Orbis now proudly displays.
I then moved on to the motor control section. Once again, with minimal effort, I had my pancake motor whirling away. I stood in awe of my creation, which had come out exactly as I had envisioned it.
At this very moment, it struck me that I was missing a key element. How should I control it? This was a classic what-if moment that all makers have when a new idea paralyzes their being. What if Orbis had an equally unique controller that I could hand to my guests -- something that would allow them to interact with her. Wouldn't that be cool?
I anxiously ran back to my desk to design a controller that had the look and feel of a past era meshed with modern times. A phone dialer was a must. Some knobs and switches would be equally important. But how was I going to communicate with Orbis from the control box? An ugly wire simply wouldn't do, but WiFi seemed to be a bit of an overkill, especially if my network ID changed. Thus it was that I opted for XBee.
As I began to write the code and verify the interactions, I realized that testing Arduino projects was not quite as effortless as one might hope. My ones and zeros were caught in a menagerie of tangled wires. The only way to set them free was to assault my tower of shields with an arsenal of invasive tools, including my DMM, oscilloscope, and RS-232 shield. But where and how was I going to connect this to my equally unique hardware?
Any time I needed to hook up a probe to my megalithic tower, I was forced to mutilate one of my precious resistors. I would rip away a limb and shove it into my Arduino stack, only to discard it when my test was complete. Then and only then could I connect my probe to my board. Over and over this situation would occur. The familiar rant: "There must be a better way," came ushering over me.
To Page 2 >
Once more a mental flash occurred, and I was paralyzed as I stared into my mind's eye. I needed a way to test my project with another type of shield. Then, at what seemed like the speed of light, various designs of what this test board might look like flurried before me. I quickly created and recreated various mental incarnations until -- there it was -- a test board I could connect to my Arduino project without getting in the way of the project itself.
I stood there for a moment to let the euphoric moment set in. "First, let's finish Orbis," I thought, "and then I'll move on to my test shield." And finish Orbis I did, as you can see in this video showing the movement and this video demonstrating the color-changing capabilities. I am very proud to say that she will be on exhibit at this year's Maker Faire Sept. 20-21 in New York.
Once I'd finished Orbis, I had to start on my test shield idea. It seemed like such a valuable tool for both novice and expert Arduino users. I simply had to create it. I took this time to update my PCB layout skills and tasked myself with learning KiCad. What a breath of fresh air this software suite is as compared to those other guys that tie you down to their artwork-locked tools. So simple, so elegant -- thank you, KiCad.
I wanted to address every pain point I had noticed while working on Orbis. First and foremost would be test points for my probes. This is sorely lacking in traditional Arduino environments, so I added ample ground points, 5V and 3V points, and monitoring points.
My next pain point was the infamous reset button, or lack thereof. As soon as my other shields were stacked on top of my Arduino board, the original reset button was never to be seen again. The only way I could access it was to sneak up on it with a pair of pliers and ever so gingerly press it without mistakenly hitting something else and/or shorting out my power rails. I made sure to include a reset button on the periphery of my board -- easily accessible and never to be hidden again.
Next was RS-232 and the use of external shields to gain access to my coms port. If you are anything like me, RS-232 dyslexia is a strong force indeed. It was a syndrome which I knew I had to cure, so adding RS-232 directly on to my test board was a no-brainer. I also wanted to make the process of testing initial coms items as effortless as Arduino makes programming, so allowing the user to perform simple loop back testing was a must.
At one point while I was developing Orbis, my control board and remote box were separated by a large enough distance that I could attach a probe and make code changes on the fly only if my arms were the length of a three-toed pigeon sloth. "Hmm," I thought, "maybe if I could hear a beep or something, I would know if my input signal is active or not." Hence, a piezo buzzer appeared on my must-have list.
During every maker's journey of creating some form of self-replicating, doodling, electro-bot widget, there inevitably comes a time when a switch breaks or a LED burns out. If it's not one thing, it's another. What if you don't happen to have a spare switch or LED lying around? I wanted to provide a mechanism that would allow for pseudo hardware to always be available. The next time anything like this happened, I wanted to be ready simply to add a switch or a LED and be up and running.
Returning to my Orbis project -- this is equipped with several potentiometers, which allow the user to do things like control the color of the tree and the speed of the motor. While I was debugging my code, it became apparent that something just wasn't reading correctly. I wanted a sanity check to check against a known voltage and potentiometer value. Unfortunately, I didn't have that capability at the time, but this led to my decision to equip my test shield with a number of potentiometers that could be injected directly into the micro, thereby alleviating the need for me to pull out the last of my golden locks.
To Page 3 >
My main gripe with debugging Arduino was related to the feature that makes Arduino development so effortless in the first place -- the stacking of shields on top of one another. The pain in this scenario was twofold.
- When I wanted to test something on my last stacked shield, I still had no way of attaching my oscilloscope's ground probe and the probe itself. I wanted a convenient way to do so on my test shield. however, I also wanted to ensure that my test shield would not block access to the board underneath it. This led my designing a large hole in the center of my test shield, as shown in the image below.
- You know the drill... You've got three stacked shields. Something is wrong on shield No. 2, but you need shield No. 3 in place in order to debug it. So you unstack, swap, and restack your shields for the quinbillionth time (don't bend that pin now), tack on your probe, etc., etc. I wanted things to be easier. I wanted my test shield to be able to be sandwiched in between the two shields of interest. Then, with a simple jumper setting, I wanted to be able to break the connection between the board above and the one below. This would allow me to determine whether I had a hardware or firmware problem. This led to yet another eureka moment: What if I could provide the ability, not only to break the signal path, but also to reroute and interface to it? This would mean that, with a simple jumper setting, the user could switch between routing the signal up to the shield above or out to any of the LEDs, switches, piezo buzzer, potentiometer, RS-232, or other elements on the test shield. This truly would me my test shield's most powerful feature.
The end result is shown below. In this case, we see my test shield sitting directly on top of an Arduino Uno. Observe the large hole in the middle of my test shield providing access to the board below (the Arduino, in this case).
As you can imagine, I was very enthused by this idea. After constructing a prototype for myself, I decided to launch a Kickstarter project, so I could share my test shield with other enthusiasts. I started preparing my Kickstarter launch, working on my website, writing text, and making videos, but something just didn't sit right. My original name for my test shield simply didn't work; Testy Shield just didn't roll off the tongue. The lack of a good name was blocking my creative processes. I needed something that would evoke what the board does -- something clever and to the point. I began to think: "What does this board do?" Well, it helps developers by providing diagnoses about the problem -- kind of like a doctor. Finally, a name I could be proud of -- Dr. Duino was born. It's like a doctor shield for your shields.
As you will see from my Dr. Duino Kickstarter project, which launched today, Dr. Duino helps you debug your projects with an arsenal of tools that can be deployed at a moment's notice. It comes complete with test points, RS-232, LEDs, switches, potentiometers, piezo buzzer, and an external reset switch that will not be blocked by any shields above it.
Dr. Duino is ready to help any Arduino user debug a project. Any shield that uses the standard Arduino Uno footprint can benefit, including the chipKIT Uno32 from Digilent. As you can imagine, this has taken a lot of work. I'd very much like to hear your comments and questions, and I'd very much appreciate your spreading the word about my Kickstarter project.