Meant to be Seen

I added the Mahony fusion to the android branch (It will be merged with the master branch soon).
Its fast, but drifty as hell (Tested with a HTC One X and Google Nexus)

It would be really nice if we could get our hands on a sexy algorithm which is fast and with as low drift as possible, than we could incorporate this fusion to all our IMU's (For the ones that expose raw data at least).

I wonder what the odds are that Carmack releases his to the community, maybe we could get Palmer to see what the chances are.

Any other ideas?

I know you didn't have much luck with it, but I think the AHRS algorithm is pretty good. My Sparkfun performs wonderfully.

brantlew wrote:I know you didn't have much luck with it, but I think the AHRS algorithm is pretty good. My Sparkfun performs wonderfully.

Yeah, doesnt work were I live

I wonder how easy it would be to port it to C#

brantlew wrote:I know you didn't have much luck with it, but I think the AHRS algorithm is pretty good. My Sparkfun performs wonderfully.

Which AHRS algorithm are you using?
CyberVillain switched to Mahony over Madgwick because the latter didn't work immediately

Although I don't see a big difference: https://vimeo.com/36319959
ps. The drift in this video is much less than experienced with the Android sensor-data.
The Android-app or plugin must be doing _something_ wrong, because I don't see this stability.

mahler wrote:

brantlew wrote:I know you didn't have much luck with it, but I think the AHRS algorithm is pretty good. My Sparkfun performs wonderfully.

Which AHRS algorithm are you using?
CyberVillain switched to Mahony over Madgwick because the latter didn't work immediately

Although I don't see a big difference: https://vimeo.com/36319959
ps. The drift in this video is much less than experienced with the Android sensor-data.
The Android-app or plugin must be doing _something_ wrong, because I don't see this stability.

I would love if someone with a little more advanced math knowledge than me could check the code

mahler wrote:Which AHRS algorithm are you using?

https://dev.qu.tu-berlin.de/projects/sf-razor-9dof-ahrs

I think it would need to ported from Arduino to PC, and I'm sure there are a bunch of difficult details - but the result seems very good to me. Also it includes a magnetic calibration algorithm so you can calibrate the sensor against the magnetic background noise.

Well this is promising - even though Microsoft has a small share in the mobile device segment, they are really pushing hard now and I suspect the Windows 8 variants will make some headway. Good news because (like Apple) Microsoft will have a mature sensor fusion package to draw upon instead of the disjoint environment that Android provides. And Windows development is typically a lot more "open" and streamlined than it is on iOS. Here is some info...

http://blogs.msdn.com/b/b8/archive/2012 ... ows-8.aspx

Unfortunately it does not appear that they will have a generic fusion "engine" that could be fed by raw data from any sensor package.

brantlew wrote:Well this is promising - even though Microsoft has a small share in the mobile device segment, they are really pushing hard now and I suspect the Windows 8 variants will make some headway. Good news because (like Apple) Microsoft will have a mature sensor fusion package to draw upon instead of the disjoint environment that Android provides. And Windows development is typically a lot more "open" and streamlined than it is on iOS. Here is some info...

http://blogs.msdn.com/b/b8/archive/2012 ... ows-8.aspx

Unfortunately it does not appear that they will have a generic fusion "engine" that could be fed by raw data from any sensor package.

I think its better we put the effort in full support for the Wiimote before supporting hardware that is used by 0.0000000000001% of the market

Why do you think its disjoin though? Sure, the Android SDK is not as nice as using Caliburn.Micro + Xaml on a W7 - W8 Phone but still, its a pretty decent SDK. Lightyears better than iOS.

How did you get Caliburn Micro from this post? I was speaking only of the sensor fusion API which on doesn't seem to officially exist on Android.

brantlew wrote:How did you get Caliburn Micro from this post? I was speaking only of the sensor fusion API which on doesn't seem to officially exist on Android.

I thought we were talking about mobile device development in general.

Sensor fusion is in the Android SDK doc (Its called orientation though)

http://developer.android.com/reference/ ... float[]%29

CyberVillain wrote:Sensor fusion is in the Android SDK doc (Its called orientation though)

Confused. If this is indeed a driftless, sensor fusion API, then why is the FreePIE Android thread five pages long?

brantlew wrote:

CyberVillain wrote:Sensor fusion is in the Android SDK doc (Its called orientation though)

Confused. If this is indeed a driftless, sensor fusion API, then why is the FreePIE Android thread five pages long?

Android plugin supports two methods from the Android App

1) App sending raw dating and plugin fusing it (using AHRS code from x-io.co.uk)
2) App sending deprecated orientation_sensor data from the device and the plugin directly translating it to yaw, pitch, roll

... there should be a third (the one CyberVillain is talking about) - but it was laggy somehow.

3) App sending fused orientation data (calculated by Android API) and the plugin directly translating it to yaw, pitch, roll

brantlew wrote:

CyberVillain wrote:Sensor fusion is in the Android SDK doc (Its called orientation though)

Confused. If this is indeed a driftless, sensor fusion API, then why is the FreePIE Android thread five pages long?

You said

brantlew wrote:I was speaking only of the sensor fusion API which on doesn't seem to officially exist on Android.

It does exists, but its not designed for head tracking in mind, it has no drift etc, but its laggy and not suited for VR