1 INTRODUCTION↩︎

Visual SLAM has been extensively studied, yet practical deployment on embedded devices remains challenging. Growing applications in robotics, autonomous drones, and wearable extended reality (XR) systems are driving demand for efficient embedded implementations. Robotics trends increasingly favor fully onboard SLAM [1], [2]; these platforms operate under strict constraints in cost, power, and form factor, where efficiency and portability matter as much as raw accuracy.

Although recent learning-based SLAM methods [3]–[7] have attracted substantial attention for richer scene reconstruction and understanding, their practical requirements are mismatched to embedded deployment: they require vendor-specific, high-power GPU hardware. Classical geometric approaches and lightweight hybrid designs, therefore, remain the most practical path to real-time SLAM on small, portable, resource-constrained devices. Yet, real-time operation remains limited by the tracking front end, whose per-frame cost can starve mapping and optimization, even with multi-threaded approaches. The central challenge is therefore to reduce front-end compute while preserving robustness and map quality under tight computing and portability constraints.

Our GLidE-SLAM approach addresses this by assigning each paradigm exclusively to the regime where it is naturally strongest. A lightweight direct tracker performs pose-only visual odometry on the majority of intermediate or tween frames and alternates back sporadically to indirect tracking to regain stability, re-anchor the pose and extend the map structure. The relationship is symbiotic: indirect tracking constructs the map that direct tracking consumes, while frequent direct poses keep the indirect pipeline well-initialized.

Because the direct module performs pose-only estimation with no depth optimization or map point creation, its workload reduces to highly parallel local photometric operations, making it a natural fit for GPU execution. We implement a complete end-to-end direct photometric pose estimation using compute shaders. This approach not only frees CPU headroom for backend tasks that would otherwise compete with tracking on constrained platforms, but also provides a vendor-agnostic acceleration path on embedded GPUs, enabling SLAM on resource-constrained devices where it was previously prohibitive.

We provide, through this framework, at least three main contributions:

1. Novel indirect-direct architectural separation. We introduce a hybrid visual SLAM architecture that combines indirect and direct tracking according to their respective strengths: indirect tracking provides keyframe structure, map extension, and recovery, while direct photometric tracking performs efficient pose-only estimation on intermediate frames.

2. Pose-only direct photometric tracking over a sparse map. We formulate direct tracking as a lightweight pose-only estimator over existing sparse map points, avoiding depth optimization and map point creation during intermediate frames. This keeps the direct workload compact, parallelizable, and suitable for repeated high-rate execution.

3. Vendor-agnostic compute-shader implementation. To the best of our knowledge, GLidE-SLAM is the first pose-only direct photometric estimator implemented with OpenGL ES 3.1 compute shaders for embedded-class devices, supporting execution across a broader range of commodity embedded GPUs.

2 RELATED WORK↩︎

2.1 Indirect and Direct Tracking Paradigms↩︎

The architectural separation in GLidE-SLAM builds on the complementary strengths of classical tracking methods, which fall into indirect feature-based and direct photometric paradigms. Indirect feature-based methods [8]–[12] match sparse keypoints and minimize reprojection error, offering robustness to large inter-frame motion and natural support for relocalization and loop closure, but impose a high constant cost per frame through feature extraction and matching. Direct photometric methods [13]–[16], on the other hand, minimize pixel-intensity differences between frames to achieve subpixel-accurate alignment, but are fragile under moderate motion, illumination changes, and motion blur.

2.2 Hybrid and Semi-Direct Methods↩︎

Semi-direct and hybrid methods aim to combine the complementary strengths of the two paradigms. LCSD-SLAM [17] loosely couples direct and indirect methods [10], [15] in parallel, but maintains two separate map representations that can drift relative to each other and increase computational overhead. H-SLAM [18] proposes a unified inverse-depth representation shared by both direct and indirect components to eliminate dual-map drift. Closer to our approach are systems that use lightweight tracking between keyframes: SVO [19] refines pose via direct image alignment while jointly estimating inverse-depth for features during tracking, and OV2SLAM [20] performs inter-frame tracking by optical-flow feature propagation followed by Perspective-n-Point (PnP) pose refinement. In contrast, GLidE-SLAM enforces strict paradigm separation: direct tracking is restricted to camera pose-only estimation over an existing sparse map, enabling a highly parallel GPU-friendly front end for embedded systems.

2.3 Embedded SLAM Acceleration↩︎

Although accelerated approaches have emerged to reduce computational overhead in embedded SLAM, most systems rely on CUDA to offload front-end operations such as feature detection and tracking [21], [22], as well as back-end components including local mapping and bundle adjustment [23]. This vendor-specific dependence restricts deployment on commodity off-the-shelf embedded platforms. FPGA-based accelerators can achieve strong performance-per-watt for specific kernels such as ORB extraction and semi-dense tracking [24], [25], but require hardware-software co-design that couples algorithms to fixed platforms, further limiting flexibility and portability. Mobile AR frameworks such as ARCore and ARKit [26] are proprietary and device-specific, and thus unsuitable for reproducible research comparisons. In contrast, GLidE-SLAM designs and implements the direct photometric pose estimator natively as an OpenGL ES 3.1 compute-shader pipeline, enabling vendor-agnostic GPU acceleration across diverse embedded platforms without CUDA dependency.

3 SYSTEM OVERVIEW↩︎

GLidE-SLAM follows the standard keyframe-based organization of visual SLAM. After initialization and bootstrap map creation, the system alternates between two modes. The indirect pipeline creates keyframes, extends the map, and provides stable anchor poses. For the larger set of intermediate tween frames, GLidE-SLAM performs pose-only direct photometric tracking on the GPU. When direct alignment degrades or the baseline to the current reference exceeds a threshold, the system returns to the indirect pipeline to regain stability, re-anchor the pose, update the map, and refresh the direct reference. Fig. 1 illustrates this schedule.

For this architecture, the indirect tracking pipeline provides the reference 3D map points and a corresponding reference camera pose, which serve as inputs to the GPU direct-tracking precompute process and cache generation. This step is performed primarily on keyframes, executed sporadically, and its results are reused within a variable-length window of consecutive frames for direct tracking. In contrast, for most sequential frames, estimates of the current frame’s camera pose are produced by the track process using incoming images together with the previously cached IC reference. An overview of the two symbiotic pipelines is provided in Fig. 2, and a formal discussion is presented in 4.

The next section formalizes the photometric alignment objective, the inverse compositional formulation used for caching, and the main stages of our compute-shader pipeline.

4 DIRECT PHOTOMETRIC TRACKING↩︎

4.1 Problem Formulation↩︎

Direct photometric tracking estimates the current camera pose \(T \in \mathrm{SE}(3)\) by minimizing photometric residuals over a set of 3D map points provided by the indirect pipeline. Let \(\{P_i\}_{i=1}^{N}\) be \(N\) 3D map points. Each incoming frame is aligned to a fixed reference frame with pose \(T_0\) and reference image \(I_0\). For a candidate current pose \(T\), point \(P_i\) projects to \[u_i^0 = \pi(T_0 P_i), \qquad u_i(T) = \pi(T P_i). \label{eq:projections}\tag{1}\] where \(\pi\) denotes the projection, \(u_i^0\) denotes the projection in the reference image \(I_0\), and \(u_i(T)\) denotes the projection in the current image \(I\).

A small \(p \times p\) patch is compared around each projection. Let \(\mathcal{P}=\{1,\dots,p^2\}\) index the pixels of the patch, where each \(k \in \mathcal{P}\) corresponds to a fixed 2D offset \(\Delta u_k\) relative to the patch center. The photometric residual for map point \(i\) and patch pixel \(k\) is defined as \[r_{i,k}(T) \;=\; I_0\!\left(u_i^0 + \Delta u_k\right)\;-\; I\!\left(u_i(T) + \Delta u_k\right),\] where intensities are sampled bilinearly.

The pose can be estimated by minimizing the sum of squared residuals for all pixels around all points: \[T^* \;=\; \arg\min_{T} \sum_{i=1}^{N} \sum_{k \in \mathcal{P}} r_{i,k}(T)^2 .\]

Optimization proceeds coarse-to-fine over the image pyramid, with the pose estimated at each coarser level used to initialize Gauss–Newton⁴ optimization at the next finer level, using a fixed maximum number of iterations per level. Pose increments are parameterized as a 6D twist \(\delta \in \mathbb{R}^6\) and applied with the exponential map using the update per iteration: \[T \leftarrow T \exp(\delta).\]

4.2 Inverse Compositional Template Approximation↩︎

Let \(r(T)\) denote the stacked residual vector formed from \(r_{i,k}(T)\). Using Gauss–Newton, the residual is linearized around the current estimate as \[r(T\exp(\delta)) \;\approx\; r(T) + J\,\delta, \label{eq:gn95linearization}\tag{2}\] Here, \(\delta \in \mathbb{R}^6\) is the pose increment and \(J\) is the Jacobian with respect to \(\delta\). Minimizing Eq. 2 . is solved iteratively via the normal equations \[H\,\delta = b, \qquad H = J^\top J, \qquad b = -J^\top r, \label{eq:normal95eq}\tag{3}\] In a forward-additive formulation, \(J\) depends on image gradients evaluated at warped locations in the current image \(I\) and must be recomputed at each iteration and for every new image. Inverse compositional (IC) alignment [27] reduces this cost by evaluating derivatives in the fixed reference image \(I_0\), making \(J\) independent of the current pose estimate while a reference is reused. This is particularly favorable in the tween-frame regime, where several frames are aligned to the same reference frame.

In the IC form used here, each Jacobian row follows the standard photometric chain rule evaluated on the reference side: \[J_{i,k} \;=\; \nabla I_0\!\left(u_i^0 + \Delta u_k\right)\, \frac{\partial \pi}{\partial x}\, \frac{\partial x}{\partial \delta}, \label{eq:ic95jacobian}\tag{4}\] with \(x = T_0 P_i\), where \(\frac{\partial \pi}{\partial x}\) is the projection Jacobian and \(\frac{\partial x}{\partial \delta}\) is the \(\mathrm{SE}(3)\) motion Jacobian. While the reference is fixed, the Jacobian stack \(J\) in Eq. 3 remains constant; only the residual vector \(r(T)\) changes with the current frame and pose estimate. Consequently, \(H\) can also be precomputed once per reference update. Solving Eq. 3 yields the pose increment \(\delta\), which is applied via \(T \leftarrow T\exp(\delta)\) to update the current pose estimate.

4.3 GPU Compute Shader Pipeline↩︎

Our GPU framework is implemented using OpenGL for Embedded Systems (OpenGL ES) 3.1, providing portability across commodity embedded GPUs and direct support for image-processing operations. Within this framework, compute shaders perform the parallel computation required by our direct photometric pose estimator. GLidE-SLAM executes the direct photometric visual odometry pipeline end-to-end on the GPU to minimize CPU–GPU data exchange. This includes image-pyramid construction, image differentiation, tree-based reduction, and Gauss–Newton optimization. Per-point and per-patch data are stored in Shader Storage Buffer Objects (SSBOs) [28] and accessed directly by the compute-shader stages. The same framework also drives a custom lightweight 3D visualization engine. The pipeline consists of three main stages:

Image pyramids. Each frame is converted to a 32-bit floating-point representation to reduce quantization error and keep downstream gradient and residual computations numerically stable. A Gaussian pyramid is then built on the GPU (Fig. 3). The first level (\(L=0\)) is full resolution, and subsequent levels are generated recursively by blurring⁵ and downsampling the previous level.

Precompute Inverse Compositional (IC). When processing a reference frame, for each of its pyramid levels, the inverse compositional cache is computed and stored in dedicated buffers (\(I_0\), \(J\), and \(H\)) shown in Fig. 4.

Each compute-shader invocation processes one map point \(P_i\): it projects \(P_i\) using \(T_0\), samples the \(p\times p\) reference patch, computes reference-side gradients, and stores the corresponding intensities and Jacobians \(J_{i,k}\) from Eq. 4 . The Hessian contribution \(H_i\) is first written per point and then reduced across points into a single per-level Hessian used during later in the track process. Since each invocation writes only to the buffer slice associated with its point index, the stage is parallel and requires no CPU-side accumulation.

Track. For each current frame, tracking is performed as a three-stage compute-shader process, repeated at each pyramid level and each Gauss–Newton iteration Fig. 5.

First, one compute-shader invocation per map point projects \(P_i\) using the current pose estimate \(T\), samples the corresponding current-image patch, and computes photometric residuals against the cached reference patch \(I_0\). For each patch pixel \(k\), the residual contribution is combined with the cached Jacobian \(J_{i,k}\). These per-pixel contributions are summed over the patch to produce one per-point right-hand-side vector \(b_i=-\sum_k J_{i,k}^\top r_{i,k}\).

Second, a tree-reduction stage aggregates all per-point vectors \(b_i\) into a single per-level 6D vector \(b\), corresponding to three rotational and three translational components.

Finally, the normal equations \(H\delta=b\) are solved on the GPU via Cholesky factorization to obtain the pose increment, and the pose is updated as \(T \leftarrow T\exp(\delta)\). The updated pose initializes the next iteration, and the procedure is repeated across pyramid levels from coarse to fine.

4.4 Indirect Tracking Switch↩︎

Direct tracking is used only for tween frames and is guarded by photometric-quality and baseline criteria. A direct-tracked frame is accepted when the GPU tracker returns a valid pose and the robust photometric error remains below the switching threshold. The system returns to the indirect pipeline given any of the following conditions: if direct tracking fails, if the error exceeds the failure threshold, or if the maximum number of direct frames since the last reference is reached. Upon successful switch back to indirect tracking, the direct pipeline is refreshed with new reference data: camera pose \(T_0\), input reference image and the 3D map points (see Fig. 2); the IC precompute stage is then re-run and track is performed for next consecutive frames.

5 EXPERIMENTAL EVALUATION↩︎

5.1 Experimental Setup↩︎

We evaluate GLidE-SLAM on three platforms comprising two embedded devices and a development laptop: the Radxa Zero 3W (RK3566, Mali-G52 MP2 GPU), representing a severely resource-constrained embedded target; the NVIDIA Jetson Orin Nano (Arm Cortex-A78AE CPU, Ampere GPU); and a development laptop (AMD Ryzen AI 9 HX 370 CPU, NVIDIA GeForce RTX 4060 mobile GPU). The evaluation comprises six image sequences: three TUM RGB-D [29] sequences, freiburg3_long_office_household, freiburg2_desk, and freiburg2_xyz, reported as tum3, tum2_desk, and tum2_xyz, respectively; and three EuRoC MAV [30] machine-hall sequences, MH01, MH03, and MH05.

All experiments use six image-pyramid levels. The direct-tracking patch size is dataset-specific: \(7\times7\) for TUM RGB-D and \(11\times11\) for EuRoC MAV. For each sequence, we report timing and accuracy over five runs to capture runtime performance and run-to-run variability. Rendering is disabled to avoid rendering-related bias. For this work GLidE-SLAM extends ORB-SLAM2, the evaluation focuses on the controlled question of how much tracking throughput improves on embedded devices while maintaining comparable accuracy. Broader comparisons to other SLAM frameworks would require additional porting and tuning across heterogeneous software and hardware dependencies and are outside the scope of this work.

6 RESULTS↩︎

We report median per-frame processing time, GPU-synchronized direct-tracking pipeline time, the percentage of frames processed by the direct tracker, and trajectory accuracy for GLidE-SLAM compared to ORB-SLAM2 on the platforms described in Sec. 5.1.

6.1 Frame Processing Performance↩︎

Table 1 reports median per-frame processing time for ORB-SLAM2 and GLidE-SLAM on all three platforms, together with the speedup factor relative to ORB-SLAM2. GLidE-SLAM reduces per-frame processing time on most sequence-platform pairs, with the largest gains observed on sequences with high direct-tracking utilization.

6.2 GPU Timings↩︎

The GPU timing breakdown reports synchronized compute-shader execution times for the two GPU paths used by GLidE-SLAM. Since image-pyramid construction is required before both precomputate and track processes, Table 2 reports Pre as pyramid+precompute and Trk as pyramid+track. All values are median elapsed times in milliseconds.

6pt

6.3 Direct Tracking Utilization↩︎

Higher direct-tracking utilization tends to increase speedup since direct tracking is significantly more efficient than indirect feature-based tracking. The indirect pipeline remains responsible for mapping and recovery when direct tracking is no longer reliable. This alternating relation is visible in Fig. 6, where indirect frames concentrate in regions requiring map extension or re-anchoring. Table 3 reports the percentage of frames successfully processed by the direct tracker using the acceptance criterion described in Sec. 4.

6.4 Trajectory Accuracy↩︎

Table 4 reports absolute trajectory error (ATE RMSE) for ORB-SLAM2 and GLidE-SLAM. Overall, GLidE-SLAM maintains accuracy across the evaluated platforms, with ATE values broadly comparable to the ORB-SLAM2 baseline.

4pt

6.5 Discussion↩︎

GLidE-SLAM improves runtime on most sequence-platform pairs while maintaining trajectory accuracy close to ORB-SLAM2. The largest gains occur with high direct-tracking utilization, especially on TUM sequences, where many frames are processed by the GPU direct tracker. Gains are more limited on EuRoC sequences, where faster motion and stronger viewpoint changes increase inter-frame baseline, reduce direct-tracking stability, and force more frequent returns to the indirect pipeline.

All reported results use the same compute-shader configuration across platforms, including workgroup sizes and dispatch structure. Since the evaluated GPUs differ in architecture and driver behavior, the results reflect a portable but not platform-optimized configuration. Further gains may therefore be possible through device-specific shader and dispatch tuning.

7 CONCLUSION↩︎

We presented GLidE-SLAM, a hybrid indirect-direct SLAM architecture that performs camera pose estimation through a fast GPU-accelerated direct pipeline and invokes the indirect pipeline primarily for re-stabilization, mapping, and relocalization. Our design allows camera tracking to be highly parallelizable on embedded GPUs, achieving substantial speed gains while preserving accuracy close to the feature-based baseline. The direct pose estimator is implemented with vendor-agnostic OpenGL ES 3.1 compute shaders, supporting portability across heterogeneous embedded devices.

Future work will extend GPU acceleration to additional pipeline stages, incorporate inertial motion priors, and investigate platform-specific shader tuning. More broadly, our results highlight an opportunity beyond SLAM: embedded platforms often include capable GPUs that remain under-utilized for onboard compute, and portable GPU implementations can provide significant performance gains.

References↩︎

---

1. This work was funded by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) under Germany’s Excellence Strategy – EXC 2117 – 422037984.↩︎

2. The authors are with the Department of Computer and Information Science, University of Konstanz, 78464 Konstanz, Germany. {carlos.pinheiro-de-sousa, heiko.hamann, oliver.deussen}@uni-konstanz.de↩︎

3. https://github.com/capsMD↩︎

4. Gauss–Newton is sufficient for this locally initialized pose-only problem with small inter-frame updates, and its fixed-iteration structure is more convenient for a compute-shader pipeline.↩︎

5. We use two-pass vertical/horizontal blur on a temporary texture buffer.↩︎