로봇 매핑 기술의 진화

로봇 매핑 기술의 진화

로봇 공학, 특히 자율 주행 시스템에서 환경을 인식하고 재구성하는 매핑(Mapping) 기술은 로봇이 미지의 공간에서 자신의 위치를 파악하고(Localization) 안전한 경로를 계획(Planning)하기 위한 가장 근원적인 전제 조건이다. 초기 로봇 시스템이 2차원 평면의 점유 격자 지도(Occupancy Grid Map)에 의존했던 것과 달리, 현대의 로봇은 복잡한 3차원 공간에서 동적인 객체와 상호작용하며 고속으로 이동해야 하는 요구사항에 직면해 있다. 이러한 요구는 LiDAR(Light Detection and Ranging)와 RGB-D 카메라와 같은 고해상도 센서의 발전과 맞물려 폭발적인 데이터 처리량을 야기했으며, 이는 필연적으로 매핑 알고리즘과 하드웨어 아키텍처의 근본적인 변화를 촉구하게 되었다. 본 장에서는 CPU 기반 처리 방식이 직면한 물리적, 구조적 한계를 심층 분석하고, 이를 극복하기 위한 GPU 가속 기반의 대규모 병렬 처리 아키텍처로의 전환이 왜 필수불가결한 선택인지를 기술적으로 논증한다.

1. CPU 기반 매핑의 한계

전통적으로 로봇 매핑 시스템은 범용 프로세서(CPU) 위에서 구동되도록 설계되었다. 이는 CPU가 복잡한 분기 예측과 순차적 논리 처리에 최적화되어 있기 때문이며, 초기 SLAM(Simultaneous Localization and Mapping) 알고리즘들이 데이터의 양보다는 논리적 정합성에 초점을 맞추었기 때문이다. 그러나 센서 기술의 비약적인 발전으로 인해 데이터의 수집 속도와 해상도가 기하급수적으로 증가함에 따라, CPU 기반 매핑 시스템은 연산 능력(Compute-bound)과 메모리 대역폭(Memory-bound) 양측면에서 심각한 병목 현상에 직면하게 되었다.

1.1 확률적 복셀 매핑과 OctoMap의 구조적 한계

3차원 환경을 표현하는 가장 대표적인 방식 중 하나는 공간을 복셀(Voxel)이라는 단위 입방체로 분할하고, 각 복셀이 장애물에 의해 점유되었을 확률을 추정하는 확률적 체적 매핑(Probabilistic Volumetric Mapping, PVM)이다.1 이 분야의 사실상 표준(de facto standard)으로 자리 잡았던 OctoMap은 옥트리(Octree) 자료구조를 기반으로 하여 광활한 3차원 공간을 효율적으로 압축하여 저장할 수 있는 장점을 제공했다.2 옥트리는 공간을 재귀적으로 8개의 자식 노드로 분할하는 계층적 트리 구조로, 데이터가 존재하지 않는 빈 공간(Free space)에 대해서는 메모리를 할당하지 않음으로써 메모리 효율성을 극대화한다.3

그러나 이러한 트리 기반 구조는 데이터의 조회(Query)와 갱신(Update) 과정에서 치명적인 연산 비용을 초래한다. OctoMap의 가장 큰 병목은 센서 원점으로부터 장애물까지의 공간을 ’비어 있음(Free)’으로 갱신하기 위해 수행하는 레이 캐스팅(Ray-casting) 작업에서 발생한다.1 예를 들어, 단일 LiDAR 스캔이 10만 개의 포인트를 생성하고 초당 20~60Hz로 작동한다고 가정할 때, CPU는 매초 수백만 번 이상의 광선 추적(Ray tracing) 연산을 수행해야 한다.4

문제의 핵심은 옥트리 구조의 순회 비용이다. 3차원 공간에서 특정 좌표에 해당하는 복셀에 접근하기 위해서는 루트 노드에서부터 리프(Leaf) 노드까지 트리를 타고 내려가야 한다. 이 과정의 시간 복잡도는 트리의 깊이(Depth)에 비례하는 O(\log N)이다. 수백만 개의 센서 포인트 각각에 대해 깊이 d의 트리를 순회해야 하므로, 전체 연산 복잡도는 O(K \cdot \log N) (여기서 K는 포인트 수, N은 전체 노드 수)으로 증가한다. CPU는 이러한 반복적이고 독립적인 연산을 순차적으로 처리해야 하므로, 센서 데이터의 유입 속도가 CPU의 처리 속도를 초과하는 시점에서 실시간 매핑은 불가능해진다.5

항목OctoMap (CPU) 특징구조적 한계
자료구조옥트리 (Octree)포인터 기반 연결 리스트 구조로 인한 메모리 파편화
접근 방식트리 순회 (O(\log N))깊이가 깊어질수록 접근 비용 증가
주요 연산레이 캐스팅 (Ray-casting)순차적 처리로 인한 대규모 포인트 클라우드 처리 불가
메모리 효율높음 (빈 공간 미할당)동적 할당 오버헤드 및 캐시 지역성 저하

1.2 메모리 접근 패턴과 캐시 미스(Cache Miss)의 병목

CPU 아키텍처 관점에서 옥트리와 같은 포인터 기반 자료구조는 현대 프로세서의 성능을 저하시키는 주요 원인인 ’캐시 미스(Cache Miss)’를 빈번하게 유발한다.6 CPU는 메인 메모리(DRAM)로부터 데이터를 가져오는 지연 시간(Latency)을 줄이기 위해 고속의 L1, L2, L3 캐시를 사용하며, 이는 공간적 지역성(Spatial Locality)과 시간적 지역성(Temporal Locality)에 의존한다.8

  • 공간적 지역성(Spatial Locality): 배열(Array)과 같이 연속된 메모리 공간에 데이터가 저장된 경우, CPU는 한 번의 메모리 접근으로 인접한 데이터를 캐시 라인(Cache Line)에 함께 로드한다. 또한, 하드웨어 프리페처(Prefetcher)가 다음에 필요한 데이터를 예측하여 미리 로드함으로써 효율을 극대화한다.9
  • 포인터 체이싱(Pointer Chasing) 문제: 옥트리는 노드들이 힙(Heap) 메모리 상의 임의의 위치에 산재되어 있으며, 부모 노드가 자식 노드를 포인터 주소로 가리키는 방식으로 연결된다.7 매핑 업데이트 과정에서 트리를 순회할 때마다 CPU는 서로 다른 메모리 주소로 불규칙하게 점프해야 한다. 이는 하드웨어 프리페처의 예측을 무력화시키고, 캐시 적중률(Cache Hit Rate)을 급격히 떨어뜨린다.

결과적으로 CPU는 연산(ALU)을 수행하는 시간보다 데이터를 메인 메모리에서 가져오기를 기다리는 스톨(Stall) 상태에 더 많은 시간을 소비하게 된다. 연구 결과에 따르면, 포인터 기반 데이터 구조의 무작위 메모리 접근은 대규모 데이터 처리 시 CPU 파이프라인의 효율을 심각하게 저하시키며, 이는 단순히 CPU의 클럭 속도를 높이는 것으로는 해결할 수 없는 ‘메모리 벽(Memory Wall)’ 문제에 봉착하게 한다.10

1.3 Voxblox의 등장과 CPU 기반 거리장(ESDF) 계산의 한계

OctoMap의 옥트리 구조가 가진 메모리 접근 비효율성을 극복하기 위해, 해시(Hash) 기반의 매핑 시스템인 Voxblox가 등장했다.12 Voxblox는 공간 해싱(Spatial Hashing) 기법을 사용하여 3차원 좌표를 키(Key)로 사용하여 복셀 블록에 O(1)의 시간 복잡도로 접근할 수 있도록 설계되었다.13 또한, 단순한 점유 여부(Occupancy)가 아니라 표면까지의 거리를 저장하는 절단된 부호 거리장(Truncated Signed Distance Field, TSDF)을 사용하여 표면 재구성의 정밀도를 높였다.

그러나 Voxblox 역시 CPU 상에서 구동될 때, 특히 로봇의 경로 계획(Path Planning)에 필수적인 유클리드 부호 거리장(ESDF)을 계산하는 과정에서 명확한 한계를 드러낸다.14

  1. ESDF의 전역적 연산 특성: TSDF는 표면 근처의 좁은 밴드(Truncation distance) 내에서만 값을 가지면 되지만, ESDF는 로봇이 장애물과의 충돌을 피하기 위해 맵상의 모든 자유 공간(Free space) 복셀에 대해 가장 가까운 장애물까지의 거리를 계산해야 한다. 이는 국소적인(Local) 업데이트가 아니라 전역적인(Global) 파급 효과를 가지는 연산이다.15
  2. 웨이브프론트(Wavefront) 알고리즘의 병목: CPU 기반의 Voxblox는 ESDF를 갱신하기 위해 웨이브프론트 알고리즘을 사용한다. 이는 변화가 발생한 장애물 복셀을 기점으로 거리 정보를 이웃 복셀로 전파(Propagate)해 나가는 방식이다.16 이 방식은 변경된 부분만 갱신한다는 장점이 있으나, 맵의 해상도가 높아지거나(예: 복셀 크기 5cm 이하), 변경되는 영역이 넓을 경우 처리해야 할 큐(Queue)의 크기가 급증하여 CPU 부하를 가중시킨다.
  3. 실시간성 상실: 실험 데이터에 따르면, Intel i7 프로세서에서 20cm 해상도의 경우 ESDF 업데이트가 비교적 원활하지만, 해상도를 2cm로 정밀화할 경우 통합(Integration) 및 ESDF 갱신 시간이 500ms를 초과하는 것으로 나타났다.12 이는 2Hz 미만의 갱신 속도를 의미하며, 고속으로 비행하는 드론이나 정밀 제어가 필요한 로봇 팔의 제어 루프(통상 20Hz~100Hz 요구)를 전혀 만족시키지 못한다.17

1.4 센서 데이터 폭증과 폰 노이만 병목

현대의 로봇 센서는 CPU가 단독으로 감당할 수 있는 데이터 처리량(Throughput)의 임계치를 넘어서고 있다.

  • LiDAR 센서: Velodyne VLP-16은 초당 약 30만~60만 포인트를 생성하며, Ouster OS1-64와 같은 고해상도 LiDAR는 초당 수백만 개의 포인트를 생성한다.19 각 포인트는 3D 좌표(XYZ), 반사도(Intensity) 등의 정보를 포함하므로 데이터 대역폭 소모가 크다.
  • RGB-D 카메라: Intel RealSense D435와 같은 깊이 카메라는 848x480 해상도의 깊이 이미지를 30~90fps로 출력한다.21 단순 계산으로도 초당 1,200만~3,600만 픽셀(포인트)의 거리 정보를 처리해야 한다.

CPU는 소수의 강력한 코어를 통해 복잡한 로직을 순차적으로 처리하는 데 특화되어 있어, 이러한 대규모 스트림 데이터를 직렬로 처리하는 과정에서 심각한 병목이 발생한다. 특히 센서 데이터를 메인 메모리로 로드하고, 처리 결과를 다시 메모리에 쓰는 과정은 소위 ’폰 노이만 병목(Von Neumann Bottleneck)’을 심화시킨다.11 CPU가 매핑 연산에 포화(Saturation) 상태가 되면, 로봇의 자세 추정(State Estimation)이나 제어와 같은 다른 중요 실시간 프로세스의 자원을 잠식(Resource Contention)하여 시스템 전체의 안정성을 위협하게 된다.5

결론적으로, CPU 기반 매핑 기술은 저해상도, 저속 이동, 정적 환경이라는 제한된 조건에서는 유효할 수 있으나, 고해상도 센서를 장착하고 복잡한 동적 환경을 고속으로 이동해야 하는 현대 로봇 시스템의 요구사항을 충족시키기에는 연산 구조적, 메모리 접근적 한계가 명확하다.

2. GPU 가속의 필요성

앞서 논의한 CPU 기반 매핑의 한계, 즉 병렬 데이터 처리 능력의 부족과 메모리 대역폭의 병목을 해결하기 위한 유일하고도 필연적인 대안은 그래픽 처리 장치(GPU)를 활용한 가속화이다. GPU는 수천 개의 코어를 탑재하여 대규모 데이터 병렬 처리(Data Parallelism)에 특화된 아키텍처를 가지고 있으며, 이는 3차원 매핑이 요구하는 대량의 레이 캐스팅과 복셀 업데이트 작업과 본질적으로 완벽하게 부합한다.

2.1 대규모 병렬 처리(Massively Parallel Processing) 아키텍처

GPU 가속의 핵심은 ‘스루풋(Throughput)’ 중심의 아키텍처에 있다. CPU가 지연 시간(Latency)을 최소화하기 위해 복잡한 제어 로직(Out-of-order execution, Branch prediction)과 큰 캐시를 사용하는 반면, GPU는 수천 개의 경량 스레드(Thread)를 동시에 실행하여 메모리 접근 지연 시간을 연산으로 덮어버리는(Hide latency with computation) 전략을 취한다.24

로봇 매핑에서 수행되는 작업들, 예를 들어 카메라의 각 픽셀이나 LiDAR의 각 빔(Beam)에 대해 공간상의 점유 확률을 업데이트하는 작업은 서로 의존성이 없는 ‘당황스러울 정도로 병렬적인(Embarrassingly Parallel)’ 문제이다. 따라서 이를 GPU의 SIMT(Single Instruction, Multiple Threads) 모델에 매핑하면 엄청난 성능 향상을 기대할 수 있다.

  • 성능 향상 사례: 연구 결과에 따르면, GPU를 활용한 OctoMap-RT는 기존 CPU 기반 OctoMap 대비 맵 구축 속도에서 최대 41.2배, SuperRay 알고리즘 대비 9.3배의 성능 향상을 기록했다.1
  • NvBlox의 혁신: NVIDIA가 공개한 GPU 가속 기반 라이브러리인 NvBlox는 CPU 기반의 Voxblox 대비 표면 재구성(Surface Reconstruction) 속도에서 최대 177배, ESDF 계산에서 31배의 획기적인 성능 향상을 입증하였다.14

이러한 성능 격차는 로봇이 인식할 수 있는 환경의 해상도를 cm 단위에서 mm 단위로 정밀화하고, 처리 가능한 센서의 개수와 데이터 양을 획기적으로 늘릴 수 있는 가능성을 열어준다.

2.2 GPU 친화적 해싱과 메모리 접근 최적화 (Coalesced Memory Access)

GPU의 성능을 극대화하기 위해서는 단순히 알고리즘을 CPU에서 GPU로 옮기는 것만으로는 부족하며, GPU의 메모리 계층 구조에 최적화된 자료구조가 필수적이다. NvBlox와 같은 최신 프레임워크는 옥트리 대신 ‘블록 해싱(Block Hashing)’ 기법을 고도화하여 적용한다.14

  1. 블록 해싱 구조: 3차원 공간을 8x8x8 또는 16x16x16 크기의 작은 덴스 그리드(Dense Grid) 블록으로 나누고, 데이터가 존재하는 유의미한 블록만 해시 테이블을 통해 GPU 메모리에 할당한다.14 이는 전체 공간을 미리 할당하지 않으므로 메모리 효율적이면서도, 블록 내부에서는 인덱싱을 통해 고속으로 접근할 수 있게 한다.
  2. 통합 메모리 접근(Coalesced Memory Access): 이것이 GPU 매핑 성능의 핵심이다. GPU의 스레드 그룹인 워프(Warp, 통상 32 스레드)가 메모리에 접근할 때, 인접한 스레드들이 연속된 메모리 주소(Contiguous memory addresses)에 접근하면 하드웨어는 이를 하나의 메모리 트랜잭션으로 병합(Coalesce)하여 처리한다.26 블록 해싱 구조에서는 하나의 블록 내부 데이터가 연속된 메모리에 저장되므로, 블록 내부를 병렬 처리하는 스레드들이 자연스럽게 통합 메모리 접근 패턴을 형성하게 되어 대역폭 효율을 극대화한다.14 반면, 옥트리와 같은 흩어진 메모리 접근(Strided or Random access)은 통합 접근을 불가능하게 하여 GPU 대역폭을 낭비하게 만든다.27
  3. 고속 해시 테이블 (Cuckoo Hashing & Linear Probing): 수백만 개의 복셀에 대한 조회(Query) 요청을 처리하기 위해, GPU 상에서의 해시 충돌(Collision) 해결 전략도 중요하다. NvBlox 및 관련 연구들은 뻐꾸기 해싱(Cuckoo Hashing)이나 선형 탐사(Linear Probing) 방식을 사용한다.28 뻐꾸기 해싱은 최악의 경우에도 1~2회의 메모리 접근만으로 데이터를 찾을 수 있도록 보장(Constant worst-case lookup)하거나, 선형 탐사를 통해 캐시 지역성을 높이는 방식으로 구현되어, 대규모 매핑 시 발생하는 빈번한 데이터 조회를 병목 없이 처리한다.29

2.3 ESDF 계산의 패러다임 전환: 병렬 밴딩 알고리즘 (PBA)

CPU에서는 연산 비용 문제로 근사값(Quasi-Euclidean)을 사용하거나 변경된 부분만 어렵게 추적해야 했던 ESDF 계산 역시 GPU를 통해 혁신되었다. GPU의 대규모 병렬성을 활용하면 전체 맵에 대해 정확한 유클리드 거리를 계산하는 전역 알고리즘을 매 프레임 실행하는 것이 가능해진다.

  • PBA (Parallel Banding Algorithm): NvBlox는 PBA와 같은 알고리즘을 채택하여 ESDF를 계산한다.31 PBA는 맵 이미지를 여러 밴드(Band)로 나누어 각 밴드를 독립적으로 처리한 후, 단계적으로 병합(Merge)하는 방식이다.32 이 알고리즘은 O(N)의 선형 시간 복잡도를 가지면서도, 각 단계가 완벽하게 병렬화될 수 있어 GPU의 수천 개 코어를 100% 활용할 수 있다.
  • 정확도와 속도의 동시 달성: 기존 Voxblox가 사용하던 근사치(Quasi-Euclidean) 거리 계산은 맵 상의 거리가 실제 유클리드 거리와 오차를 보였으나, NvBlox의 GPU 기반 계산은 ‘완전한(Full)’ 유클리드 거리를 계산하면서도 Voxblox보다 31배 더 빠르다.14 이는 로봇이 장애물과 매우 근접한 좁은 통로를 통과하거나, 고속 주행 시 더 안전하고 부드러운 경로(Trajectory)를 생성하는 데 결정적인 기여를 한다.34
특징Voxblox (CPU)NvBlox (GPU)비고
거리장 유형Quasi-Euclidean (근사치)Full Euclidean (정확)경로 계획 정밀도 차이
알고리즘Wavefront (직렬 전파)PBA / JFA (병렬 밴딩)병렬화 가능 여부
복잡도변경된 복셀 수에 비례전체 복셀 수에 선형 비례 (O(N))대규모 맵에서의 확장성
ESDF 속도느림 (병목 발생)31배 빠름 14실시간성 확보

2.4 제어 루프의 고속화와 시스템 지연(Latency) 감소

로봇의 자율 주행 성능, 특히 고속 드론이나 민첩한 로봇의 경우 ‘감지-판단-제어’ 루프의 지연 시간이 생존과 직결된다. 제어 루프는 통상 100Hz 이상의 주기를 요구하며, 전체 시스템의 지연 시간은 수 밀리초(ms) 이내여야 한다.18

GPU 가속 매핑은 센서 입력부터 맵 업데이트, 그리고 ESDF 생성까지의 파이프라인(End-to-End) 처리 시간을 획기적으로 단축시킨다. CPU 기반 시스템에서는 포인트 클라우드 전처리, 매핑, 경로 계획, 제어 로직이 모두 CPU 자원을 두고 경쟁(Context Switching)하며 예측 불가능한 지터(Jitter)를 유발할 수 있다.36 반면, GPU 매핑 시스템은 무거운 기하학적 연산을 GPU로 오프로딩(Offloading)함으로써 CPU를 제어 및 상위 수준의 의사 결정 로직에 온전히 할당할 수 있게 한다.37

또한, NVIDIA Jetson AGX Orin과 같은 최신 임베디드 플랫폼은 CPU와 GPU가 물리적 메모리를 공유하는 통합 메모리 아키텍처(Unified Memory Architecture)를 지원한다. 이를 통해 센서 데이터를 CPU 메모리에서 GPU 메모리로 복사하는 오버헤드(Zero-copy)를 제거하여 시스템 전반의 효율을 극대화하고 지연 시간을 최소화한다.23

2.5 AI 기반 인지 기술과의 융합 (Semantic Mapping)

마지막으로, GPU 가속은 기하학적 매핑(Geometric Mapping)을 넘어 의미론적 매핑(Semantic Mapping)으로의 진화를 가능하게 한다. 객체 인식(Object Detection), 의미론적 분할(Semantic Segmentation), 사람 인식과 같은 최신 딥러닝 모델들은 전적으로 GPU 상에서 구동된다.39

매핑 시스템이 GPU 상주형(GPU-resident)으로 설계되면, 딥러닝 모델이 추론한 결과(예: Segmentation Mask)를 CPU로 전송할 필요 없이, GPU 메모리 내부에서 즉시 3차원 복셀 맵에 투영(Project)하여 융합할 수 있다.40 이는 “어디에 장애물이 있는가(Geometry)“와 “그 장애물이 무엇인가(Semantics)“를 실시간으로 결합한 3D 시맨틱 맵을 구축하는 데 있어 필수적인 아키텍처 요구사항이다. 이러한 통합은 로봇이 단순히 충돌을 피하는 것을 넘어, “사람을 피해 조심스럽게 이동“하거나 “의자를 인식하여 그 아래로 지나가는” 등의 고차원적인 상호작용을 가능하게 한다.34

요약하자면, 1.1.2절에서의 논의는 GPU 가속이 단순한 연산 속도 향상의 선택적 옵션이 아니라, 고해상도 센서 데이터의 실시간 수용, 정밀한 물리적 상호작용을 위한 정확한 거리장 계산, 그리고 최신 AI 인지 기술과의 유기적 결합을 위해 반드시 채택해야 할 기술적 표준임을 시사한다. 이는 로봇이 통제된 실험실 환경을 벗어나 복잡하고 예측 불가능한 현실 세계(Real-world)에서 자율적으로 기능하기 위한 하드웨어 및 소프트웨어 아키텍처의 근본적인 진화이다.

3. 참고 자료

  1. OctoMap-RT: Fast Probabilistic Volumetric Mapping Using Ray-Tracing GPUs - Ewha Graphics Lab, https://graphics.ewha.ac.kr/octomap-rt/images/RAL/OctoMap-RT_RAL23.pdf
  2. OMU: A Probabilistic 3D Occupancy Mapping Accelerator for Real-time OctoMap at the Edge - arXiv, https://arxiv.org/pdf/2205.03325
  3. OctoMap: An Efficient Probabilistic 3D Mapping Framework Based on Octrees, https://courses.cs.washington.edu/courses/cse571/16au/slides/hornung13auro.pdf
  4. OctoMap: A Probabilistic, Flexible, and Compact 3D Map Representation for Robotic Systems, https://www.ipb.uni-bonn.de/wp-content/papercite-data/pdf/wurm10icraws.pdf
  5. octomap_server performance issues? - Robotics Stack Exchange, https://robotics.stackexchange.com/questions/47210/octomap-server-performance-issues
  6. The hidden impact of cache locality on application performance · Raygun Blog, https://raygun.com/blog/cache-locality-impact-application-performance/
  7. Cache-Conscious Data Structures - Microsoft, https://www.microsoft.com/en-us/research/wp-content/uploads/2016/12/ccds.pdf
  8. Why Arrays have better cache locality than Linked list? - GeeksforGeeks, https://www.geeksforgeeks.org/dsa/why-arrays-have-better-cache-locality-than-linked-list/
  9. Why is linear search faster than binary search for small sorted arrays in C++? : r/cpp - Reddit, https://www.reddit.com/r/cpp/comments/w939hb/why_is_linear_search_faster_than_binary_search/
  10. Data-Parallel Hashing Techniques for GPU Architectures - arXiv, https://arxiv.org/pdf/1807.04345
  11. Database Architecture Optimized for the new Bottleneck: Memory Access Peter Boncz* Stefan Manegold Martin Kersten Data Distiller, https://www.vldb.org/conf/1999/P5.pdf
  12. Performance — voxblox documentation - Read the Docs, https://voxblox.readthedocs.io/en/latest/pages/Performance.html
  13. Real-time 3D Reconstruction at Scale using Voxel Hashing - Matthias Niessner, https://niessnerlab.org/papers/2013/4hashing/niessner2013hashing.pdf
  14. nvblox: GPU-Accelerated Incremental Signed Distance Field Mapping - arXiv, https://arxiv.org/html/2311.00626v2
  15. LGSDF: Continual Global Learning of Signed Distance Fields Aided by Local Updating This work is supported by the National Natural Science Foundation of China under Grant 62233002, 92370203. (Corresponding Author: Yufeng Yue, yueyufeng@bit.edu.cn) - arXiv, https://arxiv.org/html/2404.05187v1
  16. How Does ESDF Generation Work? — voxblox documentation - Read the Docs, https://voxblox.readthedocs.io/en/latest/pages/How-Does-ESDF-Generation-Work.html
  17. What is considered to be normal control loop delay in robotics? : r/ControlTheory - Reddit, https://www.reddit.com/r/ControlTheory/comments/11fk2qd/what_is_considered_to_be_normal_control_loop/
  18. How to Resolve Frequency and Timing Synchronization Issues in Nav2? : r/ROS - Reddit, https://www.reddit.com/r/ROS/comments/1i6i7x9/how_to_resolve_frequency_and_timing/
  19. minwoo0611/Awesome-3D-LiDAR-Datasets - GitHub, https://github.com/minwoo0611/Awesome-3D-LiDAR-Datasets
  20. VLP 16 - Ouster, https://ouster.com/products/hardware/vlp-16
  21. High-speed capture mode of Intel® RealSense™ Depth Camera D435, https://dev.realsenseai.com/docs/high-speed-capture-mode-of-intel-realsense-depth-camera-d435
  22. Intel® RealSenseTM Camera 400 Series (DS5) Product Family Datasheet, https://cdrdv2-public.intel.com/841984/Intel-RealSense-D400-Series-Datasheet.pdf
  23. Vortex: Overcoming Memory Capacity Limitations in GPU-Accelerated Large-Scale Data Analytics - VLDB Endowment, https://www.vldb.org/pvldb/vol18/p1250-yuan.pdf
  24. When is GPU compute the bottleneck and memory bandwidth isn’t? : r/LocalLLaMA - Reddit, https://www.reddit.com/r/LocalLLaMA/comments/1ech0vr/when_is_gpu_compute_the_bottleneck_and_memory/
  25. nvblox: GPU-Accelerated Incremental Signed Distance Field Mapping - IEEE Xplore, https://ieeexplore.ieee.org/document/10611532/
  26. Global Memory Coalescing - CisMine Ng - Medium, https://giahuy04.medium.com/global-memory-coalescing-37a6f9d7e314
  27. Coalesced Memory access related doubt - CUDA Programming and Performance, https://forums.developer.nvidia.com/t/coalesced-memory-access-related-doubt/20134
  28. Better GPU Hash Tables - arXiv, https://arxiv.org/pdf/2108.07232
  29. Maximizing Performance with Massively Parallel Hash Maps on GPUs - NVIDIA Developer, https://developer.nvidia.com/blog/maximizing-performance-with-massively-parallel-hash-maps-on-gpus/
  30. Analyzing and Implementing GPU Hash Tables, https://par.nsf.gov/servlets/purl/10397858
  31. coVoxSLAM: GPU accelerated globally consistent dense SLAM - arXiv, https://arxiv.org/html/2410.21149v1
  32. euclidean distance transform on xavier | nvidia, https://developer.download.nvidia.com/video/gputechconf/gtc/2019/presentation/s9165-euclidean-distance-transform-on-xavier.pdf
  33. Parallel Banding Algorithm to Compute Exact Distance Transform with the GPU, https://www.comp.nus.edu.sg/~tants/pba_files/pba.pdf
  34. Technical Details - NVIDIA Isaac ROS, https://nvidia-isaac-ros.github.io/concepts/scene_reconstruction/nvblox/technical_details.html
  35. How Fast is Too Fast? The Role of Perception Latency in High-Speed Sense and Avoid, https://rpg.ifi.uzh.ch/docs/RAL19_Falanga.pdf
  36. Control loop missed its desired rate - ROS Answers archive, http://answers.ros.org/question/289092/
  37. Faster dense deformable image registration by utilizing both CPU and GPU - SPIE Digital Library, https://www.spiedigitallibrary.org/journals/journal-of-medical-imaging/volume-8/issue-1/014002/Faster-dense-deformable-image-registration-by-utilizing-both-CPU-and/10.1117/1.JMI.8.1.014002.pdf
  38. GPU-accelerated volumetric-mosaic optical-resolution photoacoustic microscopy and quantifying tumor vasculature growth - PubMed Central, https://pmc.ncbi.nlm.nih.gov/articles/PMC12677172/
  39. Isaac ROS Nvblox, https://nvidia-isaac-ros.github.io/repositories_and_packages/isaac_ros_nvblox/index.html
  40. mindmap: Spatial Memory in Deep Feature Maps for 3D Action Policies - arXiv, https://arxiv.org/html/2509.20297v1