Unfortunately, there is no way for us to provide an algorithm that will give you drift-less gyro data. This is because the algorithm will depend completely on your system - the ways in which your system can move is a required input into a kalman filter
I agree in that there is no ultimate solution, but it should be possible to provide filters and functions in the API that would give improved values for some
scenarios. I have mounted a 1056 inside a tennis ball, using it as a form of input device (rotate the ball to rotate object on screen, shake the ball to change object). For rotation, I expected to simply use the compass values, but those values varies quite a bit (up to +/- 3 degrees, depending on orientation, when the ball is stationary). In my scenario, I would guess providing a kalman filter on compass and accelerometer would make the API output more stable compass values, right? (In my project, where the change in orientation is more important than the orientation itself, I ended up just accumulating accelerometer values. Works great)
I totally agree and I understand that Kalman is not "general", but some basic principles and values can be generalized and provided by you since you know better than no one the device..
Here is my situation: I'm with a Kalman implementation in C# and after a lot of fight I still can get trusted data from the gyro...I'm lost about what else I'm doing wrong and what else I can try
The thing is that after a couple of rotations (just 3 to 5 rotations), let say just on the X axe and I get a drift from a couple of degrees (-1 or +1 degree) to a big drift about even +12 degrees!!. This also happen in the wireframe example, so Attitude calculation is not good enough...and my Kalman don't see able to compensate the drift (that part is probably my fault and not kalman of course)...Sure kalman can be generalized, but if you move your device from 0° to 90° a couple of times and that happen, then you can provide a proper filter to avoid that and can be take it as base for a specific moving system..
Plus on web there are lot of success histories about using Kalam filter to imporve gyro data with accelerometer data, but specific to "devics" (sparkfun, etc) and not to "specific application", so at least that part can be provided by you...
When you investigate kalman filters, do you get some good results about drift compensation?, can you give me some values use it and what data from the device do you give to the kalman filter?...what other sugestions do you have?
The point is that if you know about the drift, what are the solutions provided by your libs/samples...specially when the device marketing phrase says "Rigorously tested to ensure "real life" data"...
So, a simple kalman filter test sample (hopefully in C#) with your test values can help a lot to us to at least take it as base for our specific situations...
I running out of time, so any help would be appreciated..at this point is not worth to me to return the devices and start to work with others gyros...
I finally made it!, my kalman filter is working and able to compensate the bias drift of the gyro data from the spatial 3/3/3 IMU..
I want to give to all developers that can need the kalman filter that I have and I'm successfully testing and not have to going to the same nightmare than I. The kalman c# code is based in one from another author, so is licence as his request (WTFPL licence)..
Don't take me wrong, I love phidgets devices (except for this one may be..just may be still to see
, but you need to improve the lib/sample offer that you provide to fix the big bias drift that the gyro have..this kalman can be the answer including samples that use it...Test it and you would see that the values are much better and can be apply it to the Spatial_full or wireframe example or as a stand alone one to take as base for specific systems/models.
Kalman can be generalized for "specific devices", not necessary to be for "specific models", the prove is that the same kalman code is use it with sparkfun IMUs...just need to set some values..
the code still have room for improvements but is good as a base...
Finally, SFEAtomic IMU (kind of in the same price range as spatial333 just miss the compass) and Hitec HG-R01 (about US50 1 axis, so US150 for 3 axes and still need the accels and compass so it can be around us230-250) have much lower bias drift and they are devices about the price range of the spatial3/3/3 to take it in consideration...
Don't hesitate to ask anything about this kalman implementation..
Regards and keep the good job...hope that this can help someone