A Vendor-Agnostic LiDAR Data Conversion System with Multi-Signal Detection and Multi-Format Output

기술 요약: 다중 신호 탐지 및 다중 형식 출력을 지원하는 벤더 불가지론적(Vendor-Agnostic) LiDAR 데이터 변환 시스템

문제 정의
본 논문은 서로 다른 제조사(구체적으로 Ouster, Velodyne, Hesai, Livox)의 로우(raw) LiDAR 데이터를 처리할 때 발생하는 파편화 문제를 다룹니다. 이러한 센서들은 PCAP(Packet Capture) 파일로 데이터를 출력하지만, UDP 포트 관례, 패킷 레이아웃, 매직 바이트(magic bytes), 인코딩 방식 등을 포함한 내부 구조는 상호 배타적입니다. 결과적으로 기존 도구들은 교차 벤더 역량이 부족합니다. 즉, 한 벤더를 위해 구축된 파이프라인은 상당한 재설계 없이는 다른 벤더의 데이터를 처리할 수 없습니다. 또한, 생태계는 다음과 같은 "툴체인 마찰(toolchain friction)"을 겪고 있습니다:

• SDK 의존성: 벤더들은 고유한 런타임 환경과 언어적 가정을 가진 독점적인 소프트웨어 개발 키트(SDK)를 제공합니다. 특히 Hesai와 Livox는 프로덕션 수준의 오픈 소스 Python SDK가 없어, 엔지니어들이 커스텀 파서를 직접 작성해야 하는 상황입니다.
• 형식 불일치: 다운스트림 애플리케이션(로보틱스, 머신러닝, 지형정보학)은 PCD, LAS, LAZ, BIN, CSV와 같은 다양한 표준 형식을 요구하며, 이는 여러 단계의 변환 과정을 필요로 합니다.
• 수동 설정: 현재의 워크플로우는 사용자가 적절한 파서를 선택하기 위해 센서 벤더를 수동으로 식별해야 하며, 이는 자동화 또는 배치 처리 시나리오에서 병목 현상을 일으킵니다.

방법론
제안된 시스템은 로우 PCAP 파일을 입력받아 센서 벤더를 자동으로 식별하고, 사용자 개입 없이 데이터를 산업 표준 형식으로 변환하도록 설계된 통합 파이프라인입니다. 아키텍처는 세 개의 계층으로 나뉩니다:

1. 오케스트레이션 계층(Orchestration Layer): 실행 상태를 관리하고 하위 모듈로 입력 파라미터를 전달합니다.

2. 탐지 계층(Detector Layer - 벤더 식별): 이 모듈은 로우 비트스트림(bitstream)에서 직접 벤더를 식별하기 위해 **다중 신호 점수화 메커니즘(multi-signal scoring mechanism)**을 채택합니다. 시스템은 6개의 독립적인 신호를 평가하여 벤더를 결정하기 위한 가중 점수를 할당합니다:

   • 파일 확장자 (0.5): .pcap, .lvx, 또는 .rxp 여부를 확인합니다.
   • 매직 바이트 (3.0): 첫 1,024바이트를 스캔하여 제조사 시그니처(예: Velodyne의 0xFFEE, Ouster의 0x0001)를 찾습니다.
   • 컴패니언 파일 (2.5): 사이드카 메타데이터(예: Ouster의 .json 캘리브레이션 파일)의 존재 여부를 검증합니다.
   • UDP 포트 탐지 (3.5): 가장 높은 가중치를 가진 신호로, 첫 10개의 UDP 패킷에서 목적지 포트를 분석합니다 (예: Velodyne의 2368/2369, Ouster의 7502/7503).
   • 패킷 구조 (3.0): UDP 페이로드의 첫 2바이트를 벤더별 매직 바이트와 대조합니다.
   • 패킷 크기 (2.0): 처음 50개의 페이로드를 샘플링하여 벤더별 특정 크기 범위 내에 있는지 확인합니다.
     누적 점수가 정의된 임계값(2.0)을 초과하면 벤더가 선택되며, 이를 통해 높은 신뢰도를 보장합니다.

3. 변환 계층(Conversion Layer):

   • 베이스 래퍼(Base Wrapper): 핵심 로직을 특정 벤더 구현으로부터 분리하기 위해 표준화된 인터페이스(예: convert_to_las, get_vendor_info)를 강제하는 추상 클래스입니다. 이는 PCD, BIN, CSV로의 직렬화를 처리하며, 폴백 체인(fallback chain)인 laspy 또는 외부 laszip을 통해 LAZ 압축을 관리합니다.
   • 벤더별 래퍼(Vendor-Specific Wrappers):
     • Ouster 및 Velodyne: Python 바인딩이 포함된 네이티브 C++ SDK(ouster-sdk, velodyne-decoder)를 활용합니다. 이는 고처리량을 위해 사전 계산된 룩업 테이블과 내부 C++ 프로세싱을 활용합니다.
     • Hesai 및 Livox: 오픈 소스 C++ SDK가 존재하지 않기 때문에 dpkt 라이브러리를 사용하는 순수 Python 기반 파싱에 의존합니다. Livox의 경우, 시스템에는 Python의 struct 모듈을 사용하는 독점 LVX/LVX2 형식을 위한 커스텀 비트 레벨 파서가 포함되어 있습니다.

주요 기여

• 자동 벤더 탐지: 가중치가 부여된 다중 신호 접근 방식을 통해 로우 패킷 특성으로부터 센서 정체성을 도출함으로써, 수동 벤더 플래그 지정의 필요성을 제거했습니다.
• 통합 다중 형식 출력: 단일 명령으로 로우 PCAP 데이터를 LAS, LAZ, PCD, BIN, CSV의 5가지 표준 형식으로 변환합니다.
• 하이브리드 파싱 아키텍처: 사용 가능한 경우 고성능 C++ SDK(Ouster, Velodyne)를 통합하는 동시에, 오픈 SDK가 없는 벤더(Hesai, Livox)를 위한 기능적인 Python 기반 파서를 하나의 응집된 프레임워크 내에서 제공합니다.
• 소비자급 호환성: 이 파이프라인은 특수 인프라나 복잡한 환경 설정 없이도 표준 하드웨어(Intel Core i3, 8GB RAM에서 테스트됨)에서 실행되도록 설계되었습니다.

결과 및 성능
시스템은 지원되는 4개 벤더의 실제 야외 데이터셋을 통해 평가되었습니다.

• 처리량 격차: C++ 기반 파서와 Python 기반 파서 사이에 상당한 성능 차이가 관찰되었습니다.
  • Ouster: 초당 최대 208만 포인트에 도달했습니다.
  • Velodyne: 초당 최대 147만 포인트에 도달했습니다.
  • Hesai: 초당 약 11만 포인트를 기록했습니다.
  • Livox: 초당 약 15만 포인트를 기록했습니다.
• 효율성 격차: C++ 파서는 Python 기반 파서보다 8~10배 더 높은 처리량을 보여주었습니다. 논문은 이를 Python 레벨의 패킷 디코딩 및 메모리 핸들링의 오버헤드 때문이며, 변환 로직 자체의 문제는 아니라고 설명합니다.
• 확장성: 모든 벤더에서 일관된 변환 완결성을 보였으나, 대규모 작업량(특히 Ouster 및 Hesai)에서 LAS 파일 쓰기 중 발생하는 메모리 압박 및 I/O 오버헤드로 인해 처리량 저하가 관찰되었습니다.
• 신뢰성: 벤더 탐지는 수동 설정 없이 모든 데이터셋에서 성공했으며, 평가 실행 중 파서 오류는 기록되지 않았습니다.

의의
본 논문은 이 시스템을 데이터 수집 단계에서의 "벤더 이질성" 문제를 해결하는 솔루션으로 제시합니다. 벤더 탐지를 자동화하고 출력 형식을 표준화함으로써, 이 파이프라인은 여러 개의 분리된 프로세싱 워크플로우를 유지 관리해야 하는 엔지니어링 오버헤드를 제거합니다. 이를 통해 연구자와 실무자들은 센서 제조사를 사전에 알지 못하더라도 단일화된 통합 툴체인을 사용하여 다양한 벤더의 LiDAR 데이터를 처리할 수 있으며, 이는 다양한 데이터셋 구축을 용이하게 합니다. 저자들은 본 시스템이 로우 데이터 디코딩의 간극을 메우지만, 이미 디코딩된 데이터에 대한 후속 처리를 담당하는 PDAL과 같은 도구의 상위 단계에서 작동한다는 점을 명시하고 있습니다.