Panther Robot: Integrating RealSense D555 URDF and CycloneDDS Communication Issues

usef · May 6, 2026, 12:51pm

Hi Husarion Community,

I am currently working with a Panther robot equipped with an Intel RealSense D555. I am encountering two main issues regarding URDF integration and data communication.

1. URDF Configuration for D555

I am trying to add the D555 to my components.yaml file, but I cannot find the specific camera model name within the ros-components-description package or the standard camera configurations on your website (only D435 is found).

I have located the D555 CAD model on the official RealSense page.
I found a GitHub issue suggesting the use of the D585 URDF as a workaround, though it is currently untested for this setup.

Question: What is the recommended way to define the D555 in the Husarion component description to ensure it attaches correctly to the Panther’s TF tree?

2. CycloneDDS Warnings & Malformed Packets

When echoing the Color topic, I am seeing significant errors and warnings related to rmw_cyclonedds. I am receiving malformed packet errors and type hash failures:

1778070707.302948 [0]       recv: malformed packet received from vendor 1.48 length 80 state parse:shortmsg <52545053 02050130 4f981501 a5151bee 00000036 06013800 c7030000 c2030000 @80 > (note: maybe partially bswap'd)
1778070707.303046 [0]       recv: malformed packet received from vendor 1.48 length 80 state parse:shortmsg <52545053 02050130 4f981501 a5151bee 00000036 06013800 c7040000 c2040000 @80 > (note: maybe partially bswap'd)
1778070707.303084 [0]       recv: malformed packet received from vendor 1.48 length 80 state parse:shortmsg <52545053 02050130 4f981501 a5151bee 00000036 06013800 c7000200 c2000200 @80 > (note: maybe partially bswap'd)
[WARN] [1778070707.303784552] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'realsense/device-info' with type 'realdds::topics::raw::flexible' from USER_DATA '(null)'.
[WARN] [1778070707.303932484] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'realsense/D555_409122300110/notification' with type 'realdds::topics::raw::flexible' from USER_DATA '(null)'.
[WARN] [1778070707.303980573] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'realsense/D555_409122300110/metadata' with type 'realdds::topics::raw::flexible' from USER_DATA '(null)'.
[WARN] [1778070707.304022364] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/realsense/D555_409122300110_Color' with type 'sensor_msgs::msg::dds_::Image_' from USER_DATA '(null)'.
[WARN] [1778070707.304062965] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/realsense/D555_409122300110_Depth' with type 'sensor_msgs::msg::dds_::Image_' from USER_DATA '(null)'.
[WARN] [1778070707.304110906] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'realsense/D555_409122300110/control' with type 'realdds::topics::raw::flexible' from USER_DATA '(null)'.
[WARN] [1778070707.304157464] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/realsense/D555_409122300110_Infrared_1' with type 'sensor_msgs::msg::dds_::Image_' from USER_DATA '(null)'.
[WARN] [1778070707.304508043] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/realsense/D555_409122300110_Infrared_2' with type 'sensor_msgs::msg::dds_::Image_' from USER_DATA '(null)'.
[WARN] [1778070707.304607881] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/realsense/D555_409122300110_Motion' with type 'sensor_msgs::msg::dds_::Imu_' from USER_DATA '(null)'.

I saw an issue where fastdds is recommended you can find it here

3. Sequential frame_id Issue

Most critically, when I am able to receive frames, the frame_id appears to be acting as a sequence counter (incrementing with every frame) rather than a static link name:

header:
  stamp:
    sec: 8833
    nanosec: 739244000
  frame_id: '36'
height: 504
width: 896
encoding: yuv422_yuy2
is_bigendian: 0
step: 1792
data:
- 63
- 129
- 76
---
header:
  stamp:
    sec: 8833
    nanosec: 772577000
  frame_id: '37'
height: 504
width: 896
encoding: yuv422_yuy2
is_bigendian: 0
step: 1792
data:
- 57
- 129
- 75

Because the frame_id is dynamic, it is not mapping to a static link in the URDF, which breaks the TF tree.

4. Topic Availability (Only Color Streaming)

I can see several topics being published, but only the Color topic is successfully echoing data. The following topics produce no messages and result in warnings:

/realsense/D555_409122300110_Color (Works)
/realsense/D555_409122300110_Depth (No messages)
/realsense/D555_409122300110_Infrared_1 (No messages)
/realsense/D555_409122300110_Infrared_2 (No messages)
/realsense/D555_409122300110_Motion (No messages)

Questions:

Has anyone encountered these rmw_cyclonedds malformed packet issues with the newer RealSense models?
Is there a specific parameter in the RealSense ROS 2 driver to force a static frame_id (e.g., camera_color_optical_frame) instead of this sequential integer?
Is there any issues on changing the rmw from cyclone to fastdds?
How to change the camera namespace from realsense to robot1?

Best regards,

RafalGorecki · May 11, 2026, 9:56am

Hi @usef,

The D555 is quite different from older D4xx cameras — it has an embedded DDS stack (SafeDDS) and streams directly over Ethernet/PoE, which is the source of most of what you’re seeing.

1. URDF / `components.yaml`

The D555 is not yet supported in husarion_components_description. For now, declare the camera link manually with a static_transform_publisher from your mounting point to camera_link — the rest of the internal TF chain (depth/color/infra optical frames) is published by the realsense2_camera driver itself.

2. CycloneDDS errors, sequential `frame_id`, and missing streams

All three symptoms have the same root cause: you’re subscribing directly to the raw DDS topics published by the camera (realsense/D555_<serial>/..., rt/realsense/D555_<serial>_Color, etc.). These use Intel’s internal realdds::topics::raw::flexible format — they are not standard ROS 2 topics. That’s why you see Failed to parse type hash ... USER_DATA '(null)', malformed packet warnings, a frame_id that’s actually the camera’s internal frame counter ('36', '37'…), and only Color making it through.

The fix: don’t subscribe to the camera’s raw DDS topics. Run the realsense-ros driver — it bridges the camera’s DDS interface to proper ROS 2 topics with valid type hashes and static frame_ids like <camera_name>_color_optical_frame.

To keep the noisy raw DDS traffic out of your ROS graph entirely, put the camera on its own DDS domain (different from ROS_DOMAIN_ID):

rs-dds-config --domain-id 60

This is saved in realsense-config.json on the device. CycloneDDS then works fine as your RMW — no need to switch to FastDDS.

Two network gotchas that match the “only Color works” symptom:

The NIC connected to the camera must have MTU 9000. Verify: ping -M do -s 8972 <camera_ip>.
Use CAT6 or better cabling.

3. Changing to FastDDS

Configuring fastdds for the robot driver will cause some issues. Cyclone has been the most reliable and intuitive so far, so this topic hasn’t been fully explored.

4. Renaming the namespace from `realsense` to `robot1`

Once you go through realsense2_camera, it’s just driver parameters:

ros2 launch realsense2_camera rs_launch.py \
    camera_namespace:=robot1 \
    camera_name:=D555

Topics become /robot1/D555/color/image_raw, etc., and frame IDs become D555_color_optical_frame — static and TF-friendly.

Best regards