rewire-stress-example

High-rate topic publishers for reproducing rewire bridge throughput issues. Reproduces the scenario where a /tf topic flooding at 800 Hz degrades the delivered rate of an image topic publishing at 100 Hz, making the image look throttled even though no throttle is configured for it.

Topics

Topic	Type	Rate (default)	Description
/tf	tf2_msgs/TFMessage	800 Hz	Rotating map to base_link transform, deadline-paced thread
/camera/image_raw	sensor_msgs/Image	100 Hz	640x480 rgb8 scrolling gradient (~92 MB/s)
/camera/camera_info	sensor_msgs/CameraInfo	100 Hz	Camera intrinsics
/tf_static	tf2_msgs/TFMessage	latched	Static transform: map to camera_optical

Both publishers log their achieved rate every 5 seconds. Trust these log lines as the wire rate: publishing is driven by deadline-paced threads with precomputed frames, and every message that clears publish() is counted.

Do not trust ros2 topic hz on the image topic. It is a Python subscriber that deserializes every ~0.9 MB frame, and it under-reports badly at high rates; it can show 20-30 Hz while the wire carries 100 Hz. It is fine for /tf and other small messages.

Setup

Requires pixi.

pixi install

Run

pixi run -e humble ros2 launch rewire_stress stress.launch.py

Launch arguments (all optional):

pixi run -e humble ros2 launch rewire_stress stress.launch.py \
    tf_hz:=800 transforms_per_msg:=1 image_hz:=100 width:=640 height:=480

Reproducing the issue

1. Start the publishers as above.

2. Confirm the wire rates from the publishers' own "achieved" log lines in the launch output. If the image publisher cannot hold the target on your machine, lower the resolution (width:=320 height:=240) rather than the rate; message rate matters more than bytes for reproducing this issue.

3. Start the bridge and viewer:

   rewire record --diagnostics

4. In the viewer's Diagnostics panel, compare the reported Hz for /camera/image_raw against the wire rate from step 2. If the image rate reported by the bridge sits well below 100 Hz while ros2 topic hz shows 100 Hz on the wire, the bridge is dropping frames: the image subscription uses a depth-1 queue with drop-oldest, so whenever the pipeline falls behind (for example because the /tf dispatch task is consuming the runtime at 800 messages per second), frames are silently replaced before the bridge can log them.

5. Confirm the interaction by capping /tf at the bridge:

   rewire record --diagnostics --throttle /tf=50

   If the image rate recovers, the drop was caused by /tf load, not by the image pipeline itself.

Useful sweeps: raise tf_hz (or transforms_per_msg) until the image rate degrades, or lower width/height to separate CPU load from bandwidth effects.

Reference profiles

reference_publisher implements the load profiles of the rewire performance baseline suite (bridge REW-211): deadline-paced, seeded, with per-topic achieved-rate reporting as the wire-rate ground truth.

pixi run -e humble ros2 launch rewire_stress reference.launch.py profile:=nominal

Profile	Shape
light	5 topics, under 100 msgs/s: tf, pose, twist, one scalar, latched tf_static
nominal	43 topics, ~4470 msgs/s: two compressed camera streams with camera_info, 200 Hz tf, pose/twist/imu/covariance mix, markers, pose arrays, scalars, latched tf_static. Shaped like a real drone flight bag
storm	the adversarial case: 800 Hz tf plus full-rate raw camera

Trust the publisher's own achieved log lines as the wire rate, not ros2 topic hz.