Calibration toolbox crashes on topic selection: fix zero marker size

You have the calibration toolbox built, the robot driver running and the plugin panel showing in RViz. The moment you pick the camera topic from the dropdown, the GUI dies and the console prints an invalid-target error carrying two zeros. The numbers you typed were real; the backend that validates the target never received them. This guide takes the fault from symptom to fix, sizes a marker target that works at a typical standoff, and closes with the decision for each case if the crash refuses to go.

The symptom: both dimensions arrive as zero

[ERROR] Invalid target measured dimensions: marker_size 0,000000, marker_seperation 0,000000

The toolbox builds its marker target from two measured numbers: the marker edge length and the gap between markers. The log prints them as marker_size and marker_seperation — the second name really is misspelled in the toolbox, so keep that spelling when you search logs or grep the source. Selecting the image topic is the moment the plugin instantiates the target, and its first check is that both dimensions exceed zero. Both arrive as zero, the check throws, and the GUI process exits while you are still holding the dropdown.

Those zeros are not a measurement of anything. They are the backend's untouched defaults. Nothing is wrong yet with the camera, the topic or the robot — the check runs before a single image is consumed.

Why the GUI values never reach the backend

The settings panel edits a front-end copy of the target parameters. The backend holds the last values it was sent, and a keystroke in a text field is not a send. Values cross that boundary only on an explicit apply or save action, or when the backend reloads its configuration at start-up. Type your numbers, immediately pick the topic, and the backend is still holding the zeros it booted with — the validation then kills the GUI, every time, until the values land.

The fix: re-enter, apply, then select

1. Relaunch RViz so the plugin and its backend start clean.
2. Open the target settings panel, clear both fields, and retype the marker size and separation as nonzero values. For a sound starter target enter 0.06 and 0.04 — a 60 mm marker with a 40 mm gap, in metres.
3. Press the panel's apply or save control. Filling the field is not enough; the value has to be pushed to the backend.
4. Reopen the panel if it folds away and confirm both fields still hold your numbers.
5. Only now select the image topic from the dropdown.
6. The pass condition: no error line, and the plugin moves on to detecting the target. A GUI that survives topic selection has closed this fault.

Units: metres, written on the sheet

ROS software follows REP 103, which fixes SI units, with lengths in metres. A 60 mm marker is 0.06 in the field; a 40 mm separation is 0.04. The reverse mistake is the one that costs a day: millimetre numbers in a metres field pass the nonzero check and build a target a thousand times too large. That does not crash anything. It calibrates quietly into absurd poses, and you discover it downstream, in the robot's motion. Write the unit next to the value on the printed target so nobody re-types 60 into a metres field.

Size the target for the standoff

With the crash fixed, the next disappointment is a marker too small in the frame. Corner detection on a marker grid degrades once a marker edge falls under roughly 100 pixels, so plan for several hundred. The example below uses a sensor 7.2 mm wide with 3.45 µm pixels — a common 3 MP class combination, about 2,090 pixels across.

Take a 2 × 2 marker grid: 60 mm markers, 40 mm gaps, sheet about 180 mm across. Give it a 240 mm field of view for handling margin.

• Magnification: m = 7.2 mm / 240 mm = 0.03
• Focal length at a 550 mm working distance: f = 550 mm × 0.03 / 1.03 = 16.0 mm, a standard 16 mm lens
• Marker on sensor: 60 mm × 0.03 = 1.8 mm
• Marker in pixels: 1.8 mm / 3.45 µm = 1800 µm / 3.45 µm ≈ 520 px
• Sheet on sensor: 180 mm × 0.03 = 5.4 mm, inside the 7.2 mm sensor width with margin

About 520 pixels of marker is comfortable. Halve the standoff and the span doubles; halve the marker and it halves.

Two pieces go deeper on the target itself: how big a board your poses need and standoff choices for short-range cameras. When the sheet is printed, measure the marker with calipers instead of trusting the drawing.

Camera and mount that hold the geometry

Hand-entered target numbers stay valid only while the camera holds still. Two routes get you the optics above. A fixed-lens model locks the geometry at the factory: the LS-SMC-0063 pairs a 16 mm lens with a 1.6 MP sensor. A C-mount body leaves the focal length to you: the LS-SMC-0017 is an 8.8 MP camera with a C-mount. Browse smart cameras or the camera finder for the resolution class the job needs.

On the mechanical side the camera wants a column, not a bracket arm that droops between shifts. The LS-MNT-0040 is a professional slide-table type stand, height 700 mm, on a 400 × 450 mm base. That column spans the standoff above with adjustment in hand.

The target sheet wants squaring to the optical axis, and a rotation stage does it with one knob. The LS-MNT-0220 is a manual XY + rotation stage on a 60 mm diameter base. For more, see camera stands, the accessories finder, or configure a system starting from the stand.

If the crash survives the fix

Four causes remain, in the order worth checking:

1. The backend loads a different config than the panel writes. Test: put an obvious value in the file you edit, relaunch, and see whether the panel shows it. Fix: point the launch at your file — the toolbox reads the config path its launch file names, and a mistyped path falls back to defaults without complaint.
2. The topic carries no images. Test: open the topic in a plain image viewer before touching the plugin. Fix: start the camera source and pick the raw camera feed rather than a processed one. If the topic publishes but shows nothing, the QoS mismatch is the usual culprit.
3. The backend service is down or in another namespace. The panel renders, but nothing answers behind it; check the namespace and service first.
4. A stale build. After source changes the plugin can keep running old binaries; a clean rebuild settles it.

The same front-end, back-end and connection splits run through the rest of the systems topic whenever a vision tool dies on selection.

Check the result before you trust it

A surviving GUI is not a correct calibration. Before the cell runs on the result, test the calibration against a point you can measure, and remember the chain starts upstream: fix the camera intrinsics and pose first. Collect the robot poses at reduced speed with the enabling device in hand — the arm sweeps its full pose range during collection, and the safety settings stay active throughout.

Checklist for the next run

• Nonzero marker size and separation written as defaults in the toolbox config, so a relaunch starts valid.
• Apply or save pressed after every target-settings change; the topic dropdown touched last.
• Values in metres per REP 103, unit written on the printed sheet.
• Marker measured with calipers on the sheet in use, not copied from the drawing.
• Marker spanning at least 100 pixels at the real standoff, several hundred preferred.
• Poses collected at reduced speed, and the result checked against a known point before production.

The decision, by case

• Crash on topic selection, fields showing your values: the apply step is missing. Re-enter, apply, select — this closes most of these crashes.
• Crash persisting after apply and relaunch: the backend reads another config. Fix the path or its permissions in the launch, relaunch, retest.
• Values confirmed nonzero and the GUI still dying: the fault sits upstream of the target — empty topic, dead backend or stale build. Work those three checks in order.