Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LaserScan is slightly rotated and not aligned with point cloud #88

Open
CollinNHays opened this issue Nov 5, 2021 · 16 comments
Open

LaserScan is slightly rotated and not aligned with point cloud #88

CollinNHays opened this issue Nov 5, 2021 · 16 comments

Comments

@CollinNHays
Copy link

CollinNHays commented Nov 5, 2021

When viewing the /scan and /points topic from this driver in RViz it appears the LaserScan is rotated ~10 degrees counter clockwise relative to the PointCloud which is correctly oriented.

Green is the 2DLaserScan and purple is the 3dPointCloud.

For now the PointCloud to LaserScan node works correctly.

Ouster alignment

Using an Ouster OS0-128 @512x10 Rev D fw 2.1.3

@SteveMacenski
Copy link
Member

SteveMacenski commented Nov 8, 2021

Are you sure that those are from the same iteration? In ROS 2, messages would be being dropped and since these are from different subscriptions and latency is proportional to size (and 128 beam will be HUGE), they could be representing messages from different rotations / iterations. Please verify these are actually represented from the same pointcloud packet messages. I don't see this on my end, but that doesn't mean there isn't necessarily an issue.

@bertaveira
Copy link
Contributor

bertaveira commented Jan 21, 2022

I can confirm that this also happens to me. I don't really depend on it but thought would share as well

image

@SteveMacenski
Copy link
Member

Are you sure that those are from the same iteration?

Still applies. ROS 2 can be slow if not used in concert with composition, so just want to make sure that indeed these are representing the same piece of data. Please check

The issue you just uncovered in #90 could also be a problem, since that would offset everything by 1 tick incorrectly.

If one of these are mispopulated (

msg.scan_time = 1.0 / ouster::sensor::frequency_of_lidar_mode(mdata.mode);
msg.time_increment = 1.0 / ouster::sensor::frequency_of_lidar_mode(mdata.mode) /
ouster::sensor::n_cols_of_lidar_mode(mdata.mode);
msg.angle_increment = 2 * M_PI / ouster::sensor::n_cols_of_lidar_mode(mdata.mode);
) or incorrect from the metadata, that could also contribute to drift (also new to FW 2.0).

@bertaveira
Copy link
Contributor

The LiDAR and the world around it are both stationary so delay is not in question I think. Might have something to do with the other issue indeed.

@SteveMacenski
Copy link
Member

SteveMacenski commented Jan 21, 2022

Does it change (vibrate, get worse, etc) over consecutive scans or is it consistently off by exactly that amount every time?

If it vibrates / changes, then its probably a time increment issue. If its constant, its probably the angle increment issue.

@bertaveira
Copy link
Contributor

Yes it is static angle deviation.

I placed the lidar against a wall of a squared room to check whether it was the pointcloud or the laser scan to blame. It appear to be a problem in the laser scan since the corner should be aligned with the x and y axis of the scene:

Screenshot 2022-01-22 at 00 30 25

I will try to see if I can fix it along with the #90

@bertaveira
Copy link
Contributor

I don't understand why it is not aligned but rotating 10 increments seems to fix it:

image

image

@SteveMacenski
Copy link
Member

That is bizarre. Is that consistent between different operating modes (e.g. resolutions / frequencies)? If so, we can add that statically for now while I poke Ouster folks. If not, its probably actually related to another piece of the laser scan data that this happens to be the function that describes for this particular operating mode. Which mode are you using?

@CollinNHays
Copy link
Author

This is consistent between operating modes and agree it's static angle offset.
Some screenshots to compare taken with everything sitting still.

512x10
512x10

2048x10
2048x10

512x20
512x20

1024x10
1024x10

1024x20
1024x20

@SteveMacenski
Copy link
Member

That is... interesting. There has to be a reason for this that I'm not understanding at this moment. Shifting by 10 could work, but I'd like to understand where that magic number has come from or if it should be manifested elsewhere (like the time offset or something which could make more sense why that's wrong).

That's wild

@bertaveira
Copy link
Contributor

@CollinNHays That is interesting! It looks like it is a rotated at the same angle for all modes. So it might not be a matter of 10 incrementes but an angle. I don't have the sensor with me right now to test it but this weekend I can test the 10 increment patch on multiple modes to confirm it and try to figure out the deviation angle if it is indeed an angle offset.

@SteveMacenski
Copy link
Member

That's a good point - what is the 10 * angle increment actual value? I wonder if its near (or exactly) a geometrically interesting increment of PI or base ten

@bertaveira
Copy link
Contributor

bertaveira commented Jan 26, 2022

When I tested I was in 1024x10 so it was an offset of about 3.515 deg given 10 increments

@CollinNHays
Copy link
Author

Any updates on this?
I also have an OS1-64 and the offset is much less.
~2 degrees on the OS1-64
~10 degrees on the OS0-128

@SteveMacenski
Copy link
Member

SteveMacenski commented Sep 27, 2022

Have not had the time to dig into it yet, but its most likely somewhere in this block https://github.com/ros-drivers/ros2_ouster_drivers/blob/ros2/ros2_ouster/include/ros2_ouster/conversions.hpp#L227-L242

I don't use Ouster lidars at the moment in any of my projects so this is very low priority to me, but happy to review any PRs with a patch if anyone has the time to look into it.

@mintar
Copy link

mintar commented Jan 18, 2023

This bug may be caused by #127.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants