summaryrefslogtreecommitdiffstats
path: root/services/sensorservice/RotationVectorSensor.h
Commit message (Collapse)AuthorAgeFilesLines
* use quaternions instead of MRPsMathias Agopian2012-06-271-1/+14
| | | | | | | | also use correct time propagation equation disable the fused sensors when gyro is not present since they were unusable in practice. Change-Id: Iad797425784e67dc6c5690e97c71c583418cc5b5
* 9-axis sensor fusion with Kalman filterMathias Agopian2012-06-271-10/+5
| | | | | | | Add support for 9-axis gravity and linear-acceleration sensors virtual orientation sensor using 9-axis fusion Change-Id: I6717539373fce781c10e97b6fa59f68a831a592f
* fix [3369027] Sensor.TYPE_ROTATION_VECTOR is unstable and returns NaNs when ↵Mathias Agopian2012-06-271-2/+2
| | | | | | | | | | | | 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
* fix [3237242] sensormanager sensor active count gets out of syncMathias Agopian2012-06-271-2/+0
| | | | | | | | | | | | | | | | | | 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
* Add support for virtual sensors.Mathias Agopian2012-06-271-0/+60
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