Just published the first version of Sumatra on Google Play. I had to add a subtitle to avoid a naming clash in the store. So now it’s officially called “Sumatra: Jungle Escape”. It’s free.

Have fun with it

And it works like a charm.

Look here for more information.

Tobias invited me to another issue of the about:games podcast (German language only, sorry ) and I was glad to participate. This time, tobias tried something new by forming a “group of regulars” from listeners of the podcast. Nice people, interesting topics; a pleasant evening it was.

Yesterday we (Tobias from about:games, his brother Nicolas, my girlfriend and me) made a small trip to the Gamescom in Cologne. Despite the suffocating heat the place was quite crowded. The exhibition halls were air-conditioned but the walk from the parking area to the entrance was agonizing enough.

For me, personally, there weren’t much highlights, since I do not anticipate those large game titles like most people. It was rather the atmosphere which attracted me: so many gaming people, playing, talking about games, watching trailers… I was sightseeing.

Anyway, here are some updates on what is currently going on with my private projects (with screenshots ):

Failsafe (working title): This is the second name for my Metroidvania platform game I started long ago with flixel. At the beginning it was called Vessel, but then suddenly the indie developer Strange Loop Games announced their steampunk platformer with fluid mechanics, also called Vessel, so I had to abandon that name. The work on this project had been repeatedly interrupted by more important things, so it’s still not finished. However, most of the game relevant mechanics are done. What’s left are the boss fights and, well, all of the level design, which is the most fun part in my oppinion. I also built my own small level editor in PyQt. But there is one thing that’s bugging me: The whole project is done in Flash. I have learned a lot about ActionScript and how the FlashPlayer is working but the recent Flash updates introduced some really strange bugs and crashes which is really annoying. I used to be a Flash fanboy but by now I think it wouldn’t hurt to check out some alternatives.

Sumatra (working title): Actually I’d have to announce this separately. I don’t because that would make me feel like everything I started before Sumatra is unimportant. Sumatra is my first project in Unity and also my first mobile game. I’m planning to release it on Android and iOS. It is basically a Canabalt clone. I wanted to start with something small  and simple, get it actually done and see what happens. In Sumatra you play as an orangutan fleeing from the progressing deforestation. You’re swinging from branch to branch collecting bananas and try not fall off the trees while they are getting cut down beneath you.

flxmp: I started flxmp primarily to play XM tracks in Failsafe. Of course, other developers who make retro-styled games could benefit from it as well. Unfortunatelly, I hadn’t enough time to implement the whole effects-assortment of the XM format. I hoped, I could finish all features until version 0.2 (current version is 0.15). So flxmp remained untouched for about half a year. I don’t know if that will change in the following months.

That should be enough for now. Now, as usual, back to work

You can listen to it here.

I used my Samsung Galaxy S2 and decided to use its gyroscope in conjunction with the accelerometer and the magnetic field sensor in order to measure the user’s head rotations both, quickly and accurately. To acheive this I implemented a complementary filter to get rid of the gyro drift and the signal noise of the accelerometer and magnetometer. The following tutorial describes in detail how it’s done.

There are already several tutorials on how to get sensor data from the Android API, so I’ll skip the details on android sensor basics and focus on the sensor fusion algorithm. The Android API Reference is also a very helpful entry point regarding the acquisition of sensor data. This tutorial is based on the Android API version 10 (platform 2.3.3), by the way.

This article is divided into two parts. The first part covers the theoretical background of a complementary filter for sensor signals as described by Shane Colton here. The second part describes the implementation in the Java programming laguage. Everybody who thinks the theory is boring and wants to start programing right away can skip directly to the second part. The first part is interesting for people who develop on other platforms than Android, iOS for example, and want to get better results out of the sensors of their devices.

Update (March 22, 2012):
I’ve created a small Android project which contains the whole runnable code from this tutorial. You can download it here:
SensorFusion1.zip

Update (April 4, 2012):
Added a small bugfix in the examples GUI code.

Update (July 9, 2012):
Added a bugfix regarding angle transitions between 179° <–> -179°. Special thanks to J.W. Alexandar Qiu who pointed it out and published the soultion!

Update (September 25, 2012):
Published the code under the MIT-License (license note added in code), which allows you to do with it pretty much everything you want. No need to ask me first

Sensor Fusion via Complementary Filter

Before we start programming, I want to explain briefly how our sensor fusion approach works. The common way to get the attitude of an Android device is to use the SensorManager.getOrientation() method to get the three orientation angles. These two angles are based on the accelerometer and magenotmeter output. In simple terms, the acceletometer provides the gravitiy vector (the vector pointing towards the centre of the earth) and the magnetometer works as a compass. The Information from both sensors suffice to calculate the device’s orientation. However both sensor outputs are inacurate, expecially the output from the magnetic field sensor which includes a lot of noise.

The gyroscope in the device is far more accurate and has a very short response time. Its downside is the dreaded gyro drift. The gyro provides the angular rotation speeds for all three axes. To get the actual orientation those speed values need to be integrated over time.  This is done by multiplying the angular speeds with the time interval between the last and the current sensor output. This yields a rotation increment. The sum of all rotation increments yields the absolut orientation of the device. During this process small errors are introduced in each iteration. These small errors add up over time resulting in a constant slow rotation of the calculated orientation, the gyro drift.

To avoid both, gyro drift and noisy orientation, the gyroscope output is applied only for orientation changes in short time intervals, while the magnetometer/acceletometer data is used as support information over long periods of time. This is equivalent to low-pass filtering of the accelerometer and magnetic field sensor signals and high-pass filtering of the gyroscope signals. The overall sensor fusion and filtering looks like this:

So what exactly does high-pass and low-pass filtering of the sensor data mean? The sensors provide their data at (more or less) regular time intervals. Their values can be shown as signals in a graph with the time as the x-axis, similar to an audio signal. The low-pass filtering of the noisy accelerometer/magnetometer signal (accMagOrientation in the above figure) are orientation angles averaged over time within a constant time window.

Later in the implementation, this is accomplished by slowly introducing new values from the accelerometer/magnetometer to the absolute orientation:

// low-pass filtering: every time a new sensor value is available
// it is weighted with a factor and added to the absolute orientation
accMagOrientation = (1 - factor) * accMagOrientation + factor * newAccMagValue;

The high-pass filtering of the integrated gyroscope data is done by replacing the filtered high-frequency component from accMagOrientation with the corresponding gyroscope orientation values:

fusedOrientation =
    (1 - factor) * newGyroValue;    // high-frequency component
    + factor * newAccMagValue;      // low-frequency component

In fact, this is already our finished comlementary filter.

Assuming that the device is turned 90° in one direction and after a short time turned back to its initial position, the intermediate signals in the filtering process would look something like this:

Notice the gyro drift in the integrated gyroscope signal. It results from the small irregularities in the original angular speed. Those little deviations add up during the integration and cause an additional undesireable slow rotation of the gyroscope based orientation.

]]> http://www.thousand-thoughts.com/2012/03/android-sensor-fusion-tutorial/feed/ 93 http://www.thousand-thoughts.com/2012/03/master-thesis-printed/ http://www.thousand-thoughts.com/2012/03/master-thesis-printed/#comments Sat, 03 Mar 2012 17:13:16 +0000 Paul http://www.thousand-thoughts.com/?p=759 Finally, here it is. My finished thesis… …in print…

Actually…	…looking at it this way…

…	…

…Whoa!