a Kalman filter to fuse gyro and compass readings

[gloomyandy]

I have made my own investigations with many different robots and unless you correct them with other readings the errors from odometry will build up over time (and I hope this time will be considerably less than my lifetime)...

[HaWe]

yes, you sure will have to correct them as I myself already said before.
But this claim is false:

there is no way of stopping it becoming less accurate over time than an absolute reference such as a compass.

You won't mangage to do this using a HT compass - and if you try to, it's worse than before.
You will have to have reliable data. Compass data are not that reliable and gives you no absolute references at any time.

Others made the same experience like me (even when a compass was used e.g. as an extra input for a particle filter).

But show me your program (e.g. room mapping), show me your robot, and show me your mapping and navigation results
a) using odometry alone and
b) odometry in combination with a HT compass using a KF filter or simply calculating by means and medians.
And if you like, additionally
c) odometry in combination with a gyro sensor, or
d) a HT compass in combination with a gyro sensor without odometry, also using a KF filter or simply calculating by means and medians.

Like they say in the Latin fable of Aesopos: "Hic Rhodos, hic salta!"

I am open to conviction.

[gloomyandy]

Doc I was not challenging your dislike of (or the problems with) the hitechincs compass, I was challenging your statement that basic odomerty errors (no mention of correction) will not exceed the errors from a compass sensor in your lifetime (which I hope will not be that short). Since any compass can only have an error of 360 degrees and uncorrected odometry errors will always accumulate, clearly this is not the case... This thread is already way off topic and I don't intend to take it any further that way...

Now back to a discussion of how to use a gyro and a kf, both of which I've done with some success along with an accelerometer in a balancing robot... This particular combination seems to work particularly well, since the absolute nature of one nicely cancels the drift from the other...

[HaWe]

no, it's not off-topic.
We handle with real existing compasses (from HT) and gyro sensors (also from HT) and motor encoders (from Lego).
We're talking about real robots in the real world, not about theoretical philosophy.

I know from my experience: odometry gives the best results of all sensor models for navigation.
And using a (HT) compass additionally makes it not better but worse.
(The lifetime argument was related to the "reliable compass thing")

I also think, odometry data have to be improved nevertheless.

And I think the KF is a good approach for this.

But what makes the real world hard to handle are
systematic non-Gaussian errors (unpredictable noise, distraction, deviation, and drifting)
limited calculating power of the NXT

So my approach was: reduce the amount of data by dismissing the unlikely data by an intelligent preselection and use the rest as inputs to an intelligent filter (KF or PF).

And I'm still curious which results you will get at best with your robot -
with which sensor/filter combination, from your own investigations.

[physics-matt]

So don't speak from the point of a "bloody theoretican" without having data - but proof your theory by the reality (that's indeed natural science).

I don't recall seeing you produce any data either.

If you can demonstrate a system that relies purely on odometry and is able to maintain better accuracy than the HT compass over long distances then I'm sure people will be more amenable to your point of view.

Matt

[gloomyandy]

Well a few things...

You have referred a number of times to the restrictions that the NXT places on using more than 2 inputs to a kf, but several of the other posters have indicated that this may not be case. I see no reason why a three input kf can not be used, if NXC is not able to do this then there are other systems that will (RobotC and leJOS are faster for these sorts of calculations and nxtOSEK much faster).

The problem with trying to feed odometry into this system is that because of the accumulation of errors over time the probability/confidence associated with the data for this source will mean that that it does not contribute very much to the overall result. Arguably the same may be true for gyro inputs, other posters have indicated that the accumulated error for a gyro is less than that for odomtry, I'm not sure that this is correct, but I have no data for this either way. You may be able to improve this by using relative values for things like rotation (in effect resetting the starting point), but I'm not sure how well this will work...

Your notion of discarding sensor inputs is interesting, but to be honest I doubt if any useful sensors will have the sorts of errors that make it easy to discard them. If the errors are so bad, then why bother even using it? As another poster suggested you are more likely to end up with three data points all arguably correct. If you have examples of this not being the case (i.e when you would not simply always discard the same input) then I would be interested in seeing them...

In terms of my own robots well this experiment clearly shows how much odometry drifts over time and one way to correct it...
http://www.youtube.com/user/gloomyandy# ... MI63k5W3sU
Perhaps you would like to show your own results...

[HaWe]

I don't recall seeing you produce any data either.

I have published my navigation robot about 3 years ago in the RobotC forum. During that time I have published several versions and also explained intermediately the results:
A) only odometry
B) odometry + simultaneously compass all over the time (worst)
C) odometry + compass correction at standstill (like A, slightly worse, but improvable by filters)

The problem with trying to feed odometry into this system is that because of the accumulation of errors over time the probability/confidence associated with the data for this source will mean that that it does not contribute very much to the overall result.

Of course not the raw odometric data (encoder values) should be taken as inputs but the calculated headings and positions . The same it's with all other KF inputs:

relative heading angle by encoder trigonometry;
compass heading can be directly used as a heading input to KF,
the gyro value has to be integrated to be used for heading input to KF,
distance from wheel circumference and encoder ticks (gyro and compass are useless for distance calculation)
distance from accelation sensor by integration.

The position (x,y) is calculated by conversion of the polar coordinates (distance, heading) into cartesic coordinates.

If the errors are so bad, then why bother even using it?

The values of course not always are bad - but sometimes, intermediately, e.g. having the compass ad the related odometry heading (plus a fictive gyro):

Code: Select all

90 - 93 - 77 - 88 -  89 - 112 - 91 - 92 (compass, direct)
90 - 91 - 90 - 91 -  90 - 89  - 88 - 89 (odometry, by trigonometry)
90 - 92 - 88 - 114 - 98 - 90  - 84 - 85 (fictive gyro, by integration)

odometry values normaly do not jump or shift (because they base on integer counter values), but they may drift;
compass may shift and have declination, gyro may shift and drift (probably I guess, I don't have one)

If you really only have 2 KF inputs because 3 are too complicated to calculate (as aswin wrote), you will have to make a decision which one you'll dismiss - or you really manage to have 3 inputs to KF (for heading; for distance you only have 2 independent inputs anyway by odometry + acceleration)

[gloomyandy]

A few comments...

If you can, please post a link to your previous results. I'd like to see them... I think they would provide useful input to this discussion...

Is the odometry data and compass data you posted from a real set of measurements (I understand that you made up the gyro data)? If so what does it actually represent? What was the robot doing each time? Are the values relative rotations (I assume they are), or absolute headings? Is the robot moving to a different location between turns?

Going back to your original suggestion of selecting different inputs for a two input kf based on discarding one or more sensor readings. How would you actually do this? My understanding is that the kf uses predicted values based on variance data etc. won't feeding different source data (with presumably different noise characteristics) mess this up? Or alternately won't you need to run a part of the calculation for each sensor input (to maintain the prediction values), or at the very least keep separate prediction values for each possible input?

[HaWe]

I don't know how the KF works in detail, I guess better aswin should tell us what the best way could be. I'll probably go that way:

or at the very least keep separate prediction values for each possible input

the intermediate results of my navigation robot versions have been deleted meanwhile (also the code itself using continuous compass readings for heading after the results have been too unreliable), but one program code version still exists:
http://www.robotc.net/forums/viewtopic.php?f=15&t=455

[physics-matt]

the intermediate results have been deleted meanwhile, but the program code still exists:

Ok, then what you're saying is you have no data to back up your claims.

Matt