* Initial tests * more tests * More in-depth deskew() testing * slightly less verbose clamping corruption warning * added tf buffer related tests * added remaining tests * Added rosdoc2, improve tests when we require sync of odom stamp and sensor stamp * cleanup doc * fixing ci * rtabmap_util tests and doc * Added db_player tests * Added MapsManager tests * Added map_assembler tests * Documenting node first draft * relative links * Fixed british->usa english style. Reviewed all md files. * added link to install ros1 * updated badges * added Iron * added ubuntu * added codecov * updated coverage ci * fixing rosdep * updated ci cov job * ci bump * fixing cov ci * small doc cleanup
4.6 KiB
rgbd_split
Splits an rtabmap_msgs/msg/RGBDImage back into the standard ROS image topics.
RGBDImage bundles color, depth and both camera infos into one message so they arrive together, which is what RTAB-Map wants. Everything else in the ROS ecosystem — RViz, image_view, depth_image_proc — expects separate Image and CameraInfo topics. This node unpacks the bundle for them.
It is the inverse of rtabmap_sync's rgbd_sync, and of its stereo_sync when stereo is set — those two are what produce an RGBDImage in the first place.
Usage
ros2 run rtabmap_util rgbd_split --ros-args -r rgbd_image:=/camera/rgbd_image
ComposableNode(
package='rtabmap_util',
plugin='rtabmap_util::RGBDSplit',
name='rgbd_split',
remappings=[('rgbd_image', '/camera/rgbd_image')])
Subscribed Topics
| Topic | Type | Description |
|---|---|---|
rgbd_image |
rtabmap_msgs/msg/RGBDImage |
Queue depth queue_sub, 5 by default. Raw or compressed images are both accepted. |
Published Topics
The output topics are named after the resolved input topic, so remapping rgbd_image moves the outputs with it. With rgbd_image remapped to /camera/rgbd_image they are /camera/rgbd_image/rgb/image and so on. Setting stereo: true renames the two halves left and right, see Stereo messages.
| Topic | Type | Description |
|---|---|---|
<rgbd_image>/rgb/image |
sensor_msgs/msg/Image |
The color image, decompressed if needed. |
<rgbd_image>/rgb/camera_info |
sensor_msgs/msg/CameraInfo |
|
<rgbd_image>/depth/image |
sensor_msgs/msg/Image |
The depth image, or the right image of a stereo pair. |
<rgbd_image>/depth/camera_info |
sensor_msgs/msg/CameraInfo |
For a stereo pair this is the right camera, and its P(0,3) carries the baseline. |
Each half is only unpacked if something is subscribed to it, so subscribing to color alone does not pay for depth decompression.
Parameters
| Parameter | Type | Default | Description |
|---|---|---|---|
qos |
int |
0 |
Reliability of both sides: 0 system default, 1 reliable, 2 best effort. |
qos_sub |
int |
value of qos |
Reliability of the rgbd_image subscription alone. |
qos_pub |
int |
value of qos |
Reliability of the four output publishers alone. |
queue_sub |
int |
5 |
Queue depth of the rgbd_image subscription. Must be at least 1. |
queue_pub |
int |
1 |
Queue depth of every publisher. Must be at least 1. |
stereo |
bool |
false |
Name the outputs left/right instead of rgb/depth. See Stereo messages. |
Stereo messages
The node handles stereo RGBDImage messages as well as RGB-D ones. In a stereo message the "depth" slot holds the right image, and the second camera info carries the baseline; the depth topics then carry the right camera, correctly typed as mono8 or bgr8 rather than mislabeled as depth.
That works, but the topic names lie. Set stereo: true and the outputs are named for what they hold:
stereo |
Output topics |
|---|---|
false (default) |
<rgbd_image>/rgb/image, <rgbd_image>/rgb/camera_info, <rgbd_image>/depth/image, <rgbd_image>/depth/camera_info |
true |
<rgbd_image>/left/image, <rgbd_image>/left/camera_info, <rgbd_image>/right/image, <rgbd_image>/right/camera_info |
ros2 run rtabmap_util rgbd_split --ros-args \
-r rgbd_image:=/camera/rgbd_image \
-p stereo:=true
Only the names change — the message contents and the order of the two halves are the same either way, so the rgb slot always becomes the left image. The two namings are exclusive: with stereo: true nothing is published on rgb/depth.
The node checks the setting against what actually arrives, going by the encoding of the second half: 16UC1, 32FC1 and mono16 are depth, anything else is an image. If the two disagree it logs a warning once and keeps forwarding — a mismatch makes the topic name misleading, not the data wrong, so it is never worth dropping a frame over.
Notes
If a message has no frame_id on one of its sub-messages, the node fills it in from the other one so the output is always usable by TF.