Hey all, recent Rev 06 sensors come with FW 2.5.1 which throw a bunch of deprecation warnings for both TCP socket config that TD uses (superseded by HTTP API) and the ‘LEGACY’ UDP profile that TD requires for LIDAR data. RFE is to support the HTTP api for configuration and the API suggested UDP profiles (RNG19_RFL8_SIG16_NIR16, etc…)
To add to this, even in legacy mode, Rev6 Sensors with FW 2.5.1 seem to be incompatible with Ouster TOP in TD 2022.33910, and rolling back to older FW revisions (against Ouster’s best practices) does not seem to solve the issue.
Here is the point cloud for positional data in TD:
Sorry for not responding to this sooner. You’re right that Ouster is deprecating the interface that we’ve been using since their original prototypes. Unfortunately, this means that updating our node has been a much bigger project than it usually would be for a smaller firmware update. We do actually have a work in progress that you’re welcome to try out. It’s been almost completely rewritten internally to use Ouster’s c++ SDK so it supports any of the 2.0+ and 3.0+ firmware as well as the new dome sensors.
It hasn’t been well tested yet and is still missing some features, so let me know if you have any feedback. The big change you may notice from the old version is that you need to manually re-initialize the sensor after you make any settings changes.
Thank you for all of the feedback. Answers to specific questions below:
The port number defaults to zero as defined in the updated Ouster SDK. In this mode, the sensor is supposed to automatically select a port number. I’m surprised it went with 3 or 4 in your case, but I’m not sure how their system works. I’ll look into it further.
I eventually want to add a menu to select the data format, but we went with legacy by default for now for backwards compatibility. There are a lot more potential field options defined in the SDK, so I’m not sure yet whether we’re going to try and populate the field lists dynamically based on what is returned by the sensor or just return errors when the selected field isn’t available (this can happen now).
I agree this is a little confusing at the moment. In the Ouster SDK there are some settings that are always set when connecting to the sensor and some that are set in a separate configuration call. This toggle just disables the configuration call, but a few things like timing and resolution will always get set anyways. There is no longer a purely passive mode like the old node where it just listens to the incoming data since the Ouster SDK doesn’t function that way. I’ll likely remove that ‘Configure’ parameter in a future update since I think it causes more confusion than it provides usefulness.
I’ll do some more testing on this one. It definitely won’t do anything if it is already in a re-initialization phase.
I’ll look into this one. I do recall finding an issue with the azimuth window parameter, but I don’t recall if it was fixed yet.
As mentioned above, other data formats are not supported yet.
Where are you getting the default settings from? I don’t see anything in the SDK that clearly indicates default values, so we’ve been using the same values we’ve had in the node since the beginning.
That’s interesting, however, I was trying to use the previous defaults (7502, 7503) in the config dialog and it still overrides the IMU port config:
The IMU data seems to reach this machine without issue but I would not expect the same in a managed network or a different OS.
When using the new defaults (0, 0), the UDP Lidar port is chosen from a traditional range pool but the IMU is not:
This sounds good, I’d rather have an error / warning thrown or the channel data default to 0 (or some other value) instead of a crash when failing to unpack unsupported formats, could this be expected in a future build? Right now the positional data is usable because the range data is unpacked correctly. Also, it is unclear when the LEGACY profile will be fully deprecated.
Yeah, I had checked that the sensor was already re-initialized and in the RUNNING state using the web dashboard.
This would be helpful, a proper azimuth window can extend the life of the emitter in a permanent installation.
Sorry, it took a lot longer to get back to this project than expected, but I’ve got another experimental build that you’re welcome to test. It fixes a memory bug that was corrupting the settings which accounted for a lot of the issues you were seeing. It also adds support for the different data formats.
Our plan is to officially release this in our 2023 version at some point.