Wrist mounted 2D camera simulation for a robot gripper tool

You have modeled the gripper, the robot runs its pick cycle, and now you want the 2D camera that rides on the wrist — and the right-click menu on the tool frame offers nothing. That is expected behavior, not a broken installation: a camera is not a property of the tool. It is a separate sensor object that you create in the workcell, link to the end-of-arm tool, and position with its own frame offset from the tool center point (TCP). This guide gives you the steps, the offset geometry, a worked field-of-view example with the arithmetic shown, and the calibration that carries the simulated camera into the real cell.

Why the camera entry is missing from the tool menu

Camera simulation ships as an add-on, not with base tool modeling. Offline robot simulators deliver their vision features through a sensor or vision option — one simulator family lists it as "Sensor units" — and until that option is enabled for the workcell, the menus have no camera item to show. Nothing is broken; the feature is simply not loaded.

Two ways to fix it: enable the vision or sensor option for the existing workcell, or recreate the workcell with the option ticked in the wizard. Both end in the same place. After that, cameras are created through the vision-workcell-object workflow — the simulator's own help topic "Creating new vision workcell objects" describes how to create the sensor and link it with the EOAT. So the order is option first, object second, link third. Hunting for a camera entry by right-clicking the tool frame before the option exists wastes an afternoon.

What you need before you model the camera

• The simulator's vision or sensor add-on enabled in the workcell (section above).
• From the real camera's data sheet: resolution in pixels, pixel pitch or sensor width, focal length, lens mount.
• The mechanical stack: flange, camera bracket, camera body, gripper, with the distances between them.
• The name of the user tool frame (UT) the gripper is attached to, and where its TCP sits along it.

Add the camera and link it to the tool

1. Create a new sensor object of the 2D-camera type through the vision workcell object workflow.
2. Set the parent or mounting frame to the user tool frame the gripper uses. This is the step that makes the camera follow the TCP; parenting to the flange or to the world leaves a camera that does not track the tool.
3. Enter the offset from the TCP: a translation along tool Z out to the camera's imaging center — 60 mm in the worked example below — plus a 180° rotation about tool X or tool Y so the optical axis points at the scene the tool approaches.
4. Enter the real camera's numbers: resolution, pixel pitch, focal length, working distance. A simulation left at the default 640 × 480 will pass an FOV check that a real 2.5 MP camera fails.
5. Save a pose from mid-cycle, snap a test image in simulation, and confirm the rendered frame covers the target with margin on every side.

Set the camera-to-TCP offset

A wrist camera normally mounts between the flange and the gripper, and commercial brackets are built for exactly that sandwich — mounting a wrist camera around a three-finger gripper shows how the camera, bracket and gripper share one flange. Every millimeter of stack height becomes offset.

Numbers to plan around: 40-80 mm from TCP back to imaging center for a C-mount camera on a simple bracket; 30-50 mm for an integrated M12 or board-level camera; add 20-40 mm when the bracket must clear a multi-finger gripper. The basis is plain stacking — 25-50 mm of camera body, 10-30 mm of bracket, plus gripper clearance. If the stack is not drawn yet, start at 60 mm: it is the middle of the range and close to where most wrist brackets land.

Orientation matters as much as distance. Tool Z points from the flange toward the work, so the camera optical axis runs parallel to tool Z and points at the scene, with the image "up" direction aligned to tool X or Y. Leave out the 180° flip and the simulated image arrives upside down relative to the real mounting — and calibration will faithfully copy that into a mirrored pick point.

Match the simulated camera to the real one

Simulation only pays off when the numbers match the hardware you will bolt on. Three values drive everything: sensor width, focal length, working distance.

Most simulators draw the FOV rectangle once these fields are set; if yours does not, the field-of-view simulation set-up for robot cameras shows where the settings live.

Worked example: 2.5 MP class sensor, 12 mm lens, 200 mm working distance

Model a typical 2.5 MP global-shutter sensor: 2048 × 1216 pixels at 3.45 µm pitch. Substitute your own camera's data sheet values; the arithmetic stays the same.

• Sensor width: 2048 px × 3.45 µm = 7065.6 µm ≈ 7.07 mm
• FOV width: 7.07 mm × 200 mm / 12 mm = 117.8 mm ≈ 118 mm
• Sensor height: 1216 px × 3.45 µm = 4.20 mm, so FOV height = 4.20 mm × 200 mm / 12 mm ≈ 70 mm
• Ground sample distance: 117.8 mm / 2048 px = 0.0575 mm/px — a 3 mm hole spans 52 px, comfortable for locating; a 0.5 mm defect spans 9 px, marginal for measurement
• Hover height with a 60 mm offset: 200 mm - 60 mm = 140 mm — stop the robot with the TCP 140 mm above the part and the camera sees its full 118 × 70 mm frame

That last line is the payoff: it converts a data sheet number into a robot pose you can program.

For the real hardware, a compact global-shutter GigE camera in this class is the part to model:

Two shortcuts remove variables from the model. An integrated-lens smart camera has no lens to choose — the optics are fixed at 8 mm on M12 over a 6 MP mono sensor. When the target feature needs finer sampling, a 4000 × 3000 sensor on the same 1/1.7" format roughly halves the example's 0.058 mm/px at the same height and focal length.

Check the field of view at the poses that matter

• Hover pose (TCP 140 mm up in the example): does the target sit inside the 118 × 70 mm frame with 10-15% margin on every side?
• Approach pose (TCP 500 mm up puts the camera 560 mm from the scene): the same optics now see 330 mm across, a find-and-locate view rather than an inspection view — decide which decisions happen at which height.
• Grip pose: this is where simulation earns its keep. The fingers enter the frame at working distance and can cross the target region entirely. If the feature you need sits behind a finger, no exposure setting fixes it; the mount or the pose has to change.

Occlusion is the most common finding from a wrist-camera simulation, and no spreadsheet predicts it.

From simulation to the real cell: eye-in-hand calibration

The offset you typed into the simulator is nominal CAD. Bracket machining, mounting play and lens adjustment typically leave the real imaging center within about ±1 mm of the drawn position — close enough to design FOV and clearances, not close enough to pick from. The real camera-to-tool transform is measured, and the measurement is hand-eye calibration.

The flow: move the robot through a spread of poses with a calibration target in view — the inputs are the same robot pose and camera frame pairs — then let the solver recover the camera-to-tool transform. The classic version is how nine-point alignment works. Pose choice decides accuracy more than pose count; which robot positions work for eye-in-hand calibration covers the spread. Then prove it before production: test the calibration and measure the residual with a part at a known position.

Use the simulated offset as the solver's initial guess and as the sanity check: a calibration that returns a Z offset more than 2-3 mm from the drawn 60 mm points to a modeling error, not a lucky measurement. More worked calibration flows sit on the systems topic page.

Common mistakes

• Parenting the camera to the flange when the gripper already carries the tool transform: the offsets add, and the simulated camera sits one tool-length too high.
• Leaving out the 180° flip: the image arrives upside down, calibration still converges, and picks land mirrored.
• Modeling at the simulator's default 640 × 480 while the real sensor has 2048 × 1216 pixels: the FOV looks fine and the sampling is fiction.
• Checking the FOV at a single pose. Grip-pose occlusion never appears at hover height.
• Treating the simulated transform as final. If picks land a consistent millimeter or two off after calibration, diagnose the eye-in-hand pick point offset instead of nudging pick points by hand.
• Ignoring the connector envelope: a connector that fouls the wrist rotation is a mechanical failure no simulation shows. Leave the service loop in the design.

When a stationary camera beats the wrist mount

A wrist camera sees with the gripper, which is what approach correction and in-grip confirmation need. It also puts cable on a moving arm, mass on the wrist, and a recalibration on every tool change. When the task is locating parts anywhere in a fixed work area, a camera above the base with eye-to-hand calibration setup calibrates once and then never moves. The decision rule: pick-and-confirm on the end effector calls for the wrist camera; part locating over a known region favors the stationary overhead camera. Plenty of cells run both, and the modeling workflow is identical once the stationary camera is parented to the world instead of the tool.

Before you order the hardware

• Size the ground sample distance to the feature: smallest feature / 20 px is the GSD to buy for, then set focal length and height from the FOV formula.
• Global shutter if the wrist is still settling when you snap or anything images on the fly.
• GigE runs 100 m on one cable, so the run down the arm is not the constraint — the drag-chain rating of the cable is.
• C-mount for lens flexibility; integrated M12 optics when you want the simulation fixed and the footprint small.
• Camera, bracket and cable together must stay inside the wrist's payload and moment ratings.

Start from the FOV number, not the model number: the area scan cameras category filters by sensor format and resolution, the camera finder narrows by interface, and the camera configurator steps through the same choices in order. If the inspection can run on the camera itself, the smart cameras category removes the separate controller. To match a camera to the FOV you computed, contact the team.