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…)
Cheers.
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:
Here is the same scene in Ouster Studio:
Windows 10 Pro 22H2
TD 2022.33910
OS0-128, FW 2.5.1
Ouster Studio v2.0.0.0
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.
Thanks Rob, this is great news, I’ll be testing it out in short order.
I’ve done a test run and have the following feedback:
Connection:
Lidar Port defaults to 0, should be 7502
IMU Port defaults to 0, should be 7503, when configuring it becomes 3 or 4 in the Ouster Config, a port number bound to fail to comunicate in many systems.
Lidar Mode defaults to LEGACY, should be RNG19_RFL8_SIG16_NIR16.
Disabling “Configure Device” still configures the device when hitting “Re-Init”, particularly the Timing options are overridden with wrong defaults.
Hitting Re-Init sometimes does not work, especially after a configuration change takes place outside of TD. One has to Cut + Paste the OP for it to be configured again.
Azimuth Window settings have the following behavior:
azimuthwindow1 parameter is lost
azimuthwindow2 becomes the the left field in the Ouster config
The right field in the Ouster config then becomes 1
UDP Profiles:
Timing settings:
NMEA Ignore Valid Char defaults to On, should default to Off
Sync Pulse In Polarity defaults to ACTIVE_LOW, should default to ACTIVE_HIGH
Sync Pulse Out Polarity same issue
Sync Out Pulse Angle defaults to 1, should be 360
Sync Out Pulse Width defaults to 1, should be 10
In general, there seems to be a mismatch between parameter settings and the config that is applied.
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.
Thanks Rob, here’s a follow-up:
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:
Maybe this is an SDK shenanigan.
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.
Right.
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.
From the web interface:
The previous SDK did not mess with these settings, BTW.
Thanks again. This is a bit of a back burner project at the moment, but I will look into these and let you know when there is another update you can try (probably in the next week or two).
Understood, looking forward to a revised version, but this build is already usable (so far). Thanks.
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.
Thanks. Sadly I can’t test it because, even though it is versioned as 2022.x, it’s rejecting my license that stopped receiving updates in September 2023.
Sorry about that, the license update period is tied to the calendar date it was purchased rather than for a specific product version and I can’t backdate a release.
