Pith. sign in

REVIEW 4 major objections 5 minor 30 references

GLidE-SLAM: GL-Accelerated Indirect-Direct Embedded SLAM

T0 review · 4 major / 5 minor · reviewed 2026-08-01 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read GLidE-SLAM claims that a complete direct photometric pose estimator can run on commodity embedded GPUs via OpenGL ES 3.1 compute shaders, raising frame rates up to 9x over a CPU-only baseline while keeping trajectory accuracy comparable.

desk verdict A real compute-shader direct tracker for embedded SLAM, but the 9x speedup claim is an artifact of median reporting and the inverse-compositional update is questionable. read the letter →

arxiv 2607.16897 v1 pith:FWVU2MLZ submitted 2026-07-18 cs.RO

Carlos A. Pinheiro de Sousa , Heiko Hamann , Oliver Deussen This is my paper
classification cs.RO
keywords visualSLAMdirectphotometrictrackingindirect-directhybridcomputeshadersOpenGLES3.1embeddedsystemspose-onlyestimationGauss-Newtonoptimization
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper is trying to establish that Visual SLAM tracking on embedded devices need not be CPU-bound. It proposes an architectural split: a GPU-accelerated direct photometric tracker performs pose-only estimation on most frames, while the CPU runs the indirect feature-based pipeline only for mapping, re-anchoring, and recovery. Because the direct tracker never creates map points or optimizes depth, its workload becomes highly parallel photometric image alignment, well suited to compute shaders. The paper reports up to 9x higher median frame rates than the CPU-only baseline on the same platforms, with absolute trajectory error staying in the same range. A sympathetic reader would care because this points to a vendor-agnostic path for running real-time SLAM on small, power-constrained devices without CUDA.

What carries the argument

The load-bearing mechanism is the inverse-compositional precompute cache: for a fixed reference keyframe, the tracker stores per-point reference patch intensities, per-patch Jacobians evaluated from reference-image gradients, and a per-level reduced Hessian. Because the reference is fixed across a window of intermediate frames, the Jacobian and Hessian are computed once per reference and reused; each new frame only samples the current image, forms residuals, reduces the right-hand-side vector, and solves the 6x6 normal equations on the GPU. The indirect-to-direct switching schedule—direct tracking for tween frames, indirect tracking for keyframes and recovery—is what limits exposure to the d

What would settle it

Re-run the same compute-shader pipeline on a fast-motion sequence with a true inverse compositional update (applying the increment inversely to the reference) and compare per-frame ATE and direct-acceptance rates against the current forward-update version; any material divergence would show the reference-side Jacobian assumption is load-bearing.

Watch

Extended reading notes

Core claim

The central claim is that a pose-only direct tracker can be implemented end-to-end with OpenGL ES 3.1 compute shaders—pyramid building, gradient computation, patch residual evaluation, tree reduction, and Gauss-Newton solving all on the GPU—and that this offload yields large throughput gains on embedded devices while keeping accuracy close to the feature-based baseline. The key design choice is that the direct module consumes 3D map points from the indirect pipeline and aligns incoming frames to a fixed reference using a cached set of reference intensities, reference-side Jacobians, and a precomputed Hessian. The paper reports direct-tracking acceptance of 46 to 90 percent of frames dependin

Load-bearing premise

The direct tracker computes gradients in the fixed reference image but applies pose increments with a forward update T <- T exp(delta), a mixture that is not derived or validated in the paper; if that approximation biases the photometric poses, the reported accuracy and acceptance rates become sequence-specific rather than general.

Editorial extensions

If this is right

  • Embedded SLAM front ends would no longer require CUDA-specific GPUs, widening the range of commodity devices that can run real-time tracking.
  • CPU cycles freed from tracking could be spent on mapping, bundle adjustment, and loop closure, which may improve long-term map consistency.
  • Speedups scale with direct-tracking acceptance rate, so sequences with moderate inter-frame motion benefit most; fast motion still forces fallback to the indirect pipeline.
  • The same shader-based photometric alignment could be reused for other pose-only tasks on embedded devices, such as visual odometry without mapping.
  • Because the shader configuration was intentionally not platform-tuned, the reported speedups are likely a conservative estimate of what device-specific tuning could achieve.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper leaves implicit that its reference-side Jacobian combined with a forward pose update is only an approximation to true inverse compositional alignment; a corrected inverse update might change the reported direct-success rates and speedups on fast-motion sequences.
  • If that approximation is benign, the same GPU pipeline should transfer naturally to stereo or RGB-D direct tracking, since the photometric residual and Jacobian structure are unchanged.
  • A testable extension would map the accuracy-throughput frontier by varying the switch threshold on a single sequence, revealing whether the 9x figure is near the practical limit or a conservative operating point.
  • The authors' own discussion notes the configuration was not platform-optimized, so the gains likely understate what device-specific shader and dispatch tuning would deliver.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. GLidE-SLAM presents a monocular hybrid indirect-direct SLAM system in which a direct photometric pose tracker is implemented with OpenGL ES 3.1 compute shaders and runs on embedded GPUs, while an indirect ORB-SLAM2-style pipeline handles keyframes, mapping, and recovery. The paper claims that this is the first complete direct photometric pose estimator via compute shaders for embedded devices, and reports up to 9× higher frame rates than the CPU-only baseline while maintaining comparable trajectory accuracy. The evaluation covers three platforms and six TUM/EuRoC sequences, reporting median per-frame times, GPU stage timings, direct-tracking success rates, and ATE RMSE compared against ORB-SLAM2.

Significance. If the claims are correct, the architectural separation and vendor-agnostic GPU implementation are a useful contribution: they would show that a substantial fraction of visual SLAM tracking can be offloaded from a CPU to embedded GPUs without CUDA, freeing CPU resources for mapping and back-end tasks. The paper is also honest about cases where speedups are small or negative (e.g., MH03 on all platforms, MH05 on Radxa), which lends credibility to the measurements. The reported direct-tracking success rates and GPU timings are a useful first step. However, the central 'up to 9× higher frame rates' claim is currently based on median per-frame times, which do not correspond to throughput when the distribution is heavy-tailed. The inverse compositional formulation also contains a potentially load-bearing mismatch between the reference-side Jacobian and the forward pose update. These issues need to be resolved before the main contribution is established.

major comments (4)
  1. [Sec. VI, Tables I and III] The abstract and conclusion claim 'up to 9× higher frame rates' based on median per-frame processing times. This is not a valid measure of frame rate for the reported system. For example, on the Jetson Orin Nano with tum2 desk, Table I gives GLidE-SLAM a median of 3.6 ms vs ORB-SLAM2's 32.8 ms (9.0×), but Table III shows direct tracking handles only 70.3% of frames. The remaining 29.7% go through the indirect pipeline, whose cost is at least comparable to the ORB-SLAM2 baseline. A lower-bound mean per-frame time is then 0.703·3.6 + 0.297·32.8 ≈ 12.3 ms, a throughput speedup of about 2.7×, not 9×. Because frame rate is the inverse of average inter-frame time, the reported median-based speedup overstates the headline claim. Please report mean frame times or full distributions, and phrase the contribution as 'median per-frame processing speedup' rather than 'frame rate' unless throughput is
  2. [Sec. IV-A, IV-B, Eq. (6)] The inverse compositional section has an inconsistency between the Jacobian and the update rule. Eq. (6) evaluates the Jacobian on the reference side, using gradients of I0 and the reference pose T0, but the pose update is stated as T ← T exp(δ) in Sec. IV-A and used throughout Sec. IV-C. In the standard inverse compositional formulation, the residual is linearized with respect to a perturbation of the reference/template and the update is applied inversely, i.e., T ← T exp(−δ) (or an equivalent inverse warp composition). Using a reference-image Jacobian with a forward additive update is an approximation that is not stated or justified. In tween-frame windows the current pose T can drift far from T0, so the reference-side Jacobian is not obviously a valid descent direction. This affects the correctness of the pose estimates and, consequently, the reported success rates and ATE values. Ple
  3. [Sec. V-A, Tables I and IV] The paper states that all results are based on five runs but reports only a single value per sequence/platform: median times in Table I and ATE in Table IV. No variance, confidence intervals, or per-run values are given. Runtime measurements on embedded platforms are noisy, and the heavy-tailed distribution of frame times makes median-only reporting especially problematic (see the point above). The accuracy comparison also lacks any indication of run-to-run spread. Please provide distributions, at least interquartile ranges or standard deviations, for the central timing and accuracy numbers.
  4. [Sec. V-A] The direct-tracking patch size is dataset-specific: 7×7 for TUM and 11×11 for EuRoC. This is a manually chosen free parameter, and no sensitivity analysis or cross-validation is reported. Since the same datasets are used both to motivate this choice and to evaluate the system, the reported accuracy and success rates may overstate what would be achieved on unseen sequences. Please provide a sensitivity study over patch sizes, or at least a justification that the chosen sizes are not fitted to the specific evaluation sequences.
minor comments (5)
  1. [Abstract / Introduction / Sec. III] There are several typos and awkward phrasings: 'intermediatetween frames' in Sec. III, 'Precompute ICon' in Fig. 1 caption, 'Preaspyramid+precompute' in Table II, and 'differ in architecture' missing hyphenation. Please proofread.
  2. [Sec. V-A] The paper does not state whether the ORB-SLAM2 baseline was run with the same or comparable settings (e.g., number of features, pyramid levels). This is important for interpreting absolute timing comparisons.
  3. [Sec. VI-D] Table IV reports ATE RMSE to three decimal places. Given the absence of variance, these numbers may imply a precision that is not supported. Consider reporting to two decimals or with error bars.
  4. [Sec. VII] The future-work paragraph mentions 'platform-specific shader tuning,' which is relevant because Sec. V-E states the compute-shader configuration is not platform-optimized. This caveat is good, but it would be strengthened by reporting how much headroom remains.
  5. [General] The paper would benefit from a public code release or at least a more detailed algorithmic pseudocode for the compute-shader stages, since the central claim depends on a specific GPU implementation. This is not a correctness issue but would significantly improve reproducibility.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: GLidE-SLAM's speedup and accuracy claims are externally benchmarked against TUM/EuRoC and ORB-SLAM2, with no self-citation or fitted-parameter-as-prediction.

full rationale

The central claims are empirical measurements, not derivations: Table I compares median per-frame times against a CPU-only ORB-SLAM2 baseline, Table III reports measured direct-tracking success rates, and Table IV reports ATE RMSE against external TUM/EuRoC ground truth. The direct photometric tracker is defined by standard photometric residuals (Eqs. 2-3) and a Gauss-Newton/IC optimization scheme (Eqs. 4-6) whose Jacobian caching follows the external Baker & Matthews formulation [27]; no result is defined in terms of the quantity it is used to predict. The only dataset-specific setting is patch size (7x7 vs 11x11) disclosed in Sec. V-A, which is configuration tuning rather than a fitted parameter renamed as a prediction. There are no self-citations and no load-bearing citation chain from the authors' own prior work. The paper's unverified IC update convention and the median-based speedup summary are correctness/statistical-validity concerns, not instances of the derivation reducing to its own inputs.

Assumptions & free parameters 5 free parameters · 5 assumptions · 0 invented entities

The system rests on standard SLAM assumptions (brightness constancy, small motion, pinhole geometry) plus several unstated tuning choices. The largest methodological burden is the reference-Jacobian/forward-update approximation in the direct tracker and the fair-baseline assumption for ORB-SLAM2.

free parameters (5)
  • Direct-tracking patch size p = 7 (TUM), 11 (EuRoC)
    Sec. V-A states the patch size is dataset-specific; no cross-validation or justification is given. This choice affects residuals, direct utilization, and timing.
  • Switching/failure thresholds and max direct-frame count = not reported
    Sec. IV-D defines acceptance/failure criteria and a maximum number of direct frames, but numeric values are not given. These control direct utilization (Table III) and hence the speedup.
  • Gauss-Newton max iterations per pyramid level = not reported (fixed)
    Sec. IV-A says a fixed maximum number of iterations per level is used; the value is not stated, although it affects runtime and accuracy.
  • Number of image pyramid levels = 6
    Sec. V-A fixes six pyramid levels for all experiments; this is a hand-chosen constant with no ablation.
  • Compute-shader workgroup sizes and dispatch configuration = not reported
    Sec. VI-E says the same configuration is used across platforms but does not report it; GPU timing depends on these choices.
assumptions (5)
  • domain assumption Brightness constancy between reference and current images
    Photometric residual in Eq. (2) compares intensities of the same 3D points; this fails under illumination changes and motion blur, a limitation acknowledged for direct methods in Sec. II-A.
  • domain assumption Small inter-frame motion so Gauss-Newton with coarse-to-fine initialization converges
    Sec. IV-A uses local Gauss-Newton with fixed iteration count; fast EuRoC motion lowers direct success (Table III, MH03 ~46%), so this assumption is load-bearing.
  • ad hoc to paper Reference-side Jacobian is a valid descent direction with forward pose update
    Sec. IV-B Eq. (6) evaluates Jacobians in I0, but Sec. IV-A updates T forward via T exp(delta); the paper never justifies this as an inverse-compositional update, so the optimization may be biased.
  • domain assumption ORB-SLAM2 is a fair CPU-only baseline with comparable backend behavior
    Speedup in Table I assumes identical mapping/BA workload; the paper does not specify exact ORB-SLAM2 settings or whether GLidE changes keyframe policy beyond direct/indirect alternation.
  • domain assumption Ground-truth trajectories in TUM and EuRoC are accurate enough for ATE comparison
    Standard benchmark assumption; ATE RMSE in Table IV relies on these annotations.

how reviews work

0 comments
Cite this review

Pith. "Pith review of GLidE-SLAM: GL-Accelerated Indirect-Direct Embedded SLAM." pith.science (2026). https://pith.science/paper/FWVU2MLZ

@misc{pith2026260716897,
  author       = {Pith},
  title        = {Pith review of: GLidE-SLAM: GL-Accelerated Indirect-Direct Embedded SLAM},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/FWVU2MLZ}},
  note         = {Machine review of arXiv:2607.16897}
}
abstract

With the growing demand for robotics, autonomous drones, and wearable extended reality systems, the deployment of Visual SLAM on embedded devices remains challenging. Tracking must sustain high frame rates while preserving compute resources for map extension and maintenance. This paper presents GLidE-SLAM, a monocular hybrid indirect-direct framework that addresses this by architectural separation: the system performs GPU-accelerated direct tracking on intermediate frames, while reserving the full indirect pipeline for map extension and global consistency. We leverage highly parallel image-alignment operations for pose-only estimation without depth optimization or map point creation, making the workload suitable for GPU offloading and freeing CPU resources for backend tasks. We implement the direct tracker using vendor-agnostic OpenGL ES~3.1 compute shaders, enabling deployment across a broader range of commodity embedded platforms without requiring CUDA support. To our knowledge, this is the first complete direct photometric pose estimator realized via compute shaders for embedded-class devices. Experiments on target platforms demonstrate up to 9$\times$ higher frame rates than the CPU-only baseline while maintaining trajectory accuracy and improving practical deployment across commodity resource-constrained hardware.

Figures

Figures reproduced from arXiv: 2607.16897 by the authors.

Figure 1
Figure 1. Windowed visual odometry schedule. Interflow GPU-CPU: [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Direct/indirect tracking pipeline overview. GPU tracking estimates [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Multi-stage image pyramid generation. 2We use two-pass vertical/horizontal blur on a temporary texture buffer [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Per-level precompute cache storage. Per-point thread projection [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]
Figure 5
Figure 5. Figure 5: Per-level, per-iteration photometric alignment: per-point thread [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]
Figure 6
Figure 6. Figure 6: 3D render capture of GLidE-SLAM running on fr2/desk dataset: [PITH_FULL_IMAGE:figures/full_fig_p005_6.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

30 extracted references · 11 linked inside Pith

  1. [1]

    High-speed stereo visual slam for low-powered computing devices,

    A. Kumar, J. Park, and L. Behera, “High-speed stereo visual slam for low-powered computing devices,”IEEE Robotics and Automation Letters, vol. 9, no. 1, pp. 499–506, 2024

    2024

  2. [2]

    Fully onboard slam for distributed mapping with a swarm of nano-drones,

    C. Friess, V . Niculescu, T. Polonelli, M. Magno, and L. Benini, “Fully onboard slam for distributed mapping with a swarm of nano-drones,”IEEE Internet of Things Journal, vol. 11, no. 20, p. 32363–32380, Oct. 2024. [Online]. Available: http: //dx.doi.org/10.1109/JIOT.2024.3367451

    arXiv 2024

  3. [3]

    Gs-slam: Dense visual slam with 3d gaussian splatting,

    C. Yan, D. Qu, D. Xu, B. Zhao, Z. Wang, D. Wang, and X. Li, “Gs-slam: Dense visual slam with 3d gaussian splatting,” 2024. [Online]. Available: https://arxiv.org/abs/2311.11700

    arXiv 2024

  4. [4]

    Splat-slam: Globally optimized rgb-only slam with 3d gaussians,

    E. Sandstr ¨om, K. Tateno, M. Oechsle, M. Niemeyer, L. V . Gool, M. R. Oswald, and F. Tombari, “Splat-slam: Globally optimized rgb-only slam with 3d gaussians,” 2024. [Online]. Available: https://arxiv.org/abs/2405.16544

    arXiv 2024

  5. [5]

    Vggt-slam: Dense rgb slam optimized on the sl(4) manifold,

    D. Maggio, H. Lim, and L. Carlone, “Vggt-slam: Dense rgb slam optimized on the sl(4) manifold,” 2025. [Online]. Available: https://arxiv.org/abs/2505.12549

    arXiv 2025

  6. [6]

    DUSt3R: Geometric 3d vision made easy,

    S. Wang, V . Leroy, Y . Cabon, B. Chidlovskii, and J. Revaud, “DUSt3R: Geometric 3d vision made easy,” 2024. [Online]. Available: https://arxiv.org/abs/2312.14132

    arXiv 2024

  7. [7]

    Mast3r-slam: Real-time dense slam with 3d reconstruction priors,

    R. Murai, E. Dexheimer, and A. J. Davison, “Mast3r-slam: Real-time dense slam with 3d reconstruction priors,” 2025. [Online]. Available: https://arxiv.org/abs/2412.12392

    arXiv 2025

  8. [8]

    MonoSLAM: Real-time single camera slam,

    A. J. Davison, I. D. Reid, N. D. Molton, and O. Stasse, “MonoSLAM: Real-time single camera slam,”IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 29, no. 6, pp. 1052–1067, 2007

    2007

Show all 30 references
  1. [9]

    ORB-SLAM: A versatile and accurate monocular SLAM system,

    R. Mur-Artal, J. M. M. Montiel, and J. D. Tardos, “ORB-SLAM: A versatile and accurate monocular SLAM system,”IEEE Transactions on Robotics, vol. 31, no. 5, p. 1147–1163, Oct. 2015. [Online]. Available: http://dx.doi.org/10.1109/TRO.2015.2463671

    2015

  2. [10]

    Orb-slam2: An open-source slam system for monocular, stereo, and rgb-d cameras,

    R. Mur-Artal and J. D. Tardos, “Orb-slam2: An open-source slam system for monocular, stereo, and rgb-d cameras,”IEEE Transactions on Robotics, vol. 33, no. 5, p. 1255–1262, Oct. 2017. [Online]. Available: http://dx.doi.org/10.1109/TRO.2017.2705103

    2017

  3. [11]

    VINS-Mono: A robust and versa- tile monocular visual-inertial state estimator,

    T. Qin, P. Li, and S. Shen, “VINS-Mono: A robust and versa- tile monocular visual-inertial state estimator,”IEEE Transactions on Robotics, vol. 34, no. 4, pp. 1004–1020, 2018

    2018

  4. [12]

    Orb-slam3: An accurate open-source library for visual, visual–inertial, and multimap slam,

    C. Campos, R. Elvira, J. J. G. Rodriguez, J. M. M. Montiel, and J. D. Tardos, “Orb-slam3: An accurate open-source library for visual, visual–inertial, and multimap slam,”IEEE Transactions on Robotics, vol. 37, no. 6, p. 1874–1890, Dec. 2021. [Online]. Available: http://dx.doi....

    2021

  5. [13]

    DTAM: Dense tracking and mapping in real-time,

    R. A. Newcombe, S. J. Lovegrove, and A. J. Davison, “DTAM: Dense tracking and mapping in real-time,” in2011 International Conference on Computer Vision, 2011, pp. 2320–2327

    2011

  6. [14]

    Direct sparse odometry,

    J. Engel, V . Koltun, and D. Cremers, “Direct sparse odometry,” 2016. [Online]. Available: https://arxiv.org/abs/1607.02565

    2016 arXiv

  7. [15]

    LSD-SLAM: Large-scale direct monocular SLAM,

    J. Engel, T. Sch ¨ops, and D. Cremers, “LSD-SLAM: Large-scale direct monocular SLAM,” inEuropean Conference on Computer Vision (ECCV), September 2014

    2014

  8. [16]

    LDSO: Direct sparse odometry with loop closure,

    X. Gao, R. Wang, N. Demmel, and D. Cremers, “LDSO: Direct sparse odometry with loop closure,” in2018 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 2018, pp. 2198– 2204

    2018

  9. [17]

    Loosely-coupled semi-direct monocular slam,

    S. H. Lee and J. Civera, “Loosely-coupled semi-direct monocular slam,”IEEE Robotics and Automation Letters, vol. 4, no. 2, p. 399–406, Apr. 2019. [Online]. Available: http://dx.doi.org/10.1109/L RA.2018.2889156

    2019

  10. [18]

    H-slam: Hybrid direct-indirect visual slam,

    G. Younes, D. Khalil, J. S. Zelek, and D. C. Asmar, “H-slam: Hybrid direct-indirect visual slam,”ArXiv, vol. abs/2306.07363,

    arXiv

  11. [19]

    Svo: Fast semi-direct monocular visual odometry,

    C. Forster, M. Pizzoli, and D. Scaramuzza, “Svo: Fast semi-direct monocular visual odometry,” in2014 IEEE International Conference on Robotics and Automation (ICRA), 2014, pp. 15–22

    2014

  12. [20]

    Ov 2slam : A fully online and versatile visual slam for real-time applications,

    M. Ferrera, A. Eudes, J. Moras, M. Sanfourche, and G. L. Besnerais, “Ov 2slam : A fully online and versatile visual slam for real-time applications,” 2021. [Online]. Available: https: //arxiv.org/abs/2102.04060

    2021 arXiv

  13. [21]

    Fasttrack: Gpu-accelerated tracking for visual slam,

    K. Khabiri, P. Hosseininejad, S. Gopinath, K. Dantu, and S. Y . Ko, “Fasttrack: Gpu-accelerated tracking for visual slam,” 2025. [Online]. Available: https://arxiv.org/abs/2509.10757

    2025 arXiv

  14. [22]

    High- performance feature extraction for gpu -accelerated orb-slamx,

    F. Muzzini, N. Capodieci, R. Cavicchioli, and B. Rouxel, “High- performance feature extraction for gpu -accelerated orb-slamx,” in 2024 Design, Automation & Test in Europe Conference & Exhibition (DATE), 2024, pp. 1–2

    2024

  15. [23]

    cuvslam: Cuda accelerated visual odometry and mapping,

    A. Korovko, D. Slepichev, A. Efitorov, A. Dzhumamuratova, V . Kuznetsov, H. Rabeti, J. Biswas, and S. Pouya, “cuvslam: Cuda accelerated visual odometry and mapping,” 2025. [Online]. Available: https://arxiv.org/abs/2506.04359

    2025 arXiv

  16. [24]

    ac2SLAM: FPGA accelerated high-accuracy SLAM with heapsort and paral- lel keypoint extractor,

    C. Wang, Y . Liu, K. Zuo, J. Tong, Y . Ding, and P. Ren, “ac2SLAM: FPGA accelerated high-accuracy SLAM with heapsort and paral- lel keypoint extractor,” in2021 International Conference on Field- Programmable Technology (ICFPT), 2021, pp. 1–9

    2021

  17. [25]

    eslam: An energy-efficient accelerator for real-time ORB-SLAM on FPGA platform,

    R. Liu, J. Yang, Y . Chen, and W. Zhao, “eslam: An energy-efficient accelerator for real-time ORB-SLAM on FPGA platform,” in2019 56th ACM/IEEE Design Automation Conference (DAC), 2019, pp. 1– 6

    2019

  18. [26]

    An empirical evaluation of four off-the-shelf proprietary visual-inertial odometry systems,

    J. Kim, M. Song, Y . Lee, M. Jung, and P. Kim, “An empirical evaluation of four off-the-shelf proprietary visual-inertial odometry systems,” 2022. [Online]. Available: https://arxiv.org/abs/2207.06780

    2022 arXiv

  19. [27]

    Lucas-Kanade 20 years on: A unifying framework part 1: The quantity approximated, the warp update rule, and the gradient descent approximation,

    S. Baker and I. Matthews, “Lucas-Kanade 20 years on: A unifying framework part 1: The quantity approximated, the warp update rule, and the gradient descent approximation,”International Journal of Computer Vision - IJCV, 01 2004. [28]OpenGL ES 3.1 Specification, Version 3.1 ed....

    2004

  20. [29]

    A benchmark for the evaluation of RGB-D SLAM systems,

    J. Sturm, N. Engelhard, F. Endres, W. Burgard, and D. Cremers, “A benchmark for the evaluation of RGB-D SLAM systems,” in2012 IEEE/RSJ International Conference on Intelligent Robots and Systems, 2012, pp. 573–580

    2012

  21. [30]

    The euroc micro aerial vehicle datasets,

    M. Burri, J. Nikolic, P. Gohl, T. Schneider, J. Rehder, S. Omari, M. W. Achtelik, and R. Siegwart, “The euroc micro aerial vehicle datasets,”The International Journal of Robotics Research, 2016. [Online]. Available: http://ijr.sagepub.com/content/early/2016/01/21/0 27836491562...

    2016

  22. [2023]

    Available: https://api.semanticscholar.org/CorpusID: 259145125

    [Online]. Available: https://api.semanticscholar.org/CorpusID: 259145125

Pith tools

Reviewed August 1, 2026 · model on record in the stance chip above.