BUG Community

Welcome! Log In

Forums BUG SDK Avoiding Java: low level C API?

Subscribe to Avoiding Java: low level C API?  8 posts, 5 voices

Log in to reply to this topic
Jan 9, 2008 12:46pm
Img_missing_medium walkmanyi 2 posts

I learned about the BUG just an hour ago (thanks to Slashdot :wink:) 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?

Thanks a lot for any constructive info.

Jan 13, 2008 4:55am
Medium Bug Labs team kgilmer 215 posts


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.

Jan 13, 2008 12:01pm
Img_missing_medium walkmanyi 2 posts

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.)

Jan 20, 2008 12:39am
Medium Bug Labs team kgilmer 215 posts


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.

hope that helps!

Jan 22, 2008 9:18pm
Medium Bug Labs team finsprings 268 posts

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.

Just a thought.

Jan 23, 2008 3:51pm
Img_missing_medium aroman 21 posts


That’s a good suggestion.


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.


Jan 23, 2008 5:33pm
Img_missing_medium mp 1 post

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?

Good luck with the bug it looks great!


Jan 24, 2008 6:54am