BUGbase 2.0
BUGstinger
BUGvonHippel
BUGview
BUGcam
I'd been waiting to get my hands on Bug Labs latest, Bugbundle. Once I had it in hand I spent too much time playing with it to write this. The BUGbase 2.0 (see Build with a Bug) is fun to work with and it is a flexible development platform.
There are a number of BugBundles starting with the $699 Embedded BUGbundle that includes the BUGbase 2.0 (Fig. 1), BUGstinger (Fig. 2) and BUGvonHippel module (Fig. 3). I took a look at the top end Pro bundle that adds BUGview LCD display (Fig. 4), 3 Mpixel BUGcam (Fig. 5), 720p HDMI output BUGvideo, BUGlocate GPS and BUGusb.
The BUGbase is 5.1-in by 2.55-in by 0.765-in with four pliug-in expansion ports, two on each side. A built-in rechargeable 3.7V, 1500 mAh lithium-ion battery supports mobile operation. The heart of the system is a 600 MHz Texas Instruments OMAP3530 processor. The OMAP3530 is based on an ARM Cortex A-8 processor. The system has access to 64 Gbytes of flash memory using a pair of MicroSD cards.
There is built-in audio support as well as wireless support that includes a 802.11b/g Wi-Fi interface, Bluetooth 2.0 support with EDR wireless technology. A cell phone 3G module is optional. The BUGstinger provides access to the USB host port, Ethernet and a serial port.
The hardware is modular with up to four modules supported by the BUGbase although there are two different kinds of connections. One is designed for video modules. Modules have hooks on one side and snap into place.
The modular system is useful but it is the software that makes things interesting. The system runs Linux but it is Java and the Java-based OSGi system (see Open Services Initiative: OSGi Links Devices And Clients) that make the difference. Each module comes with an OSGi bundle.
Developing A Bug
Like most eval platforms these days, Bug Labs puts all its tools, documentation, etc. online. Many also take advantage of open source software. In this case, BUGbase developers can take advantage of the Eclipse IDE (see Anatomy Of An IDE).
On the plus side, Eclipse can be used to develop C/C++ applications for the BUGbase or Java-based applications. I started out setting up the WiFi support with a fixed IP address and then I tried a Hello World style app just to try out the C++ support.
I moved on to the online tutorials because the intended target development environment is OSGi and Java. OSGi is installed when the system is delivered along with basic support using OSGi bundles. Applications are written as OSGi bundles as is the support for each of the hardware modules.
The other piece to the puzzle is the Dragonfly SDK from Bug Labs. The SDK includes a number of features including a connection to OSGi running on the BugBase. OSGi supports dynamic bundle loading and provides naming and registration services. OSGi is actually at the center of the Java-based Eclipse IDE.
The first tutorial is the analog to the C Hello World program. The difference is that you define a class based on BundleActivator that has start and stop methods. It is possible to run through the tutorials without a complete understanding of OSGi but it helps. Check out Getting Started with OSGi if you are interested.
The easiest way to get started is to use the BUG Simulator that essentially provides the SDK functionality on a PC running Java. This actually highlights the portability of OSGi. It also makes debugging faster although it means hardware will not be exercised directly. It also pays to check out the OSGi console. This is a command line interface the provides access to the operating OSGi framework. It is possible to see the available services, consumers and producers plus performing other useful functions like initiating garbage collection. Commands are available to load and unload bundles. All this information is available programmatically but having the console is useful for debugging.
The BUGbase can do quite a bit by itself if wireless connectivity is all that is needed. Things got more interesting plugging in a few modules. A module usually has an OSGi bundle in a JAR file that includes often source code in addition to the class files. This lets you examine the support code. Typically the support is divided into two modules. One has the high level APIs. The other has the Java Native Interface (JNI) support that accesses the underlying Linux drivers. The OSGi bundle also defines a BundleActivator subclass.
I would have liked a little more documentation and support organized with respect to the BUGbundles. There is a lot of information on the BUG Wiki including an active community. Most demos and tutorials highlight a single module although the BUGview module is often used for text output. Finding compound examples that employ multiple modules takes a bit more looking or experimentation on your own.
Overall, the BUG system has been a lot of fun. I have not exercised all the hardware modules in the BUGbundle I have on hand yet but using the BUGcamera, BUGview and BUGlocate was easy. I've probed the BUGvonHippel and it would be an easy way to hook this up to the iRobot Create (see Real Robots: iRobot Create) robot.
Android is also Linux-based so it is not surprising that there is a beta version for the BUGbase. I was hoping to include that in this article but it will have to wait till the next one. I have downloaded the image but have not had a chance to see how much different it might be. If it supports OSGi then migrating applications to Android should be a snap. Unfortunately Dalvik does not support the normal Java Class Loader model. Instead, it uses the android.dalvik.DexFile class. I'll let you know how Android and OSGi works out soon.
