You added the HandEyeCalibration panel in RViz, created the target on the Target tab, opened Context, and the Object frame field shows no options at all. Nothing is broken in the panel. The field lists TF frames that are being published right now, and the one frame you need — the calibration target's pose frame — is published only while the camera is detecting the target. In most cases the board is simply not in the camera's view, or detection is failing quietly. This guide ranks the causes, gives a fast test for each, works a field-of-view example that tells you whether the target can be seen from where the camera sits, and ends with the fix and the bench order that keeps the list populated.
What the Object frame field lists
The Object frame field is a live view of the TF tree, not a catalog of frames the panel knows about. The MoveIt hand-eye solver builds the calibration from two poses per sample: the camera's pose, which comes from the robot kinematics, and the target's pose, which comes from live detection of the board. Detection publishes the target's pose as a TF frame, and the dropdown only offers frames that are being published at that moment. Your robot's frames appear immediately because its driver publishes them continuously; the target frame is absent because nothing has detected the board yet.
An empty frame selector in RViz has other causes with different fixes: the fixed frame does not exist error is the common sibling symptom.
Likely causes, most probable first
- Target outside the field of view. No detection runs, so no frame publishes and the list stays empty. This is the cause behind most reports of a blank Object frame field.
- Detection failing with the target in view. A square size mistyped on the Target tab, blur from a hand-held board, glare off a laminated print, or a pattern partly outside the frame each break the corner match.
- No camera image reaching the panel. The driver or the image stream is down, so there is nothing to detect on.
- A transient frame. Detection worked briefly, but the frame exists only while the pattern is found, and the field was read while it was absent.
Each cause has a fast test below; run them in this order.
Test 1: is the target frame on the TF tree?
Print the TF tree and search for the frame name you gave the target when you created it on the Target tab. The robot's frames appear at once because its driver publishes them continuously. If the target frame is absent, go straight to Test 2: nothing has detected the board yet. If it is present, close and reopen the panel so the selector rebuilds from TF, then pick the frame.
If your target is a printed marker rather than a checkerboard, the marker detector is what publishes the pose; the ArUco marker pose as a TF frame article shows that pipeline. For the wider checklist of missing-frame causes, see the target frame missing guide.
Test 2: is the camera delivering images?
Open the raw camera topic in an image viewer. You should see the live scene with the board somewhere in frame. If the image is black, frozen or absent, the driver is the problem, not the calibration; the depth image flickering fix covers the driver-first diagnosis. If the image is live, check the three things that quietly break detection:
- Exposure. The pattern must be evenly lit, with the dark squares clearly darker than the light ones.
- Focus and motion. A board waved by hand blurs; hold it still or mount it.
- Full pattern in frame. The corner detector needs every inner corner; a board clipped by the frame edge detects nothing.
Test 3: does the target definition match the printed board?
The numbers on the Target tab must equal the physical board. Measure one square with a ruler: a 1 mm error on a 10 mm square is a 10% scale error, enough that corner matching fails and detection reports nothing. Check the pattern type and the square count the same way.
Detection also runs on the undistorted image, so a missing or wrong intrinsics file can stop a visible target from being found; the camera intrinsics fix article covers that input.
Worked example: can the camera see the target from here?
Geometry decides cause 1, and two estimates settle it. The pinhole model gives the frame width at the board:
Corner detectors lock reliably once each pattern square spans roughly 20 pixels, which sets the maximum standoff:
Take a typical bench case: a 1280-pixel-wide sensor with 4.8 µm pixels, a 6 mm lens, and a board with 10 mm squares.
- Sensor width: 1280 px × 4.8 µm = 6.144 mm.
- Maximum standoff: WD_max = (10 mm × 6 mm) ÷ (20 × 0.0048 mm) = 60 mm² ÷ 0.096 mm = 625 mm.
- Frame width at that distance: FOV = 6.144 mm × 625 mm ÷ 6 mm = 640 mm.
- A 70 mm board then fills about 11% of the frame width, comfortably inside view at 0.6 m.
The decision: with these inputs, hold the board at 0.6 m or closer and the frame should publish the moment the full pattern is in view. At 1.25 m the squares fall to 10 pixels, detection turns unreliable, and the symptom is a frame that appears and disappears. Focal length moves the limit directly: a 3 mm lens halves WD_max to roughly 310 mm, a 20 mm square doubles it to 1.25 m. The pinhole estimate ignores distortion and the small magnification correction, worth under 2% at these standoffs.
Factory-lens 3D cameras publish a field of view instead of a focal length, so check the printed FOV against the same geometry; the 3D sensors category and the camera finder list it per model. For cameras that work much closer, the short-range calibration standoff guide gives the matching target geometry.
The fix, in order
- Put the board inside the computed field of view, within WD_max, held still — by hand for a first check, on a mount for repeated work.
- Confirm live images (Test 2) and a correct target definition (Test 3).
- Watch the TF tree until the target frame appears, and leave the board in view.
- Reopen the Context tab and select that frame in Object frame.
- Only then start pose capture. The sample once, replay workflow records poses cleanly, and the pose selection guide explains which robot positions carry information.
Note that the board detection accepts is often smaller than the board pose capture needs; the target size guide covers that second requirement.
Bench prevention: hold the geometry still
Before the cell is assembled, reproduce the calibration geometry on a bench. Set the camera at the standoff you computed, aim it at the board, and watch the TF tree while you sweep the board laterally through the frame. The frame should publish the moment the full pattern enters view and drop when it leaves; that boundary check takes two minutes and proves the whole detection chain.
A slide-table stand makes the set-up repeatable. The LS-MNT-0040 camera stand has a 700 mm column and a 400 x 450 mm base. That height range covers the 400-700 mm standoffs typical for checkerboard calibration with standard lenses, and the sliding stage lets you park the exact distance before the robot exists.
- Type
- Camera stands
For other heights, X/Y stages and brackets, the camera stands category and the accessories finder filter by mount type, and the stand configurator matches a stand to a camera and working distance.
If the frame exists but the dropdown stays empty
Three cases remain once Tests 1 to 3 pass:
- A stale list. The selector reads TF when the panel loads. Reopen the panel after detection is running and the frame appears as an option.
- A name you did not expect. A namespace prefix or a typo means the frame exists under another name; search the TF list for the stem of the name rather than the exact string.
- A flickering frame. Detection succeeds intermittently, so a transform lookup downstream fails with a frame-does-not-exist error; the canTransform frame not found fix shows how to pin that down.
Before you trust the result
Once Object frame is selected and the solve completes, keep the verification habit: test the calibration against a known distance before a robot acts on it, as the accuracy verification guide lays out. The output of the whole exercise is the transform that turns camera pixels into robot coordinates — the same math a teach-pendant workflow steps through, as in this pixel-to-robot coordinate transform walk-through.
Quick prevention checklist
- Target defined on the Target tab with a measured square size and the correct pattern type.
- Intrinsics loaded and verified before detection.
- Live image confirmed in a viewer.
- Board matte, evenly lit, fully inside the frame and still enough to stay sharp.
- Target frame visible on TF before the Context tab is opened.
- Pose capture started only after the frame stays published.
- Calibration verified against a known distance before production picks.
If you are still choosing hardware, the 3D topic page collects the rest of the calibration series, and the contact page reaches the applications team for a parts question the guides do not answer.
Questions
Can I type a frame name into Object frame if it is not in the list?
The field is a selector for frames that exist on TF; typing a name for a frame nobody publishes does not create the transform, and the solver cannot estimate the camera-to-target pose without it. The target frame has to come from live detection. Create or enable detection so the frame is published, then select it from the list.
How far from the camera should the calibration target sit?
A working rule is to keep each pattern square at 20 pixels or more. With a 6 mm lens on a 4.8 µm pixel sensor, a 10 mm square holds that size to about 625 mm standoff; a 20 mm square reaches about 1.25 m. Many 3D cameras print their field of view on the product page, which settles the in-frame question directly.
Does the same fix apply to eye-to-hand calibration?
Yes. The camera is mounted statically, but the Object frame logic is identical: the dropdown lists published TF frames, and the target frame appears only while the camera sees the target. Park the robot so the board is in view, confirm detection, and only then start collecting calibration poses across the workspace.
The target frame appears, then disappears while I collect poses — why?
Detection is intermittent. Common causes are motion blur from moving the board too fast, glare from a glossy or laminated print, and partial occlusion when an edge leaves the frame. Print the target matte, slow the motion, and keep the whole pattern inside the frame; the target frame should then stay published pose to pose.
Why does my robot's tool frame show in the list but the target frame does not?
The robot's frames are published continuously by its driver, so they are always in the list. The target frame is different: nothing publishes it until detection finds the pattern in a live camera image. That asymmetry is why the dropdown looks half-empty; it tells you the target side, not the robot side, is missing its publisher.
