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

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


…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?


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:
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)

(Car starts oriented south)

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:
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.Status was mostly 4 (DGPS) or 5 (RTK float):

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


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):

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:



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:


GPS.Status and GPS2.Status:

GPS.Alt and GPS2.Alt:

Best result for GPS.Alt.


GPS.Status and GPS2.Status:

GPS.Alt and GPS2.Alt:

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

“EKF” white (seems good)

“EKF” orange (bad?)

“EKF” red (very bad?)

-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))

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.


Trajectories much closer than car with RTK alone.

GPS RTK status:

RTK float all the time.

Barometer and sonar altitudes:


GPS altitude:

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


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.


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:
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:


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).


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.

After waiting long for a new version, I tried it:
MSG, 48043525, ArduRover V3.5.0-rc1 (f53c86f5)
MSG, 48043555, ChibiOS: 57801550
MSG, 48043605, fmuv2 00320046 35365118 37353630
on the car, with same three laps mission on same real R/C car circuit, and same Drotek XL RTK GPS (only one GPS).

Things went very smoothly, as with the drone above on october 11. Here are three 4K videos:




Being a bit dark, the GPS RTK red led can be seen flashing (RTK float).

After a first fast mission test, I aborted it and prepared for recording, but I couldn’t restart the mission even with a Mission Planner soft restart (PREFLIGHT_REBOOT_SHUT). Finally I switched the car off and on.

Also, the µSD card being used gave “Bad logging”, as well as other one, showing no logs on card (even being there). Finally, I used Mission Planner button “Delete logs” and for some reason could log (even old logs appeared). So only third video has a log which is this:

Possibly, the main difference for future tests is the confidence in that the car wont’k knock barriers.


On the three videos the car is started facing south, and smoothly changes to north, towards first waypoint.

Possibly, increasing speed from 3 (first two videos) to 4.5m/s makes trajectories depart a bit.

Things went smooth even appearing same warnings about the compass.

Great work!


This test was on a 2m wide circuit beside that mentioned above meant for 1/18 cars.


Nice! This has been one of my favourite blogs here. Glad to see it coming together!

Initial tests on the 2m wide circuit (changing speed):

An 1/8 R/C bike pursuing the car (with a 10 laps mission programmed):

Needs improvement.

On the 1/18 scale course why is it missing waypoints 5 and 6 so badly? Would it help to reduce the waypoint radius?

The main problem is that it is not yet repetitive on the 2m wide track. See that the first trials (20181125) were on a rainy day, but were successful. I tried on a sunny day with no clouds at all and couldn’t get a single lap.

The 2m wide track is on a corner, surrounded by trees, perhaps with less satellites.

Is it possible to rely more on inertial navigation and less on GPS? I thought I saw a setting for that.

I see these to weight the compass (magnetometer) versus the GPS units:


Does the navigation not use the gyro and accelerometers to calculate an inertially-derived position and velocity? For a car driving close by ferromagnetic objects and executing rapid maneuvers with high yaw rate in a geographically small course, it seems this would be preferred.

I’m envisioning the inertial navigation would guide the car on the 10 µs to 10 s range, and the GPS would correct the position much more slowly (less often), like 10 s to 100 s. Does the code support this approach?

I have a lot of respect for the OP for fighting through this for many months. Especially given that the quadcopter with the same hardware works so well, this must be extremely frustrating.

1 Like