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

Resumo Técnico: Um Sistema de Conversão de Dados LiDAR Independente de Fornecedor com Detecção de Múltiplos Sinais e Saída de Múltiplos Formatos

Definição do Problema
O artigo aborda a fragmentação inerente ao processamento de dados brutos de LiDAR de diferentes fabricantes (especificamente Ouster, Velodyne, Hesai e Livox). Embora esses sensores emitam dados em arquivos PCAP (Packet Capture), suas estruturas internas — incluindo convenções de portas UDP, layouts de pacotes, bytes mágicos e esquemas de codificação — são mutuamente exclusivas. Consequentemente, as ferramentas existentes carecem de capacidade cross-vendor; um pipeline construído para um fornecedor não pode processar dados de outro sem uma reengenharia significativa. Além disso, o ecossistema sofre de "fricção de toolchain":

• Dependências de SDK: Os fornecedores disponibilizam Kits de Desenvolvimento de Software (SDKs) proprietários com ambientes de execução e suposições de linguagem únicos. Notavelmente, a Hesai e a Livox carecem de SDKs Python de nível de produção e código aberto, forçando engenheiros a escrever parsers customizados.
• Incompatibilidade de Formato: Aplicações downstream (robótica, aprendizado de máquina, geomática) exigem diversos formatos padrão (PCD, LAS, LAZ, BIN, CSV), necessitando de múltiplas etapas de conversão.
• Configuração Manual: Os fluxos de trabalho atuais exigem que os usuários identifiquem manualmente o fabricante do sensor antes de selecionar o parser apropriado, criando um gargalo em cenários de processamento automatizado ou em lote.

Metodologia
O sistema proposto é um pipeline unificado projetado para ingerir arquivos PCAP brutos, identificar automaticamente o fabricante do sensor e converter os dados em formatos padrão da indústria sem intervenção do usuário. A arquitetura é dividida em três camadas:

1. Camada de Orquestração: Gerencia o estado de execução e passa os parâmetros de entrada para os módulos subsequentes.

2. Camada de Detecção (Identificação de Fornecedor): Este módulo emprega um mecanismo de pontuação de múltiplos sinais para identificar o fornecedor diretamente do bitstream bruto. Ele avalia seis sinais independentes, atribuindo pontuações ponderadas para determinar a origem do sensor:

   • Extensão de Arquivo (0.5): Verifica por .pcap, .lvx ou .rxp.
   • Bytes Mágicos (3.0): Escaneia os primeiros 1.024 bytes em busca de assinaturas do fabricante (ex: 0xFFEE para Velodyne, 0x0001 para Ouster).
   • Arquivos Companheiros (2.5): Valida a presença de metadados acessórios (ex: arquivos de calibração .json da Ouster).
   • Detecção de Porta UDP (3.5): O sinal de maior peso, analisando portas de destino nos primeiros 10 pacotes UDP (ex: 2368/2369 para Velodyne, 7502/7503 para Ouster).
   • Estrutura de Pacote (3.0): Correlaciona os primeiros 2 bytes do payload UDP com bytes mágicos específicos do fornecedor.
   • Tamanho do Pacote (2.0): Amostra os primeiros 50 payloads para verificar se eles se enquadram nas faixas de tamanho específicas do fornecedor.
     Um fornecedor é selecionado se sua pontuação cumulativa exceder um limiar definido (2.0), garantindo alta confiança.

3. Camada de Conversão:

   • Wrapper Base: Uma classe abstrata que impõe uma interface padronizada (ex: convert_to_las, get_vendor_info) para desacoplar a lógica central das implementações específicas de cada fornecedor. Ela lida com a serialização para PCD, BIN e CSV, e gerencia a compressão LAZ via uma cadeia de fallback (laspy ou laszip externo).
   • Wrappers Específicos de Fornecedor:
     • Ouster & Velodyne: Utilizam SDKs nativos em C++ (ouster-sdk, velodyne-decoder) com bindings para Python. Estes aproveitam tabelas de consulta pré-computadas e processamento interno em C++ para alta vazão.
     • Hesai & Livox: Dependem de parsing puramente baseado em Python usando a biblioteca dpkt, uma vez que não existem SDKs C++ de código aberto disponíveis. Para a Livox, o sistema também inclui um parser de nível de bit customizado para formatos proprietários LVX/LVX2 usando o módulo struct do Python.

Principais Contribuições

• Detecção Automática de Fornecedor: O sistema elimina a necessidade de flags manuais de fornecedor ao derivar a identidade do sensor a partir de características de pacotes brutos usando uma abordagem de múltiplos sinais ponderados.
• Saída Multi-Formato Unificada: Um único comando converte dados PCAP brutos em cinco formatos padrão: LAS, LAZ, PCD, BIN e CSV.
• Arquitetura de Parsing Híbrida: O sistema integra SDKs de alto desempenho em C++ onde disponíveis (Ouster, Velodyne), enquanto fornece parsers funcionais baseados em Python para fornecedores que carecem de SDKs abertos (Hesai, Livox), tudo dentro de um único framework coeso.
• Compatibilidade de Nível de Consumo: O pipeline foi projetado para rodar em hardware padrão (testado em um Intel Core i3 com 8GB de RAM) sem exigir infraestrutura especializada ou configurações de ambiente complexas.

Resultados e Desempenho
O sistema foi avaliado em datasets reais externos de todos os quatro fornecedores suportados.

• Disparidade de Vazão (Throughput): Uma lacuna significativa de desempenho foi observada entre os parsers baseados em C++ e os baseados em Python.
  • Ouster: Atingiu o pico de 2.08 milhões de pontos/segundo.
  • Velodyne: Atingiu o pico de 1.47 milhões de pontos/segundo.
  • Hesai: Média de aproximadamente 110.000 pontos/segundo.
  • Livox: Média de aproximadamente 150.000 pontos/segundo.
• Lacuna de Eficiência: Os parsers em C++ demonstraram uma vazão 8–10× maior do que os parsers baseados em Python. O artigo atribui isso ao overhead de decodificação de pacotes em nível de Python e ao gerenciamento de memória, em vez da lógica de conversão em si.
• Escalabilidade: Embora todos os fornecedores tenham mostrado completude de conversão consistente, observou-se degradação de vazão em cargas de trabalho maiores, particularmente para Ouster e Hesai, devido ao aumento da pressão de memória e overhead de I/O durante a escrita de arquivos LAS.
• Confiabilidade: A detecção de fornecedor teve sucesso em todos os datasets sem configuração manual, e nenhum erro de parser foi registrado durante as execuções de avaliação.

Significância
O artigo posiciona este sistema como uma solução para o problema da "heterogeneidade de fornecedores" na etapa de ingestão de dados. Ao automatizar a detecção de fornecedor e padronizar o formato de saída, o pipeline remove o overhead de engenharia de manter múltiplos fluxos de processamento desconectados. Ele permite que pesquisadores e profissionais processem dados de LiDAR de múltiplos fornecedores usando uma ferramenta única e unificada, facilitando a criação de datasets diversos para treinamento e mapeamento sem conhecimento prévio do fabricante do sensor. Os autores observam que, embora o sistema preencha a lacuna na decodificação de dados brutos, ele opera upstream de ferramentas como o PDAL, que lidam com o processamento subsequente em dados já decodificados.