BUG Community

Welcome! Log In

Forums Recent Posts

Subscribe to Recent Posts 12,455 posts found

Mar 22, 2008 5:36pm
Medium kschultz 107 posts

Topic: BUG SDK / Virtual Bug ... Accelerometer.

The motion sensor is infrared based afaik. When the MotionDetected method is called, that is a motion from infrared side not the accelerometer side, though I think it would be difficult to cause one without the other.

Mar 22, 2008 12:05pm
kitplummer 7 posts

Topic: BUG SDK / Virtual Bug ... Accelerometer.

Thanks John.

I realize there motion module and the accelerometer are interfaced differently. What I was doing from my code was … don’t bother measuring the movement until there was actual motion detected. Now I understand that probably is not the best way. So, does the motion event get triggered by the accelerometer or just the "motion/visual" sensor?

Sorry for these basic questions…


Mar 22, 2008 10:51am
Medium kschultz 107 posts

Topic: BUG SDK / Virtual Bug ... Accelerometer.


However, you raise a good point about the Accelerometer interface. I will provide some documentation in the wiki about how X, Y, and Z are oriented about the BUGMotion module.

That would be good, my main other question is what do the numbers "mean"? Are they normalized to something or are they just the raw data from the accelerometer? Are they calibrated to be consistent? The wiki says "Software selectable sensitivity (2.5g/3.3g/6.7g/10g)" but I'm not quite sure how that correlates to this data. What is the default?

Mar 22, 2008 9:39am
Medium jconnolly 285 posts

Topic: BUG SDK / Virtual Bug ... Accelerometer.

Hey. While I'm thinking about it - it'd be kinda cool if I could specify some argument(s) to the motion "command" given in the virtual_bug environment. Maybe a speed and direction, or options for each axis. Just an idea.



While the com.buglabs.bug.module.motion.pub library contains classes to interact with the Accelerometer and Motion features of the BUGMotion module, the two may be thought of as separate features.

Right now the motion hardware supports simple motion detection: a motion event will be triggered when motion enters the field of detection, and another triggered when the motion stops or exits the field of detection. Unfortunately the motion module alone does not support detailed information about speed or direction. The motion command provided within the virtual bug console will, from a programmatic perspective, only provide your program with this information.

The Accelerometer module may better suit your needs for information regarding velocity (or, more precisely, change in velocity). While the motion module does not provide directional information, the accelerometer provides axis information. If you can assume the physical orientation of the module in space (say that the BUG is lying flat), then you may infer direction. Coupled with GPS functionality, the accelerometer may be useful for this purpose.

In short: the motion events are simple. Speed and direction cannot be part of the motion commands.

However, you raise a good point about the Accelerometer interface. I will provide some documentation in the wiki about how X, Y, and Z are oriented about the BUGMotion module.
Mar 22, 2008 9:00am
tevslin 16 posts

Topic: BUG SDK / Unresponsive Virtual Bug


Did all this and verified that I’m at .291 for Bug components. However, appears to have no impact on the problem; the virtual bug is unresponsive until I type something in the Console window. However, since I can easily do this, it is not a blocking problem.


Mar 22, 2008 1:57am
Medium finsprings 268 posts

Topic: Applications / JNI

Sounds good Ken. I’ll definitely try and build it all once I can grab it from source control.

Mar 22, 2008 1:57am
Medium finsprings 268 posts

Topic: BUG SDK / OS-level development for the Bug

Sounds great Ken, thanks for the reply. I can see it being pretty handy to wrap drivers for common peripherals (at least USB, and perhaps on vonHippel once we find out what ports are on the vonHippel), via JNI, into modules that standard Bug applications can grab the interfaces for and use like the existing modules.

Mar 22, 2008 1:49am
Medium kgilmer 215 posts

Topic: BUG SDK / OS-level development for the Bug


Great question :). Sorry for my late response. All driver development can be done with our LTIB build system with additional BUG specific kernel patches. We will release this build system via our public CVS server shortly, and begin with some basic docs on how to build the base root filesystem. In terms of user-created drivers and low-level modifications, we are certainly very interested in getting this to other people. We are working on a contributor program now so that people like yourself can contribute this work (if you want to) back to us for inclusion in a future release.

Mar 22, 2008 1:44am
Medium kgilmer 215 posts

Topic: Applications / JNI

Hi finsprings,

Since JNI is generally non-portable, what should I use as my starting point?

There are bundles in our cvs tree (which are out of date, I'll work on pushing a snapshot to our external CVS server next week) that begin with com.buglabs.bug.jni. These bundles contain all the JNI code (C and Java) to access BUG base and module functionality.

Any JNI-related limitations of PhoneME of note?

Not that I'm aware of :)

What C library did you choose for the bug?

The BUG rootfs is glibc-4.1.1 based. We also use LTIB to build our rootfs. We simply use the default target configuration for the iMX31 with some additional patches to the kernel. All of this will be available on the public CVS server shortly.

Any compiler or linker flags of note?

Not really. Our JNI projects include makefiles to build the jni target libraries. You can call them from LTIB to generate the BUG (target) files. If you are familiar with how LTIB works you have a head start.

Is there any point in doing JNI stuff in the VirtualBug in the meantime?

Well, you could validate that you can build the JNI libraries on your FC VM. Once I publish the projects check them out and try building them.

Great questions, hope that helps.
Mar 21, 2008 9:40pm
Medium agordon 74 posts

Topic: BUG SDK / Unresponsive Virtual Bug

Tom, please disregard my previous post about moving to Integration. There’s now a new Test build on the updatesite that may work better for you than transitioning over to Integration.

To upgrade:

  • Start Eclipse
  • Go to Help > Software Updates > Find and install…
  • Click Search for new features to install, then click Next
  • Make sure that your BUG SDK field is selected, then click Finish
  • Under "Select features to install", click on Dragonfly. This will select this node and its sub-nodes
  • Make sure to have set "Show the latest version of a feature only", then click Next.
  • Accept the licensing terms and click Next
  • Click Finish

The update to your Test build will be downloaded and applied to your Eclipse installation. You will need to click "Install All".

When asked to restart Eclipse, choose No, then manually quit and restart Eclipse. Following these procedures will have you upgraded to testing build #291.

Powered by Community Engine