Possibly not your case, but see this.
That’s really spectacular! Do you think if I can test this way with a smartphone compass? Or the only best way is to use an analog compass?
Good Morning，What’s your test results in saturday？
Nothing yet. Unfortunately I did’t have time for that on the weekend. If i have any results, I will post here immediately.
-Very well known instrument during centuries.
-Cheaper and more simple than a smartphone.
-No bugs, no software, no battery.
-No new software release correcting some bugs but introducing others.
-Sensitive and reliable.
-You can slowly move your motor by hand and see really what is happening.
This post describes an iPhone app that allows you to measure the magnetic field
Facing the same problem you did (in fact, probably worse, since my deck is also electrically powered) I ended up with a large mast. https://photos.app.goo.gl/rrNTHjFD2JTFJ7Kt6
The mast presents operational challenges since it prevents the mower from mowing under trees. I’m working on switching over to a dual GPS setup and using yaw from the 2 GPSs. Several threads on this forum about that including Use Heading from Dual GPS
With that size, you can try a mumetal inverted umbrella between motors and compass:
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:
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.
While that might help it would be expensive. We use MuMetal to build induction coils and it’s very costly!
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.
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?
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.
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.