GNSS extension works?

[TokyoWarfare]

EDIT: this could be an answer
#10

I''m very confused about the GNSS extension .

Since I had seen the config json for gnss, and in teh documentation it says

"GNSS constraints (ROS2 only)

GNSS-based constraints for global optimization

"

I though it was in working order, furthermore after seeing a video with GLIM working with GPS constrains.

But when enabling the module, I see the GPS topic listed

[2026-01-15 23:00:05.389] [gnss_global] [info] initializing GNSS global constraints [2026-01-15 23:00:05.389] [gnss_global] [info] gnss_global_config_path=/root/ros2_ws/install/glim_ext/share/glim_ext/config/config_gnss_global.json [2026-01-15 23:00:05.389] [gnss_global] [info] starting GNSS global thread [2026-01-15 23:00:05.392] [glim] [info] topics: [2026-01-15 23:00:05.392] [glim] [info] - /livox/imu [2026-01-15 23:00:05.392] [glim] [info] - /livox/lidar [2026-01-15 23:00:05.392] [glim] [info] - /image [2026-01-15 23:00:05.392] [glim] [info] - /gnss (ext) [2026-01-15 23:00:05.392] [glim] [info] bag_filenames:

My doubt is because the .cpp is empty
https://github.com/koide3/glim_ext/blob/master/modules/mapping/gnss_global/src/glim_ext/gnss_global_module_ros2.cpp

I've not yet recorded a bag with gnss data but I'm getting ready for it and I don´t know if glim supports gnss or not.

from the available topics of my GPS ros driver I guess the /pose is the one I ened but I'm not sure either

`
/pose: publishes generic ROS message geometry_msgs/PoseWithCovarianceStamped.msg, converted from the SBF blocks PVTGeodetic, PosCovGeodetic, AttEuler, AttCovEuler (GNSS case) or INSNavGeod (INS case).

Note that GNSS provides absolute positioning, while robots are often localized within a local level cartesian frame. The pose field of this ROS message contains position with respect to the absolute ENU frame (longitude, latitude, height), i.e. not a cartesian frame, while the orientation is with respect to a vehicle-fixed (e.g. for mosaic-x5 in moving base mode via the command setAttitudeOffset, ...) !local! NED frame or ENU frame if use_ros_axis_directions is set true. Thus the orientation is !not! given with respect to the same frame as the position is given in. The cross-covariances are hence set to 0.`

there is also navsatfix and gps fix,

My idea is to enable RTK using ntrip, but for initial testing I may do without rtk

I would appreciate some help, tx.

[koide3]

Yes, it should work. The cpp only instantiates the implementation written in the hpp, and thus it is fine that cpp is almost empty.

The current gnss_global module accepts only PoseWithCovarianceStamped, and thus input GNSS data must be converted into that form (only XYZ coordinates are used). Meanwhile, I'm going to release a new GNSS module (gnss_global2) that accepts sensor_msgs::msg::NavSatFix that is a more standard GNSS data format and supports better optimization. It takes a bit more time to wrap up the new module, but it'll be merged into glim_ext.

[marmik18]

I am also interested in this. I will wait for gnss_global2 😁.
Thanks a lot for your continued work and for maintaining GLIM, @koide3

I would be more than happy to contribute if you can point me in the right direction.

[TokyoWarfare]

Thank you so much for clarifying this.

I'll record
/pose: publishes generic ROS message geometry_msgs/PoseWithCovarianceStamped.msg

And to be future proof will record also
/navsatfix
//gpsfix

I've been struggling with teh NTRIP client, to conclude there is a bug in Septentrio's Data Link software, both tested in Ubuntu an Win. So I'll use RTKLIB or https://igs.bkg.bund.de/ntrip/bnc. Not sure yet. I whanted to use RX Data Link to have all in same ecosystem but definitelly bugged. :\

While I whant to use RTK to get the best possible in realtime, since I whant to use GLIM for mapping, while driving I do only capture, no SLAM. Hence I will try to obtain higher precission PPK. Just in case you find interesting to feed post procesed kinematiks down the road, since you plan to upgrade this module. May be PPP could be enough. Still untested.

So far I've managed to sync the Livox Horizon timestamp to UTC time and PPS also is working so the time sync with GPS is working.

I've pending to make work the Ros capture with Rosaic.

[TokyoWarfare]

Also I forgot, not sure how much weight the GPS factor has, may be in the future , it should have more or less weight based on wethere there is RTK fix or not at a given moment, since for example Bridges or tunnels will affect the GPS signal etc.. may be this is already considered. Cheers!.

[TokyoWarfare]

One extra thing I would aks you to consider for when you modify is that if you could please add in the gnss config file, an extrinsic XYZ shift value so that the coordinates of the antenna match the source of the laser beam for setups where coordinates are precise like RTK or better.

[TokyoWarfare]

I was reading the Hesai manual (currently I'm still on the LIVOX HORIZON), and says

When GPS signal is lostThe LiDAR will still trigger GPS Data Packets by the rising edge of the internal 1 Hz signal. However, the GPS time in the packets will be countedby the internal 1 Hz signal and will drift from the actual GPS time

Hence there will be "false" gps info on the stream. It would be great if GLIM, as suggested before consider the health of the signal if available on the NAVSATFIX or GPSFIX or estimate quality based on user defined minimum like stellites used, uncertainty or whatever you consider best.

EDIT: I've acheived the full ROS integration of the gnss-lidar. I'll start recording soon. Will share bags with

/gpsfix
/livox/imu
/livox/lidar
/navsatfix
/pose

cheers!

[TokyoWarfare]

Hello, I was finally able to finish 1.0 version of my MMS rig.

This bag should contain imu , lidar & GPS data captured with RTK corrections.

https://drive.google.com/drive/folders/1WddBG9u9iDJ3oF2_y9GZ2Vm144V6aZTo?usp=sharing

/NavSatFix aswell as GPSFIX , the /Pose is not usable because it is in lat long and not in UTM as requires current gnss support. But this dataset may be usefull to test the incoming upgraded version.

Unnecesary for this test but sadly iamge captureu failed for this bag, should be fixed for next test, tomorrow.

Livox Horizon

[TokyoWarfare]

Hello. I was in a bit of a rush so I implemented using Claude Code support for /NavSatFix.

The difference vs the loop detection only is clear where the signs would fail to align, now after find overlapping submaps operation they do nicely align without manual factors

I tested with ECEF but the roatation is not user friendly at all plus other annoyances so switched to ENU whichi I believe was the original implementatiions choice.

I'll now try to implement UTM conversion as I would like to merge this data with aerial lidar aswell as do merge with geotaged cameras in Metashape.

for cameras I've aswell an idea, that is to generate camera pose using GLIMs trajectory and place cameras based on the timestamp. But may be it is better to asign control points , dont know, offtopic anyways.

still not perfect, so manual factors are needed:

It may be worth to test without loop detection since the GPS's RTK is quite accurate.

Will share code when I'm finished.

[TokyoWarfare]

I've yet some alignment issues probably an axis flip but It felt very close from the real world location so I did a quick manual alignment, the SLAM fits the real world data incredibly well, the proportions are perfectly kept all along the slam

Can´t wait to get this fully working!

[TokyoWarfare]

Hello again. I've very close to achieving georeferencing.

I've the ENU factor working, that was straightforward. Getting it to out with UTM had some challenges. In the end It was solved generating a gnss_datum.json

latitude	41.495375789797428JS:41.49537578979743
longitude	2.074395863518308
altitude	255.087818701992006JS:255.087818701992
utm_zone	31
utm_easting_origin	422740.602384038036689JS:422740.60238403804
utm_northing_origin	4594164.340661290101707JS:4594164.34066129
T_enu_world	
0	-0.962441602929830JS:-0.96244160292983
1	0.271488786048080JS:0.27148878604808
2	0.000000000000000JS:0
3	0.018296511793750JS:0.01829651179375
4	-0.271488786048080JS:-0.27148878604808
5	-0.962441602929830JS:-0.96244160292983
6	0.000000000000000JS:0
7	0.018040960328790JS:0.01804096032879
8	0.000000000000000JS:0
9	0.000000000000000JS:0
10	1.000000000000000JS:1
11	0.006527454034947

but even so and after adding a correciton for the geoid undulation which fixed Z elevation issue.

there was a persisting XY mismatch

In the end, after manually aligning to the aerial lidar (public dataset by gov).

I plotted the dots in trajectories for the /NavSatFixTopic /odomLidar-Imu /trajLidar-Imu.

and some interesting ressults came out.

THe GPS is a Septentrio Mosaic G5 P3 doing RTK on a high end antenna.

Purple line is the GPS and Odom is Green Trajectory is Orange.

Over aerial lidar:

Over aligned slam cloud

my Imu is not great is the built in in the Livox Horizon plus in the log I ocasionally see IMU quality related plots .

My plan now is that I'll add a multiplier to boost GPS weight when ther eis RTK fix. We'll see.

[TokyoWarfare]

GREAT NEWS!
Alignment is excellent now!

I dropped the ENU approach as I was unable to get an accurate initial transformation. Switched to directly use UTM at odometry stage. I thought of this at first but not to deal with possible utm zone changes I whent for the ENU (I tried asweel ECEF but that would be veru user unfriendly to manipulate).

In the end switching to UTM even at odom stage has solved the alignment issues. I've to think on how to handle zone changes within the same run. May be do it in post in the offline viewer. Wee'll see.

I've tested in a second much larger capture, with equally amazing ressults.

I've never tested the third tool for multi session, yet, the data as is aligns gracefully, lets take the pointy building contour as example.

blue-red two different sessions passing trough same street:

zoom in

would be interesting to see what ressults are with Hesait XT32, that will take some weeks.

This is the extent of the test runs, an aprox combined 12 Km MMS run in two sessions taken one after the other.

Alignment examples with aerial lidar from PNOA

Alignment of the second, larger MMS

Initial dfit when factor kicks in :D

easily cleanable usign gps time,

Final shot of the extent, with all road captured in two directions

I'll cleanup logs etc and I share the repos.

NEXT1--> Think about how to handle the UTM zone change.

NEXT2--> HD maps.
GPU offload did an epic job but it needs the offline viewer and the othe rviewer to implement this feature. As an alternative, deskewed full resolution frames can be exported at start, to separate files, do the slam normally andone everything is aligned an manually set factors in the offline viewer, load theese frames, may be on viewer only on visible area, for testing, but do so during export, loading full res data for each frame position, I think this would be a valid way to approach full resolution MMS mapping. Ideally I'll try to trim the data with a geodetic grid on a folder so it can be more standard to available public dataset!

GLIM!!
GLIM!!
GLIM!!
GLIM!!
GLIM!!
GLIM!!
:D

[TokyoWarfare]

If anyone whants to have a look into the code:

https://github.com/TokyoWarfare/glim_ext_extended

https://github.com/TokyoWarfare/glim-extended

this was needed to modify in order to better identify the aux atributes.
https://github.com/TokyoWarfare/gtsam_points_extended

@koide3 if you would like to test the test bags of this datasets I can send via dm.

[TokyoWarfare]

I finished implementing al GPS and georeferencing related features.

I added data export trimed in tiles

for Japan it uses simplified data from
https://nlftp.mlit.go.jp/ksj/gml/datalist/KsjTmplt-N03-v3_1.html

to detect what prefecture the tile centroid falls, and asign the points within the properprojection per zone, it supports that vehicle crosses to adjacent prefecture.

User can force single prefecture and avoid calculations of zone if knows data falls within a prefecture for sure

Slam can be exported as one file or trimmed by tiles,

full details and readme & acknowledgments on attached md files

coordinates_readme.md
gnss_readme.md

I'll update repo tomorrow or day after tomorrow there is one little thing I whant to polish.

[TokyoWarfare]

finally I added multisession support for georeferenced slams without dropping gps factors for the second and subsequent maps, adding aswell a visibility control and some other nice to haves like different spheres per session etc..

[TokyoWarfare]

Finally HD mapping! implemented streaming in offline viewer! But in the end was because of multisession but it is now fixed.
https://youtu.be/Au43EdnpCeA