Inspection, picking and measurement, validated on our own equipment before it reaches your line.
Camera, lighting and thresholds chosen for the actual part and the actual defect, tested against real production samples on a rig that reproduces your line, not tuned against a folder of good photos.
What this is
Machine vision is the decision made from a frame: pass or fail, a measurement in millimetres, a pick coordinate for an arm, running fast and reliably enough to sit on a production line rather than a bench. Most of what determines whether it works is decided before any algorithm runs. A rolling-shutter camera smears a moving part into a diagonal blur, which is fatal on a line that never stops for the shot. Lighting is engineered to the defect rather than left to ambient light: dark-field to raise a scratch off a flat surface, backlighting for a clean silhouette, a diffuse dome to kill glare off machined metal.
The step that fails most often is tuning. A model or a set of thresholds built against a folder of clean photos taken in a lab looks finished right up until it meets the real part population: dust, a burr, a reflection off a slightly different batch of material, the light through a factory window shifting over the afternoon. We build the rig around parts pulled from your own production, not stock images, and we validate on our own equipment first. We can afford to be wrong on our bench. We cannot afford to be wrong on your line.
A result is only useful once something acts on it. That means a hardware trigger synced to the line's own signal rather than a camera polling on a timer, a calibration that maps camera pixels to real-world or robot coordinates, and a communication path into whatever consumes the decision, a PLC, a robot controller, a reject gate. We choose classical vision, edge, blob and gauge measurement, where the geometry is well-defined and the answer needs to be explainable, and a trained model where the defect is too subtle or too variable to write as a fixed rule, which also means it needs a labelled dataset from real parts and enough examples of the defect, not just the good ones.
What you get
Camera and lens, chosen with reasons
Shutter type, resolution against your line rate, working distance, and a telecentric lens where dimensional measurement needs to be free of parallax.
A lighting rig built for the defect
Dark-field, backlight, diffuse dome or ring, whichever makes the specific edge or flaw visible, not generic ambient light.
Calibration
Lens distortion corrected, and for picking, hand-eye calibration mapping camera pixels to robot coordinates.
Inspection or measurement logic
Classical or a trained model, whichever the defect actually needs, tuned against parts pulled from your production.
Trigger and I/O integration
Hardware-triggered off the line's own signal, with the communication path into your PLC or robot controller.
Pass and fail thresholds, documented
The false-accept and false-reject trade-off recorded and agreed, not buried in a config file nobody remembers setting.
A validation rig reproducing your line
Built and run on our equipment first, against your actual part population, before install.
Source, configuration and the dataset
Handed over, so retuning or retraining later does not require us.
When this fits, and when it does not
A good fit
- You need every part checked at line speed, not a sample somebody checks by hand once a shift.
- You are picking or sorting parts that arrive with real variation: orientation, partial occlusion, a batch-to-batch colour shift.
- A measurement has to be repeatable to a stated tolerance, not just a yes or a no.
- An existing vision system was tuned on clean lab photos and is failing on the actual floor.
- The result has to drive a PLC or a robot arm directly, not get read off a screen by a person.
Not a good fit
- Somebody with calipers already checks this once a batch and that is adequate for the volume. A camera system would be solving a problem you do not have.
- The real problem is the PLC logic or the robot cell around the camera, not the camera itself. That is system integration, not this page.
- You need machine safeguarding, light curtains or a certified safety function. That is a certified safety system, not an inspection camera, and we will not blur the two.
- You want generic photo or video AI: tagging, moderation, search. That is different model work, ask about AI instead.
- Your line rate is high enough that the frame grabber itself has to be FPGA-based to keep up. That is FPGA development first and vision logic second.
How it runs
- 01
See the parts and the line
Actual samples, actual lighting conditions, actual takt time. Not photos emailed over.
- 02
Build the rig
Camera, lens and lighting chosen and tested against real defect samples, in-house, before anything ships to you.
- 03
Tune or train
Thresholds or a model tuned against parts pulled from your production, not a synthetic or stock set.
- 04
Integrate
Trigger, I/O and the coordinate handoff into your PLC or robot arm.
- 05
Validate on our equipment
Run against your real part population and record the false-accept and false-reject trade-off, before it goes near your line.
Questions we get
Deep learning or classical vision, which do you use?
Whichever the defect needs. Classical measurement, edge, blob and gauge, is more reliable and explainable for a well-defined geometric tolerance. A trained model earns its cost when the defect is too subtle or too variable to write as a fixed rule, and it needs a labelled dataset from real parts to be worth anything.
Our shop floor light changes through the day, does that break it?
It breaks a system tuned in a lab. We build for it directly: engineered lighting that dominates the ambient light rather than competing with it, and a rig validated against your actual part population before install, not against a controlled demo.
Do you build the picking robot, or just tell it where to pick?
We do the vision and the coordinate handoff: hand-eye calibration mapping what the camera sees to where the robot has to move. The arm itself is off-the-shelf hardware we integrate. If the project is really the robot cell and the line around it, that leans toward system integration alongside this.
Can this replace someone currently inspecting parts by eye?
Where the defect is well-defined and reproducible, yes, and it will not get tired on the night shift. Where the judgement is genuinely ambiguous, the kind of call a trained inspector makes on instinct, a vision system supports that judgement rather than replacing it, and we will say so rather than oversell it.
More robotics and electronics
Have a line that needs eyes on it?
Send parts, or photos of the defect if that is what you have, or the failure a QA process is currently missing. An engineer looks at it and gives a straight answer about whether vision is actually the fix.