Replicating VeloView's frame subdivision logic, resulting in numerous small frames
I'm working on a custom app that decodes a data stream (PCAP or UDP packets) and I'm struggling to replicate VeloView's frame subdivision logic. The documentation for VelodynePlugin's interpreter is non-existent, so I decided to reverse engineering LidarView's code. In particular, I'm looking at vtkLidarReader::GetFrame
and PacketConsumer::HandleSensorData
, and it seems that different logic is used for reading from a PCAP file versus reading from a streaming source.
In file reading, all the packets contained in the file are read and processed by PreProcessPacketWrapped
, which generates a vector of FrameInformation
. When the end of file is reached, the function vtkLidarReader::GetFrame
uses the FrameInformation
in ProcessPacketWrapped
to properly decode each frame.
Instead, when streaming, it directly calls ProcessPacketWrapped
for each packet and adds the last decoded frame to the frame buffer when IsNewFrameAvailable
is true.
However, when I tried to replicate the streaming logic, I ended up with numerous small frames. After debugging, I suspect that certain packets with old firing data or non-progressive azimuth or value restarting from 0 are causing the interpreter to prematurely end the current frame.
I believe there must be additional framing subdivision logic that I'm missing. Can someone guide me on the correct functions to call in order to properly decode frames when reading from a stream of UDP packets?
Details:
Sensor -> HDL-32E
OS -> Ubuntu 22.04 x64
Version -> VeloView 5.1.0 Ubuntu 18.04-x86_64