Open themightyoarfish opened 9 months ago
I don't observe any packet loss in OusterStudio, so It is not a networking issue.
If I use a pcap of the same sensor instead, I also dont see the same behaviour.
Thanks for the report, @themightyoarfish.
Since you are getting the expected results with a PCAP file, It's likely that the SLAM algorithm isn't running fast enough to keep up with the sensor's frame rate.
We're working on an approach that'll give users a way to determine if the sensor is producing frames faster than the SLAM algorithm can process them. I'll keep this ticket open in the meantime and give you an update when we have a solution for you.
Cheers, Tom
Staff Engineer Ouster Inc.
@themightyoarfish
I suspect the OSF writer in-line with SLAM may be hard (OSF writer wasn't yet optimized for such workflows and works sequentially per scan, yeah sorry about that :(
Could you try without -o
option, that should omit the OSF writer completely and juts run kiss-icp underneath + our viz (you will see the TRACK part for sure):
ouster-cli source 169.254.123.241 slam viz
Describe the bug
I am trying to execute the slam functionality in ouster sdk as documented here: https://static.ouster.dev/sdk-docs/cli/mapping-sessions.html#slam
To Reproduce Steps to reproduce the behavior (steps below are just an example):
ouster-cli source 169.254.123.241 slam viz -o sample.osf
Screenshots
Here is a screen recording showing the issue. Sensor is stationary at first, then at some point i move it (around 00:25) and chaos ensues. I have no idea what I am seeing there
https://github.com/ouster-lidar/ouster_example/assets/11613312/0c5fb07e-d227-454e-996e-ba1d75a21091
Platform (please complete the following information):