Hi all,
I’m doing some experiments with the RTK GPS (Hero+).
It is working quite well, but I have a few quesitons on how the data is used and how to retrieve some data from the logs of MAVlink.
So, the general idea with RTK is that there is a relative information, i.e. the lat,lon calculated by the rover are given by the lat,lon of the base plus the distance between the two. This was confirmed because if I move the base, the copter moves (follows) accordingly in the same direction and the same distance I moved the base.
My questions are:
the LAT and LON field I can find on the log under GPS are the ones computed with RTK (i.e. base + relative) or the pure NMEA messages arriving at the rover GPS or they are somehow manipulated?
the data coming from MAVlink GPS_RAW_INT message are the ones corrected by RTK or the raw from the rover module? If I don’t have a precise base position or the base is moving do I still have the global lat and lon here?
the data coming from MAVlink GLOBAL_POSITION_INT message are the estimation with the RTK correction? If the base position is not correct or moving do I get a wrong global coordinate but good local coordinate?
It is the Lat Lon of the Rover, they have already been manipulated by the GPS, no need to change them.
Is the corrected data already. The base can not move, or else the results will get messed up.
Is GLOBAL_POSITION_INT is the corrected position. The base can not move, or else the results will get messed up.
Bottom line:
The base can not move, or else the results will get messed up.
There is no way to access the uncorrected rover RTK GPS position.
On Arducopter master, when using and Emlid RTK GPS it is however possible to get the position of the base station relative to the Rover in XYZ millimeters (using GPS2_RTK mavlink messages).
Why the base cannot move? With UBLOX firmware 1.40+ there is the moving baseline option which supports moving base.
In my log (with RTK float) the GPS lat and lon were really not in the precision of centimeters (with the rover fixed) but in the order of meters, so that’s why I was wondering if those data are the pure NMEA data (so with typical GPS errors 2-5m) or already corrected by RTK. To me it doesn’t seem to be the RTK, because the precision was very low.
When the distance from the base to the rover is smaller than 20Km then “RTK fix” means 2~3cm precision.
Anything else is not an RTK fix.
If you never got 2 cm precision then something is wrong with your system configuration.
My suggestion: Make sure the system gets an “RTK fix” with a static base-station.
After you get that, move the base station without moving the rover.
If, and only if, the rover does not change it’s reported location, then you can say “in UBLOX firmware 1.40+ the moving baseline option supports moving base”.
If it moves then you can only say “in UBLOX firmware 1.40+ the moving baseline option DOES NOT support moving base or is NOT correctly configured”.
A working “moving baseline solution” is usually very expensive, and implies serious latency constrains.
Please read a bit more about it, I think you (or I) are missing something here.
My current behavior (I didn’t enable moving base because I don’t know if it supported in mission planner):
I get RTK Float or RTK Fixed always (GPS FIX TYPE 5 or 6)
If the rover (the quad) is on the ground perfectly fixed (and the base also), from the log, the lat and lon are moving quite a lot, for sure more than 10cm, but also in the orders of 1-5 meters. So it is not RTK precision.
If I move the BASE, the quad (in flight) follows accordingly with high precision. For example I move the base 20 meters, the quad moves 20 meters.
So as far as my understanding goes, if no moving base is enabled, if I move the base, the rover should also see a change in position, but the relative position should always be in cm precision, because the position of the rover is computed as position of the base + relative distance, which is fine for my application. If I enable the moving base, then moving the base should always return a good global position (but this feature is not well documented even by UBLOX). What I don’t get is why I get a bad lat-lon when everything is fixed and I have RTK float or Fixed.
And is it possible to retrieve the GPS reading of the rover before RTK correction? Or when RTK enabled the sensor only output NMEA messages with already corrected lat-lon?
No, it is not possible to retrieve the GPS reading of the rover before RTK correction.
Yes the rover only outputs NMEA messages with corrected lat-lon. But if the correction data is invalid or outdated, or if it does not have a good signal, then it will not give you ‘RTK fix’.
RTK float (5) has a precision of aprox. 3 meters
RTK fix (6) has a precision of aprox. 3 centimeters
So how often are you getting RTK fix relative to RTK float ?
“Moving base” does allow you to get you what you want… When it works.
But is is hard to get it to work. Furthermore, on the implementations that I know of, the rover solutions will only be outputted after the corrections have arrived. That means that instead of 200ms latency, you can now have over 1200 ms or more GPS position latency. That might cause your drone to become unstable and crash. Does U-Blox warn you about the added latency ? Did you read the user manual ? Did you ask around?
I advise you not to use the “moving base” feature to implement a “follow me”.
But if you manage to get it to work, without crashing your drone, please post the details on how to configure it.
Moving Base can be used for UAV follow me. The positioning result on rover side is a related positioning to base, so the result is related to base’s coordinates. When moving base mode, there is no accurate coordinates for base, so the positioning result is not absolutely accurate.
@tuloski I’m going to verify this, but I wonder if you could do precision follow me assuming the base is fixed even if it is moving? The GPS position would be correct in terms of being relative to the base for up to 20 KM from the original position, but its absolute position would be wrong. The GCS would monitor distance shown in the RTK_GPS record and correct the copter’s GPS position by the required delta and send the corrected position as a waypoint.
If the RTK fix was lost and the solution degraded to 3D fix, the GCS would need to immediately start sending the correct absolute GPS position for the copter as the waypoint since the pseudo position would not be correct and the RTK_GPS record wouldn’t be valid an longer.
BTW, I’ve had trouble getting the moving base mode working with the M8P. It keeps on cycling between 3D fix and float and Arducopter claims the GPS is bad. This only happens when the type 4072 PVT message is sent (not the 1005 position message). So, the only reliable approach may be to assume the base is fixed.
Actually I tried and if you put fixed base but the base is moving you get a “follow me” behavior. The problem as you said is when you lose the RTK Fix and switch back to 3D fix. The new data becomes the “absolute” one, so Kalman filter for position slowly converges back to the global coordinates and the behavior is that the copter moves slowly by a distance that is the distance covered by the base (but backward).
The GCS would need to detect that the RTK solution is invalid and switch to sending waypoints using an offset from the actual base station position rather than the virtual base station position.
As a side note, to display the copter position accurately on a map, the GCS also has to correct the RTK position of the copter to an absolute position by offsetting it by the base’s virtual position unless the RTK solution is lost.
Hello,
My name is Maciek.
I am trying to get RTK in the case of moving base, but i have problem with drone stability in loiter mode - it starts to drift (i am using ublox M8P here+). Base gps sends 1077, 1087, 4072 rtcm frames with 1 Hz frequency and 1230 with 0.1 Hz.
Drone gps works with 5Hz rate. If i well understood your post , in your opinion drone’s gps refresh position in this case with 1 Hz not 5 Hz, what couse the drift.
Is it true? If yes, can you give me any advise how to obtain rtk mode in the case of moving base (with ubloxM8P here +).
Thank you very much.
Best regards,
Maciek