EyeMo™ 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 EyeMo™ 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 EyeMo are also specially designed to account for high or low lighting levels. This effectively isolates the EyeMo trackers from minor variances is lighting conditions, except that the camera hardware may decrease the frame-rate in those conditions.

EyeMo 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 EyeMo has been running for some time?

This may be because you are expecting EyeMo to recenter itself when returning to the original orientation of the handset. Unfortunately, since EyeMo 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 EyeMo 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.