How does Ardurover Prioritize Multiple External Compasses?

I am currently blending two 3DR gps modules that each have their own magnetometers. I was wondering if anyone knows the protocol for compass prioritization with Ardurover? I’ve read that an external compass is usually assigned to compass 1 with the flight controller’s internal compasses assigned thereafter. Does this still apply with multiple external compasses? I’m using a PixRacer which has one internal compass (I think). I’m assigning my Telem2 port to be used for my 2nd gps, so in theory, I should have 3 usable compasses. I would assume that the external compass coming through the first GPS (in the GPS port) is assigned to compass 1, the external compass coming through the reassigned telem2 port of the second GPS module is assigned to compass 2, and the internal pixracer magnetometer is assigned to compass 3. Is that correct?

I’ve just been having some difficulties with my magnotometers in other physical locations than which I’m testing, so I’m trying to see if it might be because I’m using accidentally using the Pixracer’s internal magnotometer which is more prone to interference. I am currently just using compass 1 and not 2 or 3. Any help would be appreciated!

Also, on a somewhat related note, if I wanted my magnetometer influence on the ekf fusion bearing of the vehicle to decrease as the vehicle started moving, is this possible with how the ekf is currently set up? I am trying to see increasing my EK2_YAW_M_NSE param to almost 1 will do the trick but I am not sure. I trust my blended gps bearing once the car is in motion much more than my magnotometers. There have just been instances where my magnotometers have experienced strong magnetic fields from the road and caused my vehicle to spike in speed due to the magnetometer registering the car at an abrupt 90 degree error. Usually the compasses are within +/- 10 degrees which is perfect. It’s just these extreme circumstances that cause my rovers to triple their speed real quick.

PixRacer has 2 internal compass’s so the external one will be assigned as 1 (primary) then 2 and 3 for the internal ones. That is all that is supported (3). I have 3 PixRacers and don’t use the internal compass’s on any of them as they are prone to interference. I don’t believe you will be able to use a 2nd external compass.

It’s just the oddest thing. I tried to replicate the scenario with the following tlog today. I was going up and down the tile edges, but as you might notice, the compass is completely off. Usually, the rover’s bearing is just fine (+/-10 deg). I’m just really concerned if this were to happen while it is in guided/auto mode. Do you have any ideas as to what might be causing the bearing error? The gps module with the magnetometer is basically as far away from my rover’s motor as it can possibly be with the current set up. I’ve also reduced the weighting of the magnetometer with some of the parameters.

2018-07-31 14-26-45.tlog (593.5 KB)

Not with a tlog. Maybe with a flight log.

Compasses normally use an I2C connection instead of serial. So plugging in a 2nd GPS using only a serial connection will probably end up making the 2nd GPS work but not the 2nd compass.

There’s no blending of compasses nor is there a smart failover in case the first compass starts providing bad values so a 2nd external compass will only be used if the 1st compass completely fails.

Re reducing the use of the compass, I guess you’ve found this EKF wiki page, and it discusses raising the EK2_YAW_M_NSE parameter to reduce the impact of the compass.

I think we will need to do some more work on the EKF to improve resistance to compass errors. There is a PR that may help here but it needs more testing and verification that it works.

1 Like

Thank you for the feedback. I’ll download the flight log once I get back to my rover. I’ll also try and get another sample where it is working “normally” for comparison.

I had seen that ekf wiki page a while back when I initially ran into some compass issues previously. I’ve tried looking into how the parameter actually influences the filter, but it was hard for me to fully gauge its impact by looking through the github code. Thank you for clarifying. I’ll keep looking around to see if there might be a way around relying so heavily on the magnetometer once the gps-derived heading kicks in. I’ve heard that some car navigation systems use something similar since they deal with a lot of magnetic noise.

Here is a link to my flight log that corresponds with the tlog above. It’s hard for me to decipher too much from the raw magnetometer readings, but I did notice that there was at least one “ground mag anomaly”. This message usually appears whenever the rover’s heading is significantly wrong. The confusing part to me at least is that I’ve tested in the same area for a while now, and the heading only messes up about 1 in 5 trials.

https://drive.google.com/open?id=1bOf0XaI1FoPcM0GLpnrFFx2vpWvVPZNu

Grayson,

The EKF heading doesn’t match the compass heading very well during the first half of the log. I guess the vehicle is being driven around in Manual (at least in this log) so it doesn’t cause problems but I suspect it won’t drive in the correct direction at first if switched to Auto, Guided or RTL.

I think the EKF figures out the correct heading later once the vehicle starts moving. It’s just that it’s initialised badly.

I see that EKF3 is enabled… I guess that’s on purpose? I’d actually recommend sticking with EKF2 unless you’re planning on making use of some of the more advanced features like Beacons or visual-odometry…