Regular readers may recall my article on BugLabs BUGbase and selected modules which were available at that time. The BUG continues to evolve. Earlier this month, the latest R1.4 build was released, allowing BUG builders to interact with the new BUGsound module among other features.
With the release of the 1.4 build based on the Poky Linux distribution, along with version 188.8.131.52 of the BUG SDK and Eclipse-based Dragonfly development environment, the BugLabs folks are still in the modular system programming game in a serious way. Even with critics like me questioning the longevity and viability of the platform in the face of other more functional Java-based mobile platforms like Google's Android, there's just something about the tinkering aspect the BUG's ala carte modular selection coupled with the dedicated, enthusiastic hobbyist community surrounding the BUG that makes it thrive.
The BUG's kernel and root filesystem have been completely revamped since my previous article. The new system based on Poky delivers not only a much more comprehensive set of Linux command-line utilities and broader Linux module support, but even more sophisticated Linux-compiled applications including full versions of Perl (v5.8), Python (v2.5.2) and Ruby (v1.8.6). Additional programs such as MySQL and even Gnome-based window applications can be installed via the apt-like ipk package installer. And for those using the BUGdisplay module, the new Gnome-based desktop shell with its simple application selector makes using that module much more useful.
In addition to this significant operating system upgrade, Bug Labs has released two more modules: the BUGvonHippel and BUGsound.
The BUGvonHippel module, named after MIT professor Dr. Eric von Hippel (author of the book Democratizing Innovation), exemplifies the open platform nature of the BUGbase by providing an open interface for students, hobbyists and embedded systems engineers to extend the BUGbase with their own electronic designs. This breakout board module includes a female USB 2.0 port that can be used to interface the BUG with keyboards, mice, storage devices and anything else that is USB-based.
Perhaps the most exciting aspect of the BUGvonHippel is the ability to plug in a USB-to-Ethernet adapter and finally connect to the BUG to a direct network connection rather than having to rely on the clunky direct USB-Ethernet bridge interface that required the BUG to be tethered to a network-connected computer for the BUG to perform anything really interesting. Following the instructions that Bug Labs' John Connolly shared with me, I was able to load a Pegasus Ethernet module into the Poky kernel, connect a TRENDnet USB to Ethernet adapter to the connected BUGvonHippel module, set a static IP in the /etc/network/interfaces configuration file, bring up the Ethernet interface and untether for a standalone bug experience.
This not only made the BUG instantly more useful from free-standing computing platform, but also made BUG development via the updated Dragonfly SDK vastly easier. In fact, I could connect to, interrogate and develop BUG applications from several of my networked computers with Eclipse configured with Dragonfly -- very cool!
Taking it to the next level, I then successfully installed the latest stable release of the Django framework (recall that Poky is loaded with a complete install of Python 2.5.2), copied over a couple simple Django web applications (with SQLite-based data stores) that I wrote and they executed flawlessly. While I had hoped that I could control various aspects of the BUG's hardware and attached modules, that unfortunately at this time is not possible. These suspicions were confirmed by my email conversations with John, who wrote:
As it stands now, there is no Dragonfly SDK support for anything but Java. Ambitious users may be able to use our existing libraries (with some work and rewrites, which I'd be happy to support) to make it possible to control the module/Base hardware from outside of Java, but it is not supported out of the box. If you're curious, we're looking at porting JNA (Java Native Access) to Sun's PhoneME vm/classpath, or using existing support with another Java VM/classpath implementation. In essence, this would make it much easier for users to use our native libraries to control their BUG from other languages. Python, Ruby, and I'm sure Perl all have tools for using prebuilt C libraries natively. As of 1.4, the C/C++ shared libraries are crammed up with Java-centric glue, because we used JNI.
In the meantime, I have several ideas on how to circumvent this boundary, though not in a not elegant manner. Essentially, write a small Java application that polls the intended BUGmodule for whatever values/data it collected, dump this at set intervals to a file, then read that file at set intervals from my Python script(s)/Django app for further manipulation and/or browser display. Not the ideal but certainly possible until the Bug Labs development team or a contributor provides some form of direct access.
Of course, while the BUGvonHippel module supplies the ever versatile USB port, it also exposes the BUG to custom electronic interfaces via its two rows of direct female wire connections to the module's circuit board, consisting of power, DAC, ADC, GP I/O, Ground, I2C, I2S and Serial connections. This open configuration could potentially expose the BUG to countless custom electronics projects and device interface configurations for learning labs, hobbyist and prototype projects. Bug Labs also has a video interview with Dr. von Hippel talking about the BUG board named after him, discussing why the BUGvonHippel board is such an an insightful, open design.
BUGsound The BUGsound audio module contains a 20-mm speaker and omindirectional microphone with built-in hardware stereo codecs and input, output, headphone and microphone standard 3.5mm jacks along the side of the module. Additional technical details about this module can be found on the Bug Labs website.
I had big hopes for this module with the thought of being able to transform the BUG into an MP3 player and, with its newly capable free-standing network capability courtesy of the BUGvonHippel module, a networked media player. Unfortunately at this time, this module's (and quite honestly, most of the BUG modules) documentation is extremely sparse. Bug Labs currently relies on its concept/prototype applications on its Community Applications site (directly accessible within the Dragonfly perspective in the Eclipse IDE) such as this AudioEventTester application to demonstrate this and other modules as well as document the module's function calls via the raw source code provided in these projects. While uber-techies will be able to tease out the essentials from these minimal efforts, formal, comprehensive documentation for the entire BUG line is a requirement before the BUG can be comfortably incorporated into a broader developer community. Certainly the online support and community forums are helpful, but nothing beats solid, up-to-date and exhaustive as possible documentation for deep hardware and software exploration. Like the BUGvonHippel, Bug Labs has a brief video about the BUGsound module that does little more than reiterate the module's features but, like the BUGvonHippel video, does not actually show the module executing these features.
Where's the WiFi?
As of this writing, there has yet to be a WiFi-based BUG module released. However, according to Bug Lab's Mehrshad Mansouri in this BUG Community forum thread, "We're working on a wi-fi enabled BUGbase and we plan to release it within the next few months, and we will be shipping the BUGwifi module within the next few weeks."
More On the BUG
I enjoyed this piece on the BUG on Dr. Dobb's. I'm a BUG enthusiast, but (as you can tell from my email address) also a part-time consultant for Bug Labs. I go by finsprings on the forums and bugnet.
With regard to the Java-only APIs on the BUG I wanted to see if you were aware of the RESTful APIs that are currently available for the BUG modules. These are still a bit limited, and I think they're all read-only for now, but there's no reason they can't become more fully-fledged (I think John was looking at supporting writes for the von Hippel for example).
Depending on what data you need access to, and how frequently, they could be a workable solution for incorporating data into your Django web apps. They're also pretty quickly extendable in the BUG modules' Java code, so if there's something blatantly missing it could hopefully be added in relatively short order.
If you point your browser to http://bugip/service it will give you a list of the services you can access, which will depend on the modules you have installed; each service has a Service XML tag with a name attribute. Then you can query the particular service using http://bugip/service/servicename and get the data back, typically in XML form. For example, BUGlocate will give you lat/lon position data back, BUGmotion will give you back accelerometer readings or the last time motion was detected, BUGcam will take a picture and return you the jpeg, and so on.
Here's a few examples from my BUG: http://pastebin.com/m5aef9b1c so you can see what I mean.
I'm a Python fan, and I know some of the folks in the BL office are too, so if you get any cool stuff going with Django or plain ol' command-line Python on the BUG it would be great if you would share, in #buglabs on freenode or some other way :-)
Also, regarding BUGsound, here is a video of a BUG app that I wrote that uses the accelerometer in the BUGmotion to select which audio samples to mix together to output via BUGsound. It gets pretty annoying pretty quickly (the guys who were at CES were cursing me :-)) but it does at least show BUGsound doing something; and hey, there's cowbell! If you try Phunky, be aware that it takes a long time to start up; that's because it has to cache all 9 samples up-front, and because they're all 44.1kHz stereo they're a little on the large size even for as short a duration as they have.
Dave (finsprings) Findlay
BUG Release 1.4 and SDK 184.108.40.206, released the middle of March, made huge strides of improvement and bring more functionality for the BUGlocate and VonHippel modules compared to the version I wrote about last year. The most important addition is formal support for the BUGsound module via its new audio API. While I struggled to get anything more than a simple demo working with the BUGsound module, it has great potential, just like the rest of the BUG modules. I hope to follow up with the Bug Labs folks in another six months or so from now to see how this rapidly evolving platform continues to innovate, especially with the expectation that the built-in WiFi and Bluetooth hardware will be integrated into future models of the BUGbase, making the BUG platform an innovation engine for students, educators, hobbyists, tinkerers and embedded software systems engineers.