Accelerometer class with low pass filter

Home Forums Monkey 2 Code Library Accelerometer class with low pass filter

This topic contains 6 replies, has 5 voices, and was last updated by  Anatol 3 days, 13 hours ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
  • #11031



    I think this is worth sharing. I’ve written an accelerometer class with a couple of features that I find useful:

    • device rotation in radians (calculated from the raw data)
    • normalised device rotation in the range -1.0 to 1.0
    • low pass filtered output (optional but enabled by default to reduce noise from the raw data)
    • manual or “automatic” calibration (optional)
    • detection if the device provides accelerometer data (to fall back to other controls if not)
    • other data: raw data, filtered G (force) data

    You’ll notice a very slight delay of device rotation and the dependent rotation of a sprite when you use the accelerometer. This is due to the low pass filter and you’ll always have to compromise between smoothness (less noise) and delay, but I think the default filter values are acceptable. The rotation based on unfiltered raw data has no delay but looks very jittery.

    I tested this on iOS and Android and both looked the same. iOS seems to produce a different raw value range, but the class handles this (fingers crossed this is the same across all iOS devices).

    You’ll need the LowPassFilter and the Accelerometer classes below.

    Low pass filter:

    Accelerometer (with plenty of comments in case anyone wants to understand what’s going on; it took me a while to figure this out):


    It’s very simple, just import the accelerometer class and initialise an instance:

    and call Accel.OnUpdate() in the render loop.

    You can then access Accel.X / Y / Z or Accel.NormalX / NormalY / NormalZ or even the raw data or filtered G value (force) for the three axes. E.g.

    I also added a Github repo with the source files and demos:

    The screenshot is from that demo with an arrow always pointing to the ground, regardless of device rotation.

    I hope this is useful for some projects. I’m just getting into Monkey2 after a few years break from MonkeyX and I love it. Hopefully the community will become as active and helpful as it was for MonkeyX.



    Nice thanks.


    Mark Sibly

    Very nice!



    Great stuff, thank you for sharing.

    Yesterday I attended a presentation by Danish firm Rokoko about their Smartsuit Pro, and the presenter mentioned they use Kalman filters to clean up their sensor data, including the accelerometer. Could using that remove the delay?



    I’d really like to see someone implement the Kalman filter! I’ve thought for some time that this would be great for network lag prediction. Could be wrong, but it seems like it would work well — I gather it’s used in a lot of robotic/automated applications for similar purposes.

    All the implementations on Github are completely impenetrable and I couldn’t figure out how to transfer them!

    (This does look like a very useful piece of code, BTW, Anatol!)



    Thanks for the info Diffrenzy and DruggedBunny. I’ll have a look into the Kalman filter if I find the time. The delay with the low pass filter isn’t too bad for my needs, but no delay would be better. I have no idea about Kalman filters, so if anyone else knows more and wants to come up with a Monkey2 implementation that’d be nice, too. But yes, I’m keen to improve this further if I can make sense of Kalman.



    OK, I’ve done a bit of research about the Kalman filter and there are quite some implementation samples out there, but for now I still put it in the too hard basket. The main reason is that pretty much all implementations use accelerometer and gyroscope combined. I’m not sure how to access gyroscope raw data, I could get the accelerometer data via JoystickDevice, but no idea if gyro is accessible in any way. I also read that when the Kalman filter is set to be very smooth, you also end up with a delay. How much, and how it compares to a low pass filter I don’t know.

    Well, anyway, I’m still very interested in this and will probably come back to it at some point, but for now I think I’ll focus on other parts. I’m just very uncertain if it’s worth the effort in the end. Apparently the Kalman filter isn’t really a filter in that sense, but rather a predictor model with biases, sensibilities, noise, etc. Complex stuff. I also read that for simple noise filtering a low pass filter should be enough. There’s no knowing without trying and comparing, and that’ll bug me for sure, but maybe later.

    If the delay of the low pass filter is too great for your taste I suggest to play with the dt and rc values of the filter.

    Having said that, if anyone is a Kalman genius, please do post an implementation or possible approach in this forum. Or your opinion if it’s even the appropriate approach to reduce noise from the accelerometer.

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.