RViz2 stereo is not supported warning: what it means and when to act

Your stereo depth camera streams normally, yet RViz2 prints Stereo is NOT SUPPORTED at launch and a frequency readout beside it says not published yet. Two faults? No — one cosmetic line from the viewer's render layer and one real symptom on the publish side that deserves its own test. This page tells you which is which within five minutes: read the log tag, count messages on the depth topic, and sanity-check depth with one disparity calculation. It also covers the one case where the graphics stack genuinely needs work — the viewer crashing right after the line — and the map-save permission error that often arrives in the same session.

The line names the viewer, not the camera

The full text is [INFO] [rviz2]: Stereo is NOT SUPPORTED. The bracketed tag names the process that printed it: rviz2, the visualization tool. Camera drivers log under their own tags, so a camera-side fault never announces itself as an rviz2 message. The line is INFO severity, printed at startup before any device connects — your first clue that no camera took part.

What it reports is a rendering feature, not a data path. RViz2 asked the graphics stack for a window capable of stereoscopic output, the stack refused, and the viewer continues in monoscopic mode. Mono shows every message the camera publishes; nothing in the image, disparity or depth topics changes. Headless servers, virtual machines, remote-desktop sessions and most integrated laptop graphics refuse stereo output by default, so the line appears at every launch in those sessions.

Three symptoms in one session, ranked

The same session usually carries all three complaints. Ranked by what each actually is:

1. [rviz2]: Stereo is NOT SUPPORTED — viewer-side and harmless. Action: none, or switch the stereo display option off so the line disappears.
2. A frequency readout stuck at not published yet — publish-side and real. The readout has counted zero messages in its window. In order of probability: the display points at the wrong topic name; the driver node is not running; the display's delivery contract (QoS) does not match the publisher's; the camera is absent from the network.
3. Saving the map fails on a path — filesystem-side and real, and unrelated to vision entirely.

The stereo line and the empty feed look related because they arrive together. They are decoupled: the same pairing shows up across stereo camera example stacks for exactly this reason, and the camera driver has no role in the viewer's render-system check. Treat them as two separate tickets.

Count the messages before you touch the camera

1. List the live topics: ros2 topic list. Note the exact depth topic name. Most blank-display cases at this stage come from a name typed from memory instead of copied from the list.
2. Count the rate: run ros2 topic hz on that name, or any frequency counter with a known update period. Worked example: the driver is configured for 15 Hz, and over a 10.0 s window the counter reports 152 messages. 152 / 10.0 s = 15.2 Hz, within 2% of nominal — the stream is healthy.
3. Watch the stamps advance: ros2 topic echo on the topic and read two consecutive header stamps. At 15 Hz they sit 1 / 15 s ≈ 66.7 ms apart. Advancing stamps with a blank viewer point at the display; frozen stamps mean the driver stopped publishing.
4. Read the layer from the result:
   • Rate healthy, viewer blank: display-side, usually a QoS mismatch — a display that demands reliable delivery never matches a sensor publishing best-effort. The fix lives in the image-topic QoS mismatch fix; depth images that blink black instead of staying blank are the same class of mismatch, so match the depth topic's QoS. Blank image displays have their own history in this viewer, camera or no camera.
   • No camera topics at all: driver or network. For an Ethernet depth camera, start with the subnet and link checks; when ping succeeds but no stream appears, reset the apps and check the trigger.
   • Rate present but below the configured value: compare against the driver's own setting first, then the causes in the software-trigger frame-rate article.

Prove the depth scale with one calculation

A healthy rate proves transport, not correctness. One tape-measure check catches a stereo pair that publishes confidently wrong depth. Disparity converts to depth as:

Z is depth in metres, f the focal length in pixels taken from the rectified camera_info, B the stereo baseline in metres, d the disparity of the point in pixels, W the rectified image width in pixels, and FOV_h the horizontal field of view. Use the rectified pair's values — raw-image intrinsics differ, as the rectified versus raw intrinsics article explains.

Worked example with round numbers, to swap for your own camera_info: W = 1,280 px and FOV_h = 90° give f = (1,280 / 2) / tan(45°) = 640 px. Baseline B = 0.050 m. The disparity image reads d = 40 px on a target your tape measure puts at 0.80 m. Then Z = 640 × 0.050 / 40 = 0.80 m — the cloud agrees with the tape, and the scale is right.

Sensitivity: one disparity pixel moves depth here by f × B / d² = 32 / 1,600 = 0.020 m, so ±0.5 px of matching error is about ±10 mm; agreement within 20 mm of the tape at this range is normal. A cloud that doubles the tape — 1.6 m where the tape says 0.8 m — almost always means the wrong intrinsics went in, not a broken camera. The full disparity-to-coordinate mapping is in disparity to 3D coordinates, and a missing camera_info file is fixed by calibrating and publishing it.

If depth publishes but scatters, the thresholds and depth-range settings that calm it are in the noisy stereo point cloud fixes.

When the graphics stack really is the fault

One case deserves action on the graphics side: the line is followed by a viewer that never renders or exits at launch. Launch-time reports record cases where this INFO line came immediately before a crash originating in the graphics libraries — same message, real failure. Test it by launching RViz2 with an empty display list: if the 3D view itself fails to appear, the GL stack is the suspect. The fixes are the ones in the OpenGL invalid-value fix and the GPU runtime check for stereo depth nodes: a vendor driver in place of the software fallback, and GL libraries that match it.

True stereoscopic viewing is the only reason to chase the warning itself. It needs a GPU and driver that supply stereo-enabled OpenGL contexts plus display hardware that can show both eyes. Without that chain the viewer is correct to report the feature unavailable — and mono rendering loses nothing from the data. If nobody at the cell wears 3D glasses, leave the option off.

The map-save failure is a filesystem permission

The third symptom often arrives in the same session: saving the map fails and the log points at a path. That is a permission problem, not a vision fault — the node cannot create the folder you gave it. Create the target folder first and give the user running the nodes write permission on it. If the stack runs inside a container, the path must exist inside the container's filesystem or arrive as a mounted volume; a folder made on the host does not exist inside the container unless you mount it. Fix the permission and the save succeeds, with the stereo line and the topic rate untouched.

Five checks before you suspect the camera

• Read the tag and severity: [rviz2] at INFO describes the viewer's own display, not a device fault.
• Count the rate over 10.0 s and compare with the configured value: 152 messages in 10.0 s = 15.2 Hz against 15 Hz is healthy.
• Echo two header stamps: about 66.7 ms apart at 15 Hz means publishing; frozen stamps mean it stopped.
• Run the tape check at one known distance: 640 px × 0.050 m / 40 px should return the tape's 0.80 m within about 20 mm.
• Leave the viewer's stereo option off unless someone genuinely needs 3D glasses.
• Reserve driver reinstalls and firmware updates for a failed publish-side test — never as a response to the stereo line.

If you are choosing the camera instead

Everything above assumes a sensor that publishes rectified images, disparity and depth as topics, so the viewer only draws. When you are specifying that sensor rather than debugging one, start from the 3D sensors category — laser profilers and stereo 3D cameras — or the camera finder. The Hikrobot MV-DPS200P-02 is a projected structured-light 3D camera of exactly this class.

For a cell you are designing end to end, the camera configurator walks through sensor and mount in order, and the applications team answers integration questions on the contact page.