Thanks for the details. I’ll see if I can reproduce the timeout issue with the sensor I have here.
I noticed the new signal multiplier feature when I was just reviewing the docs. Our update is based on the the 2.0 firmware so it doesn’t have that option at the moment, but I’ll checkout what would be involved in adding it.
I’ve got a new Ouster build if anybody wants to try it out. This version is based on our recent 2021.15020 release and also adds the following new Ouster features:
compatibility with Ouster’s new 2.1 firmware
support for ‘Signal Multiplier’ for sensors with 2.1 firmware
new ‘Skip Partial Frames’ option will discard frames that weren’t completely received (usually due to network issues)
Ouster TOP will now revert to a blank texture when deactivated
Fixed missing/skipped packet stats when using a smaller azimuth window (previously the parts outside the window would count as missed packets)
Increased networking timeout to avoid errors when the sensor is slow to respond
Thanks Rob - this version seems a lot more stable in communicating with the OS0 when “configure device” is active. I’m not seeing any of the timeout issues I was observing previously.
I understand the reasoning for outputting a “blank” texture when the TOP is deactivated, but I actually found it convenient to hold the last frame so I could examine the point cloud from a variety of angles. Maybe this could be a parameter choice?
I have a question regarding the IMU data - I’m able to access this via an Info CHOP but the data feed seems odd. I have the sensor mounted in a static position on a tripod and I’m getting pretty wide variation on what I assume are the IMU-related channels (accel and vel).
I’m also noticing that selecting a partial azimuth window generates a panoramic image that (counter-intuitively) seems to write data from right to left. Is this intentional?
This can be seen pretty clearly in the example below:
Thanks for the feedback, and glad to here timeout errors have improved. I couldn’t reproduce it quite as you described, but my suspicion is that TouchDesigner wasn’t giving the sensor enough time to catch up with some of the commands, so I extended the timeout period quite a bit.
I’ll make the blank texture on deactivate an option - it was something I had already been wondering about.
As far as the IMU data, I have always found the data to be quite noisy on the sensor I have, but I’ll double check everything tomorrow.
I’ll take another look at the azimuth window as well. I’m currently just filling the data in the same order that the sensor always sends it in.
Regarding the azimuth window, confusingly the Ouster sensors do their scan order clockwise starting at the cable, but measure the angle for the azimuth window counter-clockwise when looking down on the sensor. There’s more information about it in the manual here: https://data.ouster.io/downloads/software-user-manual/software-user-manual-v2.1.x.pdf around page 14
I also experimented a little more with the IMU and things seem to be working well on my end … it does look really noisy at rest, but that’s because the CHOP viewer is scaling the data. If you tilt the scanner around you can pretty clearly see swings as gravity affects the different axes. The acceleration is in m/s*s which is why the accel_ty sits around 9.8. The angular velocity values can get quite high because its in degrees/sec, so the default values of +/- 2 deg/sec is just signal noise.
Hope that helps. Let me know if you have any more questions.
Today I received the OS0-128 that we’ll be using for our project, and I’m seeing issues trying to interface with it, both using the custom build 2021.15232 and the current production release of TD. The sensor shipped with firmware 2.2 - I’m wondering if something has changed?
The Ouster TOP reports RUNNING status but I’m not getting any visible output. I have tested with Ouster’s Studio software and the sensor is working there as expected.
I’ve been doing some experiments, but so far haven’t been able to reproduce your problem. I updated to the latest 2.2.1 firmware from the website and ran it in both the 15232 build as well as the latest 2022 experimental release and everything seemed to be working ok. Note, the official 2021 production release only supports sensors that are still running version 1 firmware.
To help debug things, are you able to configure the sensor i.e. does changing the resolution or other settings set the sensor to ‘initializing’ state? Do you see the packets incrementing if you attach an info chop?
Thanks for taking a look, and sorry for the trouble - in checking today the data seems to be arriving in TD as expected. The only thing that’s changed is that I updated my TD license this morning - without that I wasn’t able to launch 2022 experimental. I don’t think that should have been issue with 15232, but it wasn’t working across several restarts…
So we can plan our development, will the Ouster 2.x firmware be supported in upcoming official releases?
The next official release that will include Ouster 2 support will be when the current 2022 experimental series becomes official. I don’t have an exact date on that, but it’s relatively soon.
We’re not planning to add ouster 2 support back to the official 2021 release just because it will break things for anybody that was using that release with version 1 sensors. If you need to stick with the 2021 release, I can get you another custom build that includes any changes since 15232
@robmc Hello there! Currently working on a project, and we are using 2021.16410. Would it be possible to get a build with Ouster 2 support that incorporates everything in 16410? Would be greatly appreciated, for our project we just received our new OS-0 device, but we were not aware of this lack of support in the current production release! Thank you so much.
The 2022 release is pretty close to going production, but I can get an updated 2021 release ready if you need to stick with that version. I’ll post a link here when it’s ready.
The latest 2021 build + Ouster v2 would be amazing, if you could provide!!!
We are fairly well along in development, we could potentially try to update to 2022 when it releases… time allowing.
Yes, the 2022 builds do support fully support the new Ouster sensors.
Note: if you’re running version 2.4+ of the Ouster firmware then you’ll need at least version 2022.29530 of TouchDesigner because Ouster added some features that were not backwards compatible.