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!
