Rodemfr/MicronetToNMEA

Suspicion of bad tilt compensation in heading calculation

Closed this issue · 22 comments

All is in the title. Heading needs to be more seriously tested :

  • Compass needs to be calibrated carefully, far from metallic objects and electronic device.
  • A non metallic tool needs to be used to tilt MTN with precision.
  • Do that all of this outside the house

I don't know which algorithm we're using for tilt compensation, but here is the ST application note with the recommended algorithm for the LSM303DLH. And here is the Arduino library which implements it. Should we use it instead of reinventing the wheel ourselves?

@tvr256 : If you want save your time you checkout branch lsm303_variants and start. That's what I am using in my production version.

I must admit that I could use existing algorithms for tilt compensation, but this type of project is all about understanding how things are made and all about having fun :-)
I will test my current tilt compensation and I promise I will switch to dwarning's version if I see there is a serious problem for which I don't foresee a quick fix.

Few results with latest master branch - all values are raw estimated.

No compensation with z to bottom:
Using LSM303DLHC for magnetic heading
Magnetometer calibration : -0.03 -0.08 -0.18
Heading offset = 0
Magnetic variation = 0
East planar: 83°, 30° roll starboard 107°, 30° roll backboard 87°
South planar: 181°, 30° roll starboard 214°, 30° roll backboard 147°
West planar: 279°, 30° roll starboard 275°, 30° roll backboard 299°
North planar: 005°, 30° roll starboard 338°, 30° roll backboard 033°

With compensation with z to bottom:
Using LSM303DLHC for magnetic heading
Magnetometer calibration : -0.03 -0.09 0.01
Heading offset = 0
Magnetic variation = 0
East planar: 77°, 30° roll starboard 83°, 30° roll backboard 76°
South planar: 176°, 30° roll starboard 176°, 30° roll backboard 181°
West planar: 279°, 30° roll starboard 282°, 30° roll backboard 278°
North planar: 010°, 30° roll starboard 009°, 30° roll backboard 005°

Pitch has more deviations.

I improved my test setup with larger distance from sensor to PCB.
The compensation procedure was very quick - about 1..2 minutes.
Seems including sensor z-axis to bottom and top in the compensation is better.

BTW - my different algorithm has not better results.

Can you both make a comparable check please.

I will do the same tests on my side but I have one question : what do you mean by compensation with Z bottom?

The difference is for the first compensation procedure the z-axis points only (!) to top or better sky in all rolling and pitching moves.
For the second I made first the moves with z-axis to top and the same procedure with z-axis to bottom, or better to earth. So the entire room is covered.
My first thought was that the second approach is a bit unrealistic because rod in water is very rarely. ;) But it looks for sensor calibration we need this.

Second compensation - same coefficients. The roll and pitch angles with 30° are very rough estimated.

With compensation with z to earth and sky about 2...3min:
Using LSM303DLHC for magnetic heading
Magnetometer calibration : -0.03 -0.09 0.01
Heading offset = 0
Magnetic variation = 0
East planar: 085°, roll starboard 090°, roll backboard 084°, pitch fore 030°, pitch aft 140°
South planar: 176°, roll starboard 176°, roll backboard 181°, pitch fore 005°, pitch aft 177°
West planar: 279°, roll starboard 282°, roll backboard 278°, pitch fore 340°, pitch aft 200°
North planar: 010°, roll starboard 009°, roll backboard 005°, pitch fore 003°, pitch aft 167°

These are my values with the modified Poulo sketch from lsm303_variants.

With compensation with z to earth and sky about 2...3min:
Using LSM303DLHC for magnetic heading
Magnetometer calibration : 20.00 -12.50 121.00
East planar: 095°, roll starboard 096°, roll backboard 093°, pitch fore 092°, pitch aft 098°
South planar: 180°, roll starboard 192°, roll backboard 171°, pitch fore 183°, pitch aft 181°
West planar: 271°, roll starboard 272°, roll backboard 270°, pitch fore 270°, pitch aft 269°
North planar: 005°, roll starboard 000°, roll backboard 009°, pitch fore 003°, pitch aft 010°

In my opinion there is some margin to improve, e.g. by using offset compensated acceleration values.

There seems to be an error in my tilt compensation formula. I will not have time to investigate this so I think I will take the code from your branch, maybe make one or two structural changes and use it as the master version.

OK, but I think branch lsm303_variants is not usable. It's too old and structure full different. Should I make an temporary branch with my actual compass code? Most differences are in NavCompass.cpp.

NavCompass.txt

Please make your own check with your code!
I found out that one of my DLHC's seems broken. Didn't show plausible z-values.
And I don't know if I made the worse check with your code was with this chip. Sorry for the confusion.
Will try to repeat it at next.

Hi imported the heading caluclations from your branch (vector version), it was easy, even if the branch is somewhat old. It seems to work better now. This calculation is supposed to be the same than mine but obviously I inserted a calculation error somewhere in my optimizations.
Can you tell me if the branch fix_issue_#61 is working fine for you ?

Yes, its much better now. Acceptable and comparable roll and pitch deviations.
I feel the time constant for filtering a little bit large.
BTW: Today is my exam for boat license sea. I am back tomorrow.

Good luck for your license !
I will reduce a bit the filtering window size and merge it to the master.

I haven't tested the tilt compensation, but the new code appears to have increased the compass accuracy. Previously with a stationary compass, the reported bearing would constantly "wobble" across a range of 2 or 3 degrees. Now it stays within a 1 degree range.

Sounds good.
Few questions: How large is the difference in the four directions? Did the stationary compass consider deviations?
I understood you are on the boat. So it is not easy possible to make tilt and roll. Can you provide some day similar experimental data like mine?

I'm not on the boat, the MTN is sat on my office desk and I'm in a different room, so I'm certain it's not moving. I've captured max/min readings from the NMEA HDG output (which I've modified to 0.1 degree resolution), and the heading appears to vary by around 1.5 degrees.

screen-20221211-091713.3.mp4

I should be able to test tilt and roll fairly easily, I'll try it when I have some free time.

NMEA heading? Which sentence you are using? In my opinion you need movement for COG to get reasonable values. Or you have differential gps?

I'm using the NMEA HDG sentence. Heading (from compass) should be accurate even with no movement, but I agree that COG (from GPS) requires movement to get an accurate value.

I've tested tilt compensation tonight. It works really well, I can rotate it to simulate pitch and roll and the heading stays correct to within a degree.

However, if I increase pitch until the x-axis passes vertical, the heading flips by 180 degrees. This makes sense, but it makes me realise how important it is to mount the compass with the x axis horizontal. Unless I had done this testing, I would have mounted mine on the bulkhead with the x axis vertical, so maybe we should add a note to the readme file?

Alternatively, would there be any way to swap the x and z axes in software for a vertical installation?

Yes, you can by changing line 111 in NavCompass.cpp.
Don't know if it is advantageous because of the worse z-axis sensitivity.

I've tested tilt compensation tonight. It works really well, I can rotate it to simulate pitch and roll and the heading stays correct to within a degree.

However, if I increase pitch until the x-axis passes vertical, the heading flips by 180 degrees. This makes sense, but it makes me realise how important it is to mount the compass with the x axis horizontal. Unless I had done this testing, I would have mounted mine on the bulkhead with the x axis vertical, so maybe we should add a note to the readme file?

Alternatively, would there be any way to swap the x and z axes in software for a vertical installation?

You are right for the user manual and for the configuration. I will add an issue for that.