GLIO2: A GPU-Parallelized Tightly-Coupled LiDAR-Inertial-GNSS System for Robust and Real-Time Global Localization and Mapping

arXiv:2610.12411 · cs.RO · Submitted 2026-10-08 · Read on arXiv

Listen

Radio episode about this paper

Transcript

Introduction to the show: ident: Robotics Radio. Generated commentary on the latest robotics and control papers.

Rosa: Today's paper: "GLIO2: A GPU-Parallelized Tightly-Coupled LiDAR-Inertial-GNSS System for Robust and Real-Time Global Localization and Mapping".

Dev: The gist Globally consistent, real-time state estimation in large-scale, perceptually degraded environments is essential for autonomous vehicles and aerial robots, and requires fusing LiDAR, inertial, and GNSS measurements.

Rosa: First, who's behind it and why it matters.

Title and authors: Rosa: So we're looking at this paper called "GLIO2: A GPU-Parallelized Tightly-Coupled LiDAR–Inertial–GNSS System for Robust and Real-Time Global Localization and Mapping." It’s about getting consistent, real-time state estimation in places where the environment looks really messy for robots and planes, which usually means they need to blend data from LiDAR, inertial sensors like IMUs, and GPS signals.

Dev: That’s right. The core idea here is fusing those three streams into one big sliding-window factor graph. What makes this system interesting is that it tackles the problems where current methods fail because they rely on a fixed map that drifts when things get degenerate or when the GPS signal drops out entirely, which means the error becomes unfixable.

Taro: I'm curious about how it handles those failures specifically. When you’re driving or flying and things look like a confusing tunnel, you don't want your localization estimate to just drift away into nonsense because of a single bad measurement.

Rosa: Well, GLIO2 uses scan-to-multiscan registration in the front end, which means it doesn't reduce every single LiDAR scan to one fixed map pose. Instead, it keeps everything flexible so that raw correspondences are re-associated and relinearized every time the system updates the estimate.

Dev: That constant re-association is key because it lets the registration errors get corrected as soon as the joint state estimate improves, which makes it pretty robust against things like LiDAR degeneracy or when you lose your GNSS signal. The paper points out that this tight coupling on raw measurements is what keeps the system stable even when one sensor struggles.

Taro: So, if we think about what a person driving might ask—how reliable is this when the environment itself is really hard to map? Does it handle those tricky situations where the LiDAR just sees traffic instead of road features?

Rosa: That’s exactly what they tested on a five point six six km bridge crossed at up to ninety-six km/h, where every other competing system's estimate just fell apart due to that kind of LiDAR degeneracy, and GLIO2 still managed to keep an accuracy of one point six meters horizontally > <ref:2610.12411#pg2,5.66 km bridge crossed at up to 96 km/h, where>

Title and authors: Dev: And it does this by using the GNSS as an anchor for the Earth-fixed frame while letting the LiDAR and IMU handle the local drift accumulation, which is a real complementary relationship between those two modalities. The system also uses raw double-differenced pseudorange and Doppler data from the GNSS, which helps it constrain that along-bridge direction even when the scan itself is degenerate.

Taro: I wonder about the numbers behind that robustness. When you look at how it works, what’s the trade-off? Is it really real-time on hardware like an NVIDIA Jetson Orin NX? Because if it takes too long to process those fused measurements, it doesn't matter how accurate the math is.

Rosa: It runs at about twenty-five Hz on that Orin NX, giving you a processing time of thirty-nine point six zero milliseconds per scan, which keeps it within that real-time budget for edge hardware deployment >

Dev: And they also have this offline back-end optimization that reuses the factors generated online to refine the full trajectory in a batch operation, and they found that this process improves trajectory accuracy and runs about twelve to twenty times faster than the GLIO back-end on those three test sequences > <ref:2610.12411#pg3,factors generated online to refine the full trajectory>

Taro: That speed difference sounds important. So for someone just listening to the show, what does this actually mean for their daily navigation or autonomous systems? Is it something we’re seeing in practice right now?

Rosa: It means that you have a system that can localize itself reliably in complex, perceptually degraded environments—like those dense urban areas or scenes with bad GNSS reception—and it works fast enough to be on the edge devices used for actual autonomous driving and aerial robots >

Dev: It shows how fusing LiDAR, inertial data, and raw GNSS into one tightly-coupled factor graph can provide that global consistency under GNSS NLOS conditions without completely sacrificing real-time performance >

Taro: So, when we look at what the authors flagged as limitations in this GLIO2 work, what’s the actual sticking point? Where does it stop working or where do they say the method isn't perfect yet?

Rosa: They mentioned a few things. First, they need a more robust way to initialize the system when you start up under degraded conditions, especially if you're already in motion >

Dev: And second, they point out that there needs to be a better quality management scheme for identifying and downweighting measurements that are either experiencing NLOS or multipath interference from signals bouncing off surfaces >

Title and authors: Taro: So it’s not perfect yet. It needs better startup routines and a sharper way to filter out the noisy, unreliable data points before they get baked into the final estimate >

Rosa: Exactly. Overall, this GLIO2 paper shows how combining these three sensor types in a unified way can give you a system that's globally consistent, runs in real time on edge hardware, and performs well even when the sensors themselves are struggling >

Dev: It really highlights the benefit of exploiting the complementarity between LiDAR and GNSS while using the IMU to keep things going during outages or when one sensor is temporarily blinded by geometry >

Taro: So, if you were designing a robot that needs to operate reliably in a city, what’s the biggest lesson here about fusing data from different physical sources?

Rosa: The lesson is that you have to model those failure modes—like LiDAR degeneracy or GNSS dropouts—explicitly in your fusion strategy and design your system so it can recover or maintain accuracy under those specific conditions >

Dev: It also shows the value of having a fast front-end that handles the dense data while relying on a smarter, faster back-end to clean up the long-term trajectory refinement without needing to reprocess all that raw point cloud information >

Taro: So, for anyone interested in autonomous systems, this GLIO2 paper is about building something that doesn't just work in ideal conditions but can handle the messy reality of the real world with a single, coherent estimate >

Rosa: That’s what we’ve been discussing. We hope this overview of "GLIO2: A GPU-Parallelized Tightly-Coupled LiDAR–Inertial–GNSS System for Robust and Real-Time Global Localization and Mapping" gives you a good sense of what this system is doing >

Dev: It’s a solid piece of work that shows how tightly coupled systems can achieve high accuracy on edge hardware while maintaining real-time constraints >

Taro: I think the focus on both the real-time front end and the batch optimization back end is what makes this paper compelling for practical autonomy research >

Rosa: We’ll keep an eye out for more work in this area, and we’ll be back soon to talk about some other interesting papers.

The paper's summary: Rosa: Basically, this system takes all the data from LiDAR, your inertial sensors, and GPS signals and merges them into one single graph that updates in real time.

Dev: It’s a factor graph approach, meaning everything—every measurement you take—is a constraint in one big mathematical puzzle that gets solved step by step.

Rosa: The authors focus on how they handle the tricky parts of that fusion, especially when the LiDAR data starts getting bad or when you lose your GPS signal entirely.

Dev: They use this specific scan-to-multiscan technique in the front end, which means they don't treat every single LiDAR sweep as a separate map piece. Instead, they keep everything flexible so that when the system updates its estimate, those raw data correspondences get re-associated and corrected instantly.

Rosa: That constant re-association is what lets them stay accurate even when the geometry gets degenerate, which is where most other systems fail because they rely on a fixed map of the world.

Dev: Exactly, and they show that by tightly coupling all those raw measurements—the LiDAR, the IMU data, and even the raw GNSS pseudorange signals—they can constrain things along a path even when one sensor is struggling.

Rosa: The results are pretty solid; they’re talking about maintaining decent horizontal accuracy on long drives or in complex urban settings where other systems completely diverge.

Dev: And they prove that this real-time processing isn't just theoretical; it runs fast enough on edge hardware, like an NVIDIA Jetson Orin NX, giving you a processing time under forty milliseconds per scan.

Rosa: So for someone who’s not building robots—maybe someone just using a self-driving car or a drone—what does this mean practically?

Dev: It means you get reliable localization in environments that are tough on sensors, like areas with bad GNSS reception or scenes where the LiDAR geometry is confusing.

Rosa: It suggests that we can build systems that don't just work perfectly in clean lab settings but can handle the messy reality of navigating a city or flying a drone reliably.

Dev: The next thing they show is how they use an offline back-end optimization to refine those long-term paths without having to reprocess all that massive amount of raw point cloud data every time.

Rosa: It’s about getting that global consistency, ensuring the path stays accurate over a long stretch, and it does this while keeping the whole operation moving at real time.

Dev: What they don't cover much is how they handle those very tricky startup situations when you first turn the system on under degraded conditions or how to filter out those bad GNSS signals more effectively.

Rosa: They admit that initialization under poor conditions and a better way to manage noisy measurements are still areas for future work, which is pretty honest about where the method stops working right now.

Dev: So, it’s a powerful system for real-world deployment but it still needs smarter ways to handle those specific failure modes we discussed earlier.

Rosa: We’ll keep an eye on those improvements because getting robust startup and better measurement quality will be key for making this system truly ready for widespread use in autonomous vehicles.

The paper's improvements: Rosa: So, we’re looking at what they suggest to make GLIO2 even better—basically, how they plan to fix the stuff they admitted wasn't perfect yet.

Dev: The paper points out two main things: first, you need a much tougher way to get the system started when you’re already moving or when the sensors are struggling initially.

Rosa: That makes sense; starting up under bad conditions is always where these tightly coupled systems stumble, so they want a more robust initialization routine there.

Dev: And second, they want a better quality management scheme for those noisy signals—a way to identify and downweight measurements that are suffering from things like multipath interference or poor GPS quality.

Rosa: That’s good because it means the system won't just keep making mistakes when it encounters bad data; it will learn to trust its sensors more intelligently.

Dev: It’s about improving the input side so the fusion engine gets cleaner data to work with, which directly impacts the accuracy we saw in those benchmarks.

Rosa: So what does this mean for a user who is actually deploying this on a robot or an autonomous vehicle?

Dev: It means that if you’re running this system on hardware like that Jetson Orin NX, you’ll need to implement these new initialization routines and maybe some smarter filtering layers for your GNSS input.

Rosa: It shows the authors are thinking about the practical deployment hurdles, not just the math in a clean environment.

Dev: And from an engineering side, it means we have a clearer roadmap for improving those specific failure modes so we can push the real-world limits even further than they’ve achieved so far.

Rosa: It’s about moving from a system that works well in good conditions to one that actually survives the messy, unpredictable real world you’re trying to build.

Conclusion: Tom: So we’re wrapping up this look at GLIO2: A GPU-Parallelized Tightly-Coupled LiDAR–Inertial–GNSS System for Robust and Real-Time Global Localization and Mapping by Rosa and Dev summarizing what it does for autonomy.

Rosa: Basically, this paper shows how you can combine those three sensors—LiDAR, IMU, and GNSS—into one tight system that keeps track of where a robot or drone is going in real time.

Dev: It really lays out the math behind how they use that sliding window factor graph to handle all those different measurements simultaneously without slowing down the processing loop.

Rosa: The main implication for us is that we can build systems that stay accurate even when the environment gets visually confusing or when GPS signals are weak or unreliable.

Dev: It’s about achieving global consistency across long routes, which is a big deal for mission planning where you need to know your position accurately over miles of travel.

Rosa: The system proves it works outside the lab in challenging conditions, maintaining decent accuracy even on long bridge traversals at high speeds.

Dev: That performance comes from that GPU-parallel front end running at about twenty-five hertz on hardware like the Jetson Orin NX, keeping latency low.

Rosa: So for someone just listening to the show, this means we’re getting localization that can actually be trusted in real-world autonomous applications right now.

Dev: And while they've got some limitations regarding startup conditions and filtering noisy data, the core mechanism is strong for real-time edge deployment.

Rosa: The paper demonstrates how combining these sensors creates a system that doesn't just work in ideal conditions but can handle the messy reality of navigation with a single coherent estimate.

Dev: It really shows how exploiting the complementarity between LiDAR and GNSS, while using the IMU to bridge the gaps, is a solid way forward for localization.

Rosa: I think this GLIO2 work sets a high bar for how tightly coupled systems can perform under stress without sacrificing real-time speed.

Dev: It’s a good foundation for future work because it gives us concrete numbers on what's achievable in terms of accuracy and loop rate.

Taro: From an autonomy research angle, the way they handle that LiDAR degeneracy is interesting; it shows how to design a system that can gracefully degrade instead of just failing completely when the world misbehaves.

Rosa: Exactly, Taro, because those kinds of failure modes are exactly what we need to solve for reliable field robotics.

Dev: And I think the next step will be refining those initialization and filtering methods they mentioned, as that’s where the actual engineering refinement needs to happen next.

Taro: Right, so we want to see how they apply these robust methods when dealing with more complex, dynamic sensor failures in a real-world robot scenario.

Qi Zhang, Xikun Liu, Qijun Qin, Xiangru Wang, Junzhe Wang, Naigui Xiao, Jianhao Jiao, Weisong Wen

Department of Aeronautical and Aviation Engineering, The Hong Kong Polytechnic University

cs.RO

Submitted: 2026-10-08

Updated: 2026-10-08

The gist: The gist Globally consistent, real-time state estimation in large-scale, perceptually degraded environments is essential for autonomous vehicles and aerial robots, and requires fusing LiDAR,

Key concepts

Factor Graph Formulation
This mathematical framework represents the entire estimation problem as a graph where nodes are states (like vehicle position) and edges are constraints (factors) derived from sensor measurements. The system minimizes an objective function by optimizing all these interconnected factors simultaneously, allowing for a globally consistent estimate.
Scan-to-Multiscan Registration
This technique fuses data from multiple LiDAR scans into a single estimation process. Instead of reducing every scan to a fixed map pose, this method uses relative constraints between scans and keyframes. This allows the system to handle registration errors iteratively, improving accuracy by constantly refining the joint estimate.
LiDAR Degeneracy
This occurs when LiDAR measurements become structurally insufficient to uniquely determine the vehicle's position, often happening on long, straight paths. GLIO2 is designed to be robust against this; it relies on IMU and GNSS data to compensate for the geometric deficiencies in the LiDAR scans.
Batch Optimization
The offline back-end refines the entire trajectory by reusing factors calculated online in a single, large optimization step. This process takes pre-computed relative pose information and uses it to correct the full path efficiently, significantly improving overall 3D accuracy without needing to re-process all raw point clouds.

Terminology

Summary

The gist Globally consistent, real-time state estimation in large-scale, perceptually degraded environments is essential for autonomous vehicles and aerial robots, and requires fusing LiDAR, inertial, and GNSS measurements.

System Overview

GLIO2 is a unified tightly-coupled LiDAR–Inertial–GNSS system that fuses three asynchronous streams—LiDAR, IMU, and raw GNSS—in a single sliding-window factor graph. The methodology comprises the factor graph formulation, the four measurement factors, the active keyframe set, marginalization of states in the online front-end, and a global batch optimization in the back-end.

Front-End Operation

The GPU-parallel front-end fuses dense LiDAR, IMU, and raw GNSS in one real-time sliding window graph. Key features of the front-end include:

** A unified online LiDAR–Inertial–GNSS front-end. GLIO2 fuses scan-to-multiscan LiDAR, raw doubledifferenced pseudorange and Doppler, and IMU preintegration in a single real-time sliding-window graph. Each scan contributes relative scan-tokeyframe constraints without being reduced to a fixedmap LiDAR pose prior. The raw correspondences are re-associated and relinearized at every iteration, allowing registration errors to be revised as the joint estimate updates. Tightly coupling both modalities on the raw measurements keeps the estimate robust to LiDAR degeneracy and to GNSS dropouts. **

State Representation and Factors

The full state Xk at time step k stacks two window-shared quantities (the extrinsic transformation between the local-world and ECEF frames and the local-world gravity) with a sliding window of W time-varying navigation states. The navigation state xf n at time step n, over which all sensor modalities are jointly optimized, lives on SO(3) × R 16, where w i Rn denotes the orientation, position, and velocity of the IMU frame with respect to the local-world frame. The objective function minimizes the weighted sum of cost functions from all active factors.

LiDAR Factor Formulation

The LiDAR factor via scan-to-multiscan registration is defined by transforming the keyframe mean into frame i gives the residual rk = Tij qk − pk, whose distribution-to-distribution VGICP information fuses the two voxel covariances. The analysis shows that the rank of HL is 6N − 6, a constant structural deficiency of 6: the entire local trajectory can undergo any global rigid motion without changing any relative registration residual. This structural gauge deficiency (i) is permanent and is the mechanism exploited here; geometric degeneracy (ii), eroding the relative directions within G⊥ that LiDAR should otherwise observe, is scene-dependent and is what IMU/GNSS must compensate.

Back-End Optimization

The offline back-end reuses the same cached factors to refine the entire trajectory in batch, completing the 30-min, 4.51-km UrbanNav Whampoa sequence in about 24 s. This offline batch optimization reuses compact relative-pose LiDAR factors generated online to refine the full trajectory without re-registering the point clouds.

Validation and Performance

GLIO2 attains the best overall accuracy among evaluated systems across three public benchmarks (UrbanNav, MARSLVIG, M3DGR) and self-collected UAV and vehicle data. For example, on a 5.66-km bridge traversed at up to 96 km/h, where every competing baseline diverges under LiDAR degeneracy, it maintains 1.6 m horizontal accuracy. The batch solution achieves the lowest 3D ATE RMSE among the evaluated LiDAR–inertial–GNSS systems after batch refinement.

Applications

The system is deployed as the sole onboard localization and mapping source in two complete autonomous systems: a facade-cleaning UAV and a guide-dog quadruped for the visually impaired. GLIO2’s primary strengths include robustness to LiDAR degeneracy, global consistency under GNSS NLOS, and real-time edge deployment. The system successfully processes all eleven public and selfcollected sequences spanning GNSS NLOS and weak LiDAR geometry.

Limitations

Several limitations remain, indicating directions for future work, including the need for a more robust initialization that tolerates degraded and in-motion startup conditions, and the development of a more refined quality-management scheme to identify and downweight NLOS and multipath measurements. The source code and self-collected datasets will be released.

Runtime Analysis

The GPU-parallel front-end runs at about 25 Hz (39.60 ms per scan) on an NVIDIA Jetson Orin NX, sustaining real-time operation on edge hardware. The offline back-end re-optimizes the full 30-min Whampoa trajectory in 24 s. The total per-scan time on the Orin NX is 55.54 ms for the Velodyne scan, which is within the 100 ms real-time budget. The batch optimization time for GLIO2 on the Whampoa sequence is 24.2 s. The total per-scan time on the desktop platform for the Livox Mid-360 is 7.43 ms, which is well below the 100 ms real-time budget. The batch optimization time for GLIO2 on the Whampoa sequence is 24.2 s. The total per-scan time on the Orin NX for the Mid-360 is 39.60 ms, which is within the 100 ms budget. The batch optimization time for GLIO2 on the Whampoa sequence is 24.2 s. The total per-scan time on the desktop platform for the Mid-360 is 7.43 ms, which is well below the 100 ms real-time budget. The batch optimization time for GLIO2 on the Whampoa sequence is 24.2 s. The total per-scan time on the Orin NX for the Mid-360 is 39.60 ms, which is within the 100 ms budget.

References

[5] W. Wen, T. Pfeifer, X. Bai, and L.-t. Hsu, “Factor graph optimization for GNSS/INS integration: A comparison with the extended kalman filter,” Navigation, vol. 68, no. 2, pp. 315–331.

[7] Xikun Liu, Wensong Wen, and L.-T. Hsu, “GLIO: Tightly-coupled GNSS/LiDAR/IMU integration for continuous and drift-free state estimation of intelligent vehicles in urban areas,” IEEE Transactions on Intelligent Vehicles, vol. 9, no. 1, pp. 1412–1422.

Improvements for AI systems

  1. Bold header: Robust Global Localization under LiDAR Degeneracy

GLIO2 can maintain 1.6 m horizontal accuracy on a 5.66-km bridge where every competing baseline diverges under LiDAR degeneracy, by using a scan-to-multiscan (S2MS) front-end that keeps the raw correspondences re-associated and relinearized at every iteration.

  1. Bold header: Real-Time Edge Deployment with High Accuracy

The system can operate in real time on edge hardware, achieving a per-scan budget of 39.60 ms per scan on an NVIDIA Jetson Orin NX while sustaining the LiDAR rate, making it suitable for autonomous vehicles and aerial robots.

  1. Bold header: Global Consistency Under GNSS Outages

GLIO2 can achieve global consistency under GNSS NLOS by using a tightly-coupled factor graph that fuses raw double-differenced pseudorange and Doppler with dense scan-to-multiscan LiDAR over one large sliding window.

  1. Bold header: Enhanced Trajectory Refinement via Batch Optimization

The system can refine the trajectory offline by reusing cached factors, which improves trajectory accuracy and runs approximately 12–20× faster than the GLIO back-end on the three tested sequences.

  1. Bold header: Robustness Against Sensor Failure Modes

The system is designed to be robust under simultaneous LiDAR and GNSS degradation by employing a tight coupling that allows the double-difference factor to constrain the along-bridge direction independently of the degenerate scan.

Sources

Related papers