[BUG] Tiles are shifting when the robot moves from one tile to the next tile

[BRNKR]

What we did:
We selected a traffic circle as a prominent location and walked along the edge of a patch of grass with an rtk module.
We have recorded the GPS topic and we perform a Navsat to ENU conversion. We broadcast the ENU conversion from "map"->"gps_link" (gps_link is the frame_id we get from our ublox f9p driver)

What we expect:
That the trajectory matches the satellite image.

What we get

rviz_satellite.mp4

[BRNKR]

I think this also addresses the following issue:
#92

[beetleskin]

Code-wise this makes sense and might be just natural for GNSS signals that have poor accuracy. But I can't rule out that this is yet a bug.

So the "map"->"gps_link" is purely produced by your GNSS receiver? I.e. the the GNSS is your only localization? Are the timestamps well synchronized? Are they running at the same frequency? What's the accuracy of your receiver, i.e. what's the jitter like?

[BRNKR]

@beetleskin

your questions:

• purely produced by my ublox F9P with NTRIP feed. pretty low cov, but no rtk fix.
• no extra localization -> timestamps not necessary for plotting
• receiver accuracy: never tested with ground truth but can achieve centimeter level

you see the upper image? these are the RTK corrected GPS values plotted on a mapping service like ArcGIS satellite. this is what i would expect in rviz. a little drift but it is quiet good in my opinion ;)

have you seen the whole clip from rviz? at the edges of each tile, the tiles are shifting. My TF is looking fine -> see the trajectory which gets recorded ;) the circle remains a circle and should be aligned to the traffic circle, which isn't.

Is your code doing some UTM2ENU conversion which is done different to the conversion i use?

[Timple]

The shifting at the tiles is very interesting. There doesn't seem to be much magic going on in the conversions.

Would this problem reproduce with an artifical (made up) GPS signal from a generator? And if so, only when doing circles or also straight lines?

[BRNKR]

@Timple
Thanks for your answer.

After the weekend, I'm happy to give this a try. I just did a big lap around the block with the robot system including Robot_localization. Straight lines and curves were driven here. The shift was still present. I will prepare and upload the material on Monday.

[Timple]

That would still be measured data. It might be easier to debug (isolate) the problem with a dummy publisher of the gps signal.

[BRNKR]

@Timple
Here you go. I have done the following things:
Wrote a script that broadcasts a position as a TF. The position moves from the initial pose towards the east (x=0-1000m, y=0m).
I then converted the position to latitude and longitude like [here] (https://github.com/cra-ros-pkg/robot_localization/blob/melodic-devel/include/robot_localization/navsat_conversions.h).
When I plot the GPS coordinates with gpsvisualizer.com, it seems to me that the values not only go towards the east, but also quite slightly towards the north. In rviz it goes perfectly to the east because x-axis=east and i broadcast y=0.

I honestly have little theoretical knowledge of geodesy to interpret all this. I tought UTM is UTM.
Here are my rosbag files.
fake_gps_bagfiles.zip

(artifical)XY -> LAT/LON

RVIZ satelitte

fake_gps_small.mp4

i have corrected the Navsat-Fix Message by rotating the XY Points -2.25 deg before converting them to LatLon. No jumps in rviz anymore.

(artifical)XY -> (rotated) LAT/LON

RVIZ satelitte

fake_gps_corrected_small.mp4

[qpc001]

I meet the same bug too.

[ilgazaskin]

I also have the same issue. @TobiMiller Could you explain how you rotated the XY Points 2.5deg in detail?