GGraph: A GPU-Accelerated Library for Graph-Based Robot Deployment and Learning

Introduction

Progress in mobile robotics has been driven by a small set of design tools that became shared infrastructure, including occupancy grids for planning [1], GPU elevation mapping for locomotion [2], OpenCV for perception [3], PyTorch for learning [4], and massively parallel simulators for RL [5]. Each is valuable because one implementation serves both deployment on a robot and training in simulation, so improvements on either side transfer.

Graphs have long been used for robot planning. A navigation graph stores sparse collision-free nodes connected by traversable edges, and nodes can carry frontiers, traversability, semantics or learned scores. Such graphs underpin classical exploration planners [6, 7, 8] and a line of learned policies that reason over the graph with Graph Neural Networks [9, 10, 11]. Despite this, no shared tool builds and maintains these graphs. Deployment planners construct them inside planner-specific, single-robot code. Learning pipelines rebuild them for every environment on the CPU, so a 16-worker training run spends much of its wall-clock time maintaining graphs rather than learning. GPU graph libraries [12, 13] target fixed graphs consumed by a model, not graphs that grow and are merged and re-scored at every step of a rollout.

Emails: [email protected], [email protected], [email protected], [email protected]

To address this gap, we present GGRAPH, a GPU-resident navigation-graph library that serves as one design tool for both deployment and learning (Figure 1). GGRAPH takes occupancy grids or elevation maps as input. It samples collision-free waypoints, merges them incrementally into a persistent world-frame graph with stable node identities, and attaches per-node attributes through a layer system. Shortest paths, connectivity and frontiers are all available as CUDA tensors. The same implementation serves single-robot deployment through ROS 2 and policy learning across many parallel environments.

Building such a library raises some technical challenges. First, the graph changes at every step, as each observation adds a varying number of nodes and edges that must be merged into a graph already covering the explored world. Second, existing graph builders rely on sequential data structures, such as priority queues and per-node objects, that cannot run in parallel on a GPU. Third, learning requires hundreds of such graphs, each growing at a different rate, to be updated together. Fourth, on a real robot the graph must survive loop closure, which moves every node placed since the drift began. GGRAPH stores each graph as parallel tensors with stable node identities, so adding, merging, pruning and correcting nodes are single vectorized operations. It merges each observation with one batched nearest-neighbor assignment and one line-of-sight kernel over all candidate edges. It also reformulates graph search as edge-parallel Bellman–Ford and pointer-jumping connected components, running one robot or $N$ environments through the same kernels. The novel contribution of GGRAPH is to make the navigation graph itself a batched, GPU-resident, loop-closure-aware data structure shared by deployment and learning. To our knowledge, no other library provides this capability. Our contributions are:

1. An open-source GPU navigation-graph library. An extensible layer system stores geometric, semantic and learned attributes per node, and ROS 2 and batched interfaces let the same code serve deployment and learning (Sec. IV-A).

2. Validation in robot deployment and policy learning. We use GGRAPH to build 3-D graphs from real-world sensor data, attach frontier and semantic layers, and correct the whole graph after loop closure in one vectorized pass. Used as a batched RL environment, GGRAPH trains graph-based exploration policies that reach the quality of prior learned policies in a fraction of the training time and outperform baselines on held-out maps, on a ground vehicle in a high-fidelity simulator, and on a real robot (§ 5-A and V-B).

3. Scalability benchmarks. Graph updates take just tens of milliseconds as graphs grow to a million nodes, and environment-step throughput scales with the number of parallel robots, reaching 27× that of a SoTA baseline (§ 5-A.3 and V-B.1).

Related Work

We review representations for navigation, graph software libraries, and learning-based exploration, identifying in each the gap that GGRAPH addresses.

Representations for Navigation

Early navigation in unknown environments used 2-D occupancy grids [1], with frontier-based exploration driving the robot toward free cells that border unexplored space [14]. Volumetric maps such as OctoMap [15] and Voxblox [16] store occupancy or distance to surfaces across a 3-D volume. Topological maps [17, 18, 19] keep only the places a robot can reach and the transitions between them, and scene graphs [20] organize places into a semantic hierarchy. Exploration planners combine both. GBPlanner [7] plans over local and global graphs built on a volumetric map, and TARE [6] keeps a sparse roadmap along the past trajectory with dense point-cloud data around the robot. In both, the graph sits on a dense map that the planner still queries to score exploration gain. GGRAPH instead makes the graph the primary representation, storing frontier, semantic and learned attributes on its nodes and using dense maps only as transient inputs, so one graph serves both classical planners and learned policies.

Graph Libraries and Ecosystems

Navigation planners mutate their graphs as the robot explores, merging local observations into a global graph in custom C++ or Python code inside each planner [6, 7, 9].

Library	GPU Accel.	Spatial Graph Merging	Robotics Navigation & Exploration	Policy Learning Support
NetworkX	✗	✗	✗	✗
cuGraph [13]	✓	✗	✗	✗
PyTorch Geometric [12]	✓	✗	✗	✓
GBPlanner [7]	✗	✓	✓	✗
TARE Planner [6]	✗	✓	✓	✗
ARIADNE node manager [9]	✗	✓	✓	✓
SWAGGER [21]	✓	✗	✓	✗
GGRAPH (ours)	✓	✓*	✓	✓
* partial support (mainly CPU based); † batched across parallel environments.

SWAGGER [21] builds sparse waypoint graphs from occupancy grid maps using NetworkX [22] with partial GPU support, but derives each graph from a single map rather than merging across observations. Outside navigation, GPU graph libraries serve other workloads. Graph learning frameworks such as PyTorch Geometric [12] are fully tensorized and batch graphs by stacking adjacency matrices block-diagonally, but treat each graph as a fixed model input without spatial merging, and graph analytics libraries such as cuGraph [13] run GPU analytics over graphs built from edge lists. As Table I summarizes, navigation tools are largely CPU-based and GPU libraries lack spatial merging and navigation operations. GGRAPH combines GPU acceleration, spatial merging, navigation and exploration operations, and batched policy learning in one library.

Learning-Based Robot Exploration

Learning-based exploration trains reinforcement learning policies to choose where a robot goes next, and graphs suit them because one graph is both the map the robot traverses and the input a graph neural network [23] reasons over. Chen et al. [24] trained graph neural network policies with DQN and A2C over a graph of past poses, landmarks and candidate frontiers for exploration under localization uncertainty. ARIADNE [9] connects uniformly distributed viewpoints into a collision-free graph and trains an attention network with soft actor-critic to pick the next neighboring viewpoint, using each node’s count of observable frontiers as a feature. Its large-scale successor [10] adds graph rarefaction and a privileged critic, and GRATE [11] uses a graph transformer encoder and Kalman-filtered waypoints. These three train in 2-D grid worlds with 16 to 32 Ray workers for one to three days, and in ARIADNE’s released code each worker builds its graph in Python on the CPU. GGRAPH builds and merges every environment’s graph on the GPU, so hundreds of environments step as one tensor operation, which makes on-policy methods such as PPO [25] practical, as in massively parallel locomotion learning [26].

Problem Formulation

To showcase accelerated training for robot exploration policies that take graphs as inputs, we consider the problem of a ground robot in an a priori unknown environment whose task is to explore and observe all reachable free space while traveling the shortest possible path. At each timestep $t$ the robot has pose $x_t \in\mathrm{SE}(3)$ and receives a local observation $O_t = \{M_t, x_t\}$, where $M_t$ is a dense representation of the local environment centered on $x_t$. Our choice of representation for the entire environment is a graph that both classical planners and learned policies act on. GGRAPH maintains this graph incrementally as a stitched, world-frame graph $G_t = (V_t, E_t, S_t) = f(G_{t-1}, O_t)$, where $V_t$ are collision-free waypoints with positions $\mathbf{p}_i \in\mathbb{R}^3$, $E_t$ are collision-free edges consistent with observations $\{O_\tau\}_{t_0 \le\tau\le t}$, and $S_t : V_t \to\mathbb{R}^L$ is an $L$-channel score map that attaches geometric, semantic, or learned attributes to each node. At each step the robot sits at a node $u_t \in V_t$ and must decide which adjacent node to travel to next. We formulate this decision as a Markov decision process (MDP) over $G_t$. The action is a node $a_t = v \in V_t$ with $(u_t, v) \in E_t$, which the robot drives to. The transition is $s_{t+1} = [f(G_t, O_{t+1}), x_{t+1}]$. The reward $r_t$ credits newly observed free space and penalizes distance traveled. We seek a policy $\pi$ from which the action is sampled, $a_t \sim\pi(\cdot\mid s_t)$, and the objective is $\pi^* = \arg\max_\pi\mathbb{E}_\pi\left[\sum_{t=1}^{T} r_t\right]$.

Methodology

Our approach has two components. A batched graph builder (Sec. IV-A) maintains the navigation graph. GGRAPH implements the update $f$ of Sec. III as a GPU pipeline that samples a local graph from each observation $O_t$, merges it into the persistent world-frame graph $G_t$, and writes the per-node scores $S_t$, running one robot or $N$ environments through the same kernels. A parallel reinforcement-learning pipeline (Sec. IV-B) then solves the MDP of Sec. III. We parameterize the policy $\pi$ as a Graph Neural Network (GNN) that acts directly on $G_t$ and train it across hundreds of GGRAPH environments stepped together on the GPU.

Batched Graph Builder

Local graph construction. A frontier kernel scans the input map once, emitting the free-space mask and the frontier set in a single pass. The waypoint sampler then populates the mask with well-spaced nodes through three complementary passes. A skeleton pass places nodes along the medial axis of free space, a boundary pass places nodes along inflated obstacle contours to cover corridors and walls, and a free-space pass uses a GPU distance transform to fill open regions until every free cell lies within a fixed radius of some node. This is a tensorized implementation of the graph builder logic in NVIDIA’s SWAGGER library [21]. For learning experiments that require the uniform lattice of prior work [9], a world-anchored lattice can replace the three passes without changing anything downstream. For 2.5-D elevation inputs, a slope and step-height stage lifts the map into a 3-D traversability volume before sampling, which is what produces the graphs over ramps and stairs.

Global graph assembly. Each frame’s local graph is merged into the global graph by a single batched nearest-neighbor assignment, in which every local node is either snapped to an existing global node or appended with a fresh

unique identifier. Candidate edges are proposed by a radius query and validated with GPU-parallel line-of-sight checks against the obstacle memory, with surviving edges added subject to a per-node degree cap and a periodic pruning of redundant edges. Node and edge arrays are parallel tensors, so every mutation is a vectorized gather or scatter, and a retention rule prunes long-unobserved nodes to bound graph size. Figure 2 showcases a real-world implementation of GGRAPH building a 3-D graph in a campus setting with bridges, slopes, ramps and underpasses.

Multi-layer attribute system. Per-node attributes are exposed through registered graph layers. A compute layer executes a user kernel against the current graph each frame (the built-in frontier layer of Figure 3A is one), while an external layer ingests asynchronous scores from outside the library and persists them across frames (the terrain-semantics layer of Figure 3B). Merge policies (overwrite, blend, moving average) govern how repeated observations combine. Every layer is a GPU tensor aligned with the node array, so its output is consumed without copies, as a feature matrix for a policy or a scalar score for a planner.

GPU graph search. For planning, the global graph is materialized in compressed sparse-row form directly from the edge tensors. GGRAPH provides parallel breadth-first search, a Bellman–Ford kernel for single- and multi-source shortest paths, and pointer-jumping connected components. Bellman–Ford is preferred over Dijkstra because it relaxes all edges in one kernel launch, whereas a priority queue serializes.

Loop closure. Each node stores the index of the odometry frame at which it was created. When an external SLAM module supplies a corrected trajectory, graph correction reduces to a single $O(N)$ vectorised gather that translates each node by the displacement of its parent frame, with no graph traversal, no sensor re-integration, and no occupancy reprojection. A subsequent GPU node remerge collapses spatially coincident nodes from overlapping traversals, and a frontier validity recheck demotes boundary nodes that the correction has rendered interior to the graph’s free nodes.

Batched execution. For policy training, $N$ independent builders share the same kernels and are stepped together each simulator tick, producing padded position, adjacency, frontier, and attribute tensors that a graph-conditioned policy consumes directly. Because per-environment graph state is itself GPU-resident, only kernel saturation, not Python or PCIe overhead, bounds the batch size (§ 5-B.1).

ROS 2 deployment. A ROS 2 wrapper accumulates a sensor stream and odometry into a rolling map, feeds it to the incremental builder, and exposes the layer system so external modules publish per-position scores. The exploration node of § 5-B.3 is one such wrapper.

Parallel Policy Learning For Exploration

In order to utilize GGRAPH’s batched graph builder, we train our GNN exploration policy using SAC or PPO [25], following the massively parallel training setup of [26]. Unlike previous work where SAC was used [9, 10, 11], GGRAPH unlocks the use of on-policy PPO and large-scale parallelization by providing high-throughput environment data. GGRAPH maintains a navigation graph for each of $N$ environments. We use separate actor and critic networks, each shared across all environments. The entire training loop runs on the GPU, including graph maintenance, environment updates, observation and reward computation. Keeping the environment and learner on the GPU avoids CPU–GPU transfers.

Exploration environment: We train exploration policies in 2-D grid worlds represented as occupancy maps. Each map specifies free and occupied cells, while the robot maintains a belief map that additionally marks unobserved cells as unknown. Simulated sensor observations update this belief as the robot moves, and GGRAPH maintains a navigation graph from the observed free space. We use the same training maps as ARiADNE [9], obtained from its public repository. Since ARiADNE does not release its validation split, we generate 150 new maps using the dungeon generator of [27]. These new validation maps are excluded from training and grouped into easy, medium, and complex tiers of 50 maps each, with difficulty increasing through the number of dead-end corridors and the free-space boundary-to-area ratio.

Reward: We use the exploration reward of prior work [9, 10, 11], which rewards exploration progress and penalizes travel distance. A frontier cell is an unknown cell adjacent to known free space. At each step, the robot receives reward

where $r_f = F(\mathcal{G}_{t-1}, \mathcal{G}_t)$ counts the frontier cells removed during the step and $r_d = \lVert x_t-x_{t-1}\rVert_2$ is the distance traveled. We use the same coefficients as [9], $a = 1/64$ and $b = 1/50$, with a completion bonus of $r_c = 20$ when exploration is completed and $r_c = 0$ otherwise.

Training details: Each environment maintains an independent exploration episode. At each PPO iteration, we hold the policy parameters fixed and collect $T$ steps from each of $N$ environments, producing a rollout batch of $B = NT$ transitions. We then update the actor and critic using mini-batches drawn from this rollout. After optimization, collection resumes from the current environment states using

the updated policy. Environments reset independently upon episode termination or reaching the episode-length limit. We select the rollout batch size $B$ and its allocation between $N$ parallel environments and $T$ steps per environment through the wall-clock training experiments in § 5-B.2. Actor and critic each use ARiADNE’s attention-based encoder–decoder [9] (6 layers, 8 heads, 128-d embeddings). PPO runs 4 epochs of 4 mini-batches per iteration with clip 0.2, $\gamma= 1$, $\lambda= 0.95$, entropy coefficient 0.01, and an adaptive learning rate (initially $10^{-4}$, KL target 0.01); SAC keeps ARiADNE’s hyperparameters.

Experiments

We demonstrate the capabilities of GGRAPH by answering the following questions: (Q1) How does GGRAPH compare to existing open-source libraries for single-robot deployment? (Q2) Can GGRAPH accelerate robot policy learning by maintaining a separate graph for each robot across thousands of parallel environments? (Q3) Can policies trained using GGRAPH control robots to explore unknown environments in high-fidelity simulators and the real world?

Robot Deployment

Real-World 3-D Graphs

We first validate GGRAPH on real sensor data. Figure 2 shows the library running on a sequence captured by a Boston Dynamics Spot robot with a Manifold Odin1 LiDAR-camera mounted on it, traversing a university campus. Local point clouds are processed by EM-CuPy [2] into elevation maps $M_t$, from which GGRAPH samples a local graph. Applying $f$ at each step merges these into a single world-frame graph $\mathcal{G}_t$ spanning several elevation levels. The resulting representation is directly usable by a planner, since nodes are collision-free places, edges are traversable transitions, and shortest paths and frontier queries execute on the GPU. Figure 3 shows channels of the score map $S_t$. The frontier channel (Figure 3A) is computed internally. At each step, nodes adjacent to the known-free/unknown boundary are flagged, and this channel is what the policies of § 5-B consume. The semantic channel (Figure 3B) is supplied externally. Nodes are scored by ExploRFM [28], a foundation-model-based vision module, which can label them as grass or pavement from the camera view, and $f$ accumulates repeated observations so the label stabilizes as the robot moves.

Loop Closure

We evaluate on a closed square trajectory under a combined drift of 22% scale error and 160 mm/m additive world-frame bias, producing a precorrection loop-closure gap of 14.08 m (Figure 4A). The full correction pipeline restores the closed loop (Figure 4B) in 2.26 ms. Such efficiency is not feasible for volumetric representations. An occupancy grid or TSDF over the same environment requires an $O(W \times H)$ pixel-level warp followed by re-ray-casting or signed-distance fusion. In GGRAPH, each node carries the index of the odometry step that placed it, so loop closure reduces to a single vectorised pass.

Graph Update Time

A deployed planner updates its graph every cycle, so the cost of that update bounds how large a world a single robot can map in real time. Figure 5 measures GGRAPH update time as the global graph grows. A full update takes about 7 ms at 100,000 nodes. Compared to a SoTA baseline implementation using SWAGGER and NetworkX, this is about 120× faster. The update time is just 62 ms at a million nodes. At a 0.5 m node sampling distance, a million nodes can cover a 500 × 500 m area.

Building the local graph, selecting candidate edges and checking collisions take about 3 ms at every size, and the growth comes from merging nodes, de-duplicating edges and pruning node degrees.

Robot Learning

Autonomous exploration underpins search and rescue and inspection, and graph-based planners have been fielded in settings like the DARPA Subterranean Challenge [6, 7]. Learned policies over the same graphs now report the shortest paths on common benchmarks [9, 10, 11], but their training infrastructure has not kept pace. Massively parallel GPU simulation cut locomotion training from days to minutes [26], while graph-based exploration still rebuilds its environment on the CPU. Thus, GGRAPH’s robot learning experiments are aimed at showing how the library serves as a foundation for accelerating modern exploration policy training. We build on prior work on attention-based graph exploration policies [9, 10, 11] where robots explore 2-D grid worlds while maintaining graphs in Python. In these methods, experience is collected in parallel using Ray [29] at one worker per environment, capping parallelism at CPU thread count. We replicate their experiments using GGRAPH to maintain the navigation graph for each robot, then measure the resulting gains in throughput, training time and final policy performance.

Batched Environment-Step Throughput

We compare environment-step throughput between GGRAPH and ARiADNE’s CPU-based graph manager as the number of parallel robots grows. A step applies the selected action, updates the graph, and returns the next observation and reward.

Setup: Both pipelines run ARiADNE’s released checkpoint on 200 maps drawn at random from the training set of Sec. IV-B, with identical graph-sampling parameters so each measurement spans the same distribution of graph sizes. The measured interval begins at the end of policy inference and closes once the next observation, reward and termination flags are available. For $N$ parallel robots we accumulate wall-clock time $T_{\mathrm{env}}$ over $H = 128$ steps per robot and report throughput $R_{\mathrm{env}} = NH/T_{\mathrm{env}}$ in environment steps per second. GGRAPH batches updates across $N$ environments on the GPU while ARiADNE distributes them over 16 Ray workers. We sweep $N$ from 1 to 1024 on an AMD Ryzen 7 8700F with an RTX 5070 Ti.

Results: Figure 6A shows that the throughput advantage of GGRAPH grows with the number of parallel robots, from approximately 6× at $N = 16$ to 26× at $N = 256$. Its throughput then levels off, reaching about 6,500 env-steps per second at $N = 512$, compared with 244 for ARiADNE, a 27× speedup.

Wall-Clock Training Efficiency and Performance on 2-D Grid Worlds

We evaluate how faster environment updates affect the wall-clock time required to learn an exploration policy. We first examine how the PPO rollout budget should be split across parallel environments, then compare policy quality at a matched training budget.

Setup: We follow the training setup and use the training and validation sets of Sec. IV-B. Environment-step throughput plateaus around $N = 256$ (Figure 6A), so we first ask how the rollout budget should be split between the number of environments $N$ and the rollout length $T$ per environment. Holding the batch fixed at $B = NT = 16{,}384$ transitions, we sweep $N$ from 128 to 4096, so $T$ falls correspondingly from 128 to 4 steps. We then compare ARiADNE SAC with 16 Ray workers against GGRAPH-based SAC and PPO with 512 environments, all on an RTX 4090. Evaluation uses the 150 independently generated validation maps, 50 in each of the easy, medium and complex tiers. Policies act greedily and an episode succeeds when no node has positive utility within a 256-step limit.

Planner	Graph builder	Easy	Medium	Complex	All	Success rate
Nearest frontier (greedy)	ARiADNE	1404	1896	2388	1896	0.44
ARiADNE SAC-16 (6 h)	ARiADNE	909	1304	2305	1506	0.86
ARiADNE released policy (24 h, 32 robots)	ARiADNE	861	1090	2050	1333	0.91
SAC-512 (6 h)	GGRAPH	736	1205	2165	1369	0.98
PPO (512 × 32, 6 h)	GGRAPH	785	1156	1825	1255	0.97

Results: Figure 6B shows that 512 × 32 improves fastest early in training and holds among the highest rewards across the two-hour run. Beyond this point the rollouts become too short: early learning slows at $N = 2048$ and 4096, where $T$ drops to 8 and 4 steps. Each iteration still collects the same number of transitions, but rollouts this short truncate

the return estimates the policy learns from. Based on these results, we adopt 512 × 32 throughout our experiments.

Under this configuration both GGRAPH pipelines learn shorter exploration paths than ARiADNE SAC-16 within the same budget (Figure 7), with PPO falling below the path length of the released checkpoint, trained for 24 h, after roughly 2 h. At the 6 h budget (Table II), PPO achieves the shortest overall mean path of 1255 px and completes 97 % of maps, against 1333 px and 91 % for the released policy. The gain is largest on complex maps, where PPO reduces mean path length from 2050 to 1825 px. SAC reaches the highest completion rate at 98 % and the shortest paths on easy maps, while the released policy remains best on medium maps. Figure 8 shows the resulting performance on medium and complex maps.

Deployment of the Learned Policy in a High-Fidelity Simulator and the Real World

We deploy the learned policies on a simulated ground vehicle in the CMU autonomous exploration development environment [30]. It provides a Gazebo model of a skid-steer vehicle with a Velodyne VLP-16 LiDAR, a state estimator, terrain analysis, and a local planner that tracks a waypoint at up to 2 m/s. An OctoMap belief built from the vehicle’s registered scans is projected to a 2-D occupancy grid, a navigation graph is maintained on it, and at each step the policy selects the next goal node, which becomes the vehicle’s waypoint. Each policy acts on the graph geometry it was trained on (4 m node spacing, 16 m sensor range, 12.8 m utility range); ours uses the graph built by GGRAPH, and the ARiADNE policies use their own builder. We compare paths at equal coverage. The 150 × 150 m world is divided into 1 m cells, and a cell counts as covered once the vehicle has passed within 20 m of it. Coverage is the fraction of cells covered, and runs are cut at the moment their coverage first reaches 99.8 %.

Figure 9 shows one run of each planner in a large-scale outdoor map. ARiADNE’s recipe trained with its own code for 2 h takes the longest path to explore, 1469 m in 801 s; much of that distance comes at the end of the run, when the vehicle is forced to cross its previous path again to reach the last unexplored regions. TARE follows at 1229 m in 668 s. ARiADNE’s released checkpoint, reported to need about 24 h of training, and our SAC policy, trained for 2 h with 512 robots on GGRAPH, yield comparable performance. They drive 1143 m in 642 s and 1139 m in 615 s, respectively. Our PPO policy, trained for 1.5 h with 512 robots on GGRAPH, drives the shortest path, 1040 m in 655 s, 9 % shorter than the released checkpoint. At the same 2 h budget, the SAC policy trained on GGRAPH drives 22 % less than the one trained with ARiADNE’s code, and it matches the released checkpoint with a fraction of that checkpoint’s training time.

GGRAPH unlocks the use of on-policy algorithms like PPO by reducing the time taken for data collection. We also deploy the same PPO policy in the indoor corridors world of the same simulator [30]. It is a 130×100 m map of long corridors and lobby areas (Figure 10). The conclusion from forest therefore carries over to a structurally different environment: our policy matches the baseline’s path length at a fraction of the training budget.

Finally, we deploy the same PPO policy on the Spot robot exploring an office floor (Figure 11). The policy was trained entirely on 2-D grid-world maps and has never seen real data, yet it transfers directly, because its observation is the graph and not the raw sensor feed. The robot’s path length was 157 m. In certain areas, the cameras saw through glass doors and free space was mapped inside closed rooms and nodes were sampled there. The policy initially targeted these nodes for their frontier utility, but once the local planner could not reach them, the graph builder’s connectivity check dropped them from the robot’s graph component and the policy moved on to the reachable frontiers.

Conclusion

We presented GGRAPH: an open-source, GPU-resident navigation-graph library that serves as one design tool for robot deployment, navigation and policy learning. It maintains frontier detection, node sampling, incremental merging, edge validation and attribute layers on the GPU. The same GPU kernels build a 3-D graph, host frontier and semantic layers that classical planners read directly, correct a drifted graph after loop closure in milliseconds, and step a thousand simulated robots per tick. Using GGRAPH, training RL-based exploration policies reaches the quality of the baseline graphbased policies in an order of magnitude less wall-clock time. The policy outperforms classical planners on held-out maps, TARE in simulation, and SoTA methods like ARiADNE and GRATE at similar training budgets. It also transfers to a ground vehicle in a high-fidelity simulator and in the real world. Future work will replace the per-platform tuning of sampling parameters with learned sampling of the nodes in the graph and handle dynamic obstacles. As node attributes are tensors, the same batched environment can potentially extend to image-conditioned policies, with a vision encoder writing per-node embeddings from an RGB feed like our semantic layer already does (Figure 3B).

Acknowledgments

The authors used Claude/Codex to assist with code prototyping and debugging, manuscript revision, and formatting of Figs. The related works content used AI verification. The authors take full responsibility for the final content.