SteveMacenski
commented
1 year ago "The RPLIDAR S2 adopts coordinate system of the left hand. The dead ahead of the sensors is the x axis of the coordinate system; the origin is the rotating center of the range scanner core. The rotation angle increases as rotating clockwise."
That breaks all standard convention and the REPs for laser data. It should be a righthanded coordinate system where X is front and increases are counter-clockwise. But your fix I suppose may work. I think what you're running into is that the tool for visualizing those will actually pay attention to the TF frames to rotate it properly for visualization so its un-doing your doing.
Or there could be an actual issue for everyone, but its hard to tell without mounting another lidar correctly and testing that same feature again. It was working last I checked, but I haven't been an active user of this package in a hot minute as I've been in research and out of commercial deployment. This seems like with 180 off and your incorrect data coordinate system + rotating hack that seems like a plausible cause and Occam's razor seems to apply. There's some behind the scenes magic that's happening with laser scanner data to auto-detect if its inverted which is probably handling alot of this for you without you knowing during regular mapping.
Can you confirm that when I select a node the scan visualized must be close to its good orientation in its initial pose?
I lost you on the wording, but yes, the scan visualized should be close to that of the map where that scan was contributing to. The off by 180 is not expected. Off by a few degrees here or there is well within bounds since those are matched, corrected, and reoptimized for. But nothing significant.
If you had another lidar, I'd try that to validate the issue is with your lidar vendor and then work with them to correct the issue. These REP standards are public and well defined. I suppose more annoyingly you could unflip the lidar and make a shim node to invert the data so TF is correct and then make sure that its working properly again - but at least that doesn't involve hardware changes. Make sure to update TF to reflect it as if its just a normal correct lidar.
sylvaingauthier
First, I want to thank the people who are working on slam toolbox, it has been a pleasure to use it so far.
Steps to reproduce issue
While mapping switch in interactive mod and select a node.
Expected behavior
When a node is selected the scan visualized in its initial pose must be close to overlapping the obstacles in the map.
Actual behavior
When a node is selected the scan visualisation in its initial pose seems to be rotated by 180° from what it's supposed to be.
Origins from left to right are: map, visualized scan, lidar scan
In red: lidar scan
In green: visualized scan from slam toolbox
Additional information
Information from lidar constructor: "The RPLIDAR S2 adopts coordinate system of the left hand. The dead ahead of the sensors is the x axis of the coordinate system; the origin is the rotating center of the range scanner core. The rotation angle increases as rotating clockwise." So to make things work I rotated the lidar link by pi around the y-axis as can be seen in the image. Maybe that's what causes the problem but it works perfectly fine when using slam toolbox for mapping and it also works fine with cartographer, AMCL or other packages from Nav2. I try to set use_scan_barycenter to False like in https://github.com/SteveMacenski/slam_toolbox/issues/211 but it does not solve my problem.