You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@hyangah was suggesting that we should return a max value for each sensor type to determine what the range of outputs could be.
Android devices are being shipped with various accelerometer chips, and most of them can be dynamically configured to work in different ranges. Similarly, iDevice accelerometer sensors both support +/-2g and +/-8g, but their platform seem to be supporting the 2g range only. (Means their sensor is always working in the 2g mode?)
Probably it is from my misunderstanding of sensor data and terminology. (looking at sample snippets in android dev sites, I don't think max values are required. I'd like to know how to map sensor data to the on-screen display. http://developer.android.com/guide/topics/sensors/sensors_overview.html#sensors-coords mentions getRotation() and remapCoordinateSystem.
remapCoordinateSystem is a utility function if you work with a rotation matrix. You may prefer to interpret these values by yourself. See my simple example below.
var acc float64
go func() {
var events = make([]sensor.Event, 1)
for {
_, err := sensorManager.Read(events)
if err == nil {
acc = events[0].Data[1]
}
}
}()
// ...
func draw() {
dx = float32(-acc) // normalize dx depending on the screen width and accelerometer range optionally.
drawAt(f32.Affine{
{width, 0, x+dx},
{0, height, y},
}
}
The sample above will move the object to the left or the right of the screen depending on the acceleration in the Y-axis.
Retrieving the screen orientation is critical, because it alters which axis you need to read. See my comment at #10327 (comment)
I can send you a full sample app, if it's going to help.
@hyangah was suggesting that we should return a max value for each sensor type to determine what the range of outputs could be.
Android devices are being shipped with various accelerometer chips, and most of them can be dynamically configured to work in different ranges. Similarly, iDevice accelerometer sensors both support +/-2g and +/-8g, but their platform seem to be supporting the 2g range only. (Means their sensor is always working in the 2g mode?)
Some Android devices are found to report this value inaccurately. A peak-to-peak value is reported whereas zero-to-peak should be reported. https://code.google.com/p/android/issues/detail?id=63828
@hyangah, I am not quite sure why you needed the know the range. Could you give me a use case where it's critical?
The text was updated successfully, but these errors were encountered: