Essentials: Accelerometer Platform Inconsistencies

Created on 20 Apr 2018  Â·  4Comments  Â·  Source: xamarin/Essentials

Description

The Accelerometer performs inconsistently among the three platforms.

Steps to Reproduce

Attach an Accelerometer.ReadingChanged handler and call Accelerometer.Start(SensorSpeed.Normal)

Expected Behavior

Based on documentation, the magnitude of the vector should be approximately 9.8 m/s². The vector components should be consistent among the three platforms.

Actual Behavior

On Android, the magnitude of the vector on an Android Nexus 5 is about 9.4 to 9.8, depending on orientation. (Close enough.) However, on an iPad Mini and a SurfacePro 2, the magnitude is approximately 1.0, evidently a normalized value.

On Android, positive Y values are to the bottom of the phone, positive X values are to the left, and positive Z values are to the back of the phone. On the iPad Mini and SurfacePro 2, it's the same coordinate orientation but negative: Positive Y values are to the top of the device, positive X values are to the right, and positive Z values are to the front of the device.

Basic Information

Xamarin.Essentials 0.0.1.79-preview
Xamarin.Forms 2.5.0.280555
.NET Standard 2.0
Visual Studio 2017 on Windows 10.0.16299

  • Platform Target Frameworks:

    • iOS: 11.3

    • Android: 8.1

    • UWP: 10.0.16299.0

  • Android Support Library Version: 25.4.0.2
  • Affected Devices: Nexus 5, iPad Mini, SurfacePro 2

Reproduction Link

https://github.com/xamarin/private-samples/tree/master/EssentialsExperiment

bug

Most helpful comment

I've looked at the source code for the accelerometer and see that the current API makes no adjustments to the values obtained from the platform APIs. Some adjustments will have to be made.

The good news is that Android, iOS, and UWP all use the same device coordinate system for their sensors. When the device is held in its "natural" orientation (usually indicated by placement of hardware buttons or logos), positive X is to the right, positive Y is up, and positive Z comes out of the screen.

One difference between the platforms is that the Android accelerometer uses units of meter/sec², which iOS and UWP normalize the units. That's easily fixable and documentable.

The second difference is that the Android accelerator reports a vector pointing _away_ from the center of the earth, while iOS and UWP report a vector pointing _towards_ the center of the earth. It doesn't really matter which convention you choose, but obviously the platforms should be consistent.

I think most developers would feel comfortable with a vector that points towards earth, but theoretically, Android is correct: The vector should represent the deviation from free fall, which points away from the earth.

All 4 comments

I've looked at the source code for the accelerometer and see that the current API makes no adjustments to the values obtained from the platform APIs. Some adjustments will have to be made.

The good news is that Android, iOS, and UWP all use the same device coordinate system for their sensors. When the device is held in its "natural" orientation (usually indicated by placement of hardware buttons or logos), positive X is to the right, positive Y is up, and positive Z comes out of the screen.

One difference between the platforms is that the Android accelerometer uses units of meter/sec², which iOS and UWP normalize the units. That's easily fixable and documentable.

The second difference is that the Android accelerator reports a vector pointing _away_ from the center of the earth, while iOS and UWP report a vector pointing _towards_ the center of the earth. It doesn't really matter which convention you choose, but obviously the platforms should be consistent.

I think most developers would feel comfortable with a vector that points towards earth, but theoretically, Android is correct: The vector should represent the deviation from free fall, which points away from the earth.

Thanks for all the info, we will look into this soon.

Looks like UWP/iOS return unites in a G while Android returns m s-2 directly:

A G is a unit of gravitation force equal to that exerted by the earth’s gravitational field (9.81 m s−2).

My assumption here is to adjust Android to normalize by dividing by 9.81 and updating the docs to say we are returning G's

I like that solution.

Was this page helpful?
0 / 5 - 0 ratings