When To Move On

The quest for innovative solutions in robotics sometimes requires taking the painful step of leaving behind familiar technology in favor of new, unproven technology. The hope is that the return on investment of moving forward pays for itself in some combination of new functionality, smaller form factor, less cost, lighter weight, or ease of development. Sometimes this bears out, and sometimes it doesn’t.

For example, I recently moved from a line of microprocessor that I’ve used for years in favor of a new processor with a more powerful architecture. The original microprocessor line hasn’t been upgraded in years, and relative performance just isn’t in line with what’s available on the market today. So far, the cost of moving has been significant, but bearable.

The main issue in working with a new microprocessor, of course, is software. I had to learn several new software tools and the nuances of debugging in a new architecture. In my case, the Achilles heal of the move is the lack of a powerful debugging environment. Instead of breakpoints and register displays, I’m working with LEDs and an interactive terminal. It’s workable, but not as efficient as my old debugger.

Then, there’s the constant temptation to revert to my old platform. For example, my latest project involved interfacing a GPS module with a navigation system. Even though I had the code in a library for my old processor, I spent three days with the new processor. I wrote off the time as a learning experience, but it was tempting to use the old tools just one more time. Of course, I realized that doing so would just prolong my learning time with the new processor. The move paid off. The navigation system has more processing power and better network connectivity than I could have had with my old hardware.

While processor moves are a major commitment in time and resources, sensors, actuators, and other components tend to be no-brainers. As long as the device sports a standard interface, it’s often simply a question of relative cost and performance. For example, I recently made the move from mechanical rotary switches to rotary encoders. I had resisted the move for years, simply because of the software and processing overhead of dealing with an encoder. However, when a recent project required a 12-position rotary switch, it became a question of whether to use a mechanical rotary switch at a dollar per contact versus a rotary encoder at 25 cents per contact. The choice of a rotary encoder was easy, especially given that a dozen units were involved.

Other device moves may be less straightforward. For example, the same project with the rotary switch involved an ultrasonic rangefinder. I’ve been using dual-element rangefinders sold by Acroname ([url=http://www.acroname.com]http://www.acroname.com[/url]) and Parallax ([url=http://www.parallax.com]http://www.parallax.com[/url]) for years, but there simply wasn’t room in the new project for separate transmit and receive elements. Instead, I opted for a single element transceiver to save space and a few grams. The cost involved learning a new detection map. Instead of working intuitively with the sensor layout, I had to refer to the map provided by the rangefinder manufacturer to make certain I didn’t have any blind spots in rangefinder coverage.

The question of whether to stay put or move on to a new technology platform is becoming more frequent, thanks to the increasing number of options in the market. In particular, I’ve been watching the evolution of the Intel Atom Processor ([url=http://www.intel.com/technology/atom]http://www.intel.com/technology/atom[/url]), especially the low power version designed for smartphones and tablets. With up to 1M of cache and 2.13 GHz operation, it certainly blows away my current processor. However, moving to the Atom platform would entail another round of learning the hardware, software tools, and limitations. For now, I’m staying put, simply to avoid the churn. SV