Basics of Motion Computing

There's a lot to learn when getting started with Motion Computing; here is some information and guiding principles to bear in mind.

Hard vs. Soft Sensors

MotionStack provides access to both hard and soft motion sensors. Hard sensors refer to the sensors built into the hardware of your mobile device that directly measure motion, such as the Accelerometer and Gyroscope. In order to use these sensors in your projects, you need to be familiar with the coordinate frames in which the device reports sensor readings.

Soft sensors are quantities that are derived downstream from the hard sensors to provide additional information that are not observed directly. For example, the Orientation API is a soft sensor that estimates the angular position of the device as inferred by the Accelerometer, Gyroscope, and Magnetometer.

Discrete Gestures vs. Continuous Motion

This section emphasizes the difference between discrete gestures, which only emit an event after the specific gesture is detected, and continuous motion, which emit events continuously or semi-continuously.

Discrete Gestures

Discrete gesture APIs only emit an event after the specific gesture is detected. Each time the discrete gesture event fires, a callback function will execute to control the application. This callback function is sent to the sensor using the start() method.

Discrete Gesture APIs

Example

The following JavaScript code executes function transitionLeft() on a left tilt event and function transitionRight() on a right tilt event.


var tilt = new MotionStack.Tilt({orientation: "horizontal"});

var callbackFunction = function (e) {
  if (e.direction === tilt.DIRECTION_LEFT) {
    transitionLeft();
  }
  else {
    transitionRight();
  }
};

tilt.start(callbackFunction);

See the Tilt API for more information.

Continuous Motion

Continuous motion APIs emit events continuously at regular intervals or semi-continuously at irregularly intervals. Regular intervals means that the sensor data is fired at a constant sampling rate, which is set by the browser. In some cases the browser only fires sensor data when the device is in motion, which leads to an non-constant sampling rate. This must be taken into consideration when using these APIs.

Continuous Motion APIs

Decoupling Sensor Controls From Animation Loops

It is a best practice to keep the sensor data event stream independent from all other animation loops in the application. There are two purposes for this practice.

First, to keep the animation frame-rate unaltered by the discrete, continuous, or semi-continuous nature of the sensor controller. This is especially true for continuous motion APIs, where one may be tempted to use the stream of sensor events as the main animation loop.

Secondly, to provide additional post processing to the sensor data. Such as, if there is some type of interpolation between sensor events.

Example

If continuous updates are needed from the Gravity API, it is safest to use the sensor updates within a loop using requestAnimationFrame(). Given an update function updateWithGravity(), such a script should resemble:


var gravityData = undefined;

// Gravity controller
var gravity = new MotionStack.Gravity();
gravity.start(function (e) {
  gravityData = e;
});

// Main animation frame of the application
requestAnimationFrame(function loop() {
  if (gravityData !== undefined) {
    updateWithGravity(gravityData);
  }

  // update other application components.

  requestAnimationFrame(loop);
});