I have a problem with non-linear calibration of the the pypilot compass I have recently fitted to our sailing cat.
The setup I have used is OpenCPN, Pypilot plugin and Pypilot run as a service on a Raspberry Pi 4 using an Adafruit ICM-20948 imu. Data is NMEA 0183 from Seatalk instruments via a multiplexer, no SignalK or Openplotter.
Basically the problem is, if the boat is turned 90 degrees, the reading for the heading change is not the same. I have calibrated the compass, twice, with the report that the second time was the same as the first. Accelerometers have been marked as level but I have not been able to get data to calibrate them, a cat on the flat water we have had of late doesn't move too much.
I set the compass offset on our dock which is roughly 90 deg mag with the result I get a heading of 33 on a course that is 03 and 135 on a 180 degree course. Readings appear repeatable. The imu is not in an ideal position relative to moveable magnetic influence but nothing was moved during these tests. Magnetic deviation here is about 8 deg east, location is Australia east coast GMT+10 time zone.
I am at a loss as to where to look for a solution. Obviously the imu could be suspect but I am getting a repeatable reading. The ICM-20948 is detected as such in the RTIMU.ini file. Any ideas?
And thanks to Sean and the others who have contributed to the programming and development of Pypilot, and OpenCPN as well.
What does the calibration plot show? It should reveal what is going on with the compass. Does it really get a fix? Did you calibrate the accelerometers using the procedure described in the wiki?
you are claiming 100 degree compass change from 180 degree real change?
With heading change of 90 degrees, it is acceptable that the magnetic reading is 80-100 degree different, or +- 10 degrees. Usually it is much better than this, normally within a degree or 2, but 3-5 degrees deviation is normal. It won't affect the ability of the autopilot to hold a course.
I hadn't done the accelerometer calibration as per wiki. I was aware of it but confused about its necessity. Obviously I didn't read it properly.
Carried out the procedure as per wiki today which seemed to work. Noted that there were only small changes to the imu.alignmentQ values in the .conf file. Is that where I should be looking? I have attached the calibration plot, is that how it should appear once successful? Might be a little while before I can redo the compass calibration.
Regarding the heading on our last trip, yes, we did have only about 100 deg reading change for a 180 deg course change. Attached photo of OpenCPN showing boat heading error. Course about 003 deg, mode north up. Heading error was constant. I don't have a good photo of the return trip heading. Heading was correct at 90 deg. At the time of the photo the boat was running in track mode on the old Raymarine pilot under OpenCPN control. On the return trip at 180 deg approx, I ran on pypilot gps mode and then the O heading was alternating between the pypilot compass reading of about 135 deg and the correct heading from either the old fluxgate sensor or COG. I do have video but file size too large.
I can see there is an inherent error in the magnetometer reading of a deg or two which is really less than 1% which is not bad for any sensor and would be ok to hold a course regardless of the reading but it would be nice to get a more accurate number.
Your sensors may not require calibration but small deviations do exist, though I doubt this is the cause for 180 error.
You will have to filter the heading sentences if you have multiple sources otherwise opencpn will alternate using whatever happens to be last received that frame.
If you have bad compass results, check the calibration plot for compass.
This is the compass plot image before accelerometer recallibration. As per previous I may not get to redo the compass calibration for a few days. Does this look as it should?
2022-09-23, 12:34 AM (This post was last modified: 2022-09-23, 12:36 AM by seandepagnier.)
of course not. It is not working at all and the compass will give erratic readings. It appears that it did calibrate in the past but the calibration somehow got reset or failed to store... this is a bit strange
you can see the calibration values are all 0 and it even prints 'insufficient data'
you have "calibration locked" checked. With this, it cannot update the calibration.
The calibration was locked some time ago when we did a 360 deg rotation. The photo was taken a couple of weeks later. The compass calibration points are saved in the pypilot,conf file and look similar the the data in the other thread on compass calibration.
The versions of pypilot and the plugin I have been using date from early this year. Yesterday I tried to update both, plugin was no problem using the plugin manager but the pypilot update from git would not run. Kept restarting according to the /var/logs/syslog. I have attached an excerpt from the file, same sequence kept repeating. I reverted to the previous version I was using. No connection to the compass calibration problem as far as I can tell. Pi OS is Buster 32.
2022-09-23, 06:21 AM (This post was last modified: 2022-09-23, 06:29 AM by seandepagnier.)
oh no.. your water speed sensor is crashing it. Sorry. water speed sensor support is recent and few users have one.
I disabled this in git for not until further testing, so you can try pulling again.
it is very odd the calibration got reset but the sigma points are intact...
I wonder if you pressed "clear" in the pypilot_calibration program ui program at some point? the pypilot plugin does not have this function.
Otherwise something is amiss... did the calibration initially work at any point?
I am not on the boat so I won't be able to retry the git download until later. Glad it wasn't a mega issue.
I think the non-linearity has been there from when I originally tried to calibrate it a few weeks ago, the OpenCPN heading was strange from the start. Whether that was from the offset not being set properly or the calibration problem I can't really be sure but I suspect the latter as, from memory, the error was not consistent as it would be if the offset was the issue. I need to go though the compass calibration process again and do some proper testing. Will do that and get back in a few days.
Just back from a few days on the water so I took some readings comparing Pypilot compass with the existing Raymarine fluxgate while we were swinging on the pick.
Before we went I was able to update Pypilot to the latest from github without any problem, thanks Sean.
No problem in GPS mode, followed the OpenCPN course without any issue.
Compass calibration however is still non linear. I had done the imu calibration last week, set boat level and redid the compass calibration at the start of this trip, message was 'same as previous'. The data is not as complete as I would have liked, between the current and the wind some sectors do not have any records, however it is clear that there is a considerable problem in the calibration. In the attached data, I have listed the reading for each compass and calculated the implied adjustment. If the calibration was linear, the adjustment should be the same within the expected accuracy of the equipment. Clearly that is far from the case. Actual alignment adjustment was set to zero.
Some notes on the data. I was trying to read values on two instruments, physically separated, at the same time while both were changing, so there is an inherent error there. That given, there is a fair repeatability in the readings and the implied adjustment does vary in a reasonably smooth pattern. Some more data in the 120-270 deg range would have been nice as there is obviously a large change in the implied adjustment in this sector. Note that the data was not taken in the order it is presented. Readings were taken over 3 days in two anchorages when things were stable enough.
Possible reasons:
1. Faulty IMU. Possible but the readings are repeatable within the expected accuracy.
2. Poor Installation. IMU is on top of the RPi in a box separated from the motor controller. In any case, these readings were taken with the controller inactive.
3. Characteristics of the Adafruit Breakout. Could there be manipulation of the data before it reaches the RPi.
4. RTIMULib Handling of the ICM-20948. Doubtful.
5. Software with the ICM-20948. Doubtful. From the wiki notes this chip has been worked on previously.
My thought is to try to look at the raw data coming from the breakout using a separate program. This would require a repeat of the swing test to be comparable but a rotation test of the RPi would be a start. Adafruit have some sample programs, I will look at those.
