Hello,
I learned about the BUG just an hour ago (thanks to Slashdot ) and got quite interested. I might consider it for a research project I am working on, yet to correctly assess that I need to have more info about the SDK and the OS. I would be glad if somebody could answer at least some of my questions.

If I would use BUG, I would like program applications in a different programming language than Java - a proprietary one. The interpreter of that language (written in C++ and ported to Linux and Windows) allows my programs to easily connect to 3rd party pieces of software which provide an interface accessible from lower level languages like e.g. C, or C++ (e.g. loading a shared library and using its API, reading/writing files, etc.).

Q1: How difficult is it to connect to BUG HW via a lower level interface from e.g. a C program? If it is easy (as I guess - under the Java VM have to run the low level drivers), is there a documented higher level API which I can start from? Or is there an easily accessible and documented interface to the BUG modules' drivers?

Q2: What are my possibilities if I need to play directly with the on-board Linux system? I mean things like compiling (or cross-compiling)/porting C++ applications and libraries which already work on standard Linux OS. Could you please point me to a starting point on how to configure the on-board OS?

You bring up some great questions. Honestly these questions should be addressed conclusively on our wiki, but for now I'll respond with the basics. Essentially, the BUG is a Linux computer. During the design of the BUG, we followed the "Linux way" as much as possible. For example the bus that connects the base unit with modules was modeled after USB and PCI buses. So, in general anything that already works in Linux should be fairly easy to port to the BUG. One gotcha may be the ARM architecture.

A1: We will work on providing linux-level documentation for all our modules. As mentioned above, wherever possible we follow the linux way. For example, our camera module utilizes the same high level driver API as other linux camera devices.

A2: We use a toolchain called LTIB. There are a set of standard packages provided by the toolchain, and an extension mechanism for introducing new packages. In addition there is a "shell mode" to just build something. Unfortunately due to the rules of this forum I can't post URLs. Google LTIB to get started.

These are all great questions. We will work on putting this information in the wiki. In the mean time, please let me know if you have additional questions._________________thanks!
ken

Dear Ken,
thanks a lot for your reply. I already feared there's nobody around able to say anything to this.

So as I see, hopefully there will be at least some lower level documentation in the future. That tells me to wait few months and see what comes out . It seemed to me of course highly probable that BUG OS handles the connected devices the same way as all the other Linux distros do. However, maybe a kind of a light-weight overlay (kind of low level BUG SDK) could be useful. For example BUG specific API to find out what kind of modules are connected, what's their status and possibly retrieve their OS-specific handles to deal with them further, etc. Possibly a more heavy-weight API to handle the connected modules in a uniform way as it is probably done for Java.

Another question which recently came to my mind is how (and whether at all) can BUG integrate with middleware platforms for programming agent and multi-agent systems? I mean Java based things like e.g. JADE (by TI Labs), JadeX, maybe FIPA-OS, etc. (search Google for e.g. "Jade agent").

Such an integration could prove to be a very useful feature in contexts where several BUG devices need to communicate with each other in a modular way thus forming a small multi-agent system. Actually that's exactly why I got interested in this device in the first place. BUG seems to be an ideal modular platform for development of embodied small multi-agent systems (sensor networks possibly with actuators, maybe control units for robotic teams (RoboCup like teams), etc.)

Much of the functionality you are looking for is or will be provided in our Java application layer, including support for distributed programming models. I'd love to hear more about what you envision in terms of "light-weight overlay". In regards to discovering which modules are currently connected, most information is provided via the /proc and /sys filesystems.

To take advantage of the OSGI/bug module APIs, could you write a standard Java Bug app that used JNI to get to the C/C++ stuff? It would be sort of inside out, the Java layer bootstrapping the C/C++ stuff where your real app would be, but you could effectively mirror whatever subset of the bug module APIs you needed through JNI to your real app.

One can interact with the physical modules from C, C++, or any other language that supports native code. In fact, our OSGi runtime layer uses JNI to access the linux device drivers via system calls: read, write, ioctl, etc..

Another alternative is to interact with the web-services that each module exposes. For example, to take a picture with the camera you can do a GET on http: //<mybugsip>/service/Camera. To see if motion was detected you can GET http:// <mybugsip>/service/Motion. This allows you interact with the hardware via HTTP which most languages support one way or another.

Hello,
Does this mean you will distribute the source code for the OS and all the device drivers and I will be able to rebuild it from scratch? (I am sure your OS is very good, but I would like the option to disimprove it! )

I have a second question which is unrelated but short - does the arm11 you chose include the vector floating point coprocessor?

All sources: linux, device drivers, JVM, JNI, BUG applications are GPL or BSD-style and will be provided via SVN. Some already are, for example the SDK is available on our SVN repository and much of the BUG application layer. We will also make available the toolchain and instructions to make it easy to generate the kernel and rootfs for yourself.