Gyroscope adventure

In case you can’t fully understand yet what Adobe means by focusing on (desktop) gaming and video and not general purpose apps, allow me to demonstrate. Suppose you are making mobile app and for whatever reason you want to track device orientation. How hard can that be? Check it out:

Apple way

If you’re native iOS app developer, you are dealing with ecosystem that does support general purpose apps. You have simple CMDeviceMotion class that performs sensor data fusion, filtering, bias removal, etc, and gives you orientation data in any form you want (roll + pitch + yaw, or matrix, or quaternion). Case closed. The same class conveniently splits accelerometer data into gravity and user applied acceleration, btw. In a word, it’s perfect.

Adobe way

If you’re AIR app developer, prepare yourself – you’re going on the adventure. You can start by looking at flash.sensors package – for some mysterious reason, it has accelerometer API for desktop, but no gyroscope API for mobile. Why? Because Adobe does not feel obliged to include every piece of code you might think of in their runtime. But don’t give up your hope yet – Adobe has the solution for this kind of problems – AIR native extensions. And, it turns out that Adobe made one for you to access gyroscope data. Despite of being abandoned in 2011, apparently just before Adobe’s focus shift kicked in, this ANE still works with current AIR 3.x.

Okay, this is the part where you’re happy that you don’t have to write ANE yourself, and it seems that getting your hands on device orientation data is now only a matter of few additional build settings. Well…

This extension API, designed to be Accelerometer class twin, has two major problems in the way. Number one is that it only exposes raw gyroscope data, i.e. rotation rate. Since this is not something that flash developers do every day, you probably have no idea how to go from radians per second to orientation quaternion, or transformation matrix. So to use this ANE, you will have to learn some new tricks, such as finding approximate differential equation solutions, Taylor expansion of matrix functions, series summation and evaluating indeterminate forms. If you are still with me, good guy Oliver J. Woodman will guide you through this hell (pages 21 to 23).

Ok, now you’re done reading that and ready for action, right? Not so fast – there is problem number two. Let me just quote this comment from ANE source code:

// The singleton ExtensionContext object listens for StatusEvent events that
// the native implementation dispatches. These events contain the device’s
// gyroscope x,y,z data.
// However, each Gyroscope instance has its own interval timer. When the timer
// expires, the Gyroscope instance dispatches a GyroscopeEvent that contains
// the current x,y,z data.

Thank you, Adobe engineer, for this brilliant idea. Because there just can’t be enough lag or noise in my data. Sigh… so what do you do about this? You bypass ANE AS3 wrapper, and access its internal methods over low level interface. Of course, this means that you have to study both wrapper and native code beforehand :(

And here, my friend, we come to the end of our wonderful journey. I will go back to work on my AIR app, and you will maybe go and write your own ANE, with blackjack and hookers. Or you may choose to continue where I left off – maybe add Kalman filter or something. And don’t forget to write back, if you do :)

6 Responses to “Gyroscope adventure”

  1. 1 marpi February 14, 2013 at 05:53

    for most of the situations (games) it’s enough and really easy just to use accelerometer class. comes out of the box, without any anes or swcs:

    var accelerometer:Accelerometer = new Accelerometer();
    accelerometer.addEventListener(AccelerometerEvent.UPDATE, updateHandler);

    private function updateHandler(evt : AccelerometerEvent) : void {
    trace(evt.accelerationX, evt.accelerationY);


    • 2 makc3d February 14, 2013 at 06:00

      Unfortunately this will not work so well if you move the device left to right, for example. You will have sine-like acceleration that will be erroneously interpreted as rotation. I agree, this does not matter for this kind of games.

  2. 4 Michael February 27, 2013 at 03:48

    Quick shameless plug here for our extensions:

    But our Gyroscope one actually returns calculated roll, pitch and azimuth/yaw values for you. If you’re not looking to write one yourself.

    • 5 makc3d February 27, 2013 at 14:51

      That’s great, but I think the one and only way to do this is using fused data, gyroscope for quick orientation changes, accelerometer for correcting “down” direction, and maybe compass for correcting rotation around “down” axis. With gyroscope alone your roll/pitch/yaw will drift away very soon.

      All of this is fun to do, but with CMDeviceMotion doing it for you already you just need to write proxy ANE for it.

      • 6 Michael February 27, 2013 at 14:55

        You’re exactly right and that’s exactly what we do! :)

        Use a combination of the 3 sensors (accelerometer, magnetometer and gyroscope) to determine the 3 angles.

        You can just get the basic x,y,z data if you wish but the combined data is generally much more useful.

Leave a Reply to Michael Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Old stuff

February 2013
« Jan   Mar »

Oh, btw…

%d bloggers like this: