Hardware Mash-ups and Bug Lab's Bug

A Java-programmable electronic base with various I/O ports


August 27, 2008
URL:http://www.drdobbs.com/architecture-and-design/hardware-mash-ups-and-bug-labs-bug/210201098

Mike is a contributing editor to Dr. Dobb's Journal. He can be contacted at [email protected]


Being a child in the '60s, one of my favorite toys was Mattel's Thing Maker. If you're too young to have experienced the perilous thrill of creating a collection of plastic bugs by heating a colorful substance the Mattel designers playfully called "Goop" poured into metal molds baked on a potentially skin bubbling electric griddle, the creation process was far more satisfying than the final product. This dangerous aspect was actually part of the product's appeal; if you weren't careful, you could get badly burned. What also made the Thing Maker so fascinating was its ability to pour different color goop into different bug parts to ultimately create a unique mixture that satisfied an intrinsic inventive need. While the end product provided passing interest to friends and family, the reward was almost entirely realized during the creative phase.

That sense of joyful wonder, playful construction and even sense of danger was resurrected both literally and metaphorically when I began exploring the learning potential of Bug Labs' BUG -- an open embedded Linux-based combination of a BUGbase and four BUGmodules.

The BUGbase is a Java-programmable electronic base with various I/O ports: MicroUSB storage slot, 2-line LCD display, buttons, a 4-way joypad and four large interfaces (two each on the top and bottom) for Bug Labs' variety of BUGmodules. BUGmodules are individual modules that supply additional functionality to the BUGbase. Four BUGmodules currently exist:

A much needed WiFi module is in the works, but no release date was available at this time. An active thread of BUGmodule ideas ranging from cell radios to infrared modules can be followed at buglabs.ideascale.com/ . While each of these components can be purchased separately, the best way to experience the BUG is to obtain the combined BUGbundle. This is the edition I reviewed.

Bug Labs adopted the Apple packaging experience philosophy, as the BUGbundle is boxed in a sturdy, attractive, and innovative geometric design that folds out to reveal a snugly seated BUGbase and four BUGmodules along with a thick 4-color card stock deck mapping the hardware and prompting new owners to follow the software download and installation steps at www.buglabs.net/start. You can check out the BUGbundle un-boxing in this video.

Setup instructions are available for each of the the Linux, Mac OS X, and Windows platforms. This is because the BUG SDK (appropriately named "Dragonfly") is an Eclipse Perspective and, as such, can run within the same operating system environments that can host the Eclipse IDE. This software distribution decision lets Bug Labs continually iterate on the evolving Dragonfly software without the added expense of stale CD-ROMs and ensures that its customers are obtaining the latest bits to interact with the device.

After considering the different OS platforms to plug the BUGbase into, I opted to use OSX 10.4 as it required the least amount of prep work and, unlike the other platforms, it didn't require any additional software driver installations. This is not the case on other operating systems, including OSX 10.5, because of the need to install a USB networking driver to talk to the BUGbase's private network address of 10.10.10.10. Once the USB configuration has been set up, plugging in the BUGbase using the supplied USB cable and telnet'ing or secure shelling to its address verifies that it is ready to accept Dragonfly-constructed applications.

Unpacking, downloading, installing, and configuring application and device dependencies took me about 20 minutes although this setup time may take longer for those who don't already have the latest Eclipse IDE downloaded and configured on their computer.

Building a BUG App

With the BUGbase and respective BUGmodules connected and the Dragonfly perspective running, I was finally ready to see what the BUG could do. One of the panes in the Dragonfly perspective features a list of the most recent 15 applications submitted by members of the BUG developer community. Unfortunately, this pane is not integrated yet with the ability to click on a desired application and have it download and configure itself within Eclipse. Instead, I had to open a separate browser, navigate to the respective application's hosting page, download the respective jar file, switch back to Eclipse, create a new project, import the jar file contents and execute the code.

[Click image to view at full size]
The Eclipse-hosted Dragonfly Perspective

Like other Eclipse embedded device perspectives, Dragonfly prompts for program execution in a BUGbundle emulator or on the BUGbase itself. The inclusion of the emulator and the open source, freely accessible nature of these BUG development tools lets interested users test drive a virtual BUG while simultaneously developing and even uploading their own BUG programs to the BUG community website. As for the existing BUG programs available at the time of this review, most of them were small and briefly interesting, typically highlighting a BUGbase feature such as manipulating its display, reacting to button presses or interacting with the BUGmodules via simple I/O or data collection. Beyond a few novelties such as a GPS alarm clock or a motion detecting camera program, very few were actually productive programs that might excite non-technical users.

One of the most significant limiting factors to building really compelling BUG applications is its current requirement to be tethered to a USB network-enabled computer for any network communication. It's a major oversight that Bug Labs could have avoided if it had simply included a simple WiFi radio chip into the BUGbase. While existing BUGmodules can be used for data collection, display and the BUGbase microSD slot can be used for additional data storage beyond its primary function of hosting a copy of the kernel and the device's root file system, the lack of wireless communication deflated my enthusiasm and severely constrained a number of programming ideas for what I wanted this first generation model BUG to do.

Lack of an existing wireless network BUGmodule notwithstanding, there were still plenty of ideas to explore and many prototypes of the most obvious concepts have already been submitted to the BUG community website. Due to time and resource constraints, most of these concepts are very brief demos or skeletons upon which future features have yet to be fleshed out. The demos also provide ample code examples upon which to learn and start exploring the Java libraries that interface with the various modules. For example, collecting position data from the BUGlocate GPS module would have been a time consuming effort had it not been for the sample code supplied by early adventurers. As a consequence of the fast track evolution of the BUG by the small but very passionate and seemingly always working Bug Labs engineers coupled with the fact that like any start-up, objectives and resources have to be prioritized to survive, comprehensive developer documentation is a work in progress. This makes finding the right answers a time consuming search through the BUG community forums and Wikis or sometimes even an IRC conversation with one of the dedicated Bug Labs engineers. Compounding the problem of a stable SDK is the fact that the BUG kernel is also changing at a rapid pace with bug fixing efforts, surpassing limitations and generally smoothing out the product's rough edges.

BUG Bugs

It should come as no surprise that a product design as ambitious and complex as the BUG, developed under the tight constraints of a start-up budget and time to market pressures, that Bug Labs has shipped the product in a bleeding edge developmental state. For Bug Labs early adopter market, these problems are part of the compromise of having access to such innovation. As such, any developer seriously considering a BUG investment should be prepared to replace the BUG's kernel and root filesystem when applications accidentally bork the device. Unlike consumer-oriented products like the Asus eeePC, there does not yet exist an easy way to restore the BUG in the event of a system crash or corrupt file. The BUG forums are peppered with stories of flustered customers left with wonky systems after a few days of development. I encountered a serious problem after running an application that hosed the BUGview display, requiring a re-formatting of the BUG's MMC storage card and subsequent re-installation of the unit's kernel and file system. This was not a trivial task but fortunately the Bug Labs engineers were available to help me restore the device to working condition. The problem actually turned out to be a hardware related issue, but the exercise of upgrading the BUG to the latest revision was apprehensively educational.

Bugs also exist in the Dragonfly SDK, with one of the more annoying issues in the build I reviewed being the inability to delete a BUG application jar from the device even though a menu prompt offers the option to do so. Until this menu item placeholder has working code behind it, application jars must be manually deleted by telnet'ing or ssh'ing into the BUGbase as root and deleting the respective jar(s) location in the /opt/concierge/apps/ directory. Finally, there were discrepancies between the Virtual BUG emulator and the Real BUG device. What ran successfully in the emulator didn't always identically translate to the BUGbase, especially those employing the BUGview. After a while, I stopped using the Virtual BUG emulator and dumped my applications directly to the BUGbase for an accurate rendition of my programs.

Finally, the BUGbase connection had an annoying aspect of creating a new Ehternet connection with my OSX 10.4 system each time I connected the device to the computer. By the end of this review, I had over 20 Ethernet configurations, 19 of which were disabled. Again, the never-sleeping Bug Labs engineers came to the rescue with a MAC address setting shell script (emailed to me on a Sunday morning!) that eradicated the issue.

More To Come

While working with the Bug Labs engineers toward restoring my BUGbase to the latest build, they shared with me the news that they were working on a new upgrade using an entirely different Linux distribution. The R1.2 release is based on a LTIB root filesystem. The new R1.3 kernel is migrating to Poky Linux. This new Linux distro will greatly expand the system applications thanks to Poky's superior build system supporting more up-to-date application packages. This update will effectively turn the BUG into a mini-PC of sorts with the possibility of hosting scripting languages like Perl, Python, and Ruby. More importantly, the upgrade will offer better networking, support for WiFi and the new WiFi module, more robust OS and recovery modes and more.

Conclusion

The BUG is a work in progress, and that's one of its appealing aspects. There are no pretentious claims by the company that their product is designed for rock solid 'stake your business reputation' on this product's stability. Rather, it is for the tinker, the educator and the programmer looking for a modular playground to build, experiment and explore.

Early adopters may be agitated by the device's limitations and first generation flakiness, but the sense of close knit community coupled with the adventure of innovation balance out the frustration and anxiety associated with unknown territory. The less patient developer should wait until the re-engineered R1.3 release with its promise of wireless networking and greatly expanded programming flexibility beyond the Java language.

The other more obvious consideration toward the purchase of the BUGbundle is its price. At over $600 for this first generation model, skeptics can successfully debate that a sophisticated, programmable smartphone containing all the features of the BUGbundle could be purchased for much less and could immediately benefit from wireless networking and a robust development environment. However, this obviates the central tenant of the Bug Labs objective of interchangeable building modules based on an open design, allowing the mix and match of PC card-slot style functionality in a mobile device. Until the arrival of Android and OpenMoko phones, most smartphones like the Apple iPhone and Microsoft Windows Mobile platforms require proprietary lock-in development languages and environments that are more geared toward structured commerce than playful experimentation.

In its current state, the most satisfied customers of the BUG will be the gadget tinkering developer and the introductory computer science education markets. Bleeding edge developers who risk navigating the BUG's sharp edges may discover buried treasure within the product's modular approach.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.