Hi,
I have a platform where I have mounted the autopilot (navio2) backwards
i.e arrow on navio board points to the back of the platform.
and I have set board orientation param to be Yaw 180
Do I position the arrow marking on the Here GPS/compass module to follow the same orientation as the autopilot ? (pointing backwards to match the navio2)
Do I then need to set compass orientation to Yaw180 ?
Esa,
The COMPASS_ORIENT parameter is relative to the frame (not the flight controller) so if the arrow on the GPS/compass unit is pointing fowards (on the vehicle) then it can be left at it’s default of 0.
hope that helps.
HI Randy,
Thanks for that. I have set my compass rotation settings to none and have simply mounted the Here GPS/Compass module with its arrow pointing to the front of my platform.
I also seem to have a lot of issues calibrating the Here GPS/Compass module.
My new platform is quite large and mostly made of steel (300Kg total weight). I have the module mounted just above my platform on a small mast (https://goo.gl/images/bcqMkT). I tried calibrating the compass module near my platform but it takes forever.
When I start the calibration process it says
id2: 1%
…
id2: 30%
…
id2: 60%
…
id2: 98%
It then restarts and keeps doing this for minutes. 5-10 min.
id2: 1% … id2: 20 % … id2: 30% … id2: 100 %
I’ve tried relax fit option but that didn’t seem to work either.
Should I attempt to calibrate my module away from my platform then bring it close to my platform after calibration is done? I know this will throw off the compass heading but can I just put in an offset and be done with it?
My previous platform did not have this must difficulty performing a calibration. It was 50% smaller and mostly made of Aluminium.
Also if the compass is badly calibrated would it be better for me to simply not use it as it will affect my nav results?
I have an experiment where I am using the autopilot for my nav solution (no autonomous driving). I log via ROS the global position msg of ardurover. I also have a ZED camera setup on a tx2 which I am also logging. In the past, I’ve had great success with the nav solution from the autopilot but am worried that my newer platform might affect the solution output.
Esa,
Mounting the compass away from the metal is a great idea. Disabling all the compasses is probably not a good idea, we haven’t tested that setup very much.
It is probably the internal compass that is failing the calibration so it can be set as unused by setting COMPASSx_USE to 0 (where “x” is “2” or “3”). If using the mission planner there’s also a drop-down to allow setting how strict the calibration is. Maybe try setting this to “very relaxed”.
Of course, you’re pretty experienced with ArduPilot so of course when you’re doing the compass calibration you are rotating the frame around as shown on the wiki? There’s lots of different advice on the best methods for waving the vehicle around but it doesn’t really matter as long as during the calibration the vehicle is held in lots of different orientations.
Hi Randy,
Unfortunately, I can’t rotate the platform frame itself as it is a 300 Kg robot 
I’m using the Here compass for my tests (as seen in the image above).
When I do the calibration I take the compass off the mount and move it around with the robot in place.
I’ve set the COMPASS_OFF_MAX to 3000 and the calibration setting to relaxed. Was able to get it to calibrate when I moved the compass away from the robot by about 1 foot. I currently have the orientation set to zero but it seems that the robot is off by yaw 90 deg and facing backwards
A quick google search shows people talking about the Here gps needing orientation set to pitch 180 yaw 90.
Also getting a lot of compass variance errors.
Esa,
Aha, so rotating it might be tough even with the help of some burly friends.
With recent versions of Rover (3.3 and higher) COMPASS_ORIENT should normally be set to zero if the arrow was pointing forward. There was a short period when the Here was changed to use a new compass and the ArduPilot software had the orientation default incorrectly set. That’s been resolved now though.
If you have a log we can see the raw outputs from the compass and see how bad they are. It’s probably necessary to disable the internal compasses (COMPASSx_USE = 2) because they will be very close to the metal frame.
nice vehicle!
Thanks Randy.
Ok I’ll check to see what the internal compass settings are set to. Will upload logs tomorrow morning.
It seems that I have the same issues listed here
Was this what you were talking about Randy ?
Esa,
Sounds good.
That issue attracts users reports from a few different causes:
The first item is the one that led me to initially raise the issue. It’s unlikely your Cube suffers from this issue but it’s easy to check. if the Cube is unplugged and left for 30seconds, then plugged in again, the heading problem will be resolved.
Hi,
I can confirm the following .
COMPASS_USE = 0
COMPASS_USE2 = 0
COMPASS_USE3 = 1
Is there a reason why I need to set it to 2 …in Mission planner it says 0 = disabled 1 = enabled
Esa
Ok I’m using the Navio2
Hi Esa,
So there are normally two or three (or sometimes even more) compasses. The lowest compass is normally the external one. so it would be better to set COMPASS_USE = 1 and COMPASS_USE2 = 0, COMPASS_USE3 = 0.
I’ve been using Compass3 for eternal for quite some time .
Don’t think it works any other way.
Must be a navio thing
https://community.emlid.com/t/external-compass-questions/4422/3.
If my compass if off by 30 deg is there a way I can manually adjust ?
Which parameter do I set ?
Also when moving around I’m assuming the GPS will kick into the EKF and correct for any magnetometer misalignment ?
Like I said in my earlier post I need to use my platform to collect nav data urgently . Not planning on doing autonomous missions yet.
Will a misaligned compass affect my data significantly ?
Ok, I’m surprised navio is that way but I think they probably know what they’re doing.
The issue is that the compass may appear to be off by 30 degrees when it’s in one situation but completely different in another. You can try setting COMPASS_DEC to correct the angle (in radians) but that’s not really what the parameter is for and I suspect it won’t work.
Also we should confirm that it is really a compass issue. The EKF’s estimated heading comes from multiple sources (compass, gyros, GPS movements) so I fear we are jumping to conclusions.
I think also it would be good to actually drive the vehicle outside and provide a log so that we can be sure it’s the compass that is the issue.
I did some test today …with version 3.4 …noticed that no logs were produced on the navio2. 
what veriables do I need to check to make sure logs are initiated.
never had this issue before …
the pre version i was using was just before the 3.2 (just before the latest 3.3 release )
Just confirmed …I switched back to version 3.2 ( d7ceba8) …
logging works immediately.
Esa
I can confirm that 3.3 stable logs fine on the navio2 .
switching to version 3.4 produces no .BIN file when I arm the robot .
I’m currently running version 3.3 stable downloaded off here
http://firmware.ardupilot.org/Rover/stable/navio2/
would this binary include the chances in 3.3.1-rc1
Rover 3.3.1-rc2 12-May-2018
Changes from 3.3.1-rc1:
Rover V3.3.1-rc1 09-May-2018
Changes from 3.3.0:
If not can someone point to me where I can download it .
version 3.3 is the latest I can use that will produce a .BIN file log on the navio2
here are my logs using version 3.3 driving around in manual …
Heading seemed to look ok when I took it outside.
I switched to ublox …I also removed all my INS offset params … and left them as zero.
Didn’t get a chance to try the Here GPS
My auto pilot sits in the side modules …not at the centre of the platform
https://drive.google.com/open?id=1N2BYClou1YmEezKXiEKi72xXxfm1gH8V
Esa,
@peterbarker is having a look to see if he can reproduce the logging issue on navio2.
When you do the compass calibration are you doing the onboard calibration method? the “onboard” method is better than the “live” method.
It looks like the compass is getting a lot of interference. We can see this from looking at the sqrt(MAG3.x^2+MAG3.Y^2+MAG3.Z^2). This value is visible in real-time using the MP’s status screen. Look for “magfield3”. The strength of the field is more than doubling at times up to 700. I don’t know the cause but it’s probably something in the environment.
@peterbarker has tested that the logging on his navio2 seems to be working. This doesn’t mean there isn’t a problem of course, just that we can’t reproduce it.
I wonder if it’s possible that when installing 3.4 on your board there was some change in permissions? Or maybe a change in how it’s being started?
