Products for USB Sensing and Control
It is currently Tue Jul 22, 2014 12:43 pm

All times are UTC - 7 hours [ DST ]




Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Thu Sep 09, 2010 11:47 am 
Offline
Fresh meat

Joined: Tue Apr 06, 2010 12:44 pm
Posts: 4
Hi:

I buy 5 1056 - PhidgetSpatial 3/3/3 trusting at the "Rigorously tested to ensure "real life" data", but now I find in the bottom page at the device specification pdf (1056.pdf) that it say and I'm quote:

3-Axis Gyroscope
Drift must be addressed when developing a navigation system that uses a gyroscope. Over time, the valve that the
gyroscope outputs when in a steady position will change because of gyroscope bias drift. This is a problem when
the gyroscope output is integrated to determine heading; the error will accumulate, and the gyroscope will appear
to be rotating when it is stationary. This cumulative error can be counteracted by using the shortest integration
period possible, and by using advanced filtering algorithms, such as Kalman filters, which use the accelerometer and
compass to decrease bias drift errors.

So, the gyro data is untrusted since even with the gyro in a steady position the gyro is going to look as is been rotating when is stationary and the error is acumulative (like is show it in the device "Spatial" examples)...to make it worse I would need to implement a advance filtering algorithm like Kalman's one to counteracted this issue..I would not expect this kind of behaviour in a device that is "Rigorously tested to ensure "real life" data"...and that was the reason to buy this expensive device since I don't have the time to implement, test and calibrate a filtering algorithm. f I hade the time I would buy just a cheap US$30 gyro ...

So, I going to start kindly asking how to ensure gyro data and what is the advance filter provided by your company to make the data from gyro to be stable and trusted...

Thanks

Mauricio Henriquez


Top
 Profile Send private message  
 
PostPosted: Thu Sep 09, 2010 4:46 pm 
Offline
Lead Developer
User avatar

Joined: Mon Jun 20, 2005 8:46 am
Posts: 2603
Location: Canada
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, if you want to get useful data out of it. We invested time/money into seeing if we could develop a general purpose filter and we decided that we could not provide something useful at this time.

Even so, the Spatial 3/3/3 is quite competitively priced compared to other USB based boards with 3 axes of gyro/accelerometer/compass, and has met with considerable success.

-Patrick


Top
 Profile Send private message  
 
PostPosted: Fri Sep 10, 2010 7:12 am 
Offline
Phidgeteer!

Joined: Thu Mar 04, 2010 2:51 am
Posts: 68
patrick wrote:
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)


Top
 Profile Send private message  
 
PostPosted: Wed Sep 15, 2010 10:45 am 
Offline
Fresh meat

Joined: Tue Apr 06, 2010 12:44 pm
Posts: 4
frodegill wrote:
patrick wrote:
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)


me again...sorry..
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...

thanks

Mauricio


Top
 Profile Send private message  
 
PostPosted: Thu Sep 16, 2010 12:43 pm 
Offline
Fresh meat

Joined: Tue Apr 06, 2010 12:44 pm
Posts: 4
buhochileno wrote:
frodegill wrote:
patrick wrote:
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)


me again...sorry..
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...

thanks

Mauricio


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


Mauricio


Attachments:
File comment: Kalman Test for Spatial333 IMU
KalmanTest1.rar [48.29 KiB]
Downloaded 456 times
Top
 Profile Send private message  
 
PostPosted: Fri Oct 08, 2010 8:39 am 
Offline
Fresh meat

Joined: Wed Feb 17, 2010 4:03 am
Posts: 3
Thanks Mauricio for sharing your code.

I'm really new to Kalman filtering methode (still studying).
Can you kindly explain me how can you find these parameters:

private const double dt = 0.00809651
private double Sz_00 = 17.2;

private double P_00 = 0.005;
private double P_01 = 0.005;
private double P_10 = 0.005;
private double P_11 = 0.005;

private double Sw_00 = 0.005;
private double Sw_11 = 0.005;

// private double Sz_00 = 6.5;
private double x_00 = 0.0;
private double x_10 = 0.0;

With trial and error methode ??

Your exe gives only Kalman filtered roll angle. Can I extend it to pitch angle ?
And what about the bearing/yaw ?

Thanks,
Yaumars


Top
 Profile Send private message  
 
PostPosted: Fri Dec 02, 2011 8:42 pm 
Offline
Fresh meat

Joined: Fri Dec 02, 2011 6:10 pm
Posts: 1
Hi, i have downloaded your kalman file, and i try to run it but failed.

may i know what is wrong?

cos i am new to programming and interface all these.

anyone can help?

thanks

SJ


Top
 Profile Send private message  
 
PostPosted: Wed Dec 21, 2011 4:51 pm 
Offline
Phidgetsian

Joined: Wed Oct 07, 2009 6:21 am
Posts: 13
Dear colleagues,
Currently I am working in a project about a car. We have a similar problem with Spatial 3/3/3. We want to get a reliable acceleration and we need Kalman Filter as a good approach for the problem.
We want to control angles such as roll and pitch, because gravity component acceleration should be removed in each axis.
However we have a problem with gyroscope's drift. According to the 1056 specifications, drift/minute = 4º typical in the gyroscope
My questions are
a) which variance and covariance values are needed for Spatial 3/3/3? I know that in specification device I can found some datas, but I don't know if they are enough for KF
b) How could I remove drift effect for the gyroscope? (just with KF? is it magic!!)
c) Did I need a KF for each signal? I have 9 signals (3/3/3), should I filter out each signal independently?
d) Has Somebody a Matlab code (for example) which might it be shared?
I appreciate so much some idea or piece of advice.
Best regards
- Moises Diaz-Cabrera


Top
 Profile Send private message  
 
PostPosted: Sun Jan 08, 2012 1:12 am 
Offline
Phidgetsian

Joined: Thu Oct 06, 2011 9:15 pm
Posts: 8
buddy, may i ask, i tried your kalman. but could u tell, how to change the angle into angular velocity which is closed to the gyro value, or, I am intend to make it the gyro value,thx


Top
 Profile Send private message  
 
PostPosted: Mon Jan 09, 2012 8:25 am 
Offline
Fresh meat

Joined: Thu Jan 05, 2012 12:03 pm
Posts: 1
I got my phidget on friday and spent the weekend researching filters to remove the drift so i though i would share what I had done since it may be useful for other.

Having looked at Kalman filters and thought, no, I say i post on other options and implemented a complementary filter that seems to do the job in C#.

Below is the code i changed calculateGyroHeading but since i added some boxes to the spatial full layout so iv attached the exe, the full source can be found here

https://sites.google.com/site/jordanrsb ... stment.zip

To tweak the filters response you need to change the timeConstant variable.

Code:
 void calculateGyroHeading(SpatialEventData[] data, int index)
        {
            double timeConstant = 0.7;
            double gyro = 0;
            double accelX = 0, accelY = 0, accelZ = 0;
            for (int i = 0; i < data.Length; i++)
            {
                gyro = data[i].AngularRate[index];
                accelX = data[0].Acceleration[0];
                accelY = data[0].Acceleration[1];
                accelZ = data[0].Acceleration[2];
                     
                if (lastMsCountGood[index])
                {
                    //calculate heading
                    double timechange = data[i].Timestamp.TotalMilliseconds - lastMsCount[index]; // in ms
                    double timeChangeSeconds = (double)timechange / 1000.0;

                   

                    if (index == 0)
                    {
                        // calculate x angle from accelerometers in radians
                        angle[0] =  Math.Atan(accelX / (Math.Sqrt((accelY * accelY) + (accelZ * accelZ))));

                        //complementary filter to remove drift
                        gyroHeading[index] = (timeConstant) * (gyroHeading[index] + timeChangeSeconds * gyro) + (1 - timeConstant) * RadianToDegree(angle[0]);

                        // set text box
                        xTextBoxAngle.Text = RadianToDegree(angle[0]).ToString("F3") + "°";
                    }
                    else if (index == 1)
                    {
                        // calculate y angle from accelerometers in radians
                        angle[1] = Math.Atan(accelY / (Math.Sqrt((accelX * accelX) + (accelZ * accelZ))));

                        //complementary filter to remove drift
                        gyroHeading[index] = (timeConstant) * (gyroHeading[index] + timeChangeSeconds * gyro) + (1 - timeConstant) * RadianToDegree(angle[1]);
                       
                        // set text box
                        yTextBoxAngle.Text = RadianToDegree(angle[1]).ToString("F3") + "°";
                    }
                    else if (index == 2)
                 
                    {
                        // calculate z angle from accelerometers in radians
                        angle[2] = Math.Atan(accelZ / (Math.Sqrt((accelX * accelX) + (accelY * accelY))));

                        //complementary filter to remove drift
                        gyroHeading[index] = (timeConstant) * (gyroHeading[index] + timeChangeSeconds * gyro) + (1 - timeConstant) * RadianToDegree(angle[2]);
                       
                        // set text box
                        zTextBoxAngle.Text = RadianToDegree(angle[2]).ToString("F3") + "°";
                    }
                   

                    // original code without drift compenstation
                    //gyroHeading[index] += timeChangeSeconds * gyro;

                }


                lastMsCount[index] = data[i].Timestamp.TotalMilliseconds;
                lastMsCountGood[index] = true;
            }
        }

        private double RadianToDegree(double angle)
        {
            return angle * (180.0 / Math.PI);
        }


Attachments:
File comment: Spatial Full with filtering on the gyro
Spatial-full.zip [208.76 KiB]
Downloaded 241 times
Top
 Profile Send private message  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 7 hours [ DST ]


Who is online

Users browsing this forum: Yahoo [Bot] and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group