History log of /frameworks/native/services/sensorservice/RotationVectorSensor.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
755c451c7861a029e26e5f16e319b629169e656d 08-Apr-2016 Peng Xu <pengxu@google.com> sensorservice: switch to use sp<> in sensor list

* Switch to use smart pointer in SensorList to avoid object
life cycle issue.
* Refactor HardwareSensor and various virtual sensor class.
* Change active virtual sensor map into a set of handles.

Change-Id: I674d5eb5c0038179f9ef1b6f0d576b8b605649ec
/frameworks/native/services/sensorservice/RotationVectorSensor.cpp
0cc8f809924706c7d683da30605f432635dd5bb6 06-Apr-2016 Peng Xu <pengxu@google.com> Refactor sensor list in SensorService

Refactor sensor lists management logic in sensorservice:
* Factor all sensor list management code into a separate class.
* Remove error-prone repeated sensor lists.
* Solve synchronization issue when sensor is added or removed during runtime.
* Switch to STL containers.

Bug: b/27911774

Change-Id: I94d5571e1fa3166dbe893ffac2a2a7584be6349c
/frameworks/native/services/sensorservice/RotationVectorSensor.cpp
f66684a6fb2a2991e84a085673629db2a0494fc6 23-Jul-2015 Peng Xu <pengxu@google.com> Add AOSP Geomag and Game Rotation, and Gravity

Providing AOSP software implementation of Geomag Rotation Vector, Game
Rotation Vector and Gravity sensors for platforms that does not have
hardware implementation of these sensors but do have primitive sensors
(accelerometers, gyrometers and magnetometers).

Previously, AOSP Gravity sensor is enabled only when all primitive sensors are
available. This is changed so that AOSP Gravity will be available even
no magnetometer is in the device.

Related bug/feature request:
* b/17508800
* b/22610016

Change-Id: I4e2d3e544884047d66e7fdbce2282f1f8234eae9
/frameworks/native/services/sensorservice/RotationVectorSensor.cpp
92dc3fc52cf097bd105460cf377779bdcf146d62 12-Mar-2014 Mark Salyzyn <salyzyn@google.com> native frameworks: 64-bit compile issues

- Fix format (print/scanf)
- Suppress unused argument warning messages (bonus)

Change-Id: I05c7724d2aba6da1e82a86000e11f3a8fef4e728
/frameworks/native/services/sensorservice/RotationVectorSensor.cpp
bf72deea2f9982a09c6a95f94cfa1654bc8c684f 17-Sep-2013 Aravind Akella <aakella@google.com> Fix for AOSP fusion sensors not handling multiple clients correctly.

Bug: 10786801
Change-Id: I7b938bc583a303a30237c3d93b5accbf64cc90b5
/frameworks/native/services/sensorservice/RotationVectorSensor.cpp
0319306670b0344da99efa606b6f172dde575a39 11-May-2013 Mathias Agopian <mathias@google.com> various fixes to the sensorservice

1) "google" sensors are now reporting AOSP as the vendor string
2) don't expose the system's sensor fusion if the HAL provides it
3) use uncalibrated gyro if availble for the system's sensor fusion

Change-Id: I25140436cdb29d55e39fd6fbbf8c44a410a83d5c
/frameworks/native/services/sensorservice/RotationVectorSensor.cpp
3301542828febc768e1df42892cfac4992c35474 28-May-2011 Mathias Agopian <mathias@google.com> use quaternions instead of MRPs

also use correct time propagation equation
disable the fused sensors when gyro is not present since
they were unusable in practice.

Change-Id: Iad797425784e67dc6c5690e97c71c583418cc5b5
/frameworks/native/services/sensorservice/RotationVectorSensor.cpp
984826cc158193e61e3a00359ef4f6699c7d748a 18-May-2011 Mathias Agopian <mathias@google.com> 9-axis sensor fusion with Kalman filter

Add support for 9-axis gravity and linear-acceleration sensors
virtual orientation sensor using 9-axis fusion

Change-Id: I6717539373fce781c10e97b6fa59f68a831a592f
/frameworks/native/services/sensorservice/RotationVectorSensor.cpp
2cf098846c83bab82272f107ba110f7c47df1763 19-Jan-2011 Mathias Agopian <mathias@google.com> fix [3369027] Sensor.TYPE_ROTATION_VECTOR is unstable and returns NaNs when running slowly

The cut-off frequency of the lowpass filter was too high
for the sampling rate used by DELAY_NORMAL.

Now we use the same filters used for the gravity vector
(cascaded biquad at 1.5 Hz)

Change-Id: I319dc4f449a3abd553d61b196a9ddcf7782f912d
/frameworks/native/services/sensorservice/RotationVectorSensor.cpp
50b66767f6c5635430483393e17d15969dfe2f05 30-Nov-2010 Mathias Agopian <mathias@google.com> fix [3237242] sensormanager sensor active count gets out of sync

whether a physical sensor needed to be active or not was managed by
a simpe reference counter; unfortunatelly nothing prevented it to
get out of sync if a sensor was disabled more than once.

sensorservice already maintainted a list of all the "clients"
connected to a physical sensor; we now use that list to determine if
a sensor should be enabled. This can never be "out-of-sync" since
this is the only data structure linking a sensor to a user of that
sensor.

also removed the isEnabled() method, which was never used and
implemented wrongly (since it didn't take into account that a sensor
could be disabled for a client but not of another).

Change-Id: I789affb877728ca957e99f7ba749def37c4db1c7
/frameworks/native/services/sensorservice/RotationVectorSensor.cpp
ddf1ceb647d029febfd007b389cd92c84668a03c 23-Nov-2010 Mathias Agopian <mathias@google.com> allow rotation-vector to have 4 components

- upadte documentation for rotation vector
- update method dealing with rotation vector to deal with 4 components
- virtual rotation-vector sensor reports all four components
- improve SensorManager documentation layout

Whent he 4-th component of the rotation-vector is present, we can save
a square-root when computing the quaternion or rotation matrix from it.

Change-Id: Ia84d278dd5f0909fab1c5ba050f8df2679e2c7c8
/frameworks/native/services/sensorservice/RotationVectorSensor.cpp
5c6d7ff3e643d0fb4b46d81a3a4e6edaba779edd 22-Nov-2010 Mathias Agopian <mathias@google.com> don't attempt to normalize the rotation vector

indeed, by construction of the rotation matrix, it is
guaranteed to have a length of 1.

moreover, the normalization code was missing a square-root,
fortunatelly, since the length is 1, this didn't cause any
damage (since sqrt(1) = 1).

Change-Id: I9facd668caaf5bb3bfccb139ab872f2bb2066365
/frameworks/native/services/sensorservice/RotationVectorSensor.cpp
f001c92436b4a66eb7687286325ced7f10c9f917 12-Nov-2010 Mathias Agopian <mathias@google.com> Add support for virtual sensors.

Rework sensorservice to allow "virtual sensors", that is
sensors that report a synthetized value based on real sensors.

the main change to sensorservice is around managing which real
sensor need to be activated and which rate to use.

The logic for all this has been moved into SensorDevice, which
essentially wraps the sensor HAL but adds two features to it:
- it keeps track of which sensors need to be activated
- it keeps track of what rate needs to be used

For this purpose an "identity" is associated with each real sensor
activation, so we can track them.

On start-up we check for gravity, linear-acceleration and
rotation-vector sensors, if they're not present in the HAL, we
synthetize them in sensor-service.

Change-Id: I841db2c1b37ef127ed571efa21732ecc5adf1800
/frameworks/native/services/sensorservice/RotationVectorSensor.cpp