Question

Is it ok to assume most of the user devices will have a gyroscope? In other words will I be excluding a significant number of people by using a gyroscope in my app?

I'm making a children's storybook app and I'm wanting the user to be able to tilt their device around the yaw axis to move a rocking chair back and forth. It's a small part of the app and it doesn't have to be very precise. Is there one sensor I should use over the other?

Was it helpful?

Solution

User coverage:

Most devices have both gyroscope and accelerometer, but almost every device has an accelerometer. Especially the older devices and the cheaper ones do not have a gyroscope. Don't forget that since it is a kids app, maybe the parents don't want the little ones to use their superb 700$ tablet, and will probably use cheaper ones. Cheaper devices tend to not have gyroscopes. So +1 for the accelerometer.

User experience

The accelerometer measures acceleration in the 3-dimensional coordinate system. In most cases (when the user actually does not jump around or throw the device) the biggest part of acceleration is gravity. With gravity alone it is very easy to determine tilt and slight movements. Plus you have the Gravity software sensor to eliminate strange movements, and Linear Acceleration to eliminate Gravity. The Gyroscope detects rotation. It is more sensitive, more precise and produces events faster than the accelerometer, but it seems to be an overkill for this usecase. If you wanted to make a 3D racing game or a flight simulator It'd be a win for the gyroscope, but for a kids app it's just too much.

Battery Usage

No contest here. The gyroscope uses 3-30 times more battery (maybe more, depending on device), while the accelerometer is very gentle on the battery. Plus, for most users the accelerometer is already active (to rotate the screen automatically) so there is no sensor battery usage here. +1 for the accelerometer

Programming

Sensors are pretty easy and straightforward to implement in Android apps. Since the gyroscope detects rotation speed, it gives all 0 values if the device is left still (and maybe a little noise in the range of +-0.01rad/s), so you only need a small if block to dismiss very slight movements (e.g. when gyroscope values are less than 0.2 rad/s). With the accelerometer, you need some extra calculations to determine the orientation of the device and which axis is actually the one that needs more attention to determine the direction of movement. It's not hard to do, but it does add a few extra lines of code and some extra debugging to your line of work. +1 for the gyroscope.

Conclusion

For a simple kids app, accelerometer is the way to go. I wouldn't think about it any more. Since you don't care much about precision, you actually eliminate the points gained by the gyroscope.

OTHER TIPS

I think these sensors are the ones to consider (I'm quoting from the book "Reto Meier, Professional Android 4 Application Development" here):

  • Sensor.TYPE_ACCELEROMETER — A three-axis accelerometer that returns the current acceleration along three axes in m/ s2 (meters per second, per second.)

  • Sensor.TYPE_GYROSCOPE— A three-axis gyroscope that returns the rate of device rotation along three axes in radians/ second. You can integrate the rate of rotation over time to determine the current orientation of the device; however, it generally is better practice to use this in combination with other sensors (typically the accelerometers) to provide asmoothed and corrected orientation.

  • Sensor.TYPE_ROTATION_VECTOR— Returns the orientation of the device as a combination of an angle around an axis. It typically is used as an input to the getRotationMatrixFromVector method from the Sensor Manager to convert the returned rotation vector into a rotation matrix. The rotation vector Sensor typically is implemented as a virtual sensor that can combine and correct the results obtained from multiple sensors, such as the accelerometers and gyroscopes, to provide a smoother rotation matrix.

End of quoting... You can find the default Sensor implementation for a given type using the getDefaultSensor method, e.g.:

Sensor defaultGyroscope = sensorManager.getDefaultSensor(Sensor.TYPE_GYROSCOPE);

If that returns null, the device doesn't have the sensor so you know not to try and use it. I expect the majority of devices do have these sensors (most likely the accelerometer) since they are the ones used to detect screen rotation.

I believe most phones have the ability to tilt. I have a cheep 2 year old phone that was 45$ when it was new, and is running android 2.1, it tilts and changes perspective.
I also have a tablet that's three years old, and it too tilts.
I'd say you're quite safe assuming the tilt will be there.

Almost all (or even all) phone will have an accelerometer. But not all of them have a gyroscope. Someone made a non exhaustive list of phone with gyrosope here: Which Android phones out there do have a gyroscope?

If you can manage to make it work using only the accelerometer, its certain more devices will support your app, but I can't really tell you how big this difference is

Over time, the number and types of sensors available in a "typical" android device has changed fairly dramatically. But some means of measuring the orientation of the device is among the older capabilities. It would appear that the correct approach is to test at run time for the newer sensors, and fall back to older ones, while gracefully handling the case where the information is simply not available.

The Sensor Overiew developer document has a table showing when specific sensor types were first made available by Android API level. But do note that this just reflects the capability of that API level to talk about that data type; a specific device might still be missing the required hardware.

It does appear that accelerometer and gyroscope are among the oldest sensors and are likely present in most handsets.

Right now (December, 2013) the developer dashboard is showing that all but about 1.6% of android devices accessing the Play Store are version 2.3 or newer (API 10 or newer). That data is based solely on version 2.2 or newer devices using the store, devices older than 2.2 were only about 1% of all devices checking in to any Google server in August of 2013. That page includes information about device display resolution, but does not appear to cover other features of devices. I could not find a dashboard that specifically covered what sensors are available in the wild.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top