LaserScan is slightly rotated and not aligned with point cloud

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.

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

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.

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

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 (

ros2_ouster_drivers/ros2_ouster/include/ros2_ouster/conversions.hpp

Lines 222 to 225 in 616891c

    
           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).

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.

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.

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:

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

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

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?

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

512x10

2048x10

512x20

1024x10

1024x20

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

@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.

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

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

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

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.

This bug may be caused by #127.

	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);