Ouster OS0 support?

Hello everyone,
we are looking at updating some of our tools for some of the projects we are doing with 2D lidar to do floor tracking and would like to implement a new layer with 3D lidar tracking. The Ouster seems like a good solution for this, however the documentation specifies that it support the “The TOP currently supports an OS1-64 device using version 1.13 firmware.”. Are there any plans to implement the Ouster OS0? The greater FOV would help us get a better coverage of the room we are currently looking to track.

Thanks!

We are currently doing some fields tests for our OS0 support and expect it to be added to the official version relatively soon. Let me know if you want to try something sooner and I can get you a preview build that will work with the new firmware.

Thanks for the update @robmc , will let you know if we need sooner than the release arrives!

Any updates on this? I am also anticipating using an OS0 in a project relatively soon.

@jesgilbert I’m not sure what the schedule is for the official release at the moment, but I can get you a build anytime you need it.

We are using @robmc’s build with 4x OS0-32s and everything with the TOP is functional thus far. Have been testing for several weeks now and continuing to monitor for issues.

@robmc good to know. Has the current implementation been tested against all OS0 models? I would likely be using the OS0-64.

@dylanroscover that’s great to hear. Are you synchronizing the units via PTP?

@dylanroscover Thanks for the update, glad to hear things are working well.

@jesgilbert I don’t know if anybody has specifically tried the OS0-64, but they all work pretty much the same so I wouldn’t expect any issues. I’ve got a OS0-128 that I’ve been using for testing so I can confirm that it can handle the larger resolutions and bandwidth.

1 Like

@jesgilbert We are not syncing currently but may pursue if tracking accuracy necessitates. (At only 10-20hz frequency the sync accuracy is less of a factor than if it were higher for our particular use case.) On a somewhat related note, we can say the multi-sensor crosstalk resistance works brilliantly.

That’s very good to hear about the crosstalk resistance. Since the sensors themselves can act as PTP master clock we are definitely planning on implementing that as well.

@robmc Is there any update on this being included in a full release? If not, could I get a build that does support the OS0-32 on the v2.0 firmware?

At the moment, it looks like we’re going to keep OS0 support separate until our next major release to avoid breaking things for people who are still running version 1 firmware.

So, in the meantime, you can get the OS0 version here: Dropbox - File Deleted

Let me know if you run into any issues.

@robmc awesome, thanks Rob !

Quick question: When I set the ouster TOP parameter ‘Active’ from On to Off, the panoramic image stays in the TOP view (and subsequently, the Ouster Select view). Is this intended? I would assume that the Ouster TOP should revert back to a blank image.

pic for reference

Yeah, deactivating the node only disables the network connection, but doesn’t clear the data.

No one has brought this up before, but it probably would be more consistent with some of our other nodes to reset everything.

Is this causing you any problems at the moment?

Unfortunately it is. There’s times when it needs to be deactivated in my current patch. I could wire up a switch in the meantime with an empty Constant to achieve the same effect, but it would be nice to have that consistent with other operators.

ok, I’ll look into getting that changed and let you know when there’s an update

I agree with @wooliii, resetting the top data on deactivation would help clarify things quite a bit from a UX standpoint. Otherwise it takes a lot of extra effort to really look at the node data and see whether it’s just a freeze of the last successful frame or actually streaming data.

I’m currently using the 13075 build with the OS0-128 for testing and we’re generally seeing good performance. Our sensor is running firmware 2.1.2.

A few comments/questions:

  • I’ve noticed that periodically TD gets caught in a timeout loop with the sensor when TD is set to configure the OS0 and one of its settings has changed. I’ve had to reboot the sensor in this case several times, which often resolves the issue. I’ve also seen this happen when the network cable is unplugged, but I’ve seen it happen with no apparent cause as well. In this situation the sensor becomes unusable unless the “configure device” parameter is turned off.

  • the OS0 marketing copy describes “pixel-aligned 2D camera images” available in addition to the point cloud stream. Is this something that’s available via the sdk and could potentially be accessed via the Ouster TOP?

  • similarly, Ouster advertised the availability of ambient NIR as a potential output channel of the sensor. I’m not sure if this is currently available in the Ouster TOP?

  • the channel output option “noise” is not documented on Derivative’s doc page - not clear to me what that is?

Thanks for any insight here.

Hey Jesse,

Sorry for the delayed response, I didn’t catch this when it was first posted.

When you say it’s caught in a timeout loop. Is that the message you’re getting on the TOP e.g. “Timeout for command” or is that just the behaviour? Have you checked the web interface when the sensor is in that condition, it can potentially give more detailed error information on the status page.

I believe when it says “pixel-aligned camera image” I think it’s just referring to what we call the “panoramic” image layout. The data is actually received in a staggered pattern based on the position of the lasers around the device, but the sensor provides offset information so that we can reformat the data into a cohesive image. That’s my guess at least since I can’t find any information in the software manual: https://data.ouster.io/downloads/software-user-manual/software-user-manual-v2.1.x.pdf

Regarding noise and NIR fields: it looks like Ouster changed what data was being sent when they updated the firmware and I didn’t catch that when I was doing the update.

In version 1 firmware, the noise field is just described in the manual as “ambient noise photons”, in version 2 firmware, the field is now described as “NIR photons related to natural environmental
illumination”. It sounds like they might be the same thing, but don’t know for sure. I’ll update the docs to clarify that.

Additionally, it looks like in the latest 2.1 firmware they’ve changed the reflectivity field from a 16 bit unsigned value to an 8 bit unsigned “calibrated reflectivity”. Fortunately, I think the TOP should still handle the new values correctly.

Thanks for the detailed response Rob.

The timeout loop is only throwing errors in TD via the TOP message - the web interface is stable and reflects no errors when this is happening.

Your interpretation of the panoramic “pixel aligned” image is probably correct. This was how it was explained to me when I subsequently spoke with Ouster. I believe they’re specifically referring to the optional data channels such as what you’ve described in the NIR field.

There’s a new feature in the 2.1 firmware that would be very good to have in the Ouster TOP as well - “signal multiplier”. This allows you to increase the output power of the lasers when using a portion of the azimuth range for sensing. This can be set from the web interface but I wasn’t able to find anything in the parameters of the TOP.