ArduRover on real competition R/C 1/10 car on real circuit: missions. FAR FROM WORKING

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.

1 Like

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.


CRUISE_SPEED 4
Car knocks slightly the barriers (can be seen at the video), so this is reduced for next runs to 3.5.


The biggest separation is at the center, were the trajectory changes most.

Rover_20180820_57_start90.bin
Car rotated 90º (east) at start.


CRUISE_SPEED 3.5

Rover_20180820_58_start135.bin
Car rotated 135º (southeast) at start.


CRUISE_SPEED 3.5

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:


so as not to mess the car.
u-blox 2 HW: 00040007 SW: 7.03 (45969)
u-blox 1 HW: 00040007 SW: 7.03 (45969)
EKF2 IMU1 tilt alignment complete
EKF2 IMU0 tilt alignment complete
EKF2 IMU1 initial yaw alignment complete
EKF2 IMU0 initial yaw alignment complete
Rangefinder1 obstacle 0 cm
GPS 2: detected as u-blox at 115200 baud
GPS 1: detected as u-blox at 115200 baud
Ready to drive
Initialising APM
Beginning INS calibration. Do not move vehicle
<startup_ground> Ground start
Barometer calibration complete
Calibrating barometer
PX4v2 004B0036 3436510A 32393637
PX4: b535f974 NuttX: 1472b16c
ArduRover V3.4.2 (318a941d)

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:


(RGFD messages don’t appear in above car logs, since it has no range finders)

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?

1 Like

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…

2 Likes

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.

1 Like

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.

Hi Randy - By all means. I certainly recommend it. Perhaps I could write something up covering the basic setup and options for receiving correction data

1 Like

jimovonz5h

…Perhaps I could write something up covering the basic setup and options for receiving correction data

RTK GPS: very interesting. I’ll give it a try. I’m not familiar with it, so I have some basic questions:
-NS-HP-GL GPS/GLONASS RTK RECEIVER: it is not in a boxed form, so it would need a fixture with 4 pins GPS connector, 5V/3.3V converter, serial connection towards station, female pins for the GPS and signalling led at least. Can a breakout board with these elements or this GPS in a boxed form be found?
-Antenna: does it need an special antenna, or any for common GPS’s would suffice?
-You mention a NTRIP client running on an ESP32 board using a WiFi internet connection from a hot-spot set up on the phone in your pocket. But I see there are several NTRIP clients for Android, so a second 3DR radio (first one is telemetry) connected to an Android tablet or phone with this client and Internet connection may work. Is this so?

rmackay9

That’s a very interesting test…

Seeing both at the main straight (far) close together slowly and at the same speed in the first lap has no price.

We can also see that the Rover’s 2nd GPS (shown in green) is performing worse than the Copter’s 2nd GPS.

Above (very above) you mentioned that the Rover second GPS showed worse results, so I had substituted it, for a very similar one from other manufacturer. It cannot be a GPS problem.

On the figures you include, on that below ROVER it can be seen (better in blue) that the car started southeast (135º), as can be seen in the video.

On that below COPTER the waypoints are linked randomly. This also happens in the kmz file (waypoints):

This is the waypoints file uploaded in Mission Planner:
asoger2ROIpodio3v_3d5-4d5.waypoints.txt (7.8 KB)

In Mission Planner-> Flight Plan -> read waypoints:


(heights 3.5/4.5m)
but those resulting from button “Download Data Flash Log Via Mavlink” show heights 0m with shifted coordinates.

If using the button “Create KML + gpx” opening the .bin file, generating .txt files, heights appear 3.5/4.5m correctly.

For example on original asoger2ROIpodio3v_3d5-4d5.waypoints:
5…16…40.32145 -3.68801 3.500000 1
6…16…40.32149 -3.68804 4.500000 1
7…16…40.32147 -3.68810 3.500000 1
8…16…40.32156 -3.68820 4.500000 1
On that obtained with “Create KML + gpx” button:
5…16…40.32145 -3.68801 3.5 1
6…16…40.32149 -3.68804 4.5 1
7…16…40.32147 -3.6881 3.5 1
8…16…40.32156 -3.6882 4.5 1
On Mission Planner capture above (Flight Plan, button “Read waypoints”) heigths are 3.5/4.5 for waypoints 5, 6, 7 and 8.

But on those two obtained with button “Download Data Flash Log Via Mavlink” (.txt):
5…16…40.32156 -3.6882 0 1 (8 above)
6…16…40.32156 -3.68832 0 1
7…16…40.32151 -3.68838 0 1
8…16…40.32104 -3.68841 0 1
Heights appear 0 and coordinates are shifted.

Certainly, as appears above, a better way than barometer/GPS for measuring height is needed (sonar, range finder), but if the copter is at 0m it would crash. Coordinates appear shifted (5->2, 6->3, 7->4, 8->5).

Webillo, I think NavSpark offers a few dev boards with everything already soldered:
http://navspark.mybigcommerce.com/s2525f8-bd-rtk-evb-rtk-module-evaluation-board/
http://navspark.mybigcommerce.com/s1216f8-rtk-evb-rtk-module-evaluation-board/
Not sure what the difference is, as the specs are the same. Both can be ordered in 10Hz version.

Here are two more 4K videos and logs, with the camera on a tripod, first waypoint north:


(Car starts oriented southeast)
Rover_20180827_73_fixcam_135.bin


(Car starts oriented south)
Rover_20180827_74_fixcam_180_short.log

As can be seen in videos, the car departs from lines shown up to moreless 1.5-2m.

…NavSpark offers a few dev boards with everything already soldered…
Thanks, interesting. However I will try module NS-HP-GL and build the fixture.

1 Like

Here are the first tests with a RTK GPS, with disappointing results. Unless I miss something, it can happen that the car is not where it thinks it is.

The RTK GPS used is the Drotek XL, which includes antenna, and here is used as Rover (can also be used as base station changing a switch). The laptop running Mission Planner is connected to Internet with a mobile phone. RTK injection on Mission planner asks for the RTK station URL, port, mounpoint, user and password, and sends RTCM correction data on the 3DR radio Mavlink connection between laptop and car. I substituted second GPS used on above tests.

This GPS includes a U-blox NEO-M8P-2 chip. The RTK connection can be checked with the GPS alone and program U-center, which must be also informed of RTK station URL, port, mounpoint, user and password:
Drotek_RTK1
It also includes a RTK led, which was continuously flashing during the tests.

The mission was the same as before: three laps to same R/C circuit as above, with waypoints moreless on the center of the track (3*33+1). The RTK station is moreless 14 Km from the circuit (its position is reported by Mission Planner with many decimals).

Initially, I tried with the RTK GPS alone:
GPS_TYPE 1
GPS_TYPE2 0
SERIAL3_BAUD 115
SERIAL3_PROTOCOL 5
SERIAL4_BAUD 115
SERIAL4_PROTOCOL -1

Log:
Rover_20180928_91_RTKalone.bin

GPS.Status was mostly 4 (DGPS) or 5 (RTK float):

GPS.Alt should be constant (the track is flat), but instead is:

Trajectory:

But the car didn’t follow really the trajectories above. The car hit the barriers several times and I had to place it back, as can be seen on the Google Earth trajectory which has several acute points, such as:


On these two points the car deviated and hit the barriers and was stopped, so really the car was close to the barriers.

As had happened before and for reasons I can’t understand, it was impossible to have consistent laps for a video, situation which seemed to improve reducing speed and with the two GPS’s in Blend mode (as before):
GPS_AUTO_SWITCH 2
GPS_TYPE 1
GPS_TYPE2 1
SERIAL3_BAUD 115
SERIAL3_PROTOCOL 5
SERIAL4_BAUD 115
SERIAL4_PROTOCOL 5

However, a complete three laps video was a matter of luck. Here is an incomplete 4K one of 1.5 laps, in which the car finishes blocked at a protecting kart tyre:

Log:
Rover_20180928_98_RTK_v548.bin

Trajectory:

But a capture at the end of the video shows the car blocked around two meters south of what is indicated above:


Two other complete 4K three laps videos:

Log:
Rover_20180928_104_RTK_v553.bin

GPS.Status and GPS2.Status:

GPS.Alt and GPS2.Alt:


Best result for GPS.Alt.


Log:
Rover_20180928_110_RTK_v556.bin

GPS.Status and GPS2.Status:

GPS.Alt and GPS2.Alt:


Other mistery is how “EKF” appears in Mission Planner hud:

Asoger_RTKfloat_EKFwhite
“EKF” white (seems good)

Asoger_RTKfloat_EKForange
“EKF” orange (bad?)

Asoger_RTKfloat_EKFred
“EKF” red (very bad?)

Questions:
-Am I missing something for getting advantage of RTK?
-An explanation for being the car physically 1.5-2m apart from where it thinks it is?
-An explanation for RTK GPS altitude being constant as an exception?
-Do “EKF” color changes give a clue?
-What can I try?

If you click on the EKF symbol, it’ll pop up a small window, showing you which parts it’s struggling (GPS, compass, AHRS, etc).

Since above RTK test on Rover (version 3.4.2) went so bad, I placed the Drotek XL RTK GPS on the same drone as used above for the simultaneous missions for car and drone on the same R/C car circuit, with Copter version 3.6.0-rc12 and with the same waypoints. The drone was tested with both a conventional and the RT GPS’s (GPS_AUTO_SWITCH=1), and with the RTK alone.

Overall conclusions:
-On the test day and on the circuit RTK lock improved. RTK float (5) was normal, and RTK fixed (6) happened at times.
-The RTK GPS worked on the drone much better than on above first car test. Trajectories were tight. Longitude and latitude placing was very good.
-Altitude control was worse, even having a Benewake TFmini sonar (EK2_RNG_USE_HGT=70, RNGFND_MAX_CM=700). Could happen that barometer protection should be improved.
-Google Earth coordinates have small errors at the circuit. This is a fact to take into account.
-Excluding reliability considerations, it could happen that having two GPS’s (conventional and RTK, even with GPS_AUTO_SWITCH=1) precision decreases.

An initial observation was that RTK fixed happened at times, which validated RTK at the circuit with the base station 14 Km away. The RTK led was permanently on during long intervals; the following Mission Planner capture showed it:

The mission final LAND waypoint was placed on a well marked circuit point: an extreme of the finish line (under it is the car transponders timing loop).

Initial test (no video, two GPS’s, GPS_AUTO_SWITCH=1, waypoints altitude alternatively 3.5 and 4.5m (altitude variation amplitude 1m), under sonar range (<7))
Copter_20181009_Asoger_83_GPSRTKbest.bin


Less than two laps (battery exhausted).

GPS’s status:


GPS2 is the RTK one, and it reaches RTK fixed occasionally.

Barometer and sonar altitudes:


2m offset.

GPS’s altitudes:


GPS.Alt (conventional GPS) is completely erroneous. Even the drone starts and land at the same altitude (close together points and the circuit is flat) GPS2.Alt (RTK GPS) shows a difference of around 50 cm.

Next tests have fixed camera 4K videos, but unfortunately no logs: “Bad logging” was heard, and an empty file appeared on the µSD, even it was not chinese and with about 8% occupancy and had been used a long time on the drone without problems. The videos are:

On the first two videos it can be seen that the drone gains altitude, and even is not seen when in front of the podium, so for the rest I changed altitudes to 2 and 3m, as well as changing the µSD, getting correct logs, although at least once “Bad logging” was heard.

So next was three missions with the RTK GPS alone, with 4K videos.

Copter_20181009_Asoger_1-573_RTKalone.bin


Trajectories much closer than car with RTK alone.

GPS RTK status:


RTK float all the time.

Barometer and sonar altitudes:


Close.

GPS altitude:


As should, initial and final GPS altitudes are the same.


Copter_20181009_Asoger_2-574_RTKalone.bin


Trajectories close.

GPS RTK status:

Mostly RTK float, with RTK fixed at times.

Barometer and sonar altitudes:


A bit separated.

GPS altitude:


30 cm difference between initial and final GPS altitudes, which should be the same.


Copter_20181009_Asoger_3-575_RTKalone.bin


Trajectories close.

GPS RTK status:


Mostly RTK float, with RTK fixed briefly.

Barometer and sonar altitudes:


Very close.

GPS altitude:


As should, initial and final GPS altitudes are the same.


The three trajectories (9 laps) together:

This is a close look at the LAND waypoint and the three real landing points, which can be extracted from the logs:
LAND waypoint: 40.32111, -3.6881
Real LAND 1: 40.3211104, -3.6880976, 601.49
Real LAND 2: 40.3211120, -3.6881042, 602.23
Real LAND 3: 40.3211108, -3.6880981, 602.05


Really close, but shifted.

As can be seen in the videos, the real final land waypoint results shifted around one meter to the east. This is a capture from the first of these three videos:
Copter_20181009_Asoger_1-573_RTKalone_LAND.jpg
So for landing exactly at the indicated end of the finish line the mission LAND waypoint should be shifted one meter to the west (latitude is moreless correct). Google Earth coordinates are not exact.

And last, with both GPS’s and GPS_AUTO_SWITCH=1:

Copter_20181009_Asoger_4-576_GPSRTKbest.bin


Trajectories slightly not as close as with the RTK GPS alone.

GPS’s status:


RTK GPS is GPS2, mostly RTK float, with RTK fixed briefly. Conventional GPS mostly DGPS.

Barometer and sonar altitudes:


Very close.

GPS’s altitudes:


Very different. Conventional GPS altitude seems erroneous. RTK GPS initial and final altitudes differ in 60 cm.


In all BARO.Alt logs above there seems to be an overpressure glitch at start and end. The first one can be understood, since propellers start to rotate. But the same overpressure appears at the end, when propellers stop. Why?

In adition to these glitches, the BARO.Alt waveforms appear noisy. The Pixhawk barometer has the conventional foam protection inside its case. Must this protection be improved or changed?


Final questions:
-The behaviour with this RTK GPS has been much better with the drone than above with the car. Can there be Rover code explaining this?
-Altitude behaviour was not good, and BARO.Alt waveforms have initial and final overpressure glitches and are noisy. Can this be improved with better barometer protection? How? Any explanation for the final overpressure glitches?
-Even under sonar range in all above tests (EK2_RNG_USE_HGT=70, RNGFND_MAX_CM=700) altitude control seems not using sonar. Am I missing something for sonar to be active?
-This was the first time that with two believed good µSD’s a file with 0 size appeared and logs were lost with one, and “Bad logging” was heard with both. Can there be something in Copter version 3.6.0-rc12 causing this?

With respect to the observed barometer overpressure glitches, these are BARO.Alt and RFND.Dist1 on missions consisting in three consecutive takeoff and landing:


which correspond to these 4K videos:

What can be done about these glitches?

BTW1, drone central body had been surrounded with american tape (which was not supposed to have any effect (same glitches)), as appears in this other video:

BTW2, in this last video flight there were several minutes with RTK fixed (GPS2.Status=6):

The GPS RTK led can be seen constantly on in that video.

The test was near the R/C car circuit above but with open sky (although on a cloudy and rainy day), 14.75 Km from the RTK station. The R/C car circuit is surrounded by tall trees, so its conditions are worse.


Jakob Schmidt

If you click on the EKF symbol, it’ll pop up a small window, showing you which parts it’s struggling (GPS, compass, AHRS, etc).

EKF_Status_Terrain

Doing so, on a drone flight I captured above, but I cannot interpret it.

On the log appears:
ERR, 522890012, 24, 0
MSG, 522890048, EKF primary changed:0

How can I guess the error cause?

Ehh, not sure! Terrain following enabled, but no terrain loaded?

Thanks. Inadvertently I had TERRAIN_ENABLE=1, not using that feature at all.

Drone landing with RTK GPS repeatability test.

On drone with RTK GPS and:
ChibiOS: ff603d11
ArduCopter V3.6.0-rc12 (014022de)
from this video with repetitive landings:


giving this GPS Status:

(RTK float/RTK fixed)
these are captures of landings on the two nearest to the camera landing points:

Close, but not at the centimeter level.