Compass problem on large rover

Can you please explain how mumetal (or any magnetic shielding) would help?

I’m not sure if it would help in practice, but, since you have space, you can:
·Make a mumetal cover around the motors. You can leave out the controller (with its internal compass).
·Place a wooden plate or similar with mumetal sheets below the GPS/compass (between it and the motors), moreless like an inverted umbrella.

You want to maintain the earth magnetic field, but decrease the influence of the motors.

I’m not sure if this i useful. This a mumetal shielded input ac line transformer used in audio:
mumetal_transformer_s-l1600

Hi guys! Thank you for the lot of advices! Unfortunately I didn’t have time for doing large experiments, but I’ve found an analog compass at home and I checked the mag field around the rover.
It’s really distorted even with fully turned off electronics. I think this caused by the engine’s flywheel which contains strong magnets. And of course the motors too. So I will try to put the antenna higher, and turn on the offset learn feature in pixhawk.
We’ll see…

While that might help it would be expensive. We use MuMetal to build induction coils and it’s very costly!

http://ebay.es/itm/Mumetal-Nikel-Permalloy-Foil-For-Magnetic-Field-Shielding-0-1T-30-45cm/171173026902

30x45 cm less than a Pixhawk.

My experince with a 1/10 sacale rover and a 450 helicopter (both single electric motor):
·Calibrate with motors out. Don’t calibrate with motors in place.
·If not arming, initially move motor slightly till getting permision (audible), and later simply permit arming with compass problem.

See this video:

Rover starts even placed opposite to first waypoint.

That is a good price!

Calibrating your compass with the motors out is sort of defeating the purpose… If you can not calibrate with the motors in place then you will never get a reliable heading from your magnetometer. Sure you can pass your calibration tests but the magnetometer will output garbage when everything is back in place. If you are having issues with the proximity of the motors when they are not operational, then you either have a poorly designed PM motor that does not adequately contain its magnetic field, or you have ‘soft iron’ distortion due purely to the proximity of low permeability material. Any vehicle that contains significant amounts of ferrous metal will distort the local magnetic field and make it hard to differentiate orientation based on the output of a magnetometer. It is not the fault of the magnetometer and there is no kind of ‘super duper’ magnetic sensor that can get around this. In these cases, the magnetic field simply does not unambiguously indicate orientation. Anyone suggesting that adding ‘mu-metal’ or ‘permalloy’ in these situations, does not understand what is happening. The very properties that make these materials useful is the exact same thing that makes them distort magnetic fields. They are essentially, the very best materials available for distorting magnetic fields! The more of these materials you have in the presence of your magnetometer, the worse your magnetometer will perform. There is a very limited use case for these materials where you have a strong but compact ‘hard iron’ source (magnetic sources - this can include high current DC cables). If you can use a small amount of these materials to short circuit the magnetic field emanating from the source, and if the amount you reduce this is less than the interference you add, then you can improve the situation. I do not see this being useful in any of the scenarios listed here.

Watch how the rover (which had been calibrated with motor out) starts in above video: it is placed opposite to first waypoint, and at start it has no orientation help from the GPS. It turns 180º and heads the first waypoint. It completes the rest of the mission succesfully.

1 Like

You do seem to be doing pretty well! However, by ‘reliable’ I was referring to the ability of the magnetometer to resolve heading to within a few degrees in all orientations - something that is required if you want the most accurate course following possible. Could you post a dataflash log so we can compare heading with gps course over ground and also look at the EKF yaw innovations?

Corresponding to above video here is the rover log.

These are the trajectories, where the copters follow it better, but the rover (with RTK GPS), although its laps are closer, suffers its inertia (not clear in the video, but the mission, with waypoints at fixed speed, made the car go too fast entering the tight curves):

Thank you for following through with the data. I can’t argue with the fact that you do seem to be doing well but I can see some issues with your magnetometer. The plots of field magnitude during a mission show significant variation as well as a large offset between the beginning and end. The EKF also shows regular yaw innovations of up to +/-20 degrees.
Some other things I note from your log:
You appear to have two GNSS modules configured and that both never seem to achieve an RTK fix solution but rather mostly provide a float solution (with occasional drop to 3d fix). The EKF reports regular +/-0.3m position innovations.
Your throttle tuning looks off. I see that you have set SERVO2_MAX = 1600, SERVO2_TRIM = 1517 and SERVO2_MIN = 1000. The normal max is 2000 so you are limiting your max output going forward significantly. This may be intentional but your CRUISE_THROTTLE is set to 40 with CRUISE_SPEED set to 3.0m/s. The logs show that you do not achieve your target WP SPEED of 3.0m/s until the throttle is at ~85. Ardurover uses the CRUISE_THROTTLE/CRUISE_SPEED ratio as a feed forward term in the throttle control. In your current setup, the response is way too small and relies on the P and I term to react to the error and this causes a significant lag in the response. You can see this in the PIDA.target and PIDA.actual graphs. To fix this, you should set CRUISE_THROTTLE to 85. If you would like your rover to achieve a higher top speed, then you will need to increase SERVO2_MAX and then determine the new CRUISE_THROTTLE.
Your steering tuning is better but there is overshoot and oscillation. Your ATC_STR_RAT_FF term seems good. It is important to get this one right as it is responsible for a quick and accurate steering response. If this term is set right then you need very little input from the P & I terms. These can correct error but add lag. Your ATC_STR_RAT_I term is way too high and your ATC_STR_RAT_P term is high too. I would dial these both back to around 0.1 and check what the response is. If you want to tune these live, check out Randy’s video.
Your navigation tuning is a little loose (this may have been necessary because of the tuning issues above). The xtrack error in your log file is often close to 2m. I am not sure if this loose style of tracking suits your needs but if you would like your rover to stick closer to the WP path, then you will need to reduce the NAVL1_PERIOD. With this parameter currently set to 8, your navigation controller is always attempting to target a L1 point 5.4m along the path (presuming the vehicle is at the target speed of 3.0m/s). Reducing the NAVL1_PERIOD will make it target a point on the path closer to the vehicle and get it on track sooner (as long as the position and orientation are correct and the steering tuning gives the response that it expects!). If this parameter is set too low and the vehicle is not able to respond quickly enough, you will find that once off track, it will experience large oscillations in its direction and it will end up way off. You need to find the lowest stable value.
The L1 navigation controller only reacts to error and does not plan ahead. If you want the rover to start cornering before a WP, you need to set an appropriate WP_RADIUS. The rover will re-target the next WP as soon as it is within WP_RADIUS of the current target. This is something you may want to adjust once you get your rover following the path more closely.
I see that you have set the TURN_MAX_G to 0.3 which has the effect of slowing the vehicle down in tight turns - and I can see happening in your data. If you have a particularly tight corner that requires more precise navigation, then you can deliberately slow the vehicle down. The L1 distance depends on the vehicle speed so reducing the speed causes it to target a point that is closer and keep it on track better. You can do this selectively at given points in the mission by adding DO_SET_SPEED commands - just don’t forget to restore the desired speed after the obstacle is cleared.
These comments are based on my experience with large rovers using both skid and ackerman steering. After much work, we are seeing a cross track accuracy of better than 0.05m traveling at speeds similar to yours.
Lastly I would like to say that my use of the term ‘garbage’ for the output of a magnetometer set up as you described, was not warranted. Obviously you have made something quite useful and your experience should be valued. I apologise and hope that my input might assist you.

2 Likes

Certainly, your comments are highly appreciated. As commented, the three rover laps are tight but they don’t feet too well to the desired trajectory, although the rover in direct vision (not evident in the video) seems to go too fast.

SERVO2_MAX = 1600 has historical reasons. At the beginning of times it accelerated to high speed for no known reasons and crashed too often, so this was a safety measure. Since it permitted 4m/s, which seemed the highest speed in practical terms, I didn’t change it.

I have observed that I never reach RTK fixed in movement at the track, but these GPS’s reach RTK fixed in open sky, being quiet and with satellites well positioned. See this video: the GPS’s are 52 mm apart and from the GPS data that distance is 55 mm.

Other fact is the drivers podium, which is a huge steel structure. Certainly, when the rover passes beside (four times in the three laps mission) there is GPS shadowing (number of satellites decrease), but could also cause magnetic deviations. There are other metallic parts along the lap. Anyhow, magnetics is not a problem; it was for arming (which required rotate rotor a few degrees) but later I permitted arming with compass error.

I will test your suggestions, but may be in months because of COVID-19 restrictions, and because I prefer to test with RTK with HDOP below 0.4, which is rare. In the meanwhile, I’ll try to do a video with mumetal tests.

I see that you are using the M8P. I have some experience with this unit and RTK. Staying in FLOAT and not going to FIX means that the unit can not fully resolve the ambiguities. To me this suggests that the rover is either too far from the base station, can not see the same same set of satellites as the base station, is experiencing significant multi path or the corrections are not getting through consistently. What is your correction source? How do you transmit corrections to the rover - are you sure you are only sending the required data and that you have sufficient bandwidth? What antennas are you using? I did manage to get reasonable RTK performance out of this module but it took care. It is definitely easier with the F9P.

Rovers of all the vehicles that use Ardupilot, tend to have proportionally large amounts of ferrous metals in their construction. I have seen a number of people having problems with compass issues - especially when the rovers are of the larger kind. There is a point where a magnetometer, through no fault of its own, is not capable of resolving correct orientation due to the local magnetic fields being distorted.
I operate a number of very large rovers and have had to deal with magnetometer problems myself. While we have opted for moving baseline GNSS to solve this issue, it is obvious that for the most part, a rovers heading matches its course over ground. The only time this is not the case is when there is unintended slipping of the wheels/tracks and when the vehicle is stationary.
After playing with SITL it seems that currently, it is not possible to undertake autonomous missions without a valid heading from either a magnetometer or from a GNSS setup that outputs a heading (please correct me if I am wrong?!) I have looked over the code and can see reference to using the GPS velocity combined with the IMU data to determine heading in Copter (EK3_MAG_CAL = 7) but it seems that this is a feature not available in Rover.
In our current moving baseline setups, we force the use of the yaw heading from the GNSS module by setting EK3_MAG_CAL = 5. In the past, I have implemented my own processing of the RELPOSNED message from the Ublox F9P to provide this yaw heading so I am familiar with the code. Conveniently, by default the SITL simulator emulates a Ublox GNSS module. As a test, I have made some simple changes to the processing of the Ublox PVT message to provide yaw based on the current course over ground. I have limited this to when the rover’s speed is over 0.3m/s to avoid erroneous headings when stationary. I added the following to the processing of the PVT message:

if(state.ground_speed > 0.3f){
state.gps_yaw = state.ground_course;
state.have_gps_yaw = true;
}

The results work remarkably well! As expected, on bootup without any movement, the vehicle gets no heading information and the EKF does not initialise properly. Attempting to arm in MANUAL at this point results in: APM: EKF variance, APM: EKF failsafe! (but ARM does succeed) and in AUTO: APM: PreArm: Need Position Estimate. Simply moving the vehicle forward in MANUAL mode (faster than 0.3m/s!) results in: APM: EKF3 IMU0 yaw aligned and from this point, the rover appears happy. Arming and initiating an AUTO mission from this point works well with no heading issues.
I am fairly sure that there is a use case for a rover with no magnetometer that once driven a short distance to orient it self, can successfully complete an autonomous mission.

2 Likes

A while back I disabled all of my magnetometers just to see how my rover would behave. It would take off in a random direction, “acquire” its heading, and be pretty solid thereafter. I have wheel encoders which I’m sure aid this process.

I like the solution you described for heading Jim, I often have wondered myself why Ardurover doesn’t use previous GPS position to infer heading. I think that’s kind of what ArduPilot ends up doing if you just don’t provide magnetometer data.

14 Km straight line. However, I tested once at 40m from the base station (using 433 MHz 3DR antennas) and got:


Rover moving. Status on both GPS’s doesn’t reach 6.

Car quiet. GPS reaching status 6 was the one further away from the 3DR antenna.

Now 4G/Wifi router and ESP8266 ESP-07’s (external antenna) on rover. Laptop with MP close to the router.

Mu-metal test:
This is a great demonstration and I would expect that the mu-metal would do a good job of shielding magnetic fields between the motor and sensor. Another useful test would be to bring the same piece of mu-metal in close proximity to a magnetometer while live graphing the x, y & z output

RTK GNSS:
This is not a good result. Baseline length does affect accuracy (~1mm/km) and the ability to compute a fix solution but 14km is not too bad. Where we test we usually have our own base station within a few hundred meteres but have no problems using the local CORS site that is 19km away. In all cases we have a solid RTK fix solution for the entire duiration of the mission. What sort of antenna are you using?

When testing the M8P, I also used a sililar ESP32 wifi for corrections. This worked well using a decent external antenna.

Sorting out your RTK issues should get much better results compared to waiting for a low DOP constellation.

The RTK GPS’s are Drotek M8P. The antennas are ceramic and can be seen on this video:

Although there the GPS’s are in FIXED most of the time, other days on that same place they were in FLOAT most of the time. Testing on the circuits there have been days that the rover was out of the track continuously, so it was impossible to follow the mission, specially on the small circuit placed in a corner, which is surrounded by trees:

So regarding RTK I have observed good days and bad days. I only see the different satellites positioning (HDOP) as an explanation.

I used this app to estimate how far away from my rover I needed to place the compass to be out of the zone of interference of the rover. I put the compass on an approx 1.5 meter tall mast. My rover has a lot of metal and a 48v motor using up to 200 amps.

1 Like