Commit Graph

8 Commits

Author SHA1 Message Date
Mathias Agopian
0319306670 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
2013-05-16 18:47:21 -07:00
Mathias Agopian
3301542828 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
2012-06-27 17:07:55 -07:00
Mathias Agopian
984826cc15 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
2012-06-27 17:07:54 -07:00
Mathias Agopian
2cf098846c 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
2012-06-27 17:07:54 -07:00
Mathias Agopian
50b66767f6 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
2012-06-27 17:07:54 -07:00
Mathias Agopian
ddf1ceb647 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
2012-06-27 17:07:54 -07:00
Mathias Agopian
5c6d7ff3e6 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
2012-06-27 17:07:54 -07:00
Mathias Agopian
f001c92436 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
2012-06-27 17:07:54 -07:00