1. Sensor axes

1.1 Coordinate axes of mobile devices

The Sensor API is only related to the natural orientation of the screen (axes do not change when the device’s screen orientation changes).

1.2 Car axes

In the Android Automotive implementation, the axes are defined relative to the body coordinate system.

Figure 2. Coordinate system used by the Sensor API (relative to automotive equipment)

  • The X-axis extends along the right side of the vehicle
  • The Y-axis extends along the front of the frame
  • The Z-axis extends along the top of the frame

The origin of the coordinate system is located in the center of the rear axle of the vehicle. When viewed from the positive direction of the coordinate axis, the positive rotation direction is counterclockwise. Therefore, when the vehicle turns left, the gyroscope speed on the Z-axis should be positive.

1.3 SensorManager

SensorManager sensorManager = (SensorManager)getSystemService(Context.SENSOR_SERVICE); sensorManager.regesterListener(SensorEventListener listener, Sensor sensor, int rate); The first parameter is the sensor listener. The second parameter is the currently registered sensor. The third parameter is the precision of the delay time.

1.SensorManager.SENSOR_DELAY_FASTEST // 0ms

2.SensorManager.SENSOR_DELAY_GAME // 20ms

3.SensorManager.SENSOR_DELAY_UI // 60ms

4.SensorManager.SENSOR_DELAY_NORMAL // 200ms

2. Basic sensors

A basic sensor type is named after the physical sensor it represents. These sensors forward data from a single physical sensor (as opposed to composite sensors that generate data through other sensors). Examples of basic sensor types include:

  • SENSOR_TYPE_ACCELEROMETER
  • SENSOR_TYPE_GYROSCOPE
  • SENSOR_TYPE_MAGNETOMETER

However, the base sensor is not equivalent to its underlying physical sensor and must not be confused with these sensors. The data from the base sensor is not the original output information of the physical sensor because the data has been corrected (such as deviation compensation and temperature compensation).

2.1 Acceleration sensor

GetDefaultSensor (SENSOR_TYPE_ACCELEROMETER) Returns a non-awake sensor

The accelerometer sensor reports the acceleration of the device along the three sensor axes. The measured acceleration includes physical acceleration (change in velocity) and gravitational acceleration. The measurements are reported in the X, Y, and Z fields of Sensor_event_T. Acceleration. All values are in si units (m/s^2) and are measured as the acceleration of the device minus the acceleration of gravity along the axes of the three sensors.

  • When the device is placed flat on the table and pushed from its left to right, the X-axis acceleration value is positive.
  • When the device is lying flat on the table, the z-axis acceleration value is +9.81, which is equivalent to the device acceleration (0 m/s^2) minus the gravitational acceleration (-9.81 m/s^2).
  • When the device is laid flat on A table and lifted upward, the acceleration value is greater than +9.81, which is equivalent to the acceleration of the device (+A m/s^2) minus the acceleration of gravity (-9.81 m/s^2).

2.2 Ambient temperature sensor

GetDefaultSensor (SENSOR_TYPE_AMBIENT_TEMPERATURE) Returns a non-wake sensor

The sensor provides the ambient (indoor) temperature in degrees Celsius.

2.3 Magnetic field sensor

GetDefaultSensor (SENSOR_TYPE_MAGNETIC_FIELD) returns a non-awake sensor

SENSOR_TYPE_GEOMAGNETIC_FIELD == SENSOR_TYPE_MAGNETIC_FIELD
Copy the code

A magnetic field sensor (also called a magnetometer) reports the environmental magnetic field measured along the three sensor axes.

Measurements are reported in the X, Y, and Z fields of Sensors_EVENT_T. Magnetic and all value units are micro Tesla (uT).

The magnetometer also reports its predicted reading accuracy via sensors_EVENT_T.magnetic. Status. For more information about possible values for this field, see the SENSOR_STATUS_* constant of the SensorManager.

2.4 gyroscope

GetDefaultSensor (SENSOR_TYPE_GYROSCOPE) returns a non-awake sensor

The gyro sensor reports the rate of rotation of the device around the three sensor axes.

The counterclockwise direction is the direction of positive rotation (right hand rule). That is, if the device at the origin is rotating counterclockwise, the observer looking from a positive position on the x, Y, or Z axis of the device will report that the device is rotating in a positive direction. Note that this is the standard mathematical definition of forward rotation and is not consistent with the aerospace definition of rotation.

The measurements are reported in the X, Y, and Z fields of Sensors_EVENT_T. gyro, and all values are in radians per second (rad/s).

2.5 Heart rate sensor

GetDefaultSensor (SENSOR_TYPE_HEART_RATE) returns a non-awake sensor

The heart rate sensor reports the current heart rate of the person touching the device.

The current heart rate, expressed as heartbeats per minute (BPM), is reported in Sensors_event_T.heart_rate.bpm, while the status of the sensor is reported in Sensors_event_T.heart_rate.status. For more information about possible values for this field, see the SENSOR_STATUS_* constant of the SensorManager. Especially in the first activation, unless it is known that the device is not carried, the state field of the first event must be set to SENSOR_STATUS_UNRELIABLE. Because the sensor is in change mode, the event is fired if and only if heart_rate.bpm or heart_rate.status has changed since the last event. Events are generated no faster than every sampling_period.

Sensor_t. requiredPermission is always SENSOR_PERMISSION_BODY_SENSORS.

2.6 Light Sensor

GetDefaultSensor (SENSOR_TYPE_LIGHT) returns a non-wake sensor

The light sensor reports the current illumination in the international unit lux.

The measurements are reported in Sensors_event_T. light.

2.7 Short-range sensor

Usually defined as a wake sensor

GetDefaultSensor (SENSOR_TYPE_PROXIMITY) returns the wake sensor

The short-range sensor reports the distance from the sensor to the nearest visible surface.

In Android 4.4 and earlier, the short-range sensor has always been a wake sensor, meaning that such a sensor wakes up the SoC when it detects a change in the short-range. For versions of Android after 4.4, we recommend that you first implement a wake version of the sensor, as this version is used to turn the screen on and off when making a call.

The measurements are reported in sensors_EVENT_T.Distance (in centimeters). Note that some short-range sensors only support “near” or “far” binary measurements. In this case, the sensor reports the value sensor_T. maxRange when it detects the “far” status and a value smaller than sensor_T. maxRange when it detects the “near” status.

2.8 Pressure sensor

GetDefaultSensor (SENSOR_TYPE_PRESSURE) returns a non-awake sensor

Pressure sensors (also known as barometers) report atmospheric pressure in hPa units.

Calibrate the reading using the following parameters:

  • Temperature compensation
  • Factory deviation calibration
  • Factory scale calibration

Barometers are usually used to estimate changes in altitude. To estimate absolute height, sea level pressure (which varies with weather) must be used as a reference point.

2.9 Relative humidity sensor

GetDefaultSensor (SENSOR_TYPE_RELATIVE_HUMIDITY) Returns a non-awake sensor

The relative humidity sensor measures the relative humidity of the ambient air and returns a percentage value.

3. Composite sensor

3.1 Linear Accelerator

Underlying physical sensors: accelerometer and (if any) gyroscope (or magnetometer if gyroscope does not exist)

Report mode: Continuous mode

GetDefaultSensor (SENSOR_TYPE_LINEAR_ACCELERATION) returns a non-wake sensor

The linear acceleration sensor reports the linear acceleration (excluding gravity acceleration) of the equipment within the sensor frame.

Conceptually, the output is the output of the accelerometer minus the output of the gravity sensor. The result is reported in the X, Y, and Z fields of Sensors_event_T. Acceleration in m/s^2.

Readings on all axes should approach 0 when the device is stationary.

If the device is equipped with a gyroscope, the linear acceleration sensor must use the gyroscope and accelerometer as input sources.

If the device is not equipped with a gyroscope, the linear acceleration sensor must use an accelerometer and a magnetometer as input sources.

3.2 Large scale motion sensor

Underlying physical sensor: accelerometer (or other low-power sensor)

Report mode: Single mode

Low power consumption

Only the wake up version of the sensor is implemented.

GetDefaultSensor (SENSOR_TYPE_SIGNIFICANT_MOTION) Returns the wakeup sensor

When a large motion is detected, the large motion sensor will be triggered; A large action is an action that may cause a change in the user’s position.

The following is an example of such a large action:

  • Walk or ride a bike
  • To ride in a moving car, bus or train

The following is an example of a situation in which a large motion sensor is not triggered:

  • Cell phone in pocket, people do not move
  • The phone sits on a table that vibrates slightly from nearby traffic or from a washing machine

At a higher level, large motion sensors can be used to reduce the power consumption of position determination. When the location algorithms detect that the device is stationary, they switch the device to a low-power mode, where the algorithms rely on large movements that occur when the user changes position to wake up the device.

The sensor must have low power consumption characteristics. This can save power consumption, but may lead to a small number of underreporting cases. This is done for several reasons:

  • The sensor’s goal is to save power.
  • Triggering events (false positives) while the user is still consumes a lot of power and should be avoided whenever possible.
  • Not firing an event when the user is moving (missing alarms) is acceptable, as long as it is infrequent. If the user has been walking for 10 seconds, but the event has not been triggered in those 10 seconds, it is unacceptable.

Each sensor event is reported 1 in sensors_EVENT_T. data[0].

3.3 pacer

Underlying physical sensor: accelerometer (and possibly other low-power gauges)

Report mode: special mode (one event per step)

Low power consumption

GetDefaultSensor (SENSOR_TYPE_STEP_DETECTOR) returns a non-awake sensor

Each time the user takes a step, the pedometer fires an event.

Sensors_event_t. timestamp The timestamp of the event corresponds to the time when the foot touches the ground, and a large acceleration change will occur at this time.

Compared to the pedometer, the pedometer has a lower delay (less than two seconds). Both pedometers and pedometers detect when the user is walking, running or taking stairs. The sensing should not be triggered when the user is riding a bicycle, driving a car or taking other means of transportation.

The sensor must have low power consumption characteristics. That is, if the step sensing cannot be done in the hardware, the sensor should not be defined. In particular, when the pedometer is enabled but the accelerometer is not enabled, only the number of steps (not each accelerometer read) will trigger the interrupt.

Sampling_period_ns Does not affect the footmeter.

Each sensor event is reported 1 in sensors_EVENT_T. data[0].

3.4 a pedometer

Underlying physical sensor: accelerometer (and possibly other low-power gauges)

Report mode: Trigger mode when change occurs

Low power consumption

GetDefaultSensor (SENSOR_TYPE_STEP_COUNTER) returns a non-awake sensor

The pedometer reports the number of steps taken by the user since the last restart after activation.

The measurements are reported as uint64_t in Sensors_event_T.step_counter and reset to zero only when the system is restarted.

The timestamp of the event is set to the time of the last step of the event.

See step sensor type for the meaning of the time corresponding to a step.

Pedometers may have a higher delay (up to 10 seconds) than pedometers. Because of this delay, the sensor has high accuracy; After a full day of measurements, the number of steps should be within 10% of the actual number of steps. Both pedometers and pedometers detect when the user is walking, running or taking stairs. The sensing should not be triggered when the user is riding a bicycle, driving a car or taking other means of transportation.

The hardware must ensure that the number of internal steps never overflows. The minimum size of hardware internal counters should be 16 bits. When an overflow is about to occur (approximately every 2^16 steps at most), the SoC can be awakened so that the driver can perform counter maintenance.

As stated in the Interactive Sensor, while this sensor is operating, it must not interfere with any other sensors, especially the accelerometer, which is likely to be in use.

HAL must not report the sensor type if these modes of operation are not supported by a particular device. That said, the sensor cannot be “simulated” in HAL.

The sensor must have low power consumption characteristics. That is, if the step sensing cannot be done in the hardware, the sensor should not be defined. In particular, when the pedometer is enabled but the accelerometer is not enabled, only the steps (not the accelerometer data) will trigger the interrupt.

3.5 Tilt Detector

Underlying physical sensor: accelerometer (and possibly other low-power gauges)

Report mode: special mode

Low power consumption

Only the wake up version of the sensor is implemented.

GetDefaultSensor (SENSOR_TYPE_TILT_DETECTOR) returns the wake sensor

Each time a tilt event is detected, the tilt detector generates an event.

A tilt event is defined as a change of at least 35 degrees in the direction of the mean gravity acceleration in the 2 second time slot since activation or since the last event generated by the sensor. The algorithm is as follows:

  • reference_estimated_gravity= The average accelerometer measurement during the first second after activation or the estimated gravity at the time the last tilt event was generated.
  • current_estimated_gravity= Average accelerometer measurements over the past 2 seconds.
  • Triggering condition isangle(reference_estimated_gravity, current_estimated_gravity) > 35 degrees

When the acceleration is large and the direction of the phone does not change, the tilt event should not be triggered. For example, a sharp turn or violent acceleration while driving a vehicle should not trigger a tilt event, even though the angular change in the average acceleration may exceed 35 degrees. Typically, this sensor can be implemented with the help of an accelerometer. Other sensors can also be used (if the power gain is not significant). This is a low power sensor and should allow the SoC to enter suspend mode. Do not simulate this sensor in HAL. Each sensor event is reported 1 in sensors_EVENT_T. data[0].

4. Posture composite sensor

4.1 Rotate the vector sensor

4.4.1 definition

Underlying physical sensors: accelerometer, magnetometer and gyroscope

Report mode: Continuous mode

GetDefaultSensor (SENSOR_TYPE_ROTATION_VECTOR) returns a non-awake sensor

The rotating vector sensor reports the orientation of the device relative to the northeast sky coordinate system. This value is usually obtained by integrating accelerometer, gyroscope, and magnetometer readings. The northeastern upper coordinate system refers to a completely orthogonal basis, where:

  • The X-axis points east, tangent to the ground.
  • The Y-axis points north, tangent to the ground.
  • The z-axis is pointing up, perpendicular to the ground.

The cell phone direction is the rotation amplitude required to align the northeast sky coordinate system with the cell phone coordinate system. That is, applying a rotation of this magnitude to the world coordinate system (X,Y,Z) will align that coordinate system with the cell phone coordinate system (X,Y,Z).

This rotation can be seen as rotating the phone θ around the rot_axis from the reference (aligned with the northeast day) device to the current device. The rotation is encoded as four dimensionless X, Y, Z, w components of a unit quaternion:

  • sensors_event_t.data[0] = rot_axis.x*sin(theta/2)
  • sensors_event_t.data[1] = rot_axis.y*sin(theta/2)
  • sensors_event_t.data[2] = rot_axis.z*sin(theta/2)
  • sensors_event_t.data[3] = cos(theta/2)

Among them:

  • rot_axisThe x, y, and z fields of are the northeast coordinates of the unit length vector representing the rotation axis
  • thetaTheta is the Angle of rotation

A quaternion is a unit quaternion: its norm must be 1. Failure to meet this requirement results in unstable client behavior.

In addition, the sensor reports the estimated heading accuracy:

Sensors_event_t. data[4] = Estimated_accuracy (in radians)

95% of the time, the heading error must be less than the estimated_accuracy. The sensor must use a gyroscope as the primary directional change input source.

The sensor also uses an accelerometer and magnetometer input source to compensate for the gyroscope offset, but cannot be implemented using accelerometer and magnetometer alone.

The rotary vector sensor is called RV-sensor.

The rotation vector represents the direction of the device and is a calculation of a mixture of axes and angles.

Rv-sensor outputs three data:

xsin(theta/2) ysin(theta/2) z*sin(theta/2)

Theta over 2 is the order of magnitude of RV.

The RV is directed in the same direction as the axis is rotated.

The three values of RV form a quad with cosine theta/2.

RV data has no units and uses the same coordinate system as the acceleration.

For example:

sensors_event_t.data[0] = xsin(theta/2) sensors_event_t.data[1] = ysin(theta/2) sensors_event_t.data[2] = z*sin(theta/2) sensors_event_t.data[3] = cos(theta/2)

The values of GV, LA and RV can be directly given by no physical sensor, and they need to be calculated by g-sensor, O-sensor and Gyro-sensor through algorithm.

4.1.2 Basic Usage

The rotation vector represents the screen orientation of the device as a combination of angles and axes, where the device has been rotated by θ degrees about an axis (x, y, or Z). The following code shows how to get an example of the default rotation vector sensor:

private SensorManager sensorManager; private Sensor sensor; . sensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE); sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ROTATION_VECTOR);Copy the code

The three elements of a rotation vector are represented as follows:

Where the magnitude of the rotation vector is equal to sin(θ/2), and the direction of the rotation vector is equal to the direction of the rotation axis.

4.2 Game rotation vector sensor

Underlying physical sensors: accelerometer and gyroscope (without magnetometer)

Report mode: Continuous mode

GetDefaultSensor (SENSOR_TYPE_GAME_ROTATION_VECTOR) returns a non-awake sensor

The game rotation vector sensor is similar to the rotation vector sensor, but does not use the geomagnetic field. So instead of pointing north, the Y-axis points to some other reference coordinate. The reference coordinates can be offset by an amplitude of the same order of magnitude as when the gyroscope is offset along the Z axis.

See Rotating vector Sensor for details on how to set up sensors_EVENT_T. data[0-3]. This sensor does not report estimated heading accuracy: sensors_EVENT_T. data[4] is retained and should be set to 0. Ideally, a phone that has been rotated and returned to the same direction as the real world should report the same game rotation vector. The sensor must be based on a gyroscope and accelerometer. The magnetometer cannot be used as the input source, nor can it be used indirectly by estimating the gyroscope deviation.

4.3 Gravity Sensor

Underlying physical sensors: accelerometer and (if any) gyroscope (or magnetometer if gyroscope does not exist)

Report mode: Continuous mode

GetDefaultSensor (SENSOR_TYPE_GRAVITY) returns a non-wake sensor

The gravity sensor reports the direction and magnitude of gravity in the device coordinate system.

The gravity vector components are reported in the Sensors_event_T. Acceleration, X, Y, and Z fields (in m/s^2).

The output of the gravity sensor should be the same as that of the accelerometer when the device is stationary. On Earth, the gravitational acceleration is about 9.8 m/s^2.

If the device has a gyroscope, the gravity sensor must use a gyroscope and accelerometer as input sources.

If the device does not have a gyroscope, the gravity sensor must use an accelerometer and a magnetometer as an input source.

4.4 Geomagnetic rotation vector sensor

Underlying physical sensors: accelerometer and magnetometer (no gyroscope)

Report mode: Continuous mode

Low power consumption

GetDefaultSensor (SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR) returns a non-awakened sensor

The geomagnetic rotation vector sensor is similar to the rotation vector sensor, but it uses a magnetometer instead of a gyroscope.

The sensor must be based on a magnetometer. It can’t be implemented using a gyroscope, and it can’t use a gyroscope input.

See Rotating vector Sensor for details on how to set up sensors_EVENT_T. data[0-4].

Similar to the rotating vector sensor, the heading error must be less than the estimation accuracy 95% of the time (Sensors_EVENT_T. data[4]).

The sensor must have low power consumption, so it must be implemented in hardware.