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?
