The BUG: a Linux-Based Hardware Mashup
Tinker Toys, Lincoln Logs, Erector Sets, Legos—I think I had just about every building toy there was when I was a child. Now that I'm all grown up, I still like to play with toys, and I still like to build things and connect them together. Only now, my toys are much more sophisticated, and some of them are even practical. I think much of the attraction that software development has for me is that I get to use my creativity to build applications that didn't previously exist, using a few software building blocks. I think most programmers and Linux users can relate to feeling this attraction.
However, many of the really neat things I would like to do in software aren't typically supported by hardware. For example, my home's thermostat doesn't talk to my groupware to see when I'll be home and want the house heated or cooled. My digital camera doesn't talk to my GPS to embed location information into the pictures I take, and I'm not able to add labels to my pictures with my PDA. To be able to build functionality like this, we need hardware that is open enough so we can hack on it and powerful enough that we can do nontrivial things with it. Finally, we need hardware that has a variety of functions built in to it. I have such a device; it's called a BUG from Bug Labs, and it's got to be the neatest thing I've seen in some time.
The BUG is an embedded Linux machine that accepts up to four external modules that provide various functionality. For example, the BUG I received had a color touchscreen module, a GPS module, a 2-mega-pixel digital camera module and an accelerometer with motion sensor. All of these modules plug in to the base unit. Once plugged in to the base unit, the modules expose their functionality as a kernel device and via a Java API. The idea is that you write a program that combines these functions into useful, or simply fun, applications. Peter Semmelhack, the CEO at Bug Labs, described it to me as a hardware mashup.
When I received my review unit, I opened the package in FedEx's parking lot and couldn't believe what I saw. The base unit is only 5-inches wide, 2.5-inches deep, and less than half an inch thick. There are two module ports on top of the unit and two ports on the bottom of the unit. With all four modules installed, the whole unit fits in the palm of your hand and is about the size of a large digital camera. The Web site indicates that the camera module can output still frames or MPEG video at ten frames per second. The unit comes with an LCD status display, four software-definable buttons, two menu buttons, a USBtoGo port and a piezo speaker—all of this and a tripod mount!
The unit also comes with a 512MB MMCmicro memory card installed. I found out the hard way that this is where the BUG stores its root filesystem. I decided to see what was on it, so I put the memory card in my PDA, which of course reformatted the card and squashed my BUG pretty handily. Fortunately, I was able to download a new image from the Bug Labs Web site, and I was up and running again in minutes. The root image consumes only about 30MB of the available 512MB, so there should be plenty of space for user programs, pictures and data.
Conspicuously absent from the unit is any type of labeling. None of the buttons are labeled, nor are any of the modules, although the modules do sport some Braille marking. This doesn't make the unit difficult to use, but it does make for a clean presentation. It also opens up the possibility for chassis modification, which reinforces the idea that the BUG puts the user in control.
I've shown my review unit to my wife and every other nerd I know, and the response has been the same each time. At first they don't know what it is. After I explain what it is and what it can do, they simply can't believe it. Typically, they leave saying, “that is just too cool!” And it is.
As I mentioned earlier, the BUG exposes all of its functionality via a Java API. I have to confess that I'm not a big fan of Java, but I understand that Java is a language many people already know and almost anyone can learn. Java also is an open standard, and Bug Labs, thankfully, is all about open standards, as I discuss later in this article.
Once connected and configured, the BUG integrates seamlessly with the Eclipse IDE. After following a few simple instructions, I was able to get Eclipse to recognize my BUG and all of the installed modules. Eclipse then presented me with a programming and hardware integration environment that even I could work with, and I'm not a Java programmer. There are lots of free source code examples available from the Bug Labs support site. I was able to download and install a calculator application, as well as a digital camera application within minutes. The example code is well written, and the API seems to be intuitive. The Bug Labs Web site has a lot of documentation for the API. I've never had a compelling reason to become proficient in Java—until now. A nerd like me could have a lot of fun with this device.
Bug Labs even provides a virtual BUG environment available from within Eclipse. The virtual environment allows you to plug modules in to a simulated BUG and run Java-based applications directly on the virtual device. The virtual BUG behaves almost exactly like a real BUG. Obviously, the GPS module, for example, provides bogus data, but it's still usable for software development and testing. You don't even have to own a BUG in order to develop software for it.
As I'm not a Java programmer and I don't use Eclipse, I was very interested in other ways to interact with the BUG. Getting it connected to my network wasn't hard at all. The device's base unit doesn't have Ethernet or Wi-Fi capability; it connects to the network via USB. This meant that I had to upgrade the kernel on my workstation to enable USB networking, which presents itself as usb0 and acts just like any other network device. Note that, like most USB devices, the usb0 device won't be available until the BUG is connected and has finished booting up.
Once the BUG is booted, it runs the TWM window manager. Configuring my workstation to communicate with it was trivial, though the documentation on Bug Lab's Web site made it a bit more complicated than necessary. The Web site indicated that you needed to install ifplugd, which I think is a neat program, but it's not needed in this case. All you have to do is configure the usb0 device with the right IP address and netmask. What I did was:
ifconfig usb0 10.10.10.1 netmask 255.255.255.0
The BUG has 10.10.10.10 as its IP address and expects to find its default gateway at 10.10.10.1. My workstation had to be configured to forward network traffic:
echo 1 > /proc/sys/net/ipv4/ip_forward
After that, I was able to ssh into the device:
Use root as the default password and change it to something more secure. You also should configure /etc/resolv.conf on the BUG so that DNS works properly.
Once you've logged in, you will be presented with a BusyBox prompt. You should feel free to take a look around. Much of what you see will be familiar to you. The fun begins when you start interacting with the application manager:
telnet localhost 8090
Typing help gives a list of commands that you can send to the application manager. To spare you the suspense, I'll tell you that you can use the install command to download an application from the Internet. For example:
This installs the BasicCalculator application, which is available from the Bug Labs Web site. By using the bundles command, you can determine which ID has been assigned to this application. In my case, the application was given the ID of 30. Then, you start the application using:
Shortly after issuing this command at the prompt, you will see a four-function calculator on the touchscreen—assuming you have the touchscreen module installed. I've found that using my fingers to interact with the touchscreen isn't extremely accurate. Once I dug up a stylus from one of my PDAs, I was able to use the BUG touchscreen with little or no effort.
Several applications are available from the Bug Labs Web site. They tend to be well written and serve as good example programs from which to learn. There is sample code available on the Bug Labs Web site to exercise each of the available modules as well as the Java Abstract Window Toolkit (AWT) that comes with the BUG.
Bug Labs has a remarkable outlook when it comes to the openness of its products. To borrow a term from the CEO, Bug Labs embraces “Radical Openness”. This policy is reflected in the use of Linux as the core of its system, Java as the main development language and complete documentation for the system and programming API. But, it goes beyond that. Bug Labs even has documented the pinout of the connector that its modules plug in to. I was told that if someone wanted to start producing third-party modules for the BUG, Bug Labs would support that effort. This policy, as well as the flexibility and sophistication of the device, makes the BUG a hacker's dream come true.
Every product has its drawbacks though, and the BUG is no different. The fact that none of the buttons and connectors are labeled makes the device less than intuitive. I actually had to look at the documentation that came with it. With such a small form factor, this device is just begging to be used in mobile applications. So although the USB networking gets the job done, the BUG really needs Ethernet or Wi-Fi capability. I'm told there will be an Ethernet module available soon.
Removing the various modules from the base unit is sometimes a bit unnerving. The latching mechanism holds the modules in place quite securely, and it's often difficult to un-install them. At first, it isn't even obvious how to go about it. Having removed and replaced the modules several times now, I've gotten used to the fact that I have to press harder than expected and that the unit's chassis is more sturdy than it looks. That said, I still haven't worked up the courage to exchange modules while the unit is running, although I'm told that they're hot-swappable.
The Bug Labs Web site is testing some of the modules that they plan to release in the second quarter of 2008. The QWERTY keyboard will be a welcome addition. Though the BUG has a built-in speaker, it's of rather poor quality, so the speaker module with I/O jacks will be nice. Neither of these promised modules seem to be in the same league as the modules already available. It's pretty hard to compete with a GPS module with an external antenna connection or a motion sensor module, but they're trying. I received an e-mail from my contact at Bug Labs indicating that they have about 80 new modules on their R&D list. Some of the modules on their list include a TV tuner, Servo interface, game controller, bar-code scanner, 3G modem and a Geiger counter!
My contact at Bug Labs went on to describe a module that they are working on that will open up the BUG to a whole new world of customization. They're about to release a module that exposes all of the BUG's hardware signaling and presents it in a manner much like a breadboard or breakout box. With such a module, it seems like it would be fairly easy to interface the BUG with a PIC microcontroller, or an external relay bank, or a Roomba—but I digress.
Remembering my earlier lamentations about the inadequacies of my existing electronic gadgets, what can we really do with a BUG? I have a few suggestions that are completely plausible and that I hope pique your interest in developing programs for the BUG.
Parents of teenagers might be interested in using a BUG to track their kids' driving habits. With a built-in GPS, an accelerometer and almost 512Mb of memory, it wouldn't be difficult to track where kids go, and how fast they went. Such a device could be mounted in the trunk and would have the added benefit that if the kid decided to remove the unit and stash it at the library, where he told his parents he would be, the device could sense that it was being moved, using the motion detector module, and start filming the event—busted!
But, that's a bit too much Big Brother for me. I could see giving a BUG to a group of Boy Scouts at a camp-out. The device could be preprogrammed with GPS coordinates for various targets. The boys would be told to use the GPS to locate the targets and take a picture of them. The BUG could verify that the boys had reached the correct locations and store annotated pictures of each target. The accelerometer module could be used to measure the boys' minimum, average and maximum speed as they hiked up mountain passes and into valleys. This could evolve into a timed race between different groups.
I could go on, but I think you get the idea. Neither of these devices are on the market right now. Sure, you could use a GPS and a digital camera and get most of the same functionality described above, but part of the appeal of the BUG is that all of these features are combined in one unit and under user-programmable software control. With the appropriate modules installed, you can program the BUG to do anything you want it to do. Then, by installing different modules and running a different application, the same unit can provide an entirely different function—one of the few times when you are truly bound only by your imagination.
I don't have enough space to explore the BUG fully. I've spent hours looking at the Bug Labs Web site. I haven't written about the embedded Web server and associated Web services API. I've not written about the underlying Linux system. I've not written about the details of the SDK that are freely available from the Web site. I've not written about how the system hosts a service-oriented Java runtime component called OSGi that simplifies software development. For such a small device, there is a surprisingly steep learning curve. What originally attracted me to Linux was the fact that I could learn to do simple tasks quickly with Linux, but that I also could study Linux for years without ever running out of things to learn. I think the BUG is going to provide a very similar experience.
Mike Diehl is a freelance Computer Nerd specializing in Linux administration, programing, and VoIP. Mike lives in Albuquerque, NM. with his wife and 3 sons. He can be reached at firstname.lastname@example.org
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- RSS Feeds
- Senior Perl Developer
- Technical Support Rep
- Introduction to MapReduce with Hadoop on Linux
- Weechat, Irssi's Little Brother
- What the author describes
32 min 7 sec ago
- Reply to comment | Linux Journal
4 hours 42 min ago
- Reply to comment | Linux Journal
5 hours 27 min ago
- Didn't read
5 hours 38 min ago
- Reply to comment | Linux Journal
5 hours 43 min ago
- Poul-Henning Kamp: welcome to
7 hours 53 min ago
- This has already been done
7 hours 54 min ago
- Reply to comment | Linux Journal
8 hours 39 min ago
- Welcome to 1998
9 hours 27 min ago
- notifier shortcomings
9 hours 51 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?