TurboMap: GPU-Accelerated Local Mapping for Visual SLAM

Karthik Dantu; Kimia Khabiri; Parsa Hosseininejad; Shishir Gopinath; Soudabeh Mohammadhashemi; Steven Y. Ko

REVIEW 2 major objections 4 minor 17 references

TurboMap: GPU-Accelerated Local Mapping for Visual SLAM

T0 review · 2 major / 4 minor · reviewed 2026-08-04 · deepseek-v4-flash

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

Pith's one-line read TurboMap shows that a visual SLAM local mapping backend can be sped up 1.3–1.6× by offloading search and fusion to the GPU with persistent keyframe storage, while preserving trajectory accuracy and avoiding skipped optimization stages under

desk verdict Practical GPU-accelerated local mapping for ORB-SLAM3 with real but modest speedups; the persistent-storage story needs clarification around map-point data for fusion. read the letter →

arxiv 2511.02036 v5 pith:KLZXNDT7 submitted 2025-11-03 cs.RO

Parsa Hosseininejad , Kimia Khabiri , Shishir Gopinath , Soudabeh Mohammadhashemi , Karthik Dantu , Steven Y. Ko This is my paper

classification cs.RO

keywords visualSLAMlocalmappingGPUaccelerationCUDAbundleadjustmentkeyframecullingmappointfusionembeddedrobotics

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

This paper argues that the local mapping stage of a visual SLAM system — the pipeline stage that processes keyframes and can cause tracking failure if it falls behind — can be substantially accelerated by moving the heaviest search and fusion operations to the GPU while keeping frequently changing map observations on the CPU. The authors implement TurboMap, a redesigned local mapping backend for ORB-SLAM3, and report average speedups of 1.3× on EuRoC and 1.6× on TUM-VI across desktop and embedded platforms, with trajectory accuracy unchanged. They also show that under artificially high keyframe insertion rates, the baseline system skips local bundle adjustment and keyframe culling and loses accuracy, while TurboMap processes every stage and stays accurate. A sympathetic reader would care because local mapping latency is a known bottleneck in real-time visual SLAM, especially on embedded robots, and the result suggests a practical way to relieve it without changing the map quality.

What carries the argument

The central mechanism is persistent GPU-resident keyframe storage: each keyframe is copied to GPU memory once when it enters local mapping and stays there until it is removed, eliminating repeated transfers for the search and fusion kernels. On this storage, TurboMap runs a parallel Search for Triangulation kernel (descriptor distance plus epipolar verification per thread), a parallel Map Point Fusion kernel, and a CPU-side lightweight per-map-point observation counter array for keyframe culling. It integrates an existing GPU-accelerated Local Bundle Adjustment solver that offloads the Schur complement step. The design rule is: offload work that is computationally intense, highly parallel, a

What would settle it

Measure local mapping time on a sequence where keyframe descriptors are refreshed during map updates (for example, after loop closure or map merge); if the cost of re-synchronizing the persistent GPU keyframe storage approaches the original total local mapping cost, the central speedup claim collapses.

Watch

Extended reading notes

Core claim

The paper claims that by splitting local mapping into GPU-side and CPU-side tasks based on data mutability, the entire pipeline can run 1.3–1.6× faster on average (EuRoC and TUM-VI, desktop and embedded) with no change in absolute trajectory error. The key split: keyframe keypoints and descriptors, which are static once created, live permanently on the GPU; map point observations, which change every iteration, stay on the CPU. This lets GPU kernels for triangulation search and fusion run without repeated transfers, while a lightweight observation-count array accelerates keyframe culling. Under high keyframe insertion stress, the baseline skips LBA and culling and its trajectory diverges, whe

Load-bearing premise

The design assumes that keyframe keypoints and descriptors stored on the GPU never change during local mapping, so they need no synchronization; if keyframes were updated frequently, the synchronization overhead would eat the speedup.

Editorial extensions

If this is right

Local mapping latency drops by 1.3× on EuRoC and 1.6× on TUM-VI on both a desktop GPU (RTX 3090) and an embedded GPU (Jetson Xavier NX), with ATE RMSE essentially unchanged across all sequences.
Keyframe processing time becomes more consistent: standard deviation shrinks, and the maximum per-keyframe time drops from about 220 ms to 115 ms in the corridor1 sequence, reducing the risk of tracking failure from slow keyframes.
Under high keyframe insertion stress, TurboMap avoids skipping local bundle adjustment and keyframe culling, whereas the baseline skips many stages; TurboMap's trajectory error stays below 0.05 m ATE RMSE while the baseline reaches 10.1 m on corridor1.
The speedups scale with map point count: TUM-VI, which has roughly twice as many map points as EuRoC, shows larger gains for the GPU-accelerated components (search and fusion).
The design is presented as transferable to other visual SLAM systems that maintain a global map and implement analogous local mapping stages.

Reading between the lines

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

A testable extension is a dirty-bit mechanism on the persistent keyframe store: if a keyframe's descriptors ever need updating (for example, during map refinement), only the changed keyframe would be re-transferred to the GPU, isolating synchronization cost and making the design applicable to systems that update features.
The stress-test result suggests TurboMap's practical value is greatest when keyframe insertion is dense — fast motion, low-power robots — so a natural next evaluation is on live onboard flight or handheld data where the real-time limiter is actually active, not disabled as in the simulated stress test.
The static/dynamic data-split principle could generalize to other iterative mapping modules, such as loop-closing map merging or dense reconstruction, where stable features are stored on the accelerator and frequently changing connectivity remains on the host.
Because local bundle adjustment still dominates the remaining time in TurboMap (roughly 60–75% of local mapping), a further speedup would require making the LBA itself more parallel; the current paper relies on an existing GPU solver for only the Schur complement step.

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.

Desk Editor's Note

read the letter

Punchline: this is a legitimately useful systems paper. It offloads search-for-triangulation and map-point fusion to the GPU with persistent keyframe storage, which is a new combination, and the evaluation supports the claimed 1.3–1.6× speedups while preserving ATE. The main weakness I see is that the paper doesn't fully explain how the GPU fusion kernel gets map-point descriptors and positions for neighboring keyframes, given that the persistent storage is described as holding only keypoints and descriptors.

The paper does several things well. The per-component breakdown is clear, with triangulation search and fusion showing real speedups, and the CPU-side keyframe culling optimization is a sensible place to avoid GPU transfer overhead. Integrating the previous GPU LBA solver rather than reimplementing it is honest. Running on desktop and Jetson, with five runs per sequence and reporting standard deviations, is solid. The stress test is a nice addition: it shows that lower latency directly reduces skipped LBA and keyframe culling, which is the practical motivation for the work. Code is released too.

The soft spot is the one the stress-test note flags. In ORB-SLAM3, fusion compares descriptors of map points, not just keypoint descriptors, and those map-point descriptors and positions are updated during tracking and LBA. The paper says the persistent keyframe storage contains keypoints and descriptors, and that neighbor keyframe data is already on the GPU with no transfer cost. But it never says whether map-point data for neighbor keyframes is also on the GPU or whether it is re-transferred per keyframe. The ~100 KB figure only covers the current keyframe's map points. If the neighbor map-point data has to be synchronized each iteration, that transfer cost is not accounted for in the design description, even if it is included in the measured timings. This is a documentation gap, not a demonstrated error, but it should be fixed before publication.

Minor issues: no statistical significance tests, and the custom stress-test modifications are reasonable but worth stating more carefully as a simulation of high keyframe insertion rather than real fast motion.

Overall, this is a solid within-subfield contribution. It deserves a serious referee. The authors should be asked to clarify the GPU memory layout for map points and ideally profile transfer costs separately. I'd bring it to a reading group.

Referee Report

2 major / 4 minor

Summary. TurboMap is a GPU-accelerated local mapping backend for ORB-SLAM3. The paper identifies four local-mapping bottlenecks — map-point creation, map-point fusion, local bundle adjustment (LBA), and keyframe culling — and optimizes them: the search for triangulation correspondences is offloaded to the GPU, map-point fusion is parallelized on the GPU using a persistent GPU-resident keyframe store, an existing GPU LBA solver is integrated, and keyframe culling is optimized on the CPU. Experiments on EuRoC and TUM-VI, on a desktop RTX 3090 platform and a Jetson Xavier NX, report average local-mapping speedups of 1.3x and 1.6x respectively, with comparable ATE RMSE. A stress experiment with denser keyframe insertion shows that ORB-SLAM3 skips LBA/culling and diverges, while TurboMap maintains accuracy. The authors make their code publicly available.

Significance. If the reported results hold, this is a useful and practical contribution to real-time visual SLAM. The paper addresses a genuinely important bottleneck — local mapping latency — and combines targeted GPU kernels with a CPU-side redesign rather than a monolithic port. Strengths include reproducible open-source code, evaluation on two datasets and two very different hardware platforms, per-component speedup breakdowns, and a stress test that goes beyond standard benchmark runs. The LBA component is adopted from the authors' prior work, but the evaluation of the integrated TurboMap system is independent, so this is not circular. The main weaknesses are in the completeness of the design description for GPU fusion and in the comparability of the embedded-platform sequence subset; both are addressable. Overall, the evidence supports the central claim of moderate average speedups with preserved accuracy, though the paper needs revision to fully substantiate the no-transfer-cost claim and to clarify the experimental scope.

major comments (2)

[IV-D / IV-B] The claim that GPU fusion 'incurs no transfer cost' for neighboring keyframes is not established by the described storage layout. Section IV-B states the persistent GPU keyframe storage contains keypoints and descriptors per keyframe, and Section IV-D says the data required for Fuse are the neighboring keyframes (already on GPU) plus ~100 KB of current-keyframe map-point data. In ORB-SLAM3's fusion logic, however, duplicate detection also needs the 3D positions and representative descriptors of candidate map points observed in the neighboring keyframes. These quantities are dynamically updated during local mapping, and Section IV-F explicitly notes that such dynamic observation data is unsuitable for persistent GPU storage. If neighbor map-point data are transferred or synchronized per keyframe, the overhead is omitted from the stated ~100 KB figure; if they are not required, the paper s
[Table I / V-A] The embedded and desktop evaluations use different sequence subsets. In Table I(a) the Jetson EuRoC average is computed from MH01, MH02, V101, V102 only, and the Jetson TUM-VI average from room1, room2, corridor1, corridor2 only; in Table I(b) the desktop averages use 8 EuRoC sequences and 9 TUM-VI sequences. The text claims average speedups of 1.3x and 1.6x on EuRoC and TUM-VI 'in both the desktop and embedded settings' without noting this discrepancy. Since the central claim is across both platforms, the paper should either run the full sequence set on both platforms or explicitly state and justify the Jetson subset, and compute averages over the same sequences when making cross-platform comparisons.

minor comments (4)

[V-A] No statistical significance tests or confidence intervals are reported for the key speedup claims. Given the five-run protocol and consistent per-sequence direction this is not disqualifying, but paired tests or bootstrapped CIs would strengthen the headline result.
[V-E] The stress test is described as simulating 'high camera velocity' and 'rapidly changing scenes', but the actual modification increases keyframe insertion rate by disabling the real-time limiter and reducing the minimum keyframe interval; the camera motion in the dataset is unchanged. Please rephrase to describe the intervention accurately as a high-keyframe-rate / heavy-local-mapping-load stress test.
[IV-B] The phrase 'mainly include keypoints and their descriptors' is vague. Please give a precise list of fields stored per keyframe in the persistent GPU storage, especially any fields needed by the GPU Fuse kernel.
[IV-F] The CPU keyframe-culling optimization is described at a high level. A short pseudocode or a precise description of how the per-map-point scale counters are maintained under keyframe removal and map-point updates would make the correctness and the reported 1.8-3.3x speedup easier to assess.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: TurboMap's central claims are empirical measurements against external baselines, not derivations from fitted inputs or self-referential definitions.

full rationale

TurboMap's central claims — 1.3x speedup on EuRoC and 1.6x on TUM-VI for local mapping, with comparable ATE — are measured wall-clock timings of TurboMap versus vanilla ORB-SLAM3 on external datasets (Table I). No equation in the paper derives a predicted quantity from a fitted input, and no parameter is calibrated to the reported outcome. The design components in Sections IV-C through IV-F are engineering choices evaluated empirically: Search for Triangulation and Map-point Fusion are measured component-wise, Keyframe Culling is measured on the CPU, and LBA speedups are measured against ORB-SLAM3's g2o baseline in the same table. The paper integrates the same-group GPU LBA solver [12] and cites other same-group work [11], but it does not rely on those citations as evidence for speedup or accuracy; Table I independently reports LBA component timings and ATE on the external datasets. The paper also honestly flags limitations in Section IV-F (synchronization overhead of dynamic map-point storage was nearly the full local-mapping cost) and in the Conclusion (GPU transfer overhead on discrete platforms). These are empirical caveats, not circular premises. The persistent GPU keyframe storage description in Sections IV-B/IV-D may under-specify what map-point data the Fusion kernel requires — a potential correctness/overhead concern — but that is not a circular derivation: no result is true by construction or equivalent to its own input.

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

The paper introduces no fitted constants or new physical entities. The central claim rests on domain assumptions about representative workloads, functional equivalence of GPU kernels, and static keyframe data.

assumptions (3)

domain assumption The local mapping workload of ORB-SLAM3 is representative of global-map visual SLAM systems; the component time distribution (95% in Search, Fuse, LBA, Culling) is typical.
Generalization to other SLAM systems depends on this premise.
domain assumption The GPU implementations of Search for Triangulation and Map Point Fusion are functionally equivalent to the CPU versions, so accuracy is preserved.
This is tested indirectly via ATE, but not proven; if GPU matching differs, map quality could change.
domain assumption Persistent GPU keyframe storage avoids repeated data transfer because keyframe keypoint/descriptor data is static during local mapping.
If keyframe descriptors were mutable, synchronization would add overhead, negating speedup.

how reviews work

0 comments

Cite this review

Pith. "Pith review of TurboMap: GPU-Accelerated Local Mapping for Visual SLAM." pith.science (2026). https://pith.science/paper/KLZXNDT7

@misc{pith2026251102036,
  author       = {Pith},
  title        = {Pith review of: TurboMap: GPU-Accelerated Local Mapping for Visual SLAM},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KLZXNDT7}},
  note         = {Machine review of arXiv:2511.02036}
}

read the original abstract

In real-time Visual SLAM systems, local mapping must operate under strict latency constraints, as delays degrade map quality and increase the risk of tracking failure. GPU parallelization offers a promising way to reduce latency. However, parallelizing local mapping is challenging due to synchronized shared-state updates and the overhead of transferring large map data structures to the GPU. This paper presents TurboMap, a GPU-parallelized and CPU-optimized local mapping backend that holistically addresses these challenges. We restructure Map Point Creation to enable parallel Keypoint Correspondence Search on the GPU, redesign and parallelize Map Point Fusion, optimize Redundant Keyframe Culling on the CPU, and integrate a fast GPU-based Local Bundle Adjustment solver. To minimize data transfer and synchronization costs, we introduce persistent GPU-resident keyframe storage. Experiments on the EuRoC and TUM-VI datasets show average local mapping speedups of 1.3x and 1.6x, respectively, while preserving accuracy.

Figures

Figures reproduced from arXiv: 2511.02036 by the authors.

**Figure 1.** Local mapping workflow in ORB-SLAM3. local mapping, while Kumar et al. [13] offload Jacobian computations for pose graph optimization to the GPU. The Ceres Solver [14] introduces optional CUDA-based linear solvers to speed up the optimization steps in bundle adjustment, and MegBA [15] provides a fully GPU-native, distributed BA framework capable of handling large-scale optimizations. In contrast to previous work, w… view at source ↗

**Figure 2.** Average time spent in different sections of local [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗

**Figure 3.** Data flow of the local mapping process in [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗

Figures from the paper (4 more)

**Figure 2.** Figure 2: As discussed in Section II, several prior efforts [PITH_FULL_IMAGE:figures/full_fig_p004_2.png]

**Figure 4.** Figure 4: Corridor1 keyframe processing time for TurboMap and ORB-SLAM3 in Desktop environment. array per map point, which amounts to just a few bytes per map point. V. EVALUATION A. Experimental Setup We evaluate the performance of TurboMap by running a set of sequences on two …

**Figure 5.** Figure 5: Trajectory comparison between TurboMap and ORBSLAM3 in corridor1. Sequence TurboMap ORB-SLAM3 ATE #Skipped LBA & KF Culling ATE #Skipped LBA & KF Culling MH01 0.040 3.4 1.105 58 V101 0.039 18.8 0.091 102.6 room1 0.011 5.8 1.005 140.4 corridor1 0.045 9.2 10.136 343.8 T…

**Figure 6.** Figure 6: Trajectory comparison in MH01 between [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

17 extracted references · 1 canonical work pages

[1]

A comprehensive study of systems challenges in visual simultaneous localization and mapping systems,

S. Semenova, S. Ko, Y . D. Liu, L. Ziarek, and K. Dantu, “A comprehensive study of systems challenges in visual simultaneous localization and mapping systems,”ACM Trans. Embed. Comput. Syst., vol. 24, no. 1, Sept. 2024. [Online]. Available: https: //doi.org/10.1145/3677317

work page doi:10.1145/3677317 2024
[2]

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

2015
[3]

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

2017
[4]

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

2021
[5]

Openvins: A research platform for visual-inertial estimation,

P. Geneva, K. Eckenhoff, W. Lee, Y . Yang, and G. Huang, “Openvins: A research platform for visual-inertial estimation,” in2020 IEEE International Conference on Robotics and Automation (ICRA), 2020, pp. 4666–4672

2020
[6]

Kimera: an open- source library for real-time metric-semantic localization and mapping,

A. Rosinol, M. Abate, Y . Chang, and L. Carlone, “Kimera: an open- source library for real-time metric-semantic localization and mapping,” in2020 IEEE International Conference on Robotics and Automation (ICRA), 2020, pp. 1689–1696

2020
[7]

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/ 0278364915620033.abstract

2016
[8]

The tum vi benchmark for evaluating visual-inertial odometry,

D. Schubert, T. Goll, N. Demmel, V . Usenko, J. St ¨uckler, and D. Cre- mers, “The tum vi benchmark for evaluating visual-inertial odometry,” in2018 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 2018, pp. 1680–1687

2018

Show all 17 references

[9]

Data flow orb-slam for real-time performance on embedded gpu boards,

S. Aldegheri, N. Bombieri, D. D. Bloisi, and A. Farinelli, “Data flow orb-slam for real-time performance on embedded gpu boards,” in 2019 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS). Macau, China: IEEE, Nov. 2019, p. 5370–5375. [Online]. Availabl...

2019
[10]

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, p. 499–506, Jan. 2024

2024
[11]

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
[12]

Improving the performance of local bundle adjustment for visual-inertial slam with efficient use of gpu resources,

S. Gopinath, K. Dantu, and S. Y . Ko, “Improving the performance of local bundle adjustment for visual-inertial slam with efficient use of gpu resources,” in2023 IEEE International Conference on Robotics and Automation (ICRA), 2023, pp. 6239–6245

2023
[13]

Jacobigpu: Gpu- accelerated numerical differentiation for loop closure in visual slam,

D. Kumar, S. Gopinath, K. Dantu, and S. Y . Ko, “Jacobigpu: Gpu- accelerated numerical differentiation for loop closure in visual slam,” in2024 IEEE International Conference on Robotics and Automation (ICRA), 2024, pp. 1687–1693

2024
[14]

Ceres Solver,

S. Agarwal, K. Mierle, and T. C. S. Team, “Ceres Solver,” 10 2023. [Online]. Available: https://github.com/ceres-solver/ceres-solver

2023
[15]

Megba: A gpu-based distributed library for large-scale bundle adjustment,

J. Ren, W. Liang, R. Yan, L. Mai, S. Liu, and X. Liu, “Megba: A gpu-based distributed library for large-scale bundle adjustment,”
[16]

G2o: A general framework for graph optimization,

R. K ¨ummerle, G. Grisetti, H. Strasdat, K. Konolige, and W. Burgard, “G2o: A general framework for graph optimization,” in2011 IEEE International Conference on Robotics and Automation, 2011, pp. 3607–3613

2011
[2022]

Available: https://arxiv.org/abs/2112.01349

[Online]. Available: https://arxiv.org/abs/2112.01349

arXiv

Pith tools

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

[1] [1]

A comprehensive study of systems challenges in visual simultaneous localization and mapping systems,

S. Semenova, S. Ko, Y . D. Liu, L. Ziarek, and K. Dantu, “A comprehensive study of systems challenges in visual simultaneous localization and mapping systems,”ACM Trans. Embed. Comput. Syst., vol. 24, no. 1, Sept. 2024. [Online]. Available: https: //doi.org/10.1145/3677317

work page doi:10.1145/3677317 2024

[2] [2]

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

2015

[3] [3]

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

2017

[4] [4]

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

2021

[5] [5]

Openvins: A research platform for visual-inertial estimation,

P. Geneva, K. Eckenhoff, W. Lee, Y . Yang, and G. Huang, “Openvins: A research platform for visual-inertial estimation,” in2020 IEEE International Conference on Robotics and Automation (ICRA), 2020, pp. 4666–4672

2020

[6] [6]

Kimera: an open- source library for real-time metric-semantic localization and mapping,

A. Rosinol, M. Abate, Y . Chang, and L. Carlone, “Kimera: an open- source library for real-time metric-semantic localization and mapping,” in2020 IEEE International Conference on Robotics and Automation (ICRA), 2020, pp. 1689–1696

2020

[7] [7]

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/ 0278364915620033.abstract

2016

[8] [8]

The tum vi benchmark for evaluating visual-inertial odometry,

D. Schubert, T. Goll, N. Demmel, V . Usenko, J. St ¨uckler, and D. Cre- mers, “The tum vi benchmark for evaluating visual-inertial odometry,” in2018 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 2018, pp. 1680–1687

2018