Support Different Packet Formats

[vinnnyr]

Firmware 2.3 allowed for the ability to request different data packet formats from the sensor. [1]. The Low Data Rate profile might help with robots with limited compute / network bandwidth [2].

Looks like the ouster_example repo added a configurable UDPProfile for this [3]

1. https://ouster.com/blog/firmware-2-3-lower-data-rates-and-new-sensor-telemetry/
2. Section 6 (page 26): https://data.ouster.io/downloads/software-user-manual/firmware-user-manual-v2.3.0.pdf
3. https://github.com/ouster-lidar/ouster_example/blob/64a6cbe6dff1eea0cb5a79d63b79acf11b68b16d/ouster_client/include/ouster/types.h#L161

Where is the best place to implement this for this driver?

[vinnnyr]

I think the driver would already handle getting the correct packet format, since it seems like everything is based on the underlying Ouster library getPacketFormat

ros2_ouster_drivers/ros2_ouster/src/sensor.cpp

Line 157 in 2d36cbd

ouster::sensor::packet_format Sensor::getPacketFormat()

And that is called everytime the driver readLidarPacket

ros2_ouster_drivers/ros2_ouster/src/sensor.cpp

Line 115 in 593dc2b

uint8_t * Sensor::readLidarPacket(const ouster::sensor::client_state & state)

I would have to set the low data profile manually, and see if that is right 🤔

[vinnnyr]

on a similar note, when trying to apply dual return packet mode, it seems like this breaks the driver. I get the following log spammed:

[ouster_driver-1] Unexpected udp packet length: 6465

[vinnnyr]

I was wrong -- I think I got confused here and thought the repo was pulling in ouster_examples - - this is not the case.
We would have to add packet support here in this repo.

I think the driver would already handle getting the correct packet format, since it seems like everything is based on the underlying Ouster library getPacketFormat

ros2_ouster_drivers/ros2_ouster/src/sensor.cpp

Line 157 in 2d36cbd

ouster::sensor::packet_format Sensor::getPacketFormat()

And that is called everytime the driver readLidarPacket

ros2_ouster_drivers/ros2_ouster/src/sensor.cpp

Line 115 in 593dc2b

uint8_t * Sensor::readLidarPacket(const ouster::sensor::client_state & state)

I would have to set the low data profile manually, and see if that is right thinking

[SteveMacenski]

If its a direct copy over from ouster_example we can do that, that's basically what we do right now because the ouster SDK is source controlled with the ROS 1 drivers and not actually released into a binary format we can use here to share between them (hence, the unfortunate copy paste)

[Grisly00]

Hi!
Is there any plans on when this feature will be available? We would really like to test the dual return mode of the new lidars.
thx

[vinnnyr]

i'm not actively working on this at the moment -- i'm not sure if anyone else is.

[vinnnyr]

@SteveMacenski can you explain a bit what the process is to copy over from the ouster_example repo? I might just be missing something, but I don't really see a clear copy paste from the other repo.

I ask because if I can get some tips on how to do that, we could probably resolve both this issue and #116 in one go.

[SteveMacenski]

A matched set of header files that works for a paired version of the Ouster lidar firmware versions. Since Ouster isn't careful about backward compatibility, once we release a version of this software to a ROS distribution, it has to continue to work for whatever firmware versions for the life of that distribution. As a result, you cannot upgrade your sensor's firmware and use this driver on a given ROS 2 distribution unless its backward compatible to work with that same version of the ouster sdk given via ouster_example.

Once there's a paired version, really it is just copy pasting over and updating any API changes for the high-levels required and updating the documentation about what version of the SDK / firmware pairings this supports.