Composite sensors复合式传感器
原文：http://source.android.com/devices/sensors/composite_sensors.html
Composite sensor type summary复合传感器概要
The following table lists the composite sensor types and their categories, underlying base sensors, and trigger modes. Certain base sensors are required of each sensor for accuracy. Using other tools to approximate results should be avoided as they will invariably provide a poor user experience.
下表列出了复合传感器的类型、类别、所依赖的基础传感器以及触发模式。某些基础传感器会被每一个复合传感器所依赖，用于提高该复合传感器的精度。应当避免使用其它工具对结果进行预估，因为他们提供的用户体验总是很差劲。
When there is no gyroscope on the device, and only when there is no gyroscope, you may implement the rotation vector and other composite sensors without using the gyroscope.
如果设备上没有陀螺仪，且仅当没有陀螺仪的时候，你才可以不依赖陀螺仪去实现旋转向量和其他的复合传感器。(yasin：也就是说有陀螺仪的时候必须用陀螺仪去实现复合传感器及旋转向量)
| Sensor type | Category | Underlying base sensor | Trigger mode |
|---|---|---|---|
| Game rotation vector | Attitude | Accelerometer, Gyroscope MUST NOT USE Magnetometer | Continuous |
| Geomagnetic rotation vector (Magnetometer) | Attitude | Accelerometer, Magnetometer NOT Gyroscope | Continuous |
| Gravity | Attitude | Accelerometer, Gyroscope | Continuous |
| Gyroscope uncalibrated | Uncalibrated | Gyroscope | Continuous |
| Linear acceleration | Activity | Accelerometer, Gyroscope AND Magnetometer | Continuous |
| Magnetic field uncalibrated | Uncalibrated | Magnetometer | Continuous |
| Orientation | Attitude | Accelerometer, Magnetometer PREFERRED Gyroscope | Continuous |
| Rotation vector | Attitude | Accelerometer, Gyroscope AND Magnetometer | Continuous |
| Significant motion | Activity | Accelerometer (or another as long as very low power) | One-shot |
| Step counter | Activity | Accelerometer | On- change |
| Step detector | Activity | Accelerometer | Special |
= Low power sensor
Activity sensors动作检测类传感器
Linear acceleration线性加速度传感器
Underlying base sensor(s): Accelerometer, Gyroscope AND Magnetometer依赖的基础传感器：加速度传感器，陀螺仪和地磁传感器
Trigger-mode: Continuous触发模式：轮询模式
Wake-up sensor: No可唤醒系统：不可以
Indicates the linear acceleration of the device in device coordinates, not including gravity. The output is conceptually:
output of TYPE_ACCELERATION minus output of TYPE_GRAVITY.
用于表示设备坐标系内的设备的线性加速度，不包括重力。输出是概念性的，该输出为：TYPE_ACCELERATION - TYPE_GRAVITY
Readings on all axes should be close to 0 when the device is immobile. Units are m/s^2. The coordinate system is the same as is used for the acceleration sensor.
设备静止时各坐标轴的读值都应该接近0.单位为m/s^2。坐标系同加速度传感器的坐标系。
Significant motion场景转移监测
Underlying base sensor(s): Accelerometer (or another as long as low power)依赖的基础传感器：加速度传感器(或其它低功耗传感器)
Trigger-mode: One-shot触发模式：单次触发
Wake-up sensor: Yes可唤醒系统：可以
Significant motion allows a device to stay in suspend and idle modes longer and save power. It does this by relying upon last known location until the device experiences "significant motion." Such a movement would trigger on mode and a call to retrieve new location.
场景监测允许设备长期处于休眠模式或空闲模式以达到省电目的。它通过基于已知的上次检测到的场景直到设备再经历一次场景转变而触发。就像一个运动(yasin：由先前的静止态到当前的运动态)将会触发一次新的场景检测调用。
Here is an example on how the platform can use significant motion to save power. When users are moving, their locations are updated frequently. After some period of inactivity, significant motion presumes the device is static and stops seeking location updates. It instead registers the last known location as valid. The device is then allowed to go into idle and then suspend mode.
来看一个关于平台如何利用“场景监测”来达到省电目的的例子。当用户处于移动状态，他们的位置信息会周期性改变。在一段非活动时间后，场景监测系统假设设备是静止的从而停止位置更新(yasin:也就是关闭GPS吧)，而同时会把上次的位置信息视为有效值进行注册(yasin:或进行上报)。接下来设备被允许进入空闲模式，继而进入休眠模式。
This sensor exists to save power by keeping the SoC in suspend mode when the device is at rest. A sensor of this type triggers an event each time significant motion is detected and automatically disables itself. The only allowed value to return is 1.0.
这种传感器的存在是为了在设备静止时能够让AP保持休眠状态从而达到省电目的。(yasin：本文中的SoC都应该被理解为AP，即应用处理器)。这种类型的传感器在检测到场景发生改变时上报一个事件而后立刻自动将自身禁止。其返回值只有1和0.
A significant motion is a motion that might lead to a change in the user location. Examples of such significant motions are:
场景监测用于指出用户所处环境场景的变化，这些可能的场景如下:
- walking or biking步行或骑行
- sitting in a moving car, coach or train在行驶的轿车内，在行驶的公共汽车内，或者在行驶的列车中
Examples of situations that should not trigger significant motion:
以下情景是不应该触发场景切换的:
- phone in pocket and person is not moving手机放在包里面并且用户没有位移
- phone is on a table and the table shakes a bit due to nearby traffic or washing machine手机放在桌面，但桌子由于附近过往的重型车辆或附近的洗衣机工作而引起桌面轻微晃动
This sensor makes a tradeoff for power consumption that may result in a small amount of false negatives. This is done for a few reasons:
这个传感器使得功耗上能够获得一个折衷的效果，同时导致一定量的误报(false negatives假阴性)
- The goal of this sensor is to save power.该传感器的目的就是降低功耗。
- Triggering an event when the user is not moving (false positive) is costly in terms of power, so it should be avoided.当用户没有移动时而触发了一个事件(这种事件是“假阳性”false positive)在功耗方面的代价是昂贵的。因此，这个事件应该是被避免的。
- Not triggering an event when the user is moving (false negative) is acceptable as long as it is not done repeatedly. If the user has been walking for 10 seconds, not triggering an event within those 10 seconds is not acceptable.在用户移动时却没有触发一个事件(这种事件是“假阴性”false negative)是可以被接受的，只要它没有被反复执行。（即只要下次用户移动是能够触发事件就没问题）。如果用户已经步行了10秒钟，而在这10秒内竟然没有触发事件，这是绝对不能接受的。
To ensure the applications have the time to receive the significant motion event before the application processor goes back to sleep, the driver must hold a "timeout wake lock" for 200 milliseconds for every wake-up sensor. That is, the application processor should not be allowed to go back to sleep in the 200 milliseconds following a wake-up interrupt.
为了确保应用程序在AP再次休眠之前能有足够的时间收到场景转变事件，这种具有唤醒AP功能的传感器驱动必须在中断发生后拿住一个至少200ms的“超时锁”。也就是说，AP在被一个这样的中断唤醒后，在接下来的200ms内是不允许再次进入休眠的。
Important: This sensor is very different from the other types in that it must work when the screen is off without the need for holding a partial wake lock (other than the timeout wake lock) and MUST allow the SoC to go into suspend. When significant motion is detected, the sensor must awaken the SoC and the event be reported.
重要：这个传感器和其它的有很大不同。因为在屏幕已经关闭的情况下，这个传感器也必须能工作，且不需要持有一个wake lock或者一个timeout wake lock，并且必须允许AP休眠。(yasin：换言之：这个传感器在AP已经休眠时依然能够独立工作，那么它必然是由sensor hub实现的)。当该传感器检测到场景变化后，它必须唤醒AP并将事件上报。
If a particular device cannot support this mode of operation, then this sensor type must not be reported by the HAL. ie: it is not acceptable to "emulate" this sensor in the HAL.
如果个别的设备不支持这种操作模式，那么这个传感器类型必须在HAL层被禁止。也就是：不允许在HAL层模拟出这个传感器类型。
When the sensor is not activated, it must also be deactivated in the hardware; it must not wake up the SoC anymore, even in case of significant motion.
如果该传感器处于非活动状态，那么它在硬件层面也必须是非活动状态的。这时它绝对禁止唤醒AP，哪怕此时发生了场景变化。
setDelay() has no effect and is ignored.该传感器无视setDelay()函数。
Once a "significant motion" event is returned, a sensor of this type must disable itself automatically, as if activate(..., 0) had been called.
当一个场景转变的事件被上报，该类型的传感器必须自动禁止自身。类似activate(..., 0)的函数会被调用。
Step detector步伐检测传感器
Underlying base sensor(s): Accelerometer 依赖的基础传感器：加速度传感器
Trigger-mode: Special 触发模式：特殊模式
Wake-up sensor: No 可唤醒系统：不可以
A sensor of this type triggers an event each time a step is taken by the user. The only allowed value to return is 1.0 and an event is generated for each step. Like with any other event, the timestamp indicates when the event (here the step) occurred. This corresponds to when the foot hit the ground, generating a high variation in acceleration.
该传感器在用户每走一步时都会触发一个事件。它的返回值为1.0并且每一步都会产生一个事件。像其它事件一样，会有一个时间戳用来指示事件发生的时间。这个时间对应的是用户的脚碰到地面的时刻，这个接触瞬间所产生的加速度变化最大。
Compared to the step counter, the step detector should have a lower latency (less than 2 seconds). Both the step detector and the step counter detect when the user is walking, running and walking up the stairs. They should not trigger when the user is biking, driving or in other vehicles.
和计步器相比，步伐检测传感器具有较小的时延特性(小于2秒)。步伐检测传感器和计步器两者都会在用户步行、跑动、或者爬楼梯时检测到用户行为。但是当用户处于骑行状态、驾车状态、或者处于其它运动的交通工具中时，这两个传感器是不应该触发事件的。
While this sensor operates, it shall not disrupt any other sensors, in particular, the accelerometer; it might very well be in use.
当操作这个传感器时，不应中断(或影响到)其它传感器的工作，尤其是加速度传感器，它很可能正在使用中。
This sensor must be low power. That is, if the step detection cannot be done in hardware, this sensor should not be defined. Also, when the step detector is activated and the accelerometer is not, only steps should trigger interrupts (not accelerometer data).
该传感器是一个低功耗设备。也就是说，如果步伐检测传感器没有被硬件实现(yasin:由类似sensor hub内的firmware算法实现)，就不应该定义这个传感器类型(yasin:选择为“不支持”)。同理，当步伐检测传感器处于活动状态，而加速度传感器却处于非活动状态时，则只有“步伐检测”会触发中断，而加速度传感器的数据不会被上报。(yasin:步伐检测是基于加速度传感器的一个虚拟设备，那么只要步伐检测传感器被打开时，加速度传感器必然是开着的，这是我们在底层看到的。但是上层是不知道也不关心这些的，上层看到了n多传感器，而且每个都是独立的、彼此没有耦合的。因此上层可以在打开步伐传感器的情况下关闭加速度传感器)
setDelay() has no impact on this sensor type. 对该传感器而言，setDelay()是无效的。
Step counter计步器
Underlying base sensor(s): Accelerometer 依赖的基础传感器：加速度传感器
Trigger-mode: On-change 触发模式：中断模式
Wake-up sensor: No 可唤醒系统：不可以
A sensor of this type returns the number of steps taken by the user since the last reboot while activated. The value is returned as a uint64_t and is reset to zero only on a system reboot.
该传感器返回自开机以来活动状态下用户的总的运动步数。该值类型为uint64_t，且只有当系统被重启后该值才会清零。
The timestamp of the event is set to the time when the last step for that event was taken.该事件的时间戳为最后一次步伐检测发生的时间。
See the Step detector sensor type for the signification of the time of a step.请参考“步伐检测传感器”部分对每一步的时间戳的解释。
Compared to the step detector, the step counter can have a higher latency (less than 10 seconds). Thanks to this latency, this sensor has a high accuracy; the step count after a full day of measures should be within 10% of the real step count. Both the step detector and the step counter detect when the user is walking, running and walking up the stairs. They should not trigger when the user is biking, driving or in other vehicles.
和步伐检测传感器相比，计步器拥有更高的时延特性(小于10秒)。得益于该时延性，该传感器拥有了很高的精度；计步器在使用一整天后，其测量值和真值的误差应该在10%以内。在用户步行、跑动、或者爬楼梯时步伐检测传感器和计步器二者都能够检测到。但是当用户处于骑行、驾车、或者在其他交通工具上时，这二者是不应该触发动作的。
Important note: This sensor is different from other types in that it must work when the screen is off without the need of holding a partial wake-lock and MUST allow the SoC to go into suspend.
注意：该传感器不同于其它传感器，该传感器在屏幕关闭状态下也能工作且不需要持有任何锁，即必须允许AP休眠。(yasin:该传感器完全由sensor hub实现，并且该传感器不会唤醒AP，AP在只在需要的时候读取该传感器的数据)
While in suspend mode this sensor must stay active. No events are reported during that time but steps continue to be accounted for; an event will be reported as soon as the SoC resumes if the timeout has expired.
在系统休眠后该传感器也必须处于工作状态。系统休眠期间不会有任何计步器事件被上报，但是计步器的计步动作还在工作(还在累加)。一旦系统唤醒，在计时器到期时，一个计步器事件会被立刻上报。(yasin:计步器工作在轮询模式，这个轮询周期可能比较长，或许超过10秒，所以说在系统醒着的时候，且轮询周期到达时计步器事件才会上报)
In other words, when the screen is off and the device is allowed to go into suspend mode, it should not be woken up, regardless of the setDelay() value. But the steps shall continue to be counted.
换言之，当屏幕关闭且允许系统进入休眠的情况下，系统就不应该因为计步器的计数更新而被唤醒，同时，也和setDelay() 的设置没有关系，但是系统休眠状态下计步器的计数动作会继续进行。(setDelay() 的轮询动作只会在系统醒着的时候进行，系统休眠后轮询就自动停止了)
The driver must however ensure the internal step count never overflows. The minimum size of the hardware's internal counter shall be 16 bits. (This restriction is here to avoid too frequent wake-ups when the delay is very large.) It is allowed in this situation to wake the SoC up so the driver can do the counter maintenance.
驱动必须确保任何时候计步器的计数都不会溢出。计步器的计数值存储单元至少都需要是16位的。(这个限制是为了避免当延时设置的很大时导致的过于频繁的系统唤醒) 。在这种情况下(指发生计数溢出的情况)允许唤醒AP，从而能够让驱动对该计数器进行维护(yasin:让计数器复位) (yasin：解释：计步器的值是轮询读取的，如果计步器的计数器很小，而轮询周期却很大，那么在每个轮询周期内都会发生计数溢出事件，从而导致系统被唤醒，因此，这个计数器的计数范围应该比较大才行。另外，从这里的描述推测，上层应该会在每个轮询周期内读取到当前的计数值，并把该值累加到一个上层的全局变量中，所以才会有前面提到的，所谓记录的是从开机到目前的总的步伐数。所以，对驱动而言，每次该计数器的值被读走后，都应该对该计数器清零！)
While this sensor operates, it shall not disrupt any other sensors, in particular, the accelerometer; it might very well be in use.
该传感器在工作时不应该破坏其他传感器的工作。尤其是加速度传感器！它可能正处于正常工作状态！
If a particular device cannot support these modes of operation, then this sensor type must not be reported by the HAL. ie: it is not acceptable to "emulate" this sensor in the HAL.
如果一个设备不能支持上述的这种互不影响的操作行为，那么HAL层就应标明该传感器为不支持类型。也就是：不允许在HAL层模拟出这个传感器类型。
This sensor must be low power. That is, if the step detection cannot be done in hardware, this sensor should not be defined. Also, when the step counter is activated and the accelerometer is not, only steps should trigger interrupts (not accelerometer data).
这是一个低功耗的传感器。就是说，如果步伐检测功能不能够在硬件层面实现的话，软件就不应定义这个传感器。还有，从上层看：计步器工作时允许加速度传感器是非工作状态，如果上层选择让计步器工作而同时关闭加速度传感器，那么就只会有计步器的中断产生而非加速度的。(yasin:我们很清楚，计步器在硬件层面是基于重力加速度传感器的数据的，也就是计步器工作时，加速度传感器必然是开着的。但是你要注意，这里强调了：从上层的角度来看！)
Attitude sensors姿态传感器
Rotation vector旋转矢量
Underlying base sensor(s): Accelerometer, Gyroscope AND Magnetometer 依赖的基础传感器：加速度传感器，陀螺仪和指南针
Trigger-mode: Continuous 触发模式：轮询模式
Wake-up sensor: No 可唤醒系统：不可以
The rotation vector symbolizes the orientation of the device relative to the East-North-Up coordinates frame. It is usually obtained by integration of accelerometer, gyroscope and magnetometer readings.旋转矢量表示的是以“站心坐标系”为相对参考的设备的方向。该矢量通常是由加速度传感器、陀螺仪、以及指南针这三者的数据进行融合而求得的。
The East-North-Up coordinate system is defined as a direct orthonormal basis where: 站心坐标系被定义为一个直接的标准正交基：
- X points east and is tangential to the ground. X指向东并且与地面相切。
- Y points north and is tangential to the ground. Y指向北并且与地面相切。
- Z points towards the sky and is perpendicular to the ground. Z指向天空并且垂直于地面。
The orientation of the phone is represented by the rotation necessary to align the East-North-Up coordinates with the phone's coordinates. That is, applying the rotation to the world frame (X,Y,Z) would align them with the phone coordinates (x,y,z).
The rotation can be seen as rotating the phone by an angle theta around an axis rot_axis to go from the reference (East-North-Up aligned) device orientation to the current device orientation.
The rotation is encoded as the four (reordered) 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)
Where:
- rot_axis.x,y,z are the North-East-Up coordinates of a unit length vector representing the rotation axis
- theta is the rotation angle
The quaternion must be of norm 1. (It is a unit quaternion.) Failure to ensure this will cause erratic client behaviour.
In addition, this sensor reports an estimated heading accuracy:
sensors_event_t.data[4] = estimated_accuracy (in radians)
The heading error must be less than estimated_accuracy 95% of the time. This sensor must use a gyroscope and an accelerometer as main orientation change input.
This sensor should also include magnetometer input to make up for gyro drift, but it cannot be implemented using only a magnetometer.
Game rotation vector
Underlying base sensor(s): Accelerometer, Gyroscope NOT Magnetometer
Trigger-mode: Continuous
Wake-up sensor: No
Similar to the rotation vector sensor but not using the geomagnetic field. Therefore the Y axis doesn't point north but instead to some other reference. That reference is allowed to drift by the same order of magnitude as the gyroscope drifts around the Z axis.
This sensor does not report an estimated heading accuracy:
sensors_event_t.data[4] is reserved and should be set to 0
In an ideal case, a phone rotated and returned to the same real-world orientation should report the same game rotation vector (without using the earth's geomagnetic field).
This sensor must be based on a gyroscope. It cannot be implemented using a magnetometer.
Gravity
Underlying base sensor(s): Accelerometer, Gyroscope NOT Magnetometer
Trigger-mode: Continuous
Wake-up sensor: No
The gravity output of this sensor indicates the direction and magnitude of gravity in the device's coordinates. Units are m/s^2. On Earth, the magnitude is 9.8 m/s^2. The coordinate system is the same as is used for the acceleration sensor. When the device is at rest, the output of the gravity sensor should be identical to that of the accelerometer.
Geomagnetic rotation vector (Magnetometer)
Underlying base sensor(s): Accelerometer, Magnetometer NOT Gyroscope
Trigger-mode: Continuous
Wake-up sensor: No
This sensor is similar to the rotation vector sensor but using a magnetometer instead of a gyroscope.
This sensor must be based on a magnetometer. It cannot be implemented using a gyroscope, and gyroscope input cannot be used by this sensor.
Just like the rotation vector sensor, this sensor reports an estimated heading accuracy:
sensors_event_t.data[4] = estimated_accuracy (in radians)
The heading error must be less than estimated_accuracy 95% of the time.
See the rotation vector sensor description for more details.
Orientation
Underlying base sensor(s): Accelerometer, Magnetometer PREFERRED Gyroscope
Trigger-mode: Continuous
Wake-up sensor: No
Note: This is an older sensor type that has been deprecated in the Android SDK although not yet in the HAL. It has been replaced by the rotation vector sensor, which is more clearly defined, requires a gyroscope, and therefore provides more accurate results. Use the rotation vector sensor over the orientation sensor whenever possible.
The orientation sensor tracks the attitude of the device. All values are angles in degrees. Orientation sensors return sensor events for all three axes at a constant rate defined by setDelay().
- azimuth: angle between the magnetic north direction and the Y axis, around
the Z axis (0<=azimuth<360). 0=North, 90=East, 180=South, 270=West - pitch: Rotation around X axis (-180<=pitch<=180), with positive values when the z-axis moves toward the y-axis.
- roll: Rotation around Y axis (-90<=roll<=90), with positive values when the x-axis moves towards the z-axis.
Please note, for historical reasons the roll angle is positive in the clockwise direction. (Mathematically speaking, it should be positive in the counter-clockwise direction):
Figure 2. Orientation relative to a device.
This definition is different from yaw, pitch and roll used in aviation where the X axis is along the long side of the plane (tail to nose).
Uncalibrated sensors
Uncalibrated sensors provide more raw results and may include some bias but also contain fewer "jumps" from corrections applied through calibration. Some applications may prefer these uncalibrated results as smoother and more reliable. For instance, if an application is attempting to conduct its own sensor fusion, introducing calibrations can actually distort results.
Gyroscope uncalibrated
Underlying base sensor(s): Gyroscope
Trigger-mode: Continuous
Wake-up sensor: No
The uncalibrated gyroscope is useful for post-processing and melding orientation data. All values are in radians/second and measure the rate of rotation around the X, Y and Z axis. An estimation of the drift on each axis is reported as well.
No gyro-drift compensation shall be performed. Factory calibration and temperature compensation should still be applied to the rate of rotation (angular speeds).
The coordinate system is the same as is used for the acceleration sensor. Rotation is positive in the counter-clockwise direction (right-hand rule). That is, an observer looking from some positive location on the x, y or z axis at a device positioned on the origin would report positive rotation if the device appeared to be rotating counter clockwise. Note that this is the standard mathematical definition of positive rotation and does not agree with the definition of roll given elsewhere.
The range should at least be 17.45 rad/s (ie: ~1000 deg/s).
Content of an uncalibrated_gyro event (units are rad/sec):
- x_uncalib : angular speed (w/o drift compensation) around the X axis
- y_uncalib : angular speed (w/o drift compensation) around the Y axis
- z_uncalib : angular speed (w/o drift compensation) around the Z axis
- x_bias : estimated drift around X axis in rad/s
- y_bias : estimated drift around Y axis in rad/s
- z_bias : estimated drift around Z axis in rad/s
If the implementation is not able to estimate the drift, then this sensor must not be reported by this HAL. Instead, the regular Gyroscope sensor is used without drift compensation.
If this sensor is present, then the corresponding Gyroscope sensor must be present and both must return the same sensor_t::name and sensor_t::vendor.
Magnetic field uncalibrated
Underlying base sensor(s): Magnetometer
Trigger-mode: Continuous
Wake-up sensor: No
Similar to Geomagnetic field sensor, but the hard iron calibration is reported separately instead of being included in the measurement. The uncalibrated magnetometer allows the system to handle bad hard iron estimation.
Factory calibration and temperature compensation should still be applied to the "uncalibrated" measurement. Separating away the hard iron calibration estimation allows the system to better recover from bad hard iron estimation.
All values are in micro-Tesla (uT) and measure the ambient magnetic field in the X, Y and Z axis. Assumptions that the magnetic field is due to the Earth's poles should be avoided.
The uncalibrated_magnetic event contains three fields for uncalibrated measurement: x_uncalib, y_uncalib, z_uncalib. Each is a component of the measured magnetic field, with soft iron and temperature compensation applied, but not hard iron calibration. These values should be continuous (no re-calibration should cause a jump).
The uncalibrated_magnetic event contains three fields for hard iron bias estimates: x_bias, y_bias, z_bias. Each field is a component of the estimated hard iron calibration. They represent the offsets to apply to the calibrated readings to obtain uncalibrated readings (x_uncalib ~= x_calibrated + x_bias). These values are expected to jump as soon as the estimate of the hard iron changes, and they should be stable the rest of the time.
If this sensor is present, then the corresponding Geomagnetic field sensor must be present and both must return the same sensor_t::name and sensor_t::vendor.
See the geomagnetic field sensor description for more information.