I am following the ROS1/Cameras tutorial in order to create a camera publisher with 3D bounding box data.
I have a simple scene with a cylinder for which I have attached a semantic label. In the viewport, I am able to see the semantic segmentation and 2D or 3D bounding boxes.
I may be missing something, but I have not been able to find a ROS command line terminal tool that supports 32SC1 conversion to other formats. Then, I created a simple script to transform 32SC1 to 8UC1 (mono/gray scale image): convert_32SC1_to_8UC1.py (1.4 KB)
I have been looking at the 3D bounding box data but it seems that something is off.
I wasn’t sure whether the pose of the bounding box is w.r.t. the camera or the world (actual pose equal to the prim’s pose shown in properties) but after moving the camera, I get the same pose for the bounding boxes, so I assume it is w.r.t. the world. Is this accurate?
The issue I have is that the bounding boxes seem accurate only for cubes and not for spheres or cylinders (haven’t tested anything else).
In the .usd example given above, I have added a cylinder and translated the cube.
For the cube, the center of the bbox matches the cube’s center, there is no rotation and the size is correct:
However, for the cylinder, the bbox’s center position is not the same as the prim’s translation, it shows a rotation that does not exist and the size also seems wrong.
Same for the sphere.
The center’s position numbers are the same but they refer to different axes, there is a rotation that shouldn’t exist and the size is different.
Since the cube’s bbox matches the prim’s characteristics, I would expect that to happen for the other objects as well. So, are the other data indeed wrong? If not, how should I interpret them?
Edit: After examining the bbox data in another scene with two cubes and a cylinder, I get “correct” results that match the prim’s attributes for the cylinder and “wrong” results for the cubes. So, it is not the shape that matters but I cannot figure out why only one shape gives “correct” results while the others don’t.
Due to a memory layout change bbox2d loose, tight and bbox3d were all incorrect in 2022.2.0
I have added better tests to catch this and it is fixed in 2022.2.1, coming out this week (fingers crossed)
tested with the warehouse and ROS2 humble and it is correct in 2022.2.1: