ABB's Integrated Vision System gives a RobotStudio cell 2D vision: enough for presence checks, labels and fasteners, and useless for a 0.2 mm dent or a panel seated 1 mm proud in its fixture. The upgrade is a robot-mounted 3D camera, and simulation is the right place to prove it, because reach, cycle time, data flow and the dent-volume math can all be settled before a single bracket is cut. This guide walks that path: the depth precision a dent demands, the sensor class that delivers it, flange mounting, the pose-and-cloud loop through the virtual controller, and the volume arithmetic at the end. You finish with a pre-hardware checklist you can defend to a project board.
Can ABB RobotStudio simulate a 3D camera directly?
No. RobotStudio executes real controller code, kinematics, collision checks and I/O timing, but it does not compute how a fringe pattern falls on painted sheet metal, so a 3D camera enters the station as a pose-and-cloud loop rather than as an optical model.
The virtual controller inside RobotStudio runs the same controller software as the real cabinet, so your RAPID scan routine, zone data, output pulses and fault handling behave as they will on the floor. The station side of that set-up is well trodden: the RobotStudio IRC5 virtual controller set-up walkthrough covers stations, systems and the handover to real hardware.
What no vendor supplies is the optics. RobotStudio computes kinematics and collisions, not how projected fringes land on metallic paint, and ABB's own vision option stays 2D. So split the problem: RobotStudio answers whether the robot reaches every view, how long the cycle takes and whether the handshake works; the point-cloud side answers whether the dent is there and how deep it is. The same split governs a real cell, which is what makes the exercise honest. The hardware-side version of that division is covered in 3D camera robot integration: check compatibility.
How much 3D resolution does a minor dent need?
Plan for depth noise of 0.05 mm or better and lateral sampling of 1 mm: a typical door ding runs 0.1-0.3 mm deep and 5-20 mm across, so depth precision, not pixel count, is the spec that picks or kills a sensor.
Two rules set the budget. Depth noise must be at most a third of the shallowest dent you must catch, and lateral sampling at most a quarter of its diameter:
A representative door ding is 0.15 mm deep and 10 mm across, so the rules give 0.05 mm depth noise and 2.5 mm sampling; run the analysis grid at 1 mm so a detector sees real shape instead of stair-steps. Depth is the hard half, because 0.05 mm at a 500 mm stand-off is one part in ten thousand. Lateral is easy by comparison: 300 mm of panel at 0.5 mm per pixel is only 600 pixels across, and almost anything in 3D sensors clears that bar.
The class comparison settles the choice:
| Sensor class | Typical depth noise | Verdict for a 0.15 mm dent |
|---|---|---|
| Time of flight | about 1% of range, so ±10 mm at 1 m | Out by a factor of 200 |
| Passive stereo | about 1/1000 of distance, so 0.5 mm at 500 mm | Out by a factor of 10 |
| Projected structured light | 0.02-0.10 mm close up | The default choice |
| Laser profiler, rastered | 0.005-0.05 mm in Z | Yes, but slower over an area |
For a wider view of the method trade-offs, read 3D scanning method selection for inspection.
Which 3D sensor type should the simulated camera be?
Choose projected structured light for panels and keep a speckle or ToF volume camera for gross volume only: fringe projection holds 0.02-0.10 mm depth noise at close range, while the volume-camera class works in whole millimetres and cannot see a dent at all.
The class to simulate first is projected structured light, represented here by the MV-DPS200P-02, a projected structured-light 3D camera: one mount, one dwell, a full height map of the panel in view.
- Type
- Stereo / structured light
Two neighbours cover the edges of the task. The MV-DLS300P-04 is a laser galvanometer stereo camera, worth simulating where one mount must cover more area. On the volume side, a depth camera such as the MV-DT01WMU, a ToF sensing camera, suits gross volume measurement of cartons and loads — right for the volume half of a logistics cell and wrong for dents.
| Specification | MV-DPS200P-02 | MV-DLS300P-04 | MV-DT01WMU |
|---|---|---|---|
| Near field of view | 180 mm × 160 mm @ 250 mm | 280 mm × 220 mm @ 400 mm | – |
| Far field of view | 420 mm × 320 mm @ 500 mm | 620 mm × 440 mm @ 800 mm | – |
| Clearance distance (CD) | 250 mm | 400 mm | – |
| Measurement range (MR) | 250 mm | 400 mm | – |
| Repeatability (Z-axis) | 0.02 mm @ 300 mm | 0.03 mm @ 600 mm | ±(10+0.5%depth1)mm |
| VDI/VDE accuracy | 0.03 mm @ 300 mm | 0.05 mm @ 600 mm | – |
| Resolution | 3200 × 1944 @ RGB image; 1632 × 1264 @ depth map | 3200 × 1944 @ RGB image; 1632 × 1080 @ depth map | Depth map: 640 × 480 @ 30 fps; RGB image: 1280 × 1024 @ 30 fps |
| Data type | Raw image (mono + color), Depth map, RGB-D image | Raw image (mono + color), Depth map, RGB-D image | Intensity image, Color image, Depth map |
| Acquisition time | 0.2 ~ 0.7 s | 0.4~0.9 s | – |
| Image output latency | 0.5 ~ 1.2 s | 0.8~1.5 s | 133 ms |
| Dimension | 126 mm × 90 mm × 50 mm | 236.3 mm × 79.8 mm × 98.5 mm | 91 mm × 26 mm × 31.2 mm |
| Weight | 0.74 kg | Approx. 1.3 kg | Approx. 70 g |
| Price | $8,829.00 · quoted | $16,579.00 · quoted | Price on request |
Values as printed in each product's data sheet; open a part for its drawing and full specifications.
Glossy body paint is survivable by design: coded projection that combines Gray-code stripes with phase shifting is the established technique on specular surfaces. The method is not the risk; exposure and incidence angle are, and the mounting section below handles both.
Keep the genuinely 2D tasks 2D. Presence, label and fastener checks run faster on smart cameras; reserve the cloud for geometry.
How should the camera sit on the robot flange?
Work at 300-600 mm stand-off, keep the optical axis within about 15 degrees of the panel normal, and budget a hand-eye calibration residual of 0.1-0.3 mm for a flange-mounted camera against 0.05-0.1 mm at a fixed station. That residual comes straight out of your dent budget, so choose the layout with it in mind.
Eye-in-hand earns its calibration cost when one robot must see several faces of a part in one fixturing. A fixed overhead station gives tighter repeatability and a simpler laser safety case, with the robot presenting parts. For a single robot auditing whole body panels, mount the camera on the flange; that is the layout worth simulating.
Every structured-light camera has a narrow usable working-distance window; outside it the pattern defocuses and depth noise climbs steeply. The 3D camera working distance and positioning guide works through the geometry. Hold the panel within about 15-20 degrees of the optical axis for fringe contrast, and expect holes in the cloud past 60-70 degrees of incidence. That limit, not robot reach, is what forces multiple views per panel.
Cross-polarization tames metallic gloss at a price of about two stops, a factor of four on exposure. A pattern set that needs 20 ms per frame at baseline needs 80 ms polarized; sixteen frames then cost 16 × 80 ms = 1.28 s per view instead of 0.32 s. Budget the dwell for the polarized case from day one, or the simulated scan step is out by the same factor of four.
How does the point-cloud loop run through RobotStudio?
The robot logs its flange pose at every scan trigger, you transform each cloud from the sensor frame into station coordinates with that pose, and stitch neighbouring views with 15-25% overlap. RobotStudio supplies the poses and the timing; the camera SDK supplies the clouds.
- Import the camera CAD as a tool, set the tool frame at the sensor origin, and check reach, collision and cable dress across the whole panel set.
- Write the RAPID scan routine on the virtual controller: move to view, settle, pulse the trigger output, log the flange pose with a timestamp, advance. Iterate until no view is unreachable and no cable pinch appears.
- Generate clouds three ways, best first: recorded scans from a demo unit, the vendor SDK in offline mode, or synthetic depth renders from the panel CAD.
- Transform every cloud by its pose into station coordinates, then stitch overlapping views; keep three reference spheres per panel so stitching error lands an order below dent depth.
- Run the dent and volume analysis below and return the verdict over simulated device I/O, because that is what actually tests the PLC handshake. Matching each cloud to the right pose by timestamp is its own failure mode; asynchronous vision result frame matching with timestamps covers the pattern.
- Play the poses back as a trajectory to catch uncovered strips of panel; 3D camera trajectory visualization from pose updates shows the technique.
The station work is standard; the RobotStudio configuration for an arc-based 3D printing cell walkthrough follows the same station, system and virtual-controller path you need here.
Size the loop with real numbers. A 600 × 400 mm panel under a 300 × 250 mm field at 25% overlap takes 3 × 3 = 9 views; at 1.5 s dwell plus 0.8 s average move that is 9 × 2.3 ≈ 21 s per panel. Each view at 1.3 million points, stored as binary XYZ float32, is 1.3 M × 12 B ≈ 15.6 MB, so about 140 MB per panel. Keep it binary: ASCII roughly triples the file.
Run that math on a vision controller, not on the robot controller. Vision controllers give the camera dedicated ports and keep point-cloud load away from motion timing.
How do you turn the cloud into a dent volume?
Fit a reference plane to the undamaged panel around the damage and integrate the signed height difference over the dent footprint: a 0.15 mm deep, 10 mm wide ding then reports about 11.8 mm³, from 78.5 mm² of area times 0.15 mm of mean depth.
Work it through. A circular ding 10 mm across has an area of π × 5² = 78.5 mm²; at 0.15 mm mean depth the volume is 78.5 × 0.15 ≈ 11.8 mm³. On the 1 mm grid that footprint holds about 79 samples, so per-point noise of 0.05 mm averages down to 0.05/√79 ≈ 0.006 mm on the mean depth. The volume figure is roughly ten times steadier than any single depth reading, which is why displaced volume is a better pass criterion than peak depth.
Whole-part volume behaves the opposite way. A flatness or calibration bias of 0.05 mm integrates to 90,000 mm² × 0.05 mm = 4,500 mm³ (4.5 cm³) over a 300 × 300 mm patch, while random noise averages down as above; hunt bias, not noise, before quoting part volumes. Counting voxels is the standard route there: voxel spacing volume calculation for segmented regions and storing point cloud data in a voxel grid cover the mechanics, and 3D cylinder head volume measurement for inline inspection is a worked production case.
Detection comes free from the same plane fit: the height residual map is exactly what a blob detector wants, and 3D surface blob analysis for dents on tilted parts runs that step end to end.
Where will the simulation disagree with the real cell?
Count on four gaps: dark or glossy paint inflates depth noise by 1.5-2× over the matte-white datasheet condition, stitching without reference targets drifts 0.2-0.5 mm across nine views, real cycles run 10-30% longer than the virtual controller's motion time, and CAD panels do not flex like stamped ones.
Paint is the biggest one. Datasheet depth noise is measured on matte white at the stand-off sweet spot; dark reds and metallic blacks push it out 1.5-2×. The counters are cross-polarization, a 10-15 degree tilt away from the specular direction, or matte spray for lab validation only.
Pose-only stitching drifts 0.2-0.5 mm over nine views, the size of the dent itself, so reference spheres are fixtures, not accessories. Cycle time misses because image transfer, cloud compute and the PLC handshake live outside the virtual controller; carry 10-30% contingency on the simulated takt. And a fixture that bows a real panel by 0.2 mm writes a dent-sized signal into every scan, so validate the fixture in the model, then on a real panel with a dial indicator.
A smaller cousin of every gap above appears between a viewer's shaded render and the raw exported data; why exported point clouds differ from the viewer render catalogues it.
What should you check before ordering hardware?
Demand these seven items in order: measured depth noise on your darkest panel, a working-distance window with margin, CAD and mass for the flange model, a pose-logging SDK with binary export, the laser class off the label, stitching targets, and a controller with camera ports plus its own PLC link.
- Depth noise on dark paint, measured, at most 0.05 mm. The white-target datasheet figure will not survive metallic black.
- A working-distance window covering your stand-off with 20% margin at each end. Structured light degrades fast at the edges of its window.
- Camera CAD, mass and centroid from the vendor. Your tool frame, wrist load and collision model all hang on them.
- An SDK that logs poses and exports binary XYZ. ASCII-only export triples storage and slows the loop.
- The laser class, read off the label, feeding the interlock and eyewear plan.
- Three reference spheres per panel, visible in at least two views each.
- A controller built for the split. The robot motions; the vision controller computes. The MV-SVC2506-16G60-128G is one such vision controller, with 4 camera GigE ports, a configuration port, a communication port and 16 GB of memory.
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 2 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 16 GB
When the checklist passes, take the camera choice into the camera finder or build the full set in the system configurator. For scan-path and sensor selection review, the contact page reaches the applications team, and volume-only cells can go straight to a quote request.
Questions
Can ABB Integrated Vision detect the dents without a 3D camera?
For shallow dents, no, and it cannot measure any of them. Under grazing light a dent of roughly 1 mm or deeper shows as a shading change a 2D tool can flag, but a 0.15 mm door ding vanishes into paint texture, and no 2D image yields depth or displaced volume. Keep Integrated Vision or a 2D smart camera for presence, labels and fasteners; put geometry on the 3D camera.
How do you create point clouds before the camera exists?
Render depth maps from the panel CAD in any 3D tool, then corrupt them until they are honest: add Gaussian noise of about 0.05 mm per point, drop points where surface incidence exceeds 70 degrees, and thin edges to match the sensor footprint. Better still, ask for recorded scans of a similar surface from a demo unit. Synthetic clouds prove the math; recorded clouds prove the optics.
How much storage does one scanned vehicle need?
Plan near 0.85 GB per vehicle. Nine views per panel across six panels is 54 views, and at the 140 MB per panel the loop produces, a full body lands around 840 MB per pass. Archive the 1 mm analysis grid instead, roughly 90,000 points or about 1 MB per panel, and keep full-resolution clouds only for rejected parts.
Does the point-cloud math need a vision controller, or will the robot controller do?
The robot controller will not do it. It is built for motion and I/O, while one stitched panel cloud is millions of points, and the plane fit, blob detection and volume integration want a PC-class processor. A vision controller with dedicated camera ports also isolates that load from motion timing and gives the PLC its own link: the robot hands over poses, the vision controller hands back the verdict.
Which coordinate frames must stay straight in the loop?
Four of them: the station (base) frame, the robot flange frame, the sensor frame fixed to the flange, and each cloud's native frame. The robot gives you base-to-flange; hand-eye calibration gives flange-to-sensor; applying both lands the cloud in station coordinates. One wrong sign and the cloud arrives mirrored or upside down. Recognize that symptom before you blame the calibration itself.