Wrong lidar mounting on ergocubSN000

[SimoneMic]

Hello,

Today we've tested the lidar on the robot and we have seen a mismatch between the mounting of the lidar with the URDF of the robot. In few words: the lidar should be rotated by 90 degrees clockwise.

Here's a screenshot of the lidar on Rviz, the readings circled in blue are the ones crane and the support of the robot that should be behind. Here they are on the right of the robot (the red axis in Rviz is the x-axis that points forward)

Here we tried to put a box behind the robot and is still displayed to the side

Do we change the URDF of the robot or fix the mounting of the lidar? The easiest way is to adapt the URDF, but then it should be consistent through all the other versions of ergocub and also the model on gazebo

[pattacini]

Thanks for reporting 👍🏻

Do we change the URDF of the robot or fix the mounting of the lidar? The easiest way is to adapt the URDF, but then it should be consistent through all the other versions of ergocub and also the model on gazebo

We need to check which is the intended mounting and then adapt accordingly.

cc @Nicogene

[pattacini]

From a first inspection, it came out that the LIDAR is mounted correctly as per the CAD. The problem should be then a missing/wrong CSYS that impacted the URDF.

Stay tuned.

[Nicogene]

This issue is confirmed by the fact that right now this is the frame exported

But the datasheet says that the x is ahead

[Nicogene]

PR:

• https://github.com/icub-tech-iit/ergocub-software/pull/134

[Nicogene]

@SimoneMic on master you should find the fix (https://github.com/icub-tech-iit/ergocub-software/pull/136)

[Nicogene]

Actually we noticed that the ref frame of the lidar is left-hand, since it does not exist a transform from a right-hand to left-hand csys, we could do as hotfix to align x a y axis and point z downward instead of upward. Correct me if I am wrong but the measures of the lidar are not considering the z right? It is just d (distance) and theta?

cc @traversaro @randaz81 @SimoneMic @pattacini

[randaz81]

No, the lidar is right-handed. The x is pointing forward, y on the left, z is pointing upward. >> Scans data are ordered CCW << As mentioned by @SimoneMic just a 90 deg rotation is fine to fix the issue.

[randaz81]

What is shown in the datasheet picture mentioned above should be considered wrong and is not consistent with our yarp/ros data representation.

[pattacini]

Hi @randaz81

It's true that a left-handed triplet is kind of unusual/weird but could you elaborate more on the following?

What is shown in the datasheet picture mentioned above should be considered wrong and is not consistent with our yarp/ros data representation.

To which extent should the datasheet be considered misleading?

[randaz81]

Because it states: "The rotation angle increases as rotating clockwise".

However, we are representing the scan data ordered counterclockwise. In fact, giving an X pointing to the front of the robot, and Y pointing to the left, then Z is pointing upwards (right-handed). And Z pointing upwards defines a counterclockwise rotation on a right-handed reference system (which is ok, while a clockwise rotation would be left-handed).

Extras about ROS standards: https://www.ros.org/reps/rep-0103.html https://www.ros.org/reps/rep-0105.html

[pattacini]

Because it states: "The rotation angle increases as rotating clockwise".

This is expected for a left-handed triplet, I think.

Theoretically, we ought to insert in the CAD the information relative to the physical device to then deal with it at a higher level.

Nonetheless, there are a bunch of things to consider as well:

• The flexibility of the CAD to deal with left-handed CSYS.
• The possibility to have left-handed reference frames within a URDF (probably there ain't any).

cc @fiorisi @Nicogene @maggia80

[Nicogene]

Because it states: "The rotation angle increases as rotating clockwise".

However, we are representing the scan data ordered counterclockwise. In fact, giving an X pointing to the front of the robot, and Y pointing to the left, then Z is pointing upwards (right-handed). And Z pointing upwards defines a counterclockwise rotation on a right-handed reference system (which is ok, while a clockwise rotation would be left-handed).

Extras about ROS standards: ros.org/reps/rep-0103.html ros.org/reps/rep-0105.html

Is it possible that the data is manipulated by the yarp-device / SDK in order to be expressed in a right-handed csys? Because I would expect that the sensor give me the data as it states in the datasheet, or maybe there is a configuration for chooseing the reference frame?

[randaz81]

It's possible that the datasheet represents how the device internally works, i.e. the direction of rotation of the motor (for the S2 device it is hidden inside the case so it cannot be seen from outside). However, the SDK provides an array of tuples [angle, distance] in random order (for example, the angle could be: 3, 4, 7, 5, 2..] and is up to the user to process it. However, I don't think that is necessary to know these internal details exactly: given the fact the device has axial symmetry, the x axis, which defines the 0 angle, is defined merely by the software, and it can be placed (in our device driver code) as the user prefers. In our case, we are publishing data following the ROS convention, and what the datasheet says can be completely ignored. Please note that this consideration of mine is specific for a 2D lidar device, which has z-axis symmetry, but it is not general. Indeed, for an RGB camera or an IMU, the reference frame orientation should be chosen carefully according to the hardware.

[Mick3Lozzo]

⬆️ From the official PTC Creo support page, the confirmation that Creo does NOT support left-handed coordinate systems.

I don't think that this problem could be managed at a CAD level.

@randaz81 @pattacini @mfussi66 @Nicogene

[pattacini]

Hi @Mick3Lozzo

Let's proceed with a right-handed CSYS with the x-axis and the y-axis oriented as required by the discussion above.

[Mick3Lozzo]

Corrected the coordinate system CSYS_RPLIDAR_2 in the RPLIDAR commercial part, as a reference for SCSYS_HEAD_S2_LASER at an assembly level. Now the orientation is compliant with the standard.

@randaz81 @pattacini @mfussi66 @Nicogene

[Nicogene]

If now is ok for @randaz81 and @SimoneMic we can close it.