a Kalman filter to fuse gyro and compass readings

[gloomyandy]

I thought my previous post had made this pretty clear.... I am not (and have never) proposed that using pure compass data makes any sense. Clearly a combination of compass and odometry is a better route. Basically you run on pure odometry until your estimate of the accumulated error is such that it exceeds the expected error from a compass sensor. At that point you use the compass sensor to correct the heading data (pretty much in the same way that my video shows absolute positioning data from beacons being used to correct heading and position data after a series of moves). So for instance in the final table of my data, if after every 10 squares I had corrected the orientation data using the compass then I would expect that the final error would have been more like 10 degrees rather than the 25 actually measured. It may even have made sense to correct more often and lower the final error further still...

The gyro presents a different option. It does seem to generate data that could be of use actually during a rotation (though I suspect it would still be best to combine it with odometry).

@doc I don't think you answered my question....
When you ran your original squares test just using odometry what would happen if you lifted it up from the floor? What position would the robot think it was at? Perhaps we are all misunderstanding what you did with your pure odometry robot. How did it work?

[HaWe]

Basically you run on pure odometry until your estimate of the accumulated error is such that it exceeds the expected error from a compass sensor. At that point you use the compass sensor to correct the heading data

that's about the way the last release of my navigation robot (about 3 years ago) worked (but it still was not accurately and reliably enough).
Just have a look at the code.

But that will never be the way it will work if you'll pass both encoder data and compass data simultaneously to your navigation algorithm.
But I am still open to conviction.

[physics-matt]

this is the Ultimate Question - why do we want to improve navigation data if we don't want to improve the results of navigation?

[OT] Wasn't the ultimate question "what do you get if you multiply six by nine?" ?[/OT]

But seriously, there is a good reason why this is not the question we should be trying to answer at this point: It does not allow us to assess the performance of the sensors independently of the robot control algorithm. Personally, I don't think this is a very scientific way of going about things as we are changing too many variables at once.

Matt

(Edited to avoid sounding too much like a flame and risking the wrath of Xander!)

[HaWe]

Show me your robot that can navigate reliably and accurately using simultaneoulsy a compass (or a gyro, e.g. as an input to a Kalman Filter) - better than a robot just using odometry can do .
I am eager to know, and I am open to conviction.

ιδού η ρόδος, ιδού και το πήδημα - hic Rhodos, hic salta.

[physics-matt]

doc-helmut,

I've just been looking through your code and it appears that you check the compass or odometry measurement each time the robot stops (please correct me if I'm wrong - not being able to read German and only having a small amount of experience with RobotC makes it difficult to understand your code).

Your robot then calculates how much it needs to turn each motor based on this bearing and the bearing it needs to head for, and moves the motors until their tacho counts equal those calculated.

That's interesting because, as has been demonstrated, the compass is quite capable of being more accurate at measuring the bearing of the robot than odometry. There must therefore be another reason for the relatively poor performance and it would be interesting to find out what that is.

Perhaps you could provide the measurements of the bearings from the compass and odometry each time it stops?

It would be useful if you could confirm exactly when your robot takes bearing measurements (I noticed that even though the odometrics () does take a reading from the compass, you have commented out the line that copies it to the global variable Kurs, which stores the bearing).

If I have time I will try and reproduce your results on my robot, but I can't promise anything.

Matt

[HaWe]

yes, you are right, that is exactly what it does:

I've just been looking through your code and it appears that you check the compass or odometry measurement each time the robot stops

Going straight ahead is intermediately (simultaneously) corrected by synchronization of motors, and wheel turning is calculated by the required encoder targets of both motors. When finished, the running or turning result (target state) is compared with the actual state and corrected or aligned if necessary. So far the odometry part.

The compass data have been too faulty to use them simultaneously, so checking the odometric calculated data only between 2 maneuvers (like course changes) was the best approach I could achieve (you actually have discovered the relicts and ruins of that different formerly try). Nevertheless the compass headings even at the intermediate stops often have been more faulty than the odometric headings - only if odometry errors had accumulated to a "huge amount" they gave a little improvement; but in that case "hops and malt were already lost anyway" as we say.

So my suggestion was:
Feed all the data (odometric, compass, and gyro) into the KF. Having all 3 inputs would be best, but if only 2 inputs are available, 1 has to be dropped (admittedly a compromise solution).

The program design of my program must be changed for that approach:
instead of re-calculating the postion only between 2 maneuvers (maybe also only after a very long run "straight" ahead), all the values now should be polled every - let's say - 10 or 20 msec.
Store them to an array, calculate the heading and the position out of them seperately, an feed them to the KF.

That was actually my original approach.

I will have to write the code new for using it again - because I don't use RobotC anymore. Although I needed RobotC because it had fp arithmetics opposite to NXC, it was on the other hand bugged like hell at that time (~2 years back) and by the many bugs I could not program properly (I therefore renamed it to "RobugC" - and sacrificed almost all of my projects).
Then fortunately NXC got fp arithmetics too, and so I quickly switched my programming platform (anybody who wants my license?).

I will re-write my program to NXC at the moment when there will be a intelligent filter in sight that really improves the navigation accuracy significantly (KF? PF?)

[physics-matt]

Ok, so I've just programmed my robot to go round a 1m^2 square and finish reliably in the same spot & orientation as it started (to within a couple of cm and degrees). Each turn was conducted by moving the motors until the compass sensor measured the desired bearing. No odometry was used at any point.

The trick to getting it to work was to properly calibrate the compass. The readings were offset by different amounts at different bearings, but these were repeatable such that they could be calibrated out in my software.

So there we go. A much more satisfying answer I think than simply concluding that the compass sensor isn't very accurate. Admittedly, I haven't compared it to results using odometry, but I'm quite satisfied that navigation can be achieved to a high level of accuracy with careful use of the compass.

Matt

[HaWe]

if you didn't use any odometry at any point: then I'm curious to know how you made your robot go exactly 1m straight ahead?
and - completely forgot to ask: do you have ferroconcrete walls /floors/ceilings with water pipes, and also heating radiators in your room?

[physics-matt]

I just used the Wait function and chose a length of time such that, at the power it was running, I got roughy 1m. Obviously, the exact distance will depend on battery power levels etc, but during the course of a single run it will move the same distance each time, which is the most important thing. The main thing was to use the OnFwdSync function so that the left and right motors were synchronised, which helps it go straighter.

I was doing the experiment in my kitchen which doesn't have any metal in the floor as far as I know, but there are large pieces of metal in places, such as my oven. These do have an effect if you get close and to some extent can be calibrated out (i.e. if you know you're near to a large metal object you may be able to compensate for it), but I accept that this will always be a fundamental limitation to the compass.

What I would like to know is exactly why the compass has such a strong dependence on its tilt (i.e. how far it is off being horizontal). Having a better understanding of the underlying physics of it may help to find better ways to compensate. Even better, do we know whether anyone else has made a compass sensor that doesn't have this limitation?

Matt

[HaWe]

using OnFwdSync is an odometric compensating instrument. You'll have to navigate ahead without using odometric instruments if you want to gather results about compass navigation. I'm really curious how your square experiment proceeds completely without odometrics in relation to odometrics completely without compass. And more than this: your robot always has to calculate where he exactly is on his internal map.

But we can endlessly argue about the devil's beard.

I'm sure - no: I am convinced that your method does not achieve the required accuracy to me (estimated 0,1-0,2% navigation accuracy for a maze mapper and solver, size about 10m x 7m for all rooms on the floor, driving around about 1 hour at a go).

Lets wait and see what the KF (or a PF) brings in future.

PS:
I'm using compasses since 40 years in airoplanes and on ships for navigation and bearing. Believe me: I know about their limitations.