CMPS10 deviation problem

[ArtBot]

I've mounted the CMPS10 on my robot. The factory calibration was okay in terms of North and South, but the compass suffers serious deviation problems with East and West, both of them reading about 20deg towards the North (ie, E was actually around 70 and W around 290).

I'm assuming this is to do with the metal on the robot. (As a pilot, I'm familiar with this problem.)

So, I did a calibration. The first attempt had little effect, but the second attempt seemed to cure the problem. And then, in the same session (ie, without powering down anything) the problem returned. I tried calibrating again, but it only improved a little.

Is it possible for the servos or something else on the robot to throw the compass out of whack again - ie, to undo the calibration?

FYI, I actually don't need accurate compass bearings as such, just relative bearings - ie, I don't care if the robot is accurately pointing north when it thinks it is. What I do need is for a change of bearing from north to east to be a reasonably accurate 90 degrees.

[chris]

The servos contain magnets so the position of the servo relative to the compass will affect the reading.

[ArtBot]

Hi Chris, thanks for the response. I understand that the servos are going to have an affect. It's just that, having 'swung' the compass by doing the calibration, I thought that would compensate for the presence of the servos. FYI, the servos are never moving when compass readings are being taken (the two servos control a pan & tilt head that's used only sporadically) although I guess there's a constant current going to the servos to make them maintain their position. I was just surprised that the calibration which seemed to work then stopped working!

[H.J. Windt]

Could it be that you are trying to read out the data too quickly?
I had the same problem until I read that it takes 640ms to completely refresh the CMPS10 buffer, changed my robot software and all was fine!
http://www.robot-electronics.co.uk/htm/cmps10doc.htm

[ArtBot]

I'll check that out, but I think it's unlikely. It's a classic deviation problem in that North and South are fine. Once calibrated, the robot will turn to N or S accurately, but E and W are predictably off by the amounts I mentioned. I'm using an algorithm to turn to a heading in which the robot makes smaller and small turns as it approaches the desired heading. In order to prevent overshooting, the algorithm leaves increasingly long gaps between each turning motion. You can see it doing it in this video:

http://www.youtube.com/watch?v=hvuRf7rG4C4

I'm about to dismantle the current robot in order to use the parts on a bigger one (see here: Speculatrix). On the new version, I'll try moving the compass module further from the servos (it's actually rather close at the moment). I'll also experiment with switching off the pins that talk to the servos whenever I read the compass. I don't need to use the pan & tilt head at the same time as reading the compass.

[H.J. Windt]

Easy enough to test...

Stop the robot, pause 640ms, read out the CMPS10, turn the robot a number of steps, stop the robot, pause 640ms, read out the CMPS10............

My turning algorithm works the same as yours except if it does overshoot it will correct itself by taking small "steps" in the other direction.
By adding the 640ms pause my robot turned very accurately, before this I thought there was something wrong with the CMPS10.
Let use know how it works out.

[ArtBot]

Okay, well a tried a couple of extra things.

First, I recalibrated and added a full 1s delay between steps when aligning to a heading. This made no difference. The robot still ended up pointing around 290-300deg when it was reporting that it was pointing 270, and 60-70deg when it was reporting 90. N and S (0 and 180) were reasonably accurate, which is also unchanged and why I had a hunch the delay thing wasn't the issue.

Next, I disconnected the servos and recalibrated. But when I ran it again, same problem. Which is a bugger because I'd assumed that proximity to the servos was causing the deviation, but evidently not. So maybe it's the motors? Batteries? Or other electronics - the compass module is right next to a Bluetooth module, so don't know if the RF from that could have an effect?

[H.J. Windt]

Does look like something else is the issue.
Try mounting the CMPS10 10 to 20 cm higher, as a test, and see if that works out better (keep the pause of 640ms).
The CMPS10 on my robot is also mounted very high due to the proximity of a stepper-motor.

[ArtBot]

Yep, that's what I plan to do on the next robot...

[shlantz]

Hi,

I have the same problem... I tured up my robot without motors power and moved the compass with my hand and saw the same problem exactly...
0 and 180 was accurate and 270 was 290+/-

I have to find a solution soon!!! Its my university final project and I have to finish it this week.

Please help!

[ArtBot]

I haven't been able to sort this problem, although I haven't spent much time on it because I've been focusing on other things (like earning a living!).

I'm probably going to accept the inaccuracy and just apply a compensating factor. The error is fairly repeatable and predictable and so I'll do what we do in aircraft - accept that the deviation exists and apply a correction factor depending on heading. (An aircraft has a 'compass card' held in a mount on the compass. It shows how many degrees, plus or minus, to add to the displayed bearing for each of the 8 main points of the compass.)

I guess there should be some clever mathematical way of doing this - so that the compensation factor is 0 for a bearing of zero, rises to +20 when the bearing gets to 70 and then declines again to 0 once it gets to 180. (And then something similar for the other half of the compass). Anyone know what the proper way of doing this might be?