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

Resumen Técnico: Un Sistema de Conversión de Datos LiDAR Independiente del Proveedor con Detección de Señales Múltiples y Salida de Formatos Múltiples

Declaración del Problema
El artículo aborda la fragmentación inherente al procesamiento de datos LiDAR brutos de diferentes fabricantes (específicamente Ouster, Velodyne, Hesai y Livox). Aunque estos sensores emiten datos en archivos PCAP (Captura de Paquetes), sus estructuras internas —incluyendo las convenciones de puertos UDP, los diseños de paquetes, los bytes mágicos y los esquemas de codificación— son mutuamente excluyentes. En consecuencia, las herramientas existentes carecen de capacidad multiplproveedor; un flujo de trabajo diseñado para un proveedor no puede procesar datos de otro sin una reingeniería significativa. Además, el ecosistema sufre de "fricción en la cadena de herramientas":

• Dependencias de SDK: Los proveedores proporcionan Kits de Desarrollo de Software (SDK) propietarios con entornos de ejecución y supuestos de lenguaje únicos. Notablemente, Hesai y Livox carecen de SDK de Python de grado de producción y código abierto, lo que obliga a los ingenieros a escribir analizadores (parsers) personalizados.
• Incompatibilidad de Formatos: Las aplicaciones descendentes (robótica, aprendizaje automático, geomática) requieren diversos formatos estándar (PCD, LAS, LAZ, BIN, CSV), lo que necesita múltiples pasos de conversión.
• Configuración Manual: Los flujos de trabajo actuales requieren que los usuarios identifiquen manualmente el fabricante del sensor antes de seleccionar el analizador apropiado, lo que crea un cuello de botella en escenarios de procesamiento automatizados o por lotes.

Metodología
El sistema propuesto es un flujo de trabajo unificado diseñado para ingerir archivos PCAP brutos, identificar automáticamente el fabricante del sensor y convertir los datos en formatos estándar de la industria sin intervención del usuario. La arquitectura se divide en tres capas:

1. Capa de Orquestación: Gestiona el estado de ejecución y pasa los parámetros de entrada a los módulos descendentes.

2. Capa de Detección (Identificación del Proveedor): Este módulo emplea un mecanismo de puntuación de señales múltiples para identificar al fabricante directamente desde el flujo de bits bruto. Evalúa seis señales independientes, asignando puntuaciones ponderadas para determinar el sensor de origen:

   • Extensión de Archivo (0.5): Verifica si son .pcap, .lvx o .rxp.
   • Bytes Mágicos (3.0): Escanea los primeros 1,024 bytes en busca de firmas del fabricante (por ejemplo, 0xFFEE para Velodyne, 0x0001 para Ouster).
   • Archivos Compañeros (2.5): Valida la presencia de metadatos adjuntos (por ejemplo, los archivos de calibración .json de Ouster).
   • Detección de Puerto UDP (3.5): La señal con mayor peso, que analiza los puertos de destino en los primeros 10 paquetes UDP (por ejemplo, 2368/2369 para Velodyne, 7502/7503 para Ouster).
   • Estructura de Paquete (3.0): Compara los primeros 2 bytes de la carga útil (payload) UDP contra los bytes mágicos específicos del fabricante.
   • Tamaño de Paquete (2.0): Muestrea las primeras 50 cargas útiles para verificar si caen dentro de los rangos de tamaño específicos del fabricante.
     Un fabricante se selecciona si su puntuación acumulada supera un umbral definido (2.0), asegurando una alta confianza.

3. Capa de Conversión:

   • Envoltorio Base (Base Wrapper): Una clase abstracta que impone una interfaz estandarizada (por ejemplo, convert_to_las, get_vendor_info) para desacoplar la lógica central de las implementaciones específicas del proveedor. Gestiona la serialización a PCD, BIN y CSV, y administra la compresión LAZ mediante una cadena de fallback (laspy o laszip externo).
   • Envoltorios Específicos del Proveedor:
     • Ouster y Velodyne: Utilizan SDK de C++ nativos (ouster-sdk, velodyne-decoder) con enlaces (bindings) de Python. Estos aprovechan tablas de búsqueda precomputadas y procesamiento interno en C++ para un alto rendimiento.
     • Hesai y Livox: Dependen de un análisis basado puramente en Python utilizando la biblioteca dpkt, ya que no existen SDK de C++ de código abierto disponibles. Para Livox, el sistema también incluye un analizador de nivel de bits personalizado para los formatos propietarios LVX/LVX2 utilizando el módulo struct de Python.

Contribuciones Clave

• Detección Automática de Proveedores: El sistema elimina la necesidad de indicadores manuales de proveedor al derivar la identidad del sensor a partir de las características de los paquetes brutos mediante un enfoque de puntuación de señales múltiples ponderadas.
• Salida Multi-Formato Unificada: Un solo comando convierte datos PCAP brutos en cinco formatos estándar: LAS, LAZ, PCD, BIN y CSV.
• Arquitectura de Análisis Híbrida: El sistema integra SDK de alto rendimiento en C++ donde están disponibles (Ouster, Velodyne), mientras proporciona analizadores funcionales basados en Python para los proveedores que carecen de SDK abiertos, todo dentro de un único marco cohesivo.
• Compatibilidad de Grado de Consumo: El flujo de trabajo está diseñado para ejecutarse en hardware estándar (probado en un Intel Core i3 con 8GB de RAM) sin requerir infraestructura especializada o configuraciones de entorno complejas.

Resultados y Rendimiento
El sistema fue evaluado con conjuntos de datos reales en exteriores de todos los cuatro proveedores soportados.

• Disparidad de Rendimiento (Throughput): Se observó una brecha de rendimiento significativa entre los analizadores respaldados por C++ y los basados en Python.
  • Ouster: Alcanzó un máximo de 2.08 millones de puntos/segundo.
  • Velodyne: Alcanzó un máximo de 1.47 millones de puntos/segundo.
  • Hesai: Promedió aproximadamente 110,000 puntos/segundo.
  • Livox: Promedió aproximadamente 150,000 puntos/segundo.
• Brecha de Eficiencia: Los analizadores de C++ demostraron un rendimiento 8–10× mayor en comparación con los analizadores de Python. El artículo atribuye esto a la sobrecarga del decodificado de paquetes a nivel de Python y el manejo de memoria, más que a la lógica de conversión en sí misma.
• Escalabilidad: Aunque todos los proveedores mostraron una completitud de conversión consistente, se observó una degradación del rendimiento en cargas de trabajo más grandes, particularmente para Ouster y Hesai, debido al aumento de la presión de memoria y la sobrecarga de E/S durante la escritura de archivos LAS.
• Fiabilidad: La detección de proveedores tuvo éxito en todos los conjuntos de datos sin configuración manual, y no se registraron fallos en los analizadores durante las ejecuciones de evaluación.

Significado
El artículo posiciona este sistema como una solución al problema de la "heterogeneidad de proveedores" en la etapa de ingestión de datos. Al automatizar la detección del proveedor y estandarizar el formato de salida, el flujo de trabajo elimina la sobrecarga de ingeniería de mantener múltiples procesos de procesamiento desconectados. Permite a investigadores y profesionales procesar datos LiDAR de múltiples proveedores utilizando una única herramienta unificada, facilitando la creación de diversos conjuntos de datos para entrenamiento y mapeo sin conocimiento previo del fabricante del sensor. Los autores señalan que, si bien el sistema cierra la brecha en la decodificación de datos brutos, opera aguas arriba de herramientas como PDAL, que gestionan el procesamiento posterior sobre los datos ya decodificados.