Webillo,
That’s a great video demonstration of compass interference! It’s perhaps a bit hard to know what the level of interference is occuring in percentage terms but it does make it super clear that a motor causes interference even at quite long distances. Really great.
Here appear both the CellSensor and a conventional compass, and the rotor is manually moved.
I suppose that the program will filter the variable magnetic field caused by the rotor (may be 10 to 1000 Hz), but for calibration the compass should be far away from the rotor.
While rotating the car while calibrating the compass, the rotor moves with the compass. I wonder if calibrating succeeds if moving the rotor, such as with battery and transmitter and bypassing the controller (such as with a servo tester), since if arming compass calibration is not possible.
nice video. I’m sure there’s almost no way we can filter out a lot of interference… we sample the compass at about 100hz so a motor moving faster than that will lead to all kinds of aliasing and basically I don’t think we can filter it out.
On these cars 5m/s should be moreless 25 Hz on wheels and 125 Hz on motor axle (now I try at CRUISE_SPEED 4.5). Competition speeds would be five times that on the straight.
I tried to change EK2_YAW_M_NSE, but did not reach a conclusion.
All following is with V3.4.1:
u-blox 2 HW: 00080000 SW: EXT CORE 3.01 (107900)
u-blox 1 HW: 00080000 SW: EXT CORE 3.01 (107900)
GPS: u-blox 2 saving config
GPS: u-blox 1 saving config
EKF2 IMU1 tilt alignment complete
EKF2 IMU0 tilt alignment complete
EKF2 IMU1 initial yaw alignment complete
EKF2 IMU0 initial yaw alignment complete
GPS 2: detected as u-blox at 115200 baud
GPS 1: detected as u-blox at 115200 baud
RCInput: decoding PX4IO_PPM
Ready to drive
Initialising APM
Beginning INS calibration. Do not move vehicle
<startup_ground> Ground start
Barometer calibration complete
Calibrating barometer
PX4v2 00320046 35365118 37353630
PX4: b535f974 NuttX: 1472b16c
ArduRover V3.4.1 (8e958687)
I noticed that common compasses HMC5883 and QMC5883 have different I2C addresses (0x1E and 0x0D), so I installed both as external compasses, as always on the front bumper, away from motor:
The two screws near the compasses are titanium ones (paramagnetic). I placed a sheet of mumetal behind the compasses, but I’m not sure if it does any good (it covers the front differential, which has steel parts).
They calibrated succesfully:
(internal Pixhawk compass disabled)
I also changed the motor with one with weaker magnets, but didn’t notice any difference.
Here are three logs:
Rover_2018-07-27_18-37-11.bin
Rover_2018-07-27_18-59-45.bin
Rover_2018-07-27_19-08-11.bin
These are the trayectories:
Although they seem neat, the reality is that the first meters are as before difficult: the car hits the barriers at left or right, or is blocked, as in previous videos such as:
It could happen as if the program relies on the GPS for orientation, but the car being still initially cannot have GPS orientation (it should initially fully trust the compass).
Question: can the car start trusting fully the compass orientation?
As an experimental experiment on the second two logs I tried to only use Galileo satellites (Galileo is said to be more precise):
GPS_GNSS_MODE 6
GPS_GNSS_MODE2 6
However the number of satellites detected didn’t change (in Rover_2018-07-27_19-08-11.bin GPS.NSats goes from 17 to 23 and GPS2.NSats goes from 12 to 14).
Question: how can I try Galileo only satellites?
There are still few, but more are being deployed, four last monday july 23:
Ariane 5 rocket, Galileo satellites on launch pad in French Guiana
Webillo,
I had a quick look at the logs. The steering and speed control is pretty good so it’s not a tuning issue.
Re the vehicle hitting the sides at the beginning. So the issue is probably that the compass heading is off a bit but the EKF learns the correct heading once the vehicle starts moving. I think if the car was driven manually forwards and backwards on the straightaway before starting the mission it would be OK. A better solution is probably to modify the EKF to get it to try and learn the heading faster at the beginning.
The position from GPS2 is really very bad. It should just be disabled or simply removed because it is not doing any good.
The 2nd compass appears to be pointing in the wrong direction. I think it’s upside down.
There are some large spikes in the primary compass’s Z axis probably caused by driving over something metal in the track. It might be interesting to determine where these happen on the track and see if that is related to the vehicle going off course. Maybe the compass can be moved higher?
To help you properly I probably need to get a fast Rover of my own and try racing it on a race track here in Japan…
Thanks for your patience and for discovering how interesting and informative are the logs.
…I think if the car was driven manually forwards and backwards on the straightaway before starting the mission it would be OK…
I had tried that learning possibility before, but in Manual, without any conclusion. I’ll try shortly in Acro and Steering. Anyhow, it is a workaround.
…The position from GPS2 is really very bad…
Well, the car does not go between the trees. I agree that there is something strange with this GPS, so I had changed it, but did not reach a conclusion. I’ll substitute it again and see what happens.
Anyhow, in the logs lat/long/alt don’t differ too much between the two GPS’s.
When I tried one only GPS things didn’t work at all, for whatever the reason.
…The 2nd compass appears to be pointing in the wrong direction. I think it’s upside down…
I have never been sure about the definition of the compass positioning. Above I started with one compass at Roll180, which seems what is documented elsewhere.
Here is the detail of the actual positioning (HMC5883, QMC5833, Roll180Yaw90) of both external compasses:
Chip orientation dot is indicated in red. The two near screws are titanium screws. Note that previous orientation above for a single compass was Roll180; rotating it 90º leaves cables more protected.
But note that chip orientation is the same and axes notation in the PCB’s is the same. Although the manufacturers are different, it would be annoying if their rules would be different.
An overall reasoning for compass orientation is deduced from the following figure, obtained from chip’s documentation (compare positioning dots and axes):
A) Internal Pixhawk compass (not used). It is upside down (shown red). It is clear that its orientation is None.
B) First external compass here (Roll180). It is clear that this positioning is obtained rotaing A) 180º, but Roll is not so clear.
C) and D) Actual external compasses, rotating B) 90º.
What is really strange is that both compasses, oriented and defined the same, show different behaviour. Although similar in name they are different in software. Can somewhere be a bug?
I made at home three logs (v3.4.2), rotating the car uniformly (by hand) over a rotating platform, so yaw is linear and mag is sinusoidal (moreless).
Rover_20180801_192933_motoroff_10cw.bin
Car is rotated 10 times cw.
Rover_20180801_193045_motoroff_12ccw.bin
Car is rotated 12 times ccw.
Rover_20180801_193224_motoron_15cw.bin
Car is rotated 15 times cw with motor on (not much difference).
There are some large spikes in the primary compass’s Z axis…
They repeat on above logs on first compass:
10t cw:
12t ccw:
15t cw (motor on):
I’ll change compass 1 (same chip).
To help you properly I probably need to get a fast Rover of my own and try racing it on a race track here in Japan…
Some on road tracks in Japan:
31°47’26"N 130°44’10"E
31°49’04"N 130°16’41"E
32°43’10"N 130°18’21"E
32°46’04"N 129°48’01"E
33°01’26"N 130°40’02"E
33°01’39"N 131°16’25"E
33°12’17"N 130°18’52"E
33°14’22"N 130°17’17"E
33°17’22"N 130°31’57.50"E
33°19’02"N 130°25’37"E
33°21’46"N 130°24’46"E
33°36’45.50"N 133°34’00.50"E
33°39’41"N 130°49’47"E
33°39’42.50"N 135°54’22"E
34°02’08.50"N 131°55’29.50"E
34°12’22"N 135°23’21"E
34°13’10"N 134°02’48"E
34°17’24"N 135°21’25"E
34°31’36"N 135°39’14"E
34°35’43"N 135°35’57"E
34°37’03.50"N 132°57’25"E
34°37’28"N 136°32’24"E
34°40’17"N 133°57’44"E
34°42’47"N 135°34’59"E
34°45’35"N 135°49’12"E
34°47’11"N 138°02’28"E
34°50’05"N 137°20’27"E
34°50’18"N 136°53’01"E
34°52’47"N 136°59’32.50"E
34°53’06"N 137°26’48"E
34°53’52"N 134°34’43"E
34°58’48"N 138°25’18"E
34°59’33"N 135°37’23"E
35°06’13"N 136°41’18"E
35°08’56"N 136°51’20.50"E
35°09’12"N 135°07’47"E
35°10’06"N 136°30’36"E
35°15’17"N 137°05’59"E
35°17’54"N 136°56’37.50"E
35°19’17"N 136°43’59"E
35°22’28"N 138°34’26"E
35°23’39"N 136°49’08"E
35°24’56"N 136°40’16"E
35°25’23"N 139°21’23"E
35°25’50"N 140°08’04"E
35°29’40"N 140°05’45"E
35°32’10"N 139°19’18"E
35°36’10"N 139°12’45"E
35°36’21"N 138°36’18"E
35°42’10"N 139°34’48"E
35°42’29"N 140°22’48"E
35°44’31"N 139°48’34"E
35°49’10"N 140°24’39"E
35°55’10"N 139°33’21"E
35°59’19"N 136°05’56"E
36°00’45"N 140°05’08"E
36°00’52"N 139°36’38"E
36°09’10"N 139°25’06.50"E
36°10’09"N 139°10’19"E
36°16’04"N 139°55’36"E
36°16’10"N 136°42’32"E
36°21’09"N 139°00’14.50"E
36°21’15.50"N 139°02’08"E
36°21’37"N 139°07’37"E
36°23’24.50"N 140°32’01"E
36°24’38"N 139°03’54.50"E
36°27’30"N 140°22’16"E
36°30’55"N 139°49’09"E
36°40’07"N 139°45’13"E
36°41’37"N 139°06’24"E
36°56’40"N 139°57’18"E
37°26’55"N 138°48’38"E
37°51’11"N 138°53’53"E
38°12’44"N 140°48’46"E
42°55’19"N 143°09’27"E
42°57’02.50"N 143°13’13"E
With latest firmware these are the curves above (Sensors/Compass/Compass vs Yaw all) even with three compasses (including Pixhawk internal, motor extracted), 5 laps cw and 5 laps ccw, which seems good. I’ll test shortly.
Webillo,
The latest Rover firmware includes a new feature that can automatically determine and correct the compass orientation as part of the compass calibration. COMPASS_AUTO_ROT is the parameter which controls this behaviour.
As a side note, the picture of the compass makes it look to me like the orientation should be ROLL_180. X is normally forward and Y is normally to the right. Still, these are old compasses build for the APM2.x boards I think so it’s possible the lettering isn’t correct for use with modern AP boards. It’s really not AP’s fault, it’s about the orientation that the GPS/compass module manufacturers have chosen and that may have changed over time… we just try to make the defaults work with the most common compasses.
Hi.
Having last firmware V3.4.2 installed (sawtooth mag curves orientation above correct) I did some tests, with the following conclusions:
-Difficult starts continue. At mission start car goes left or right, and knocks the barriers.
-Occasional deviations elsewhere.
-Tried with three (ext/ext/int) and two (ext/ext) compasses, without difference. I will later post the logs, so it can be seen if the internal compass is affected by the motor. External compasses are HMC5883L and QMC5883.
-Tried the “learning” trick, driving previously in Manual, Auto and Steering. This indeed worked, and the car didn’t deviate at start.
-I have to check if just after reset (before any movement) and with GPS lock, the initial yaw indication is correct. If I try at home (without GPS) it is correct.
–
The COMPASS_AUTO_ROT parameter is very promising. I did what follows.
COMPASS_AUTO_ROT doesn’t appear in V3.4.2 or trying beta (which also shows now V3.4.2), so I flashed V3.5.0-dev.
Initial messages:
u-blox 1 HW: 00080000 SW: EXT CORE 3.01 (107900)
PX4v2 00320046 35365118 37353630
PX4: bb30641a NuttX: 1472b16c
ArduRover V3.5.0-dev (5ad1dee2)
After reset from Mission Planner:
u-blox 1 HW: 00080000 SW: EXT CORE 3.01 (107900)
EKF2 IMU0 tilt alignment complete
EKF2 IMU1 tilt alignment complete
EKF2 IMU1 initial yaw alignment complete
EKF2 IMU0 initial yaw alignment complete
GPS 2: detected as u-blox at 115200 baud
GPS 1: detected as u-blox at 115200 baud
RCInput: decoding PX4IO_PPM
Ready to drive
Initialising APM
Beginning INS calibration. Do not move vehicle
<startup_ground> Ground start
Barometer calibration complete
Initialising APM
so even the two GPS’s are detected, a line:
u-blox 1 HW: 00080000 SW: EXT CORE 3.01 (107900)
is missing.
Parameter COMPASS_AUTO_ROT appeared, with value 2 (correct external compasses orientation if wrong).
But when trying to calibrate the compasses (both the three ext/ext/int, and the two ext/ext) the second external one indication didn’t advance, as if the QMC5883 were not recognized in this version.
Anyhow, when the first external and the internal compasses calibration finished, these messages appeared:
Mag(2) good orientation: 0 7.5
Mag(0) good orientation: 10 1.0
From the documentation:
0 None
10 Roll180Yaw90
Mag(0) should be the first external compass, and Mag(2) the internal Pixhawk one, so it seems that the external recognized one is well oriented Roll180Yaw90 (chip towards sky (dot back right), image C) and D), X forward, Y left), as in above photo with pins pointing right, and the other external one is equally oriented.
If pins point forward (photo above, chip orientation as GPS/compass drone photo beside), image B), with X pointing left and Y pointing backwards, orientation should be Roll180, but pins are less protected so I rotated the compasses 90º cw (Roll180->Roll180Yaw90).
These are the logs with the conclusions mentioned above:
-Difficult starts continue. At mission start car goes left or right, and knocks the barriers.
-Occasional deviations elsewhere.
-Tried with three (ext/ext/int) and two (ext/ext) compasses, without difference. I will later post the logs, so it can be seen if the internal compass is affected by the motor. External compasses are HMC5883L and QMC5883.
-Tried the “learning” trick, driving previously in Manual, Auto and Steering. This indeed worked, and the car didn’t deviate at start.
-I have to check if just after reset (before any movement) and with GPS lock, the initial yaw indication is correct. If I try at home (without GPS) it is correct.
In addition:
-GPS2 was changed.
-Car knocking the barriers is not apparent in GoogleEarth images below.
-The circuit was dirty with pine leaves. This caused yaw changes that the car corrected, but even stopped it.
-Certainly at times when the car has not yet moved yaw is off up to 20º from the real car orientation, but I am not sure when it happens and how to correct it. Shouldn’t the car trust the compass orientation fully at start (no GPS data for orientation yet)? I have to try low values on EK2_YAW_M_NSE.
Start with the three compasses (enabling the Pixhawk one (internal)):
Rover_20180807_19_3compassesextextint.bin
The internal compass didn’t seem affected (similar mag curves for the three):
MAG1 external:
Disabling the internal compass:
Rover_20180807_20_2compassesextext.bin
Same, but hard reset (turn off and on):
Rover_20180807_21_2compassesextext_reset.bin
Learn (manual, acro, steering):
Rover_20180807_22_2compassesextext_learn.bin
…We don’t have a way to restart the logs I think but you can reboot…
LOG_FILE_DSRMROT: Stop logging to current file on disarm
When set, the current log file is closed when the vehicle is disarmed. If LOG_DISARMED is set then a fresh log will be opened.
Value Meaning
0 Disabled
1 Enabled
Thanks for the update.
My guess is the EKF is correctly initialising to the heading from the compass, but the compass is incorrect… so it will be interesting to hear what you find when you check the compass direction at the track.
One important thing we need to determine is whether this is an estimation problem or a control problem. This comment from you, “Car knocking the barriers is not apparent in GoogleEarth images below” means that it is probably an estimation problem. I guess the track is about 5m wide and we definitely see times where the two GPSs disagree by at least 1.5m (compare green line vs blue line). It would be nice to put an RTK GPS on the vehicle to see if that helps. Someone else in this forum said they found a UBlox RTK GPS for about $250 I think.
I will ask Thunder Tiger to send me a fast rover so I can help test.
Hi.
I did some runs trying to experiment with EK2_YAW_M_NSE, using the three compasses. After them, I saw inconsistencies in the compasses, and did two more using only the internal compass, which resulted good and with a good start. Later I saw that the QMC5883L (external 2) seemed faulty (enabling it only and as primary compass, and rotating it 0/90/180/270º) and even refused to calibrate.
So above, the problem in ArduRover V3.5.0-dev was not the QMC5883L not being recognized: it was deffective.
However, this is a test with the three compasses and EK2_YAW_M_NSE=0.2 (appears 0.4 in the .param file, due to changing it just after the run) in which the second GPS was disconnected (DF13 connectors not reliable) and the car went crazy (I had to abort):
Rover_20180817_24_3compassextextint_GPS2disconnected_carcrazy.bin
It happened at the straight on the second lap. The car is brought back later (horizontal yellow trace).
What would have happened with a drone?
So I did two more tests with only the Pixhawk internal compass enabled, which resulted good and with a good start:
EK2_YAW_M_NSE=0.05 (internal compass only):
Rover_20180817_41_1compassint_EK2_YAW_M_NSE-0d05.bin
EK2_YAW_M_NSE=0.5 (internal compass only):
Rover_20180817_45_1compassint_EK2_YAW_M_NSE-0d2.bin
So it seems that the internal compass is usable even being close to the motor. However, I had calibrated it with the motor extracted.
…I guess the track is about 5m wide and we definitely see times where the two GPSs disagree by at least 1.5m (compare green line vs blue line). It would be nice to put an RTK GPS…
Yes, those are the real dimensions. Possibly 1m precision would be enough for the task; only needed (apart from a good start) is that the car repeats the trajectory. I have no experience with RTK GPS’s (they are too expensive for what is pretended here). In adition, the circuit is surrounded by trees, and usually there are seen much fewer satellites than outside.
…I will ask Thunder Tiger to send me a fast rover so I can help test…
About the external compasses, I see that HMC5883L is now hard to find, but the HMC5983L is available and has the same I2C address.
This is a capture of a test with an Arduino I2C scanner connecting both external compasses (see on photos above that I can connect them easily through an only Dupont connector):
0x0D: QMC5883L
0x1E: HMC5883L/HMC5983
There are others: LIS3MDL (0x1C/0x1E), BMM150 (0x10 to 0x13)…
I have changed the deffective compass and will do more tests shortly.
Hi.
With the failing compass substituted, things went much better. Car starts correctly, even placing it rotated at start. Three logs and 4K videos follow, with car rotated 270º, 90º and 135º at start (0º would be pointing to first waypoint).
The three compasses were enabled. For avoiding any learning, the car is reset from Mission Planner before each run.
Rover_20180820_56_start270.bin
Car rotated 270º (west) at start.
Rover_20180820_57_start90.bin
Car rotated 90º (east) at start.
Rover_20180820_58_start135.bin
Car rotated 135º (southeast) at start.
Any recommendation for increasing speed and stay inside the circuit?
–
For starting to test sonars and object avoidance, I have used a spare Pixhawk in a fixture:
Telemetry is on serial 1, there are two GPS’s on serials 2 and 3, and the TFMini’s are in serials 4 and 5:
RNGFND_ORIENT 1
RNGFND2_ORIENT 7
RNGFND_TYPE 20
RNGFND2_TYPE 20
SERIAL1_BAUD 57
SERIAL1_PROTOCOL 1
SERIAL2_BAUD 115
SERIAL2_PROTOCOL 5
SERIAL3_BAUD 115
SERIAL3_PROTOCOL 5
SERIAL4_BAUD 115
SERIAL4_PROTOCOL 9
SERIAL5_BAUD 115
SERIAL5_PROTOCOL 9
Above appear two TFMini’s connected on SERIAL4 and SERIAL5. To avoid any doubts about their supply (high current when triggered) I have used a special cable (data from Pixhawk SERIAL4/5 and supply from servo pins).
This is a log, moving the fixture horizontally with walls at 2-3m:
Rover_20180821_Fixtura1_2tfmini.bin
This is the log of RGFD.R1Dist and RGFD.R2Dist:
Obviously, the walls are not 655m away, althogh “Rangefinder1 obstacle 96 cm” may make sense:
Some range finder related messages, or they seem so:
RGFD, 121686271, 0, 65421, 328, 0, 0, 0, 0.13, 0
RGFD, 121705946, 0, 65421, 328, 0, 0, 0, 0.13, 0
RGFD, 121725660, 0, 65421, 328, 0, 0, 0, 0.13, 0
difficult to understand.
These anomalies are parallel to what happens on Copter:
PLS HELP! ArduCopter V3.6.0-rc7: two sonars, none works (glitches, extreme values)
I2C sonars Maxbotix VL53L0X absurd values on log
Have I any misconfiguration on both Rover and Copter, or is there a mess in range finder code on both Rover and Copter?
Glad to hear that replacing the compass helped.
I don’t have much advice for increasing the speed. If you graph the NTUN.XTrack value we can see that the car is up to 2m off the track at times. I’m not yet an expert in tuning the L1 controller and it may be that we need to significantly rework the navigation controller to improve performance. I’m planning to do that at some time in the next couple of months but it’s hard work and I need some help from Leonard Hall maybe. Until then you could try playing around with the NAVL1_ parameters to see if anything helps.
I’m not a fan at all of the sonar. They very often suffer from interference especially if the power line doesn’t have a cap on it.
This 4K video might show the need for a working sonar:
The copter waypoints are alternatively at 3.5m and 4.5, high enough because of the low barometer/GPS’s altitude measurements precision. ROI=podium.
Both at 3.5m/s. The car knocks the barriers twice and is delayed.
Two instances of Mission Planner on same laptop (two simultaneous voices).
Simultaneous_Copter_20180822_30.bin
Simultaneous_Rover_20180822_63.bin
It is not documented (as appears above related to GPS.Status=4 “…The documentation is a bit behind on the wiki but we will get to it eventually I think…”) a possible problem on sonars supply when they are triggered. On the Pixhawk the +5V on several connectors has a FET in series, so it may not be a good practice to supply any sonar from them. Therefore on the fixture test I use a special cable to supply the TFMini’s: supply from servo pins and data from SERIAL4/5.
The above sonars problem on the fixture is not related to the supply. It happens with different sonars.
You can find details on an RTK GPS for $125 USD including antenna and the results you can expect here: RTK vs M8N Comparison - Rover I can not see that you can achieve reliable tracking on this scale if your navigation is reliant on standard GPS…
Jim,
Ah, thanks for that. I wanted to recommend this GPS you’d found but couldn’t immediately find the link. I might actually add this to our wiki… it’s certainly the lowest priced RTK GPS I’ve ever seen.
Webillo,
That’s a very interesting test, thanks for doing that. One thing it clearly shows is how Rover navigations very differently from Copter. Rover overshoots waypoints while Copter turns early. We can also see that the Rover’s 2nd GPS (shown in green) is performing worse than the Copter’s 2nd GPS.
So once we get the estimation part working better (i.e. better GPS), there’s some improvements we can make in Rover’s navigation. In particular looking at the pictures above, what’s important is the vehicle’s estimated position (in red) vs the waypoints. There are definitely cases (like the bottom right corner) where the vehicle is not driving through the waypoint, it’s completely missing them. It may help a little to remove some waypoints and maybe some extra navigation tuning may help… or we need to do that Rover navigation rewrite we’ve been thinking about for a couple of months now.
There’s definitely some improvements we can make in the navigation to keep the vehicle closer to the line.
