Google is committed to advancing racial equity for Black communities. See how.
本頁面由 Cloud Translation API 翻譯而成。
Switch to English

傳感器類型

本節介紹傳感器軸,基本傳感器和復合傳感器(活動,姿態,未校準和交互)。

傳感器軸

來自許多傳感器的傳感器事件值以相對於設備靜態的特定幀表示。

移動設備軸

Sensor API僅與屏幕的自然方向相關(當設備的屏幕方向更改時,不會交換軸。

移動設備傳感器API的坐標系

圖1. Sensor API使用的坐標系(相對於移動設備)

汽車軸

在Android Automotive實現中,相對於車體框架定義了軸。

汽車設備傳感器API的坐標系

圖2. Sensor API使用的坐標系(相對於汽車設備)

  • X向車輛右側增加
  • Y向著身體的鼻子增加
  • Z朝向車身框架的頂部增大

坐標系的原點位於車輛後軸的中心。從軸的正方向看時,正旋轉為逆時針方向。因此,當車輛向左轉彎時,z軸陀螺儀的轉彎速率被期望為正值。

基本傳感器

基本傳感器類型以它們代表的物理傳感器命名。這些傳感器中繼來自單個物理傳感器的數據(與從其他傳感器生成數據的複合傳感器相反)。基本傳感器類型的示例包括:

  • SENSOR_TYPE_ACCELEROMETER
  • SENSOR_TYPE_GYROSCOPE
  • SENSOR_TYPE_MAGNETOMETER

但是,基本傳感器並不等於其基礎物理傳感器,也不應與其混淆。來自基礎傳感器的數據不是物理傳感器的原始輸出,因為應用了校正(例如偏差補償和溫度補償)。

例如,在以下使用情況下,基本傳感器的特性可能與其基礎物理傳感器的特性不同:

  • 陀螺儀芯片的額定偏置範圍為1度/秒。
    • 經過工廠校準,溫度補償和偏置補償後,Android傳感器的實際偏置將減小,可能會保證偏置低於0.01度/秒。
    • 在這種情況下,我們說Android傳感器的偏差低於0.01度/秒,即使底層傳感器的數據表中的偏差為1度/秒。
  • 功耗為100 uW的氣壓計。
    • 由於生成的數據需要從芯片傳輸到SoC,因此從氣壓計Android傳感器收集數據的實際功耗可能會更高,例如1000 uW。
    • 在這種情況下,我們說Android傳感器的功耗為1000 uW,即使在氣壓計芯片引線處測得的功耗為100uW。
  • 校準時消耗100uW的磁力計,但校準時消耗更多。
    • 它的校準例程可能需要激活陀螺儀,消耗5000 uW,並運行某種算法,花費另外900 uW。
    • 在這種情況下,我們說(磁力計)Android傳感器的最大功耗為6000 uW。
    • 在這種情況下,平均功耗是更有用的度量,它是通過HAL在傳感器靜態特性中報告的。

加速度計

報告方式:連續

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER)返回非喚醒傳感器

加速度傳感器報告設備沿三個傳感器軸的加速度。測得的加速度包括物理加速度(速度變化)和重力。測量值在sensor_event_t.acceleration的x,y和z字段中報告。

所有值均以SI單位(m / s ^ 2)為單位,並測量設備的加速度減去沿三個傳感器軸的重力。

以下是示例:

  • 自由落體時(x,y,z)的範數應接近0。
  • 當設備平放在桌子上並將其左側推向右側時,x加速度值為正。
  • 當設備平放在桌子上時,沿z的加速度值為+9.81 alo,這對應於設備的加速度(0 m / s ^ 2)減去重力(-9.81 m / s ^ 2)。
  • 當設備平放在桌子上並推向天空時,加速度值大於+9.81,這對應於設備的加速度(+ A m / s ^ 2)減去重力(-9.81 m / s ^ 2)。

讀數使用以下方法校準:

  • 溫度補償
  • 在線偏差校準
  • 在線秤校準

僅在停用傳感器的情況下,才必須更新偏置和比例尺校準,以避免在流式傳輸期間導致值跳變。

加速度計還通過sensors_event_t.acceleration.status報告期望讀數的sensors_event_t.acceleration.status 。有關此字段的可能值的更多信息,請參見SensorManagerSENSOR_STATUS_*常量。

環境溫度

報表模式:變更中

getDefaultSensor(SENSOR_TYPE_AMBIENT_TEMPERATURE)返回非喚醒傳感器

該傳感器提供攝氏溫度(室溫)。

磁場傳感器

報告方式:連續

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD)返回非喚醒傳感器

SENSOR_TYPE_GEOMAGNETIC_FIELD == SENSOR_TYPE_MAGNETIC_FIELD

磁場傳感器(也稱為磁力計)報告沿三個傳感器軸測得的環境磁場。

測量值在sensors_event_t.magnetic的x,y和z字段中sensors_event_t.magnetic ,所有值均在微特斯拉(uT)中。

磁力計還通過sensors_event_t.magnetic.status報告了期望讀數的sensors_event_t.magnetic.status 。有關此字段的可能值的更多信息,請參見SensorManagerSENSOR_STATUS_*常量。

讀數通過以下方式校準:

  • 溫度補償
  • 工廠(或在線)軟鐵校準
  • 在線硬鐵校準

陀螺儀

報告方式:連續

getDefaultSensor(SENSOR_TYPE_GYROSCOPE)返回非喚醒傳感器

陀螺儀傳感器報告設備圍繞三個傳感器軸的旋轉速率。

逆時針方向旋轉為正(右手定則)。也就是說,如果觀察者從x,y或z軸上某個正位置看向位於原點的設備,則該觀察者將報告正旋轉,如果該設備看起來是逆時針旋轉的話。請注意,這是正向旋轉的標準數學定義,與滾動的航空航天定義不同。

測量值在sensors_event_t.gyro的x,y和z字段中sensors_event_t.gyro ,所有值均以弧度/秒(rad / s)為單位。

讀數通過以下方式校準:

  • 溫度補償
  • 工廠(或在線)規模補償
  • 在線偏置校準(消除漂移)

陀螺儀還通過sensors_event_t.gyro.status報告期望讀數的sensors_event_t.gyro.status 。有關此字段的可能值的更多信息,請參見SensorManagerSENSOR_STATUS_*常量。

陀螺儀無法基於磁力計和加速度計進行仿真,因為這將導致陀螺儀的局部一致性和響應性降低。它必須基於常用的陀螺儀芯片。

心率

報表模式:變更中

getDefaultSensor(SENSOR_TYPE_HEART_RATE)返回非喚醒傳感器

心率傳感器報告觸摸設備的人的當前心率。

當前心跳率(每分鐘心跳數(BPM))在sensors_event_t.heart_rate.bpm中報告,傳感器的狀態在sensors_event_t.heart_rate.status報告。有關此字段的可能值的更多信息,請參見SensorManagerSENSOR_STATUS_*常量。特別是,在首次激活時,除非已知設備不在人體上,否則必須將第一事件的狀態字段設置為SENSOR_STATUS_UNRELIABLE 。由於此傳感器處於更改狀態,因此僅在自上一個事件以來heart_rate.bpmheart_rate.status發生更改時heart_rate.bpm生成事件。生成事件的速度不會比每個sampling_period更快。

sensor_t.requiredPermission始終為SENSOR_PERMISSION_BODY_SENSORS

報表模式:變更中

getDefaultSensor(SENSOR_TYPE_LIGHT)返回非喚醒傳感器

光傳感器以SI lux單位報告當前照度。

該測量結果在sensors_event_t.light報告。

接近

報表模式:變更中

通常定義為喚醒傳感器

getDefaultSensor(SENSOR_TYPE_PROXIMITY)返回喚醒傳感器

接近傳感器報告從傳感器到最近的可見表面的距離。

在Android 4.4之前的版本中,接近傳感器始終是喚醒傳感器,當檢測到接近變化時會喚醒SoC。在Android 4.4之後,我們建議您首先實現此傳感器的喚醒版本,因為它是在撥打電話時用於打開和關閉屏幕的傳感器。

測量值以厘米為單位在sensors_event_t.distance報告。請注意,某些接近傳感器僅支持二進制“近”或“遠”測量。在這種情況下,傳感器在“遠”狀態下報告其sensor_t.maxRange值,在“近”狀態下報告小於sensor_t.maxRange的值。

壓力

報告方式:連續

getDefaultSensor(SENSOR_TYPE_PRESSURE)返回非喚醒傳感器

壓力傳感器(也稱為氣壓計)以百帕斯卡(hPa)為單位報告大氣壓。

讀數使用

  • 溫度補償
  • 工廠偏差校準
  • 工廠規模校準

氣壓計通常用於估計高程變化。要估算絕對海拔,必須使用海平面壓力(隨天氣變化而變化)作為參考。

相對濕度

報表模式:變更中

getDefaultSensor(SENSOR_TYPE_RELATIVE_HUMIDITY)返回非喚醒傳感器

相對濕度傳感器測量相對環境空氣濕度並返回百分比值。

複合傳感器類型

複合傳感器通過處理和/或融合來自一個或多個物理傳感器的數據來生成數據。 (不是基礎傳感器的任何傳感器都稱為複合傳感器。)複合傳感器的示例包括:

與基本傳感器一樣,複合傳感器的特性來自其最終數據的特性。例如,遊戲旋轉向量的功耗可能等於加速度計芯片,陀螺儀芯片,處理數據的芯片以及傳輸數據的總線的功耗之和。作為另一個例子,遊戲旋轉向量的漂移取決於校準算法的質量以及取決於物理傳感器特性。

下表列出了可用的複合傳感器類型。每個複合傳感器都依賴於一個或多個物理傳感器的數據。避免選擇其他潛在的物理傳感器來近似結果,因為它們會帶來糟糕的用戶體驗。

感應器類型類別底層物理傳感器報告方式

遊戲旋轉矢量

態度

加速度計,陀螺儀,不得使用磁力計

連續

地磁旋轉矢量低功率傳感器

態度

加速度計,磁力計,不得使用陀螺儀

連續

掃視手勢低功率傳感器

相互作用

未定義

一槍

重力

態度

加速度計,陀螺儀

連續

陀螺儀未校準

未校準

陀螺儀

連續

線性加速度

活動

加速度計,陀螺儀(如果有)或磁力計(如果沒有陀螺儀)

連續

磁場未校準

未校準

磁力計

連續

方向(不建議使用)

態度

加速度計,磁力計,陀螺儀(如果有)

連續

拿起手勢低功率傳感器

相互作用

未定義

一槍

旋轉矢量

態度

加速度計,磁力計,陀螺儀

連續

重大運動低功率傳感器

活動

加速度計(或其他只要極低功率的加速度計)

一槍

步數計數器低功率傳感器

活動

加速度計

不斷變化

步進檢測器低功率傳感器

活動

加速度計

特別

傾斜探測器低功率傳感器

活動

加速度計

特別

喚醒手勢低功率傳感器

相互作用

未定義

一槍

低功率傳感器 =低功率傳感器

活動複合傳感器

線性加速度

底層物理傳感器:加速度計和陀螺儀(如果有)(如果沒有陀螺儀,則是磁力計)

報告方式:連續

getDefaultSensor(SENSOR_TYPE_LINEAR_ACCELERATION)返回非喚醒傳感器

線性加速度傳感器報告設備在傳感器框架中的線性加速度,不包括重力。

輸出在概念上是:加速度計的輸出減去重力傳感器的輸出。它以m / s ^ 2的形式在sensors_event_t.acceleration的x,y和z字段中sensors_event_t.acceleration

當設備靜止時,所有軸上的讀數應接近於0。

如果設備具有陀螺儀,則線性加速度傳感器必須使用陀螺儀和加速度計作為輸入。

如果設備沒有陀螺儀,則線性加速度傳感器必須使用加速度計和磁力計作為輸入。

重大運動

底層物理傳感器:加速度計(或其他只要低功率的傳感器)

報告模式:單發

低電量

僅實現此傳感器的喚醒版本。

getDefaultSensor(SENSOR_TYPE_SIGNIFICANT_MOTION)返回喚醒傳感器

重要運動檢測器在檢測到重要運動時觸發:可能導致用戶位置發生變化的運動。

此類重大議案的示例包括:

  • 步行或騎自行車
  • 坐在移動的汽車,長途汽車或火車上

不會觸發明顯運動的情況示例:

  • 手機放在口袋裡,人不動
  • 手機在桌子上,桌子因附近的交通或洗衣機晃動了一下

在較高級別,有效運動檢測器用於減少位置確定的功耗。當定位算法檢測到設備是靜態的時,它們可以切換到低功耗模式,在這種模式下,當用戶更改位置時,它們依靠大量運動來喚醒設備。

該傳感器必須是低功率的。它需要權衡功耗,從而可能導致少量誤報。這樣做有幾個原因:

  • 該傳感器的目的是節省電量。
  • 在用戶不動時觸發事件(誤報)會耗費大量動力,因此應避免使用。
  • 只要用戶不重複操作,就不觸發事件(錯誤否定)。如果用戶已經走了10秒鐘,那麼在這10秒鐘之內不觸發事件是不可接受的。

每個傳感器事件在sensors_event_t.data[0]報告1

步進檢測器

底層物理傳感器:加速度計(可能還包括其他只要低功率的傳感器)

報告模式:特殊(每步驟執行一個事件)

低電量

getDefaultSensor(SENSOR_TYPE_STEP_DETECTOR)返回非喚醒傳感器

每次用戶執行步驟時,步檢測器都會生成一個事件。

事件sensors_event_t.timestamp的時間戳對應於腳踩到地面的時間,從而產生很大的加速度變化。

與步進計數器相比,步進檢測器應具有較低的等待時間(少於兩秒)。踏步檢測器和踏步計數器都檢測用戶何時走路,跑步和上樓梯。當用戶騎自行車,駕駛或乘坐其他車輛時,它們不應觸發。

該傳感器必須是低功率的。也就是說,如果無法通過硬件完成步進檢測,則不應定義此傳感器。特別是,當步進檢測器被激活而加速度計未激活時,只有步進才應觸發中斷(並非每個加速度計讀數)。

sampling_period_ns對階躍檢測器沒有影響。

每個傳感器事件在sensors_event_t.data[0]報告1

步數計數器

底層物理傳感器:加速度計(可能還包括其他只要低功率的傳感器)

報表模式:變更中

低電量

getDefaultSensor(SENSOR_TYPE_STEP_COUNTER)返回非喚醒傳感器

步數計數器報告自激活後的最後一次重新啟動以來用戶所採取的步數。

測量值在sensors_event_t.step_counter報告為uint64_t ,並且僅在系統重新啟動時才重置為零。

事件的時間戳設置為採取該事件的最後一步的時間。

有關步進時間的含義,請參見步進檢測器傳感器類型。

與步進檢測器相比,步進計數器可能具有更高的延遲(最多10秒)。由於這種延遲,該傳感器具有很高的精度;一整天的措施後,步數應在實際步數的10%以內。踏步檢測器和踏步計數器都檢測用戶何時走路,跑步和上樓梯。當用戶騎自行車,駕駛或乘坐其他車輛時,它們不應觸發。

硬件必須確保內部步數不會溢出。硬件內部計數器的最小大小應為16位。在即將發生溢出的情況下(最多每2 ^ 16步),可以喚醒SoC,以便驅動程序可以進行計數器維護。

如“交互”中所述,當此傳感器運行時,不得破壞任何其他可能正在使用的傳感器,尤其是加速度計。

如果特定設備不支持這些操作模式,則HAL不得報告此傳感器類型。也就是說,在HAL中“模擬”此傳感器是不可接受的。

該傳感器必須是低功率的。也就是說,如果無法在硬件中完成步進檢測,則不應定義此傳感器。特別是,當激活了步數計數器而未激活加速計時,只有步應觸發中斷(而不是加速計數據)。

傾斜探測器

底層物理傳感器:加速度計(可能還包括其他只要低功率的傳感器)

報告方式:特殊

低電量

僅實現此傳感器的喚醒版本。

getDefaultSensor(SENSOR_TYPE_TILT_DETECTOR)返回喚醒傳感器

每次檢測到傾斜事件時,傾斜檢測器都會生成一個事件。

自傳感器激活或發生最後一次事件以來,2秒窗口平均重力的方向至少改變35度來定義傾斜事件。這是算法:

  • reference_estimated_gravity =激活後第一秒內加速度計測量值的平均值,或者最後一次傾斜事件發生時的估計重力。
  • current_estimated_gravity =最近2秒鐘內加速度計測量值的平均值。
  • angle(reference_estimated_gravity, current_estimated_gravity) > 35 degrees時觸發

沒有改變手機方向的大加速度不會觸發傾斜事件。例如,即使平均加速度的角度變化可能超過35度,駕駛汽車時急轉彎或強烈加速也不應觸發傾斜事件。通常,該傳感器僅借助加速度計來實現。如果其他傳感器不會顯著增加功耗,則也可以使用它們。這是一個低功耗傳感器,應允許SoC進入掛起模式。不要在HAL中模擬該傳感器。每個傳感器事件在sensors_event_t.data[0]報告1

姿態復合傳感器

旋轉矢量

底層物理傳感器:加速度計,磁力計和陀螺儀

報告方式:連續

getDefaultSensor(SENSOR_TYPE_ROTATION_VECTOR)返回非喚醒傳感器

旋轉矢量傳感器報告設備相對於東西北坐標系的方向。通常通過集成加速度計,陀螺儀和磁力計讀數獲得。東-北-上坐標係被定義為直接正交基礎,其中:

  • X指向東方並與地面相切。
  • Y指向北並與地面相切。
  • Z指向天空並垂直於地面。

手機的方向由將東西向北坐標與手機坐標對齊所需的旋轉表示。也就是說,將旋轉應用於世界框架(X,Y,Z)將使它們與電話坐標(x,y,z)對齊。

旋轉可以看作是圍繞軸rot_axis將手機旋轉了一個角度theta,從參考(東-北-上對齊)設備方向轉到當前設備方向。旋轉編碼為單位四元數的四個無單位的x,y,z,w分量:

  • 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)

哪裡:

  • rot_axis的x,y和z字段是表示旋轉軸的單位長度向量的East-North-Up坐標
  • theta是旋轉角度

四元數是單位四元數:必須為範數1 。無法確保這樣做將導致不穩定的客戶端行為。

此外,此傳感器報告了估計的航向精度:

sensors_event_t.data[4] = estimated_accuracy (以弧度為單位)

航向誤差必須在95%的時間內小於estimated_accuracy精度。該傳感器必須使用陀螺儀作為主要方向更改輸入。

該傳感器還使用加速度計和磁力計輸入來補償陀螺儀的漂移,不能僅使用加速度計和磁力計來實現。

遊戲旋轉矢量

底層物理傳感器:加速度計和陀螺儀(無磁力計)

報告方式:連續

getDefaultSensor(SENSOR_TYPE_GAME_ROTATION_VECTOR)返回非喚醒傳感器

遊戲旋轉矢量傳感器類似於旋轉矢量傳感器,但不使用地磁場。因此,Y軸不是指向北,而是指向其他參考。與陀螺儀繞Z軸漂移時,該參考點可以漂移相同的數量級。

有關如何設置sensors_event_t.data[0-3]詳細信息,請參見旋轉矢量傳感器。該傳感器沒有報告估計的航向精度: sensors_event_t.data[4]已保留,應設置為0

在理想情況下,旋轉並返回相同現實方向的手機應報告相同的遊戲旋轉向量。

該傳感器必須基於陀螺儀和加速度計。除了間接地通過陀螺儀偏置估計之外,它不能使用磁力計作為輸入。

重力

底層物理傳感器:加速度計和陀螺儀(如果有)(如果沒有陀螺儀,則是磁力計)

報告方式:連續

getDefaultSensor(SENSOR_TYPE_GRAVITY)返回非喚醒傳感器

重力傳感器在設備坐標中報告重力的方向和大小。

重力矢量分量在sensors_event_t.acceleration的x,y和z字段中以m / s ^ 2 sensors_event_t.acceleration

當設備處於靜止狀態時,重力傳感器的輸出應與加速度計的輸出相同。在地球上,震級約為9.8 m / s ^ 2。

如果設備具有陀螺儀,則重力傳感器必須使用陀螺儀和加速度計作為輸入。

如果設備沒有陀螺儀,則重力傳感器必須使用加速度計和磁力計作為輸入。

地磁旋轉矢量

底層物理傳感器:加速度計和磁力計(無陀螺儀)

報告方式:連續

低電量

getDefaultSensor(SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR)返回非喚醒傳感器

地磁旋轉矢量類似於旋轉矢量傳感器,但使用磁力計而不使用陀螺儀。

該傳感器必須基於磁力計。它不能使用陀螺儀來實現,並且該傳感器不能使用陀螺儀輸入。

有關如何設置sensors_event_t.data[0-4]詳細信息,請參見旋轉矢量傳感器。

就像旋轉矢量傳感器一樣,航向誤差必須在95%的時間內小於估計的精度( sensors_event_t.data[4] )。

該傳感器必須是低功率的,因此必須以硬件實現。

方向(不建議使用)

底層物理傳感器:加速度計,磁力計和陀螺儀(如果有)

報告方式:連續

getDefaultSensor(SENSOR_TYPE_ORIENTATION)返回非喚醒傳感器

注意:這是Android SDK中已棄用的較舊的傳感器類型。它已由更明確定義的旋轉矢量傳感器代替。盡可能在方向傳感器上使用旋轉矢量傳感器。

方向傳感器報告設備的姿態。在sensors_event_t.orientation的x,y和z字段中以度為單位報告測量結果:

  • sensors_event_t.orientation.x :方位角,即磁北方向與Y軸之間的角度,圍繞Z軸( 0<=azimuth<360 )。 0 =北部,90 =東部,180 =南部,270 =西部。
  • sensors_event_t.orientation.y :螺距,繞X軸旋轉( -180<=pitch<=180 ),當Z軸朝Y軸移動時具有正值。
  • sensors_event_t.orientation.z :滾動,繞Y軸旋轉( -90<=roll<=90 ),當X軸朝向Z軸移動時具有正值。

請注意,由於歷史原因,側傾角在順時針方向上為正。 (從數學上講,它應在逆時針方向上為正):

相對於設備的方向描述

圖3.相對於設備的方向

此定義不同於航空中使用的偏航角,俯仰角和側傾角,其中X軸沿著飛機的長邊(從尾到鼻子)。

方向傳感器還通過sensors_event_t.orientation.status報告期望讀數的sensors_event_t.orientation.status 。有關此字段的可能值的更多信息,請參見SensorManagerSENSOR_STATUS_*常量。

未校準的傳感器

未經校準的傳感器可提供更多的原始結果,並且可能會包含一些偏差,但通過校准進行的校正也會包含較少的“跳躍”。某些應用可能更喜歡這些未經校準的結果,因為它們更平滑,更可靠。例如,如果某個應用嘗試進行自己的傳感器融合,則引入校準實際上會扭曲結果。

加速度計未校準

底層物理傳感器:加速度計

報告方式:連續

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_UNCALIBRATED)返回非喚醒傳感器

未經校準的加速度計傳感器會報告設備沿三個傳感器軸的加速度,而無需進行任何偏差校正(將工廠偏差和溫度補償應用於未經校準的測量)以及偏差估計。所有值均以SI單位(m / s ^ 2)為單位,並在sensors_event_t.uncalibrated_accelerometer的字段中sensors_event_t.uncalibrated_accelerometer

  • x_uncalib :沿X軸的加速度(無偏置補償)
  • y_uncalib :沿Y軸的加速度(無偏置補償)
  • z_uncalib :沿Z軸的加速度(無偏置補償)
  • x_bias :沿X軸的估計偏差
  • y_bias :沿Y軸的估計偏差
  • z_bias :沿Z軸的估計偏差

陀螺儀未校準

底層物理傳感器:陀螺儀

報告方式:連續

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_UNCALIBRATED)返回非喚醒傳感器

未經校準的陀螺儀會報告圍繞傳感器軸的旋轉速率,而不會對傳感器軸施加偏差補償以及偏差估計。所有值均以弧度/秒為單位,並在sensors_event_t.uncalibrated_gyro字段中sensors_event_t.uncalibrated_gyro

  • x_uncalib :繞X軸的角速度(無漂移補償)
  • y_uncalib :繞Y軸的角速度(無漂移補償)
  • z_uncalib :繞Z軸的角速度(無漂移補償)
  • x_bias :估計的繞X軸的漂移
  • y_bias :估計的繞Y軸的漂移
  • z_bias :估計的繞Z軸的漂移

從概念上講,未校準的測量值是已校準的測量值和偏差估計值的總和: _uncalibrated = _calibrated + _bias

x_biasy_biasz_bias值會在偏差的估算值發生變化時立即跳變,並且在其餘時間內應該保持穩定。

有關使用的坐標系的詳細信息,請參見陀螺儀傳感器的定義。

必須將工廠校準和溫度補償應用於測量。另外,必須執行陀螺儀漂移估算,以便可以在x_biasy_biasz_bias報告合理的估算。如果實施方案無法估計漂移,則不得實施此傳感器。

如果存在此傳感器,則還必須存在相應的陀螺儀傳感器,並且兩個傳感器必須共享相同的sensor_t.namesensor_t.vendor值。

磁場未校準

底層物理傳感器:磁力計

報告方式:連續

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED)返回非喚醒傳感器

未校準的磁場傳感器會報告環境磁場以及硬鐵校準估算值。所有值均以微特斯拉(uT)為單位,並在sensors_event_t.uncalibrated_magnetic字段中sensors_event_t.uncalibrated_magnetic

  • x_uncalib :沿X軸的磁場(無硬鐵補償)
  • y_uncalib :沿Y軸的磁場(無硬鐵補償)
  • z_uncalib :沿Z軸的磁場(無硬鐵補償)
  • x_bias :沿X軸的估計鐵偏置
  • y_bias :沿Y軸的估計鐵偏置
  • z_bias :沿Z軸的估計鐵偏置

從概念上講,未校準的測量值是已校準的測量值和偏差估計值的總和: _uncalibrated = _calibrated + _bias

未經校準的磁力計允許更高級別的算法處理不良的鐵估算。預計x_biasy_biasz_bias值會在估計硬鐵變化時立即跳躍,並且在其餘時間內應該保持穩定。

測量中必須使用軟鐵校準和溫度補償。另外,必須實施硬鐵估算,以便可以在x_biasy_biasz_bias報告合理的估算。如果實施方案無法估計偏差,則不得實施此傳感器。

如果存在此傳感器,則必須存在相應的磁場傳感器,並且兩個傳感器必須共享相同的sensor_t.namesensor_t.vendor值。

鉸鏈角

報表模式:變更中

getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)返回喚醒傳感器

鉸鏈角度傳感器測量設備的兩個整體部分之間的角度(以度為單位)。預期通過這種傳感器類型測量的鉸鏈的移動會改變用戶與設備交互的方式,例如,通過展開或露出顯示器。

互動式複合傳感器

一些傳感器主要用於檢測與用戶的交互。我們沒有定義這些傳感器的實現方式,但是它們必須是低功耗的,設備製造商有責任根據用戶體驗驗證其質量。

喚醒手勢

底層物理傳感器:未定義(任何低功耗)

Reporting-mode: One-shot

Low-power

Implement only the wake-up version of this sensor.

getDefaultSensor(SENSOR_TYPE_WAKE_GESTURE) returns a wake-up sensor

A wake up gesture sensor enables waking up the device based on a device specific motion. When this sensor triggers, the device behaves as if the power button was pressed, turning the screen on. This behavior (turning on the screen when this sensor triggers) might be deactivated by the user in the device settings. Changes in settings don't impact the behavior of the sensor: only whether the framework turns the screen on when it triggers. The actual gesture to be detected isn't specified, and can be chosen by the manufacturer of the device.

This sensor must be low power, as it's likely to be activated 24/7.

Each sensor event reports 1 in sensors_event_t.data[0] .

Pick up gesture

Underlying physical sensors: Undefined (anything low power)

Reporting-mode: One-shot

Low-power

Implement only the wake-up version of this sensor.

getDefaultSensor(SENSOR_TYPE_PICK_UP_GESTURE) returns a wake-up sensor

A pick-up gesture sensor triggers when the device is picked up regardless of wherever it was before (desk, pocket, bag).

Each sensor event reports 1 in sensors_event_t.data[0] .

Glance gesture

Underlying physical sensors: Undefined (anything low power)

Reporting-mode: One-shot

Low-power

Implement only the wake-up version of this sensor.

getDefaultSensor(SENSOR_TYPE_GLANCE_GESTURE) returns a wake-up sensor

A glance gesture sensor enables briefly turning the screen on to enable the user to glance content on screen based on a specific motion. When this sensor triggers, the device will turn the screen on momentarily to allow the user to glance notifications or other content while the device remains locked in a non-interactive state (dozing), then the screen will turn off again. This behavior (briefly turning on the screen when this sensor triggers) might be deactivated by the user in the device settings. Changes in settings do not impact the behavior of the sensor: only whether the framework briefly turns the screen on when it triggers. The actual gesture to be detected isn't specified, and can be chosen by the manufacturer of the device.

This sensor must be low power, as it's likely to be activated 24/7. Each sensor event reports 1 in sensors_event_t.data[0] .