General Questions

What needs to be done to make the tracker differentiate between rotational motion and translation?

The EyeMoRocknRoll tracker models a 2-D accelerometer, which can be used to measure 2 or 6 possible degrees-of-freedom. The application developer is able to choose between rotation or translation, but cannot use both simultaneously. This issue occurs for any sensor that measures less than the full 6 degrees-of-freedom.

There is a slight difference between tracking rotation and translation. A rotation motion offers more change in the camera frame per unit movement than is observed with a translation motion. This makes rotational tracking slightly more accurate than using translation. Measuring translation will also suffer from parallax issues, where objects in the distance appear to move less than objects closer to the camera.

What is the difference between immediate and accumulated motion?

This is a subtle but important point. This distinction between immediate and accumulated motion is caused by the fact that the camera operates at a frame-rate independent of the application. Because of this, your application must be aware that any number of frames (zero or more) have been processed since the last application update. The application must decide how to interpret the tracking data in this case.

The accumulated motion represents the sum of all motion that has been seen since it was last queried. This ensures that all motion observed by the tracker is counted exactly once by the application. However, successive queries of the accumulated motion will return 0 when no new frames have been processed. This makes the accumulated motion suitable for applications where the tracker data is being used to modify an absolute position, such as a crosshair or a mouse pointer.

The immediate motion represents the motion seen between the previous two frames. This approach can return the same motion results for multiple application updates (if 0 frames have arrived in the interim), or it can miss processing motion from certain frames (when 2 or more frames arrive between updates). However, the immediate motion will be approximately the same between any two frames while the user is performing a sustained motion, which can be advantageous. This type of motion is best used as a force acting on an object in game.

When the phone is stationary, why do the numbers keep changing?

You are seeing the effect of camera noise on the tracking data. Even when the handset remains stationary, the camera sensor cannot guarantee that consecutive frames are bit-for-bit identical. A small amount of random noise is always present in any camera image, and therefore the tracker is forced to report non-zero motion data.

How does EyeMobile® handle low-light conditions?

Most camera hardware is designed to increase the exposure of a frame in low-light conditions. The image-processing routines used by EyeMobile are also specially designed to account for high or low lighting levels. This effectively isolates the EyeMobile trackers from minor variances is lighting conditions, except that the camera hardware may decrease the frame-rate in those conditions.

EyeMobile does require a small amount of light to operate effectively. Under those conditions, the EyeMoRocknRoll tracker will “fail gracefully” as the light level decreases. EyeMoRocknRoll will return a tracker status of “low detail” when lighting conditions are borderline and “too fast” indicating a tracking failure in near-darkness.

Why do my controls "drift" after EyeMobile has been running for some time?

This may be because you are expecting EyeMobile to recenter itself when returning to the original orientation of the handset. Unfortunately, since EyeMobile lacks an absolute point of reference, the sum of the motion values that were produced may not be exactly zero in that situation. It is likely this difference between the actual and "expected" outcomes, that is responsible for your drift.

This may seem inaccurate, but in reality this is not the case. The "expected" model described above is very similar to the behavior of a hardware joystick. No matter how the user moves the stick while playing their game, the springs bring the joystick back to center when the user lets go. However, the "actual" behavior of EyeMobile is much more like a computer mouse. Users are very skillful at using a mouse, even though there is no guarantee that returning the physical hardware to the same position results in the same cursor position on-screen.

There are several ways to mitigate the problem above. The correct solution will depend on the desired control for your application:

• One way to avoid drift is to avoid accumulating the tracking values for any significant period of time. For instance, the app could be designed to only sum tracking values when the player presses a button. When the button is released, the accumulated values could be zeroed.
  
• Another option is to provide the user with the ability to manually recenter the game when they detect drifting. This tactic is most effective when combined with another game-mechanic that does not involve the tracking data. This effectively hides the operation from most users.
  
• It is also possible to incorporate a damping force that acts to push the accumulated tracking values towards zero. For instance, if the accumulator were to decay at a rate of 50% per second, the control will naturally recenter for the user over time. The damping value will need to be tuned for your application, since sustained gestures may be desirable in some cases.
  
• The best option would be to refactor the control metaphor for the applications. Instead of accumulating the tracking data over a series of frames, treat the immediate data as a "force" within your application, and have the relevant objects react accordingly. This is the most general solution since it allows a potentially non-linear force to be applied if desired. However, it is also the most difficult control mode to tune properly.

Brew FAQ Which versions of BREW does EyeMoCamera support? EyeMoCamera supports BREW 2.1.3 and higher. How can I make use of sound in my EyeMobile-enabled application? The current Qualcomm chipsets share DSP resources between the camera and the sound processing hardware. Unfortunately, the current generation of those chipsets are unable to run the simultaneously play certain kinds of sounds and run the camera. This will be fixed on newer chipsets. There are work-arounds available that allow for some sounds in an EyeMobile-enabled application. The EyeMoCamera extension includes functions to pause and resume the camera over extremely short intervals. Applications are able to use these functions to interrupt tracking for short periods while sounds are played. On some platforms, up to 200ms is required for the camera to restart. How can I get EyeMoCamera to support the latest handsets? The public EyeMoCamera extension contains handset-specific work-arounds for many of the most popular handsets on the market. Unfortunately, new handsets are being released far more often than the public extension is updated. If you want to support a handset that is not officially supported by EyeMoCamera, you have several options: EyeMoCamera contains a set of sensible default parameters that are used for unrecognized handsets. If the handset properly implements BREW’s ICamera interface, then there is a very good chance that the handset works out of the box. If this is the case, please notify GestureTek, so that we can add the handset to the officially supported list. GestureTek is continually updating our list of supported handsets. In the interim between public releases, GestureTek maintains a private version of the extension that we license to our partners. Licensing arrangements can be made that will allow for the use of the private extension until the next public release. The EyeMoCamera extension makes available a large number of configuration parameters for a particular handset. It is often the case that new handsets can be supported simply by working with those parameters. GestureTek investigates the compatibility of particular handsets on a case-by-case basis, based mostly on demand. If there is a particular handset that you would like to see supported, please let us know.

Symbian Which versions of Symbian does EyeMoCamera support? EyeMoCamera supports Symbian v7.0s and higher. For S60 devices, 2nd edition feature pack 1 or later is required. For UIQ devices, version 2.0 or later is required.

Windows Mobile Which versions of Windows Mobile does EyeMoCamera support? EyeMoCamera supports Windows Mobile 5 and higher.