Open 99andreas opened 8 months ago
Thanks for the report @99andreas.
As far as I'm aware, there's no technical issue that prevents storing the 8-bit reflectivity values coming from the sensor's UDP packet stream into the 16-bit reflectivity channel in LidarScan
objects. Are you seeing incorrect values when accessing reflectivity via LidarScan
? If so, could you please provide a minimum reproducible example?
I should mention that the fact that they are differently sized fields shouldn't be a problem in and of itself: values from packets are casted to the appropriate types and assigned to scans on a per-pixel basis. Please refer to the packet_format::block_field
and packet_format::col_field
methods for more info about how this is done.
This said, there are known issues the low-bandwidth profile in 0.9.0 that will be addressed in the upcoming 0.10.0 release.
I hope this addresses your concerns. Please let me know if there are any questions.
Best Regards, Tom
Staff Engineer Ouster Inc.
Hi Tom and thanks for your swift response. I just want to confirm that treating it as a 16 bit works fine. BTW, it would be nice with some sort of "known issues and workarounds" information somewhere.
@99andreas that's a great suggestion. Going forward we'll work toward including more information about known issues into the documentation.
Best Regards, Tom
Staff Engineer Ouster Inc.
Ouster SDK v0.9.0:
The size of Reflectivity for Single Return Profile is 8 bits according to specification but is implemented as 16 bits in the C++ SDK (https://github.com/ouster-lidar/ouster_example/blob/master/ouster_client/src/lidar_scan.cpp#L70). This means that it is impossible to read correct Reflectivity from a lidar in Sigle Return Profile with the C++ SDK.
Since Single Return Profile is becoming the new default profile when Legacy is not supported anymore, this should probably have a high priority (a patch release 0.9.1?). Also I guess there is some test code missing that should have cought this bug earlier.