Unity, and the Accelerometer vs. the Gyroscope: A Complete Guide

Introduction:
It has recently come to my attention that there really isn't a clean, concise guide to using the accelerometer and gyroscope, which really is a shame, because they have the potential to change the way we play games. After a lot of trail and error, a lot of research, and a lot of testing, I think I have a pretty good grasp on how they work, the similarities, the differences, when to use one or the other, and when not to. A lot of this can be useful regardless of the tool, but there will also be a lot of Unity specific stuff, so be mindful of that. This is the post that I wish I had when researching this stuff. So however you stumbled upon this post, welcome, and I hope you learn something!

The Bottom Line:
I know a lot of people don't have time to read a super long, detailed post like this, so if you're one of those people, this is for you. Please know though, that if you have a project that seriously uses one of these technologies, it would be a disservice to stop here. Knowledge can only help you. But anyways here's the overarching theme: the gyroscope, frankly, works a lot better than the accelerometer, but it's a lot less convenient for the player to use. The accelerometer is a much more user-friendly option than the gyroscope, but doesn't work nearly as well. What do I mean? Well lets talk about it

Credibility:
I thought I would establish a little ethos considering how much information i'm giving you. I've been using Unity specifically for a good 3-4 years, so not that long in the grand scheme, but it's been a jam-packed 3-4 years. I'm no programming guru, but I certainly know the fundamentals. Finally, I have 2 games that make use of these technologies. One is a VR game that's on Google Play (I won't say the name because this isn't a self-promotion post), and the other is an unreleased game that's my main project right now, and I've been switching back and forth between the acc. and gyro. trying to find what works best. So keep in mind, I'm no elite professional by any stretch, but I know what I'm talking about.

What They Do:
What do they do? In one word - rotation. Both the accelerometer and gyroscope are used to track rotations in the device they are in, but they do so in different ways. They are used by a wide variety of objects; everything from airplanes, jets, and the mars rover, to the ps3 controller and, famously (or infamously), the Wii Remote. It's even used in the new Nintendo Switch controllers! The device we will focus on, however, are smartphones.

How They Work:
Time to get down to the nitty gritty. Like I said, they essentially have the same goals, but work differently. Let's start with the gyroscope. The gyroscope works by using inertial force. There are many types of gyros, but the classic version consists of a wheel rotating in a freely spinning enclosure. The wheel makes inertial force, and this force causes the gyroscope to stay in the orientation you place it in.

This is the classic gyroscope. It's been around since before the 1920s!

Nowadays there are much smaller, much cheaper, electronic gyroscopes available, such as MEMS gyroscopes, but the principles still apply. A constantly moving object uses angular velocity for precise tracking of absolute orientation. The accelerometer, or at least the electronic variants, aren't wildly different. It, too, has many different types, but the concept remains the same with all of them; have a flexible material and restrict it to only move on one axis, have one for each the x, y, and z axis, and how much the material stretches is equal to how much rotation is being applied to the object, whether static or dynamic, essentially. This works great for determining relative forces applied to an object. This, too, has an extremely popular MEMS variant. MEMS sensors use silicon, as it's unique properties make it great for this sort of application.

Differences in Tracking Methods:
With the boring stuff our of the way, lets transition into the practical. The gyroscope is a solid technology. It's physically sound, and provides great results. In Unity, it's so precise it almost looks unreal; the values are very stable, they change incredibly smoothly, and the input is an accurate representation of device orientation, which can lead to very intuitive one to one control. It measures the phone's absolute orientation in space, so it technically ignores changes in rotation over time, but since we have the rotation before and after, as well as how long it took to get from before to after, measuring the act of rotating the phone is a trivial task. The accelerometer, as it uses the forces being applied to spring-like objects, can be thown off by constant forces like gravity, but it theoretically accounts for these forces. Where the accelerometer should shine, however, is when measuring changes in rotation, as that what it's designed to do, and what the spring-like objects should have constant measurements of. In theory...

Restrictions within Unity:
...But within Unity, the accelerometer actually performs much worse. Firstly, the tracking is much less accurate than the Gyroscope, largely due to the static spring-like objects used for measurements, as well as the smaller size. Smaller objects are more sensitive to fine changes, sort of like how blowing on a human doesn't affect him/her, while blowing on an ant causes it to fly away. This results in the sensor being extremely sensitive. Worse yet, springs have a tendency to, well, spring, and these factors combined results in very fidgety input. The numbers Unity gives you can be extremely twitchy, and while spacing out the intervals in which you take input, as well as damping the input, can help, that comes at the cost of responsiveness, while you can have the responsiveness and the smoothness with the gyroscope. Not to mention those solutions can only do so much, as it's still not as smooth. On top of this, it appears that only two accelerometer axis work at once! It's still not 100% clear, but if I had to chuck up a reason, I would say gravity is definitely throwing off the third axis. It's not always the same axis that's broken, but instead it appears that the axis parallel to the ground is completely screwed, which makes sense. There may be a way to manually account for gravity to fix it, but good luck with that. Even Unity's official tutorial on the accelerometer is sure to only use an example using two axis, excluding the one that rotates parallel to the ground, although they make no mention of it that I know of.

Using it in Unity:
Although the accelerometer is built for relative changes in velocity, you still only have access to the absolute orientation calculated by the static offset of the springs, so so much for that advantage. I have no clue if that's a Unity thing or a hardware thing, but it's most likely the latter. Due to the relatively simple nature of the accelerometer, you only have one way to access it: Input.acceleration, which is a Vector3 that records a rotation. It appears that the rotation is relative to whatever the start rotation was at the start of the game, although i'd have to double check on that. And then there's the huge limitation of one axis always being unresponsive.

The gyroscope actually has an entire class within Unity. It is disabled by default, so make sure to manually enable it with Input.gyro.enabled = true;. If you have tried the gyroscope in the past, and it wouldn't work, this very well may be why. From there, there are two main ways to read gyroscope input: the first is Input.gyro.attitude, which is a very accurate reading of device orientation. It is a Quaternion instead of a Vector3. Do not be scared to work with Quaternions. Don't change single values of a Quaternion (unless you're a rotation guru). Don't convert it to a Vector3 for no reason. If you do have to convert it, use [your quaternion].eulerAngles. If you need to add, subtract, multiply, or divide the rotation, you may or may not be better off converting it. If you do need to do this, be careful not to break the input. If your rotation jumps around for seemingly no reason, it's most likely because the 360-0 degree wraparound got misaligned, and you should check what operations you're performing on the rotation. You may need to multiply it by -1 to invert an axis or two, depending on your game. This shouldn't cause any issues.

The other way to access gyroscope data is with Input.gyro.rotationRate. Remember how we talked about how the gyroscope is about absolute orientation, and rotation delta is technically not part of the calculation, but you can find it yourself? Well you don't even have to, because it's done for you! RotationRate is a Vector3, and it is not a measure of orientation, but of delta, the speed at which the object is being moved. This is pretty ironic, because the accelerometer is supposed to be about measuring, well, acceleration, but the gyroscope is even better at that. There are actually two variations of rotationRate: rotationRate and rotationRateUnbiased. RotationRate is the standard input, but rotationRateUnbiased is a special processed variant that removes bias. I'll spare you an explanation of bias; just know that it's a huge reason why the accelerometer is so inaccurate, and although rotationRate already works well, rotationRateUnbiased amps up the accuracy, if you can believe that! Input.gyro.attitude is used for absolute rotation, while Input.gyro.rotationRateUnbiased is used for relative rotation. There are times when it makes sense to use one or the other, but that's beyond the scope of this post. You can comment if you want more help on that.

So Why an Accelerometer Then!?
By now I bet you're thinking "so what's the deal, i'll just use the gyroscope and that's that!". Well, it goes much deeper than that. Make no mistake, the gyroscope is the superior sensor, but that superiority comes at a cost. Figuratively and literally. Yeah the gyroscope is more accurate, but it's more expensive to make and takes up more room. Although its not that big, the accelerometer is stupid small.


Image of an accelerometer from youtuber "engineerguy"

Also, the accelerometer is worse because it's basically just a bit of springy stuff and conductors, but that also makes it ridiculously cheap to make, and that has real value. It's also been around longer (at least in phones), and the longer something has been around, the cheaper it becomes to make, traditionally. As a result, just about every smartphone on the planet has an accelerometer, and that's no exaggeration. Meanwhile, phones start having gyroscopes in the lower-midrange. I think the threshold is about $150, generally speaking of course. For example, my $150 Nexus 5 (by LG, used) has a gyro, while the $100 LG K7 doesn't. I wanted to find an even clearer example, and I found one; the $100 (on Amazon) Moto G4 Play has no gyro, while the $150 (on Amazon) Moto G4 does. It may not seem like a big deal; "so the ultra-budget users can't play my game, oh well", right? Well if you think this, I don't think you realize just how huge this market is. I have personal experience; my VR game uses a gyro for obvious reasons, and when it launched my younger cousin said he would get it and tell his high school friends all to get it. Well, not a single one could find it on Google Play, because they all had budget phones. Every single one of these phones has an accelerometer. Even my $20 switch-to-MetroPCS throwaway phone had an accelerometer. You know how I know this without even checking? Because thinking back, I got a VR game on it, and the head tracking only worked on two axis! I could tilt my head, and look up and down, but I couldn't look left and right, or in other words, rotate on the axis parallel to the ground! It didn't make sense to me at first, but it's all coming full circle now!

A great example demonstrating this price-to-performance compromise are Nintendo controllers. Anyone who has used a Wii remote knows that although it can detect swipes, swings, tilts, and the like, it could never track the remote's exact orientation in space. It launched at around $40. Then the Wii Motion Plus came out, and it was an add-on with a built-in tuning fork gyroscope for all that rotation tracking goodness, and it released at $20! No buttons, no battery, no bluetooth, no IR blaster, none of the Wii Remote features, just the sensor in an enclosure, and it increased the price by 50%! Then comes the Nintendo Switch. The entire Switch system is $300. It comes with two controllers. They cost $50 EACH. THE CONTROLLERS COST A THIRD OF THE CONSOLE. I think that's a sufficient real-world example to get the point across.

Additionally, the gyroscope is a detailed measurement using a constantly moving part, and as a result it can be a detriment to battery life. Not only does the simplicity of the accelerometer keep the hit to battery light, but your smartphone has it on anyways! Its constantly on so it can detect when you switch from portrait to landscape and vice versa.

Obviously if your game pushes mobile graphics to the limit, or if it's an even moderately intense VR game, the ultra-budgets couldn't run it anyways, and the battery life would take a major hit regardless. Also, some games simply require the added benefits of the gyroscope. Both of my games use the gyro, for no other reason besides the game wouldn't function otherwise. But otherwise, you have to be honest with yourself. Actually consider using the accelerometer. Despite everything I've said, it works surprisingly well, all thing considered. Don't limit your customer base, and make it harder on your existing customers, if you don't have to.

Give It To Me Straight, Doc:
So what are ideal conditions to use one or the other? Well VR is obviously a gyroscope job, not only because you need tracking in all three axis, but also because head-tracking can make a user nauseous if it isn't extremely accurate. Tabletop roll-a-ball games work great with an accelerometer, as it only requires 2 axis. Think games like Super Monkey Ball. My favorite is Kirby Tilt 'n' Tumble for the Gameboy Color. Nintendo built an accelerometer into the cartridge, and it came out in the year 2000! Games like Warioware Twisted have fun gameplay with only one axis! Something like a tennis game, or something the uses swipes and wacks of the phone, can get away with just an acc., but more precision-based movement, such as flight simulators, will need the full gyro.


Nintendo was ahead of their time with this one!

Conclusion:
Well, that was long, but it was worth it. Hopefully, by now you feel like an expert on this stuff. I hope this can serve as a one-stop shop so you don't have to scrape all the information you can from skimp tutorials and old forum posts. The Unity community has been good to me, so consider this payback. Disagree? Have a question? Comment below, let's talk about it. Otherwise, good luck, and happy game making!

 

Accelerometers are not for tracking rotation, they're for tracking acceleration. That's why they're bad at tracking rotation: That's not what they're tracking at all.

Acceleration are multiple things. When the mobile device starts or stops being moved, for example when you wave it around, that creates acceleration. So every movement will affect the accelerometer, also if there's no rotation at all.

Acceleration is also gravity however. On Earth we have a constant gravity that points "downwards". This is picked up by the accelerometer in addition to movements. If you rotate the mobile device the gravity vector might change, because "down" relative to the phone has changed. However, if you rotate the mobile device purely horizontally, e.g. about the up-down axis, then the "down" vector compared to the mobile device won't change and thus the accelerometer isn't affected by that type of rotation at all.

Why does the accelerometer detect both acceleration and gravity and mix it all together into one vector? This relates to how physics work. Gravity and acceleration are in one way one and the same, and in any case impossible to measure separately.

So to sum up:

• The accelerometer is not for measuring rotation, it's for measuring acceleration (which includes gravity).
• Since gravity on Earth is a constant reference point, the measured acceleration can change based on certain rotations, but some rotations (horizontal ones) won't affect it.

If you want to measure rotation, use the gyroscope.

Furthermore, none of this is related to "limitations in Unity". It's central to how these technologies work and you'd get the same limitations accessing them through other software.

 

The accelerometer is supposed to be for tracking changes in rotation, but the accelerometer input from Unity (Input.acceleration) is not a measurement of such a thing. Acceleration is a delta. A rate of change. Input.acceleration doesn't return the speed at which the object is rotating over time. If I hold it flat, completely still, it reads (0,0,-1). If I hold it upright, completely still, it reads (0,-1,0). If I hold it in between the two positions, it reads (0, -0.7, -0.7). Clearly this is a normalized, absolute measurement, as if this were measuring a change, it would increase based on how quickly it moved the object, and zero out when there was no movement (when accounting for gravity of course). And guess what? That is exactly what Input.gyro.rotationRate does. The only way to semi-justify it is if you say it is a measurement in the change of orientation from a given start rotation, but even that isn't supposed to be what acceleration is.

What's happening is that it is measuring how much gravity is pulling down each of the three sensors, and this measurement, although you can use this to calculate delta, by default, doesn't say the rate at which the object is rotating through space, which is precisely what acceleration is. As a result, Input.acceleration ends up being a poor man's version of Input.gyro.attitude, and even if it wasn't, Input.gyro.rotationRate would be a more accurate measurement anyways.

Essentially, the Gyro can do everything the Acc. can and then some, and can do it better. If you need the benefits of the Gyro, use it, but use the Acc. if it has everything you need anyways

 

If you are in a moving car and hold the phone horizontal, it won't be the data you mentioned, guarantee.

 

There still isn't one.

It's not clear that you understand the technology. You haven't explained what the accelerometer can do that the gyro can't. Using the accelerometer to track orientation is a cheap hack, but it's not actually what the accelerometer was designed for.

Nor is your explanation especially concise. There are a huge amount of unneeded words there.

 

With all due respect, your only real criticism is that I didnt explain what the accelerator can do that the gyro can't, which is exactly what I did do. The answer is nothing. Technologically speaking, the gyro is 100% the superior technology. The rest of your comment doesn't have much substance

 

I must be misunderstanding the technology then. Can the gyro track linear acceleration?

Ultimately linear acceleration is what the accelerometer is built for. And using it for anything else, like tracking device orientation, is patchy at best. As you have discovered and pointed out.

 

@Jjules
You are confused, accelerometer track "translation" using acceleration, but gravity IS an acceleration toward the center of earth, so by default we always have a data pointing down. Since this force create a direction at relative "rest" as a reference, we can infer some relative angle, but it's not what is measured at all. Rotation with accelerometer is just a side effect of the property of gravity and its nature as an acceleration. It's wrong to say it measure rotation, it's more like we can infer rotation from the reference, it wouldn't work in deep space for that. But with complex movement that reference get lost in the "noise" wich is why it's an unreliable method outside of "rest". You can't play wii game that rely on rotation on a moving car without compensating for the car acceleration, the direction of the accelerometer would be bias against the direction of the moving car that add up to gravity.

 

You hit the nail on the head. That's what the accelerator is supposed to be for, but the issue is that for some reason Input.acceleration is not returning an acceleration. Acceleration is (CHANGE in velocity/time), so if the velocity isn't changing, the numerator is 0, and there is no acceleration, yet this isn't what Input. acceleration reads. This is the root of the problem

 

To repeat myself...again...At a rest position, with no translation, no change, Input. acceleration reads various values other than zero, even when accounting for gravity. The input in Unity is not tracking a translation. Actually try it yourself

 

@Jjules
Although you made a nice explanation you are saying lot's of wrong info here too invalidating the effort:
"If I hold it flat, completely still, it reads (0,0,-1). If I hold it upright, completely still, it reads (0,-1,0)"
That's because it's tracking gravity. Being the accelerometer a weight plus spring it's being pulled down by gravity.
If you tilt it the weight is being pulled down in another direction. That's all, but the weight will always be pulled down.

"If I hold it in between the two positions, it reads (0, -0.7, -0.7). Clearly this is a normalized, absolute measurement"
Wrong, it's not normalized as a vector of lenght 1, I don't think I ever read something like the above unless I were moving the phone. At most you can have (0,-0.5,-0.5) where the gravity is split between two axis when you are holding it 45 degrees. It is normalizing in the sense that is dividing by 9.8, to return 1 when the device is flat on one axis, it won't change anything for you.

"as if this were measuring a change, it would increase based on how quickly it moved the object, and zero out when there was no movement"
Aaaaaaand this is exactly the definition of acceleration my friend, a change of speed....
So it will raise and and smooth out until it will return to the gravity vector. You are accelerating the device and complain it is reporting an acceleration? I don't understand.

You can filter out the gravity with some math, but since there is no real way to know what the gravity is really and what is the raw acceleration you will be filtering out the real acceleration too when changing the device orientation.

The accelerometer can be used to track absolute orientation as a hack, by using gravity as reference but shouldn't be used to track rotation or movement cause the error will accumulate too fast and would be way too unreliable.

"To repeat myself...again...At a rest position, with no translation, no change, Input. acceleration reads various values other than zero, even when accounting for gravity. The input in Unity is not tracking a translation. Actually try it yourself"
Tried tons of time, report all zero except the axis facing the floor. If it doesn't for you it mean the place you used to sit it wasn't leveled.

 

Not moving is not the same as not accelerated.

A plane is very fast, but you will not constantly being pulled to the back, if you jump you will still land exactly where you jumped(relative to the plane). It is because it is not accelerated, if you jump while the plane taking off, even while it still flat on the ground, you will land behind where you jump.

A phone on the table is not moving because the table push it against gravity, remove the table and it will stay still at first, but increase in speed 9.8m per second, per second.

The point is the phone is alway accelerated, it just that you apply a force to it constantly to keep its speed at zero. That force is not an acceleration, so it does not cancel gravity in the reading.

 

"If I hold it in between the two positions, it reads (0, -0.7, -0.7). Clearly this is a normalized, absolute measurement"

"Wrong"

" don't think I ever read something like the above unless I were moving the phone"

Check the attachment. I can show you the truth, but I can't make you accept it

 

Ok, so ill repeat myself, again...

At a rest position, with no translation, no change, Input. acceleration reads various values other than zero, EVEN WHEN ACCOUNTING FOR GRAVITY.

In addition, the readings of the accelerometer are the same regardless of the rate at which I rotate my phone

Here's the bottom line, and this goes for everybody else too, because this is the root of the problem. The accelerometer is measuring the acceleration of gravity, but not any user-made acceleration

 

My wikipedia skills have uncovered a possible source of confusion. Apparently, an accelerometer measures "proper acceleration" not "coordinate acceleration". I would guess that most non-engineers/non-physisists think in terms of coordinate acceleration. In that case the accelerometer will read the combination of the force of gravity and external applied accelerations. With proper acceleration, the device is still accelerating when sitting stationary on a desk. I personally had never heard of "proper acceleration".

I don't understand. How can accelerometer read the force of gravity but not any user-made acceleration. Are you trying to say that if the user jiggles his phone around that the accelerometer is not going to read it?

 

I developed some game and plugin to use external Accelerometer, Gyroscope, Magnetometer.
Only magnetometer can measure rotation,
A gyroscope or accelerometer can only measure acceleration to know torque or speed.

 

I'll look into the concept of proper vs. coordinate

 

The magnetometer is another good topic, and I was gonna bring it up, but the post was already long enough. It's good stuff though

 

Sensor fusion (combining data from different sensors) is a pretty complicated subject which is why I let Oculus, Valve and Unity worry about it for me.

 

There are some inaccuracies in this thread but rather than correcting them or getting into a question of semantics and arguing back and forth, I'll try and make a concise overview of the sensors, what they are good for and what they aren't good at. I'll try and make a short paragraph of each. I can certainly go more in depth if anyone has further questions.

Accelerometer- You can get as the name implies acceleration in the 3 axis (x,y, and z). These tend to be noisy and of less precision, and if you watch the telemetry even when still they will be going up and down in small amounts all the time. Also, because gravity is a form of acceleration you will tend to only know "acceleration from you and not the earth" in only 2 out of the 3 axis. Those are the main drawbacks but it has been mentioned above that there are no sensor strengths and this is not true. The biggest plus of the accelerometer over the gyro is that it does not drift over time. The usecase of a steering wheel is prime example of one that is better suited to the accelerometer and not a gyro. The sensor not drifting is more important in this usecase than the precision or noise in a few decimal points. I'm sure someone will question this later but I'll leave it at this for now until that happens to make this concise and explain why later and go more in depth.

Gyro- Within Unity from the gyro you can get acceleration with gravity filtered out, rotation rate, orientation, etc. These tend to be more precise and less noisy. Gyro's do suffer from drift over time though so if you really need to know that you are pointing exactly northwest this isn't ideal. A gyro with no correction will actually get inaccurate quite quickly. A gyro correcting with gravity alone will get inaccurate slower but still fairly quickly. A gyro correcting with a magnometer (most phones) will get slightly inaccurate by the end of its check for sanity with the magnometer (usually a few seconds) and then sharply adjust to correct again. You can see this behavior easily in the telemetry if you rapidly move the phone from straight vertical to horizontal a few times quickly and then stop and set it down. When you first set it down it will be off by as much as 20 degrees and then a few seconds after putting it down it will all of a sudden be correct again. That is the sanity check with the magnometer. Most normal uses it won't by off by nearly this much but it is important to know that this drift is there all the time. Gyro's are good and better for most cases but drift is its main drawback so if your application can't handle drift then it's best to use a different sensor.

Magnometer- Unless doing an actual compass application or another magnetic field application the compass is mainly used as a supporting sensor for the gyro. It uses the earths magnetic field to get the drift out of the gyro at specific intervals. It is also why your gyro orientation returned really does know if you are facing northwest and isn't only relative to the direction you were facing when you started the app and then measuring left/right.


Miscellaneous- Hopefully that's short enough and a quick highlight of strengths/weaknesses. I have quite a bit of experience with sensors not only in phones, but also the sensors directly, and also in embedded systems like the TI sensortag. Some of the above criticism of Unity isn't warranted and it's further down the pipeline that is to blame. The lowest level of common issues is actually the motion chips used themselves. In low end phones some are pretty bad. The next level is the OS API's for accessing the motion chips. When IOS/Android were new most MPU's hadn't started down the road of sensor fusion yet so the API's are really only similar for cross platform for the basics above. Newer chips tend to do sensor fusion on the chip itself but the API's for setting the frequency/precision desired diverged making it more difficult for unity to do this in a nice cross platform way. As such most code that wants to run cross platform tends to still not utilize sensor fusion. Also, the phone makers tend to be stuck on the previous generation of MPU's like the Invensense 6xxx series and not what is current like the Invensense 9xxx series even though they are better in every way and not really that much more expensive. The last main comment I'd like to make clear is that no current combination of these sensors is reliable for position tracking. There is a reason that the Wii had a lightbar, Vive has lighthouse, Oculus has the sensors, etc. When you start caring about position (double integral of acceleration) the error factors really propagate and you need a 4th sensor in the mix. It isn't clear what the best 4th sensor will be (stereo IR cameras, other depth sensors, etc) but if this is required the accel/gyro/magnometer is not enough.

 

Thank you for this post @Jjules and everyone's contribution.
Cheers for making this extensive discussion to OP once again, - otherwise it would remain untouched for quite a long time

 

There seems to indeed be a problem, with gyroscope and Android specifically, which lead me to this thread

 

I have many android devices and have used Unity and non Unity applications and when you lay the phone flat an important sensor for the orientation axis parallel with gravity is actually the magnometer (compass). Unlike IOS not all current android phones have a magnometer and others have one but they are junk. Now the link you posted said the data was checked in an android diagnostic on the accelerometer and the gyro but not the magnometer to see if it is functioning properly.

I don't have an S4 but I do have an S3 and and S6 and they behave fine for me so I would think the S4 would as well but it would probably be worth checking that the devices compass is operating properly.

That being said I would expect that if the compass wasn't operating properly for the telemetry to just drift (meaning that even if still the orientation in that direction would keep moving). I haven't ever seen the data give back undefined or an error.

 

it's possible rotation with accelerometer, like a gyroscope, this Asset calculates the rotation with the accelerometer, and makes possible the VR in all android phones:
https://www.assetstore.unity3d.com/en/#!/content/87609

 

You can do this easily for 2 out of the 3 axis like a steering wheel effect. However, your 3rd axis (yaw) will not be accurate without a gyro and a compass (magnometer). This doesn't make VR usable on all android phones. VR requires you to have an accurate representation of what you did otherwise you will get motion sickness.

 

This thread is a much too hard read. I tinker a lot with the gyro so i might give some insights. I try to be more practical and keep it short with optional info only, please correct me if i am wrong but i am very confident this is it:

Input.acceleration: Accelerometer

• measures acceleration
• - jittery as F***
• + absolute measurement = no drift, the values always noise about the correct value

Spoiler

The current acceleration on the sensor, includes everything because it is physically impossible to separate accelerations that came from gravity, user handling or a centrifuge (into which you dropped the phone by accident) from one another. It is only zero if the phone is in free fall.

Input.gyro.rotationRate: Gyroscope

• measures the current degree/seconds at which the sensor is rotating in 3 device-local axes
• - not absolute = innate drift even when the phone is still
• + no jitter (no, that's only your hand shaking)
• + very low latency
  
• low noise
• frame rate independent momentary reading
  • therefore needs to be scaled with your framerate: rotRate *= Time.deltaTime;

Spoiler

This is the best thing you can use to create camera rotation. But it needs filtering + threshold for the shaky human hands plus calibration for the innate drift. It yields only delta values (look at how this thing is actually built and you understand, link below), so you might use a very very smoothed version of Input.gyro.attitude to nullify your accumulated drift into the correct value.

www5.epsondevice.com/en/information/technical_info/gyro/
->Vibration Gyro Sensors

The drift will not follow the ScreenOrientation = If you turn your screen upside down and the phone rotates the Unity-App accordingly, the innate drift measured by Unity will switch signs for x and y

rotationRate and rotationRateUnbiased always give me the same values on my current phone, no idea

Input.gyro.attitude: Accelerometer + Gyroscope + magnetometer

• some easy to use quat, unity-forged by internal processing of various sensors
• - jittery because it also uses the Accelerometer
• - some latency compared to rotationRate
  
• - fixed 1:1 sensitivity to the real world
• + absolute
• + works regardless of the phone orientation

Spoiler

Need a rotatable window peeking into your game-scene? try this:

Code (CSharp):

1. camTrans.rotation = Input.gyro.attitude;
2.     camTrans.Rotate( 0f, 0f, 180f, Space.Self ); // Swap "handedness" of quaternion from gyro.
3.     camTrans.Rotate( 90f, 180f, 0f, Space.World ); // Rotate to make sense as a camera pointing out the back of your device

I wont use Input.gyro.attitude to directly swivel a camera because it is jittery and delayed, but it can help you even out accumulated errors when using rotationRate.

Input.gyro.gravity: Accelerometer + Gyroscope + ?magnetometer

• almost jitterless version of Input.acceleration

Spoiler

much cleaner value of Input.acceleration, if you have a game that uses Input.acceleration, always check if a gyro exists (SystemInfo.supportsGyroscope) and use Input.gyro.gravity instead of Input.acceleration

 

Whoa... awesome! I am playing around with this and coming up with all sorts of awesome use cases

Thanks a ton for that snippet and your detailed info!

 

How to combine accelerometer and gyroscope data?

 

You have to be more specific. This sentence on its own sounds like you don't even know what you want to achieve by combining them. I guess you work on a Shmup (your recent post) and you want to control by tilt. You don't need the gyroscope but it may help. So check if the smartphone supports Input.gyro.gravity by SystemInfo.supportsGyroscope and use that, otherwise go for Input.acceleration but apply heavy filtering to it.

Anyway, you should open a thread instead of derailing this Guide into a support thread.

 

Thank you.
Can I contact you if I have some questions if you dont mind?

 

You should probably create a new thread to get help with your specific problem.

 

Fantastic Guide Thanks

 

I have developed an AR camera for Unity using an accelerometer.
Researchers say that it works on 90% of devices.

☄ Download: http://u3d.as/YSM

 

Can you explain what your acceleration do in this project? I don't notice any acceleration here.

 

He's using the accelerometer as a way to map the virtual objects to a spot on the table in the video. While accelerometers are in virtually all phones for either AR or VR to be stable it's not really enough (a gyro and compass in addition is better but obviously cuts down on the number of phones that have them). You'll notice in the video he was moving the camera up and down and tilting, but not rotating on yaw. You'll also notice that the objects are a bit jumpy, due to the way an acceleromter is noisy. A neat project for sure, there is a similar one for vr head tracking on the store, but an accelerometer alone isn't good enough for anything other that tinkering.

 

I have tried this kind of solution couple years back. It will never work. Unless you just want to rotate on one position. Else dont bother.

 

AR Camera ACCELEROMETER has 3 different forms of tracking.

One of them (BACK CAMERA) rotates on the YAW with the back camera and comparing the difference of the pixels.
For rotation around the Y axis, an algorithm compares the pixel changes to the previous and current frames.

---

90% of all mobile devices have an accelerometer and video camera but only 20% have a gyroscope.

If you want greater coverage of devices, but less accuracy and stability, use AR Camera ACCELEROMETER.
If you want greater accuracy and stability, use AR Camera GYRO.

You can also try to use both cameras for different cases.

 

AR Camera ACCELEROMETER has 3 different forms of tracking.

One of them (BACK CAMERA) rotates for all axis.
For rotation around the Y axis, an algorithm compares the pixel changes to the previous and current frames.

 

I think your videos sum up why current hardware isn't really sufficient except for very simple mechanics (like your basketball video). This isn't a knock on anything you've done more just pointing out the limitations of the various sensors. The accelerometer doesn't help for yaw. The gyro drifts a bit until calibration with the magnometer. Single camera alone is processing intensive (hence the framerate in that mode) and really needs a second camera to know depth.

When AR starts getting heavier adoption it will be in a system that has more sensors than current normal phones (probably multiple normal cameras, an IMU, and a depth camera).

 

Do you have some sources about that claim? Is it corrected for Devices that are actually used for playing games?
I would be eager to read those.

 

I've read in places that the number of phones with gyro has risen a lot recently, after google cardboard came out.

I'd love to see some info about that if anybody has hard numbers.

Here is a start:
https://www.gsmarena.com/results.php3?chkGyro=selected&sFreeText=gyro

(It says 1110 of 8422 devices listed have a gyro - isn't a complete list of course)

 

I tried accelerometer with the example in https://unity3d.com/es/learn/tutorials/topics/mobile-touch/accelerometer-input and it doesnt work, the object just starts moving all the time in one direction even if i almost dont move the mobile, a samsung s8

 

Because I'm targetting Tablets I just checked Tablets all from 2016 on using GSM Arena and only 23% have a gyroscope by 99% (all but one) have Accelarometers, I'm guessing that mobile phones are similar.
Just FYI
https://www.gsmarena.com/search.php3?mode=tablet&nYearMin=2016

 

Actually Unity uses a blend of all available sensors and the gyro will not return an attitude vector if not gyroscope as well as magnetometer and acceleration is present so seems not surprising gyro.rotationRate behaves like it does...

 

Just to put some device hardware states listed above into context, it's not the number of device models that contain a gyroscope/magentometer that is important; it's the usage rates. For example, in the US, in Q 42018, 9 of the top 10 devices BY USAGE are iPhone 6 and above; all of which have gyroscopes & magnetometers. The next 3 most used are Samsung 7, 8 & 9. Those 12 devices represent 67% of the market and don't include Google Pixels (all of which also have all three sensors and Samsung 6 or older which also do). So, your target market that can use a gyroscope, in the US, is AT LEAST 67%, not 20%.

*the more you know*

 

An Update, you guys:
Since i own a Samsung A3 2017 i noticed that this phone and other "newer" phones perform gyro-recalibration all the time.

As far as i found out by testing myself, this gyro-recalibration kicks in when the phone is still for about 1 second, which is great. But it also happens when you manage to rotate the phone in a very steady fashion for 1 second. This is happening to me during normal gameplay.

So i suspect Unity only uses TYPE_GYROSCOPE for both gyro.rotationRate & gyro.rotationRateUnbiased:

https://developer.android.com/reference/android/hardware/Sensor.html#TYPE_GYROSCOPE
https://developer.android.com/reference/android/hardware/Sensor.html#TYPE_GYROSCOPE_UNCALIBRATED
developer.android.com/guide/topics/sensors/sensors_motion

RotationRateUnbiased seems to be Unity's own calibration.


So currently the is no way of obtaining android's TYPE_GYROSCOPE_UNCALIBRATED through the Gyroscope class. While this is not a bug per se, i filed a ticket: (coming up shortly...) EDIT: ticket still not reviewed or i made a mistake, where can i see its state?

 

So I developing an app that I want to move around my real room how I can use the mems in order to move around the 3D space relative the real world?
A mobile VR headset maybe we call it MR but with the ability to walk around...

 

Phone accelerometer and gyroscope will not provide you enough data to reliably determine position of your phone in real 3d world. Gyroscopes drift, and accelerometer is noisy. You'll get massive errors in mater of seconds.

There's a reason why modern VR headsets rely on image recognition for position tracking.

 

Okay I have a question in AR sessions we take the position of the point reference and we calculate the distance of that point relative to our device is that right ?