Lidar Packet Format Update
Starting in firmware v2.0.0, all sensors with the same number of channels have the same data structure and same maximum data rate. Prior to v2.0.0, all sensors, regardless of their number of channels, had the same data rate.
If you have either a Gen 1 OS1-16 or Gen 1 OS1-32, upon upgrading to firmware v2.0.0, you will see a drop in data rate. Please refer to the diagram below for a visualization of lidar packet structure.
Prior to v2.0.0, all sensors, regardless of number of channels, had a fixed number of data blocks in their lidar packets. In v2.0.0, the number of data blocks in a sensor’s Measurement Block is equal to the number of channels it has. Customers with Gen 1 OS1-16 or Gen 1 OS1-32 will see a 75% and 50% respective drop in data rate due to unused data blocks being omitted from the sensor output.
These customers will also see a change in the output of the TCP command
get_beam_intrinsics. Previously, the
beam_altitude_angles output array was padded with zeros so that they were always of length 64, regardless of the number of channels in that sensor. Now, the padded zeros are dropped so that the lengths of both arrays are equal to number of channel in the sensor e.g. all 32-channel sensors will have
beam_altitude_angles output arrays of length 32 on v2.0.0 and beyond.
The TCP command
get_lidar_data_format can also be useful in interpreting the lidar data format structure:
columns_per_frame: Number of data columns per frame. This can be 512, 1024, or 2048, depending upon the set lidar mode.
columns_per_packet: Number of Measurement Blocks contained in a single lidar packet. In v2.0.0 and earlier, this is 16.
pixel_shift_by_row: Offset in terms of pixel count. Can be used to destagger image. Varies by lidar mode. Length of this array is equal to the number of channels of the sensor.
pixels_per_column: Number of channels of the sensor.
column_window: Indices of active columns of data in the sensor. These bounds will change when a custom azimuth window is used.