RGBD camera range longer than specified

[osrf-migration]

Original report (archived issue) by Paul Jurczak (Bitbucket: pauljurczak).

---

Description of RGBD camera reads:

VGA RGBD camera 640x480 60-deg RGBD camera, 10m range

but the actual range observed in PointCloud2 messages published by this camera goes up to 11.7m. Is this intentional?

[osrf-migration]

Original comment by Paul Jurczak (Bitbucket: pauljurczak).

---

• Edited issue description

[osrf-migration]

Original comment by Paul Jurczak (Bitbucket: pauljurczak).

---

• Edited issue description

[osrf-migration]

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

---

I believe this comes from the convention that the depth image values are the z values in the camera frame. I believe those ranges in the depth image are what are clipped to 10 meters. So, the distance from a point in the point cloud to the camera could be more than 10 meters - particularly for those points near the edge of the image.

[osrf-migration]

Original comment by Paul Jurczak (Bitbucket: pauljurczak).

---

GoRobotGo (GoRobotGo) It doesn’t seem so. Z-values are in [-0.06, 4.57] interval in the PointCloud2 I’m referring to. I think clipping occurs in depth Image , which is the source of PointCloud2 data.

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

Ian Chen (Ian Chen) , was this fixed?

[osrf-migration]

Original comment by Ian Chen (Bitbucket: Ian Chen).

---

no, this is not fixed.

As GoRobotGo (GoRobotGo) said, the RGBD camera implementation in ignition does clipping using the Z position of a point (in camera frame) as opposed the distance to the point so if the ‘range’ may be larger than 10m but the Z value should not be larger than 10m.

Additional work need to be done if we want to support clipping based on distance to point.

‌

[iche033]

Coming back to this, clipping by "range" would be a change in behavior so I think we could use a param / sdf tag to toggle this behavior.

[Lobotuerk]

@nkoenig After speaking with Ian, I have opened gazebosim/gz-rendering#325 to fix this. Bear in mind that this would change behavior at a minimum and maximum range (with this PR, it should be more realistic) so we are not sure if it's worth changing it before Subt ends or after it. This correlates with what documentation I found (https://www.intelrealsense.com/wp-content/uploads/2020/06/Intel-RealSense-D400-Series-Datasheet-June-2020.pdf for ex) stating that "range" is measured as a distance to focal point, so having a 30 meters max range RGBD camera with points at 31 meters from the focal length would be "not realistic"

[nkoenig]

We'll merge the above mentioned PR after subt final code freeze in order to avoid negatively impacting teams.

[Lobotuerk]

According to @iche033 : In our depth camera, we are doing clipping by intentionally setting the near clip distance in code to be smaller than the user specified value and then manually clipping the points in the shaders. However currently, we are only setting it to 0.9 of the user specified value. This is not enough for a camera with 60 degrees FOV. If we do some trigonometry, we find that the points at the edge of the image has a depth value of cos(60/2) * near , which is less than 0.9 * near. If we change the code to something like 0.7 * near , we may get better results but I think it would not work for other cameras with different FOV. In addition we will definitly run into the same issue found in this comment: gazebosim/gz-rendering#356 (comment)

For now we will fix the far clipping, to fix this issue. Hopefully when the other issue is fixed, we can fix the near clipping