Creating an Object
system/create-object cuts a rectangle out of a live camera image and saves it as an object. It is
how you teach an object from the real camera, in the real lighting, at the real working distance.
It is an application-wide operation, not a per-module one: it writes into the one object directory every module shares, so an object taught once is findable by every module.
Inputs
| Node | Meaning |
|---|---|
|
Address of the image node to cut from. |
|
The object’s name. Becomes |
|
Top left corner of the region to cut. |
|
Size of the region. Both must be greater than 0. |
Teaching an object
-
Put the part in front of the camera in the orientation it actually arrives in.
-
Set
object-idto the object’s name. -
Set the crop around the part and write to
execute.
system/create-object/input/input-image-address = hdvisionsystems/lumiscan-cam-driver/camera1/output/image system/create-object/input/object-id = screw-m6 system/create-object/input/crop/startX = 820 system/create-object/input/crop/startY = 400 system/create-object/input/crop/width = 160 system/create-object/input/crop/height = 120 write system/create-object/execute
The picture is written to <object-dir>/screw-m6.png and system/objects picks it up straight away.
Several orientations
The detector does not rotate the picture, so one object is one appearance. A part that arrives at
more than one orientation needs one object per orientation - screw-m6-front, screw-m6-tilted -
and a find-object run for each.
|
Start with the orientations the part really arrives in. Each extra view costs a little matching time and buys tolerance to that one orientation - there is no value in views you will never see. |
How tight to crop
Leave a few pixels of background around the part - but only a few. Both directions cost you something, and the tight side is the one that fails quietly.
The detector keys on gradients, and an edge only exists where there is something different on the other side of it. Crop exactly along the part’s silhouette and there is nothing on the other side, so the outline produces no features at all. The detector blurs 7x7 and then runs a 3x3 Sobel, both replicating the edge pixel outward, so it discards the outermost ring of the picture and computes weakened gradients for about 4 pixels in from any edge.
|
A crop that stops at the silhouette hides the part’s outline from the detector. Either the object is refused outright - reported as a failed run naming it, because a template must yield a minimum number of strong gradient points - or it is accepted but keyed only on the part’s interior detail. The detector shrinks the template to the region where it found features, so it then matches on less than the picture shows, and a part that is distinctive mainly in outline matches poorly. |
About 5 pixels of margin is enough and more buys nothing. Background inside the template is background the detector then expects to see, so a loose crop that takes in a workbench edge or a neighbouring part makes matching less reliable. Aim for a thin, even band of the surface the part normally sits on.
On success output/object-path reports the file that was written, relative to the configuration
directory, and system/objects is refreshed. Every module retrains before its
next detection, so a new view is usable immediately.
Failures
The whole crop must lie inside the image. A region that overflows is refused, naming the edge and the image size:
error: Crop region does not fit inside the 1920x1080 image: crop/startY + crop/height (1000 + 200 = 1200) exceeds the image height 1080
object-id is interpreted relative to the configuration directory. An absolute
path, or one climbing out with .., is refused with status -2.
output/object-path is emptied when a run starts, so a failed run never leaves a path pointing at
a template it did not write. See Execution Status.
Failures are described step by step in Troubleshooting: