One interface panel from vision software incorporates key design principles. Source: Dalsa
It is possible to look at a vendor’s specifications and verify that a machine vision system’s hardware meets the application’s needs. However, vision software specifications are not as easy to determine because each vision problem is, in many respects, unique, and vision software can be complex. The vendor might list provided algorithms, such as finding part locations, and give an idea of what it is like to use the software, but trying the software is often necessary to validate that it meets the requirements. An evaluation should consider how easy the software is to use, as this can make or break a project.
Three Components of Vision Software
Vision software can be divided into three components. First, algorithms provide vision capabilities for operations such as finding parts, measurements on parts and reading barcodes. The software vendor has worked hard to make these algorithms fast, accurate and stable. The vendor can provide some performance specifications, but treat these specifications as estimates, as they are not based on a specific vision problem.Second, the developer interface or design-time interface (DI) is used to specify the algorithms and operations needed to solve the vision problem. As an example, the DI might train a vision system to find a particular part and then make a series of measurements on it for quality control.
Third, the user interface (UI) or run-time interface is what is presented to the person using the system, such as the operator or line engineer. The UI must be easy and obvious to use for someone unfamiliar with machine vision. In some products, the UI and the DI are the same but the DI can be locked so that individuals cannot change the underlying algorithms and operations.
Ease-of-use is a key factor in evaluating and using the DI and UI. In the past, the DI was often programming to a C library or perhaps learning a scripting language. As might be expected, using this kind of DI was difficult and slow because the operator had to learn the details of the library or language. The UI was often hand coded for each vision task.
Most modern vision software has both a graphical DI and UI and is much faster and easier to use. Software libraries still have performance advantages in demanding applications. To ease development, some libraries now have a “wrapper” of graphical tools.
This developer interface-which shows a seat-belt axle being calipered and, below it, a graphical property page for caliper measurements-can be locked or wrapped for a user interface. Source: ESI
The Human Factors
Let’s look at some of the factors that make vision software easy to use. Research on human factors provides ideas on how to design easy-to-use, human-software interfaces. This research started with how to physically place controls, say in a car or airplane, so that they were ergonomic-easy to understand and use.There are some simple lessons from human factors that help make vision software usable. The DI and UI should be graphical-a graphical interface is faster and simpler than text commands (think Windows vs. DOS). The graphical controls should be chosen to be isomorphic-structurally mapped-to the underlying operation. For example, a slider control for setting camera exposure time is more natural than entering an exposure time in milliseconds.
Button controls should be large enough to target and click, as described by “Fitts’ Law,” which explains a speed/accuracy trade-off connected with pointing, whereby targets that are smaller or further away require more time to acquire. Icons also should be well chosen to represent the operation they control. Operators want to have graphical interaction with images, say by putting a rectangle around a part to be identified rather than having to specify image coordinates.
Large buttons with icons that represent their operation (such as barcode reading) are used to select operations. These operations are applied by selecting image areas such as rectangles or circles on the image itself. In this software, the DI and UI are the same, but the UI can be locked to prevent operators from tampering with the inspection.
Minimizing Mental Effort
Now consider some of the logical or mental issues that go into the design of vision software. Controls should be grouped logically and hierarchically so that an operator knows where they are and how to drill down for more detail. Common ways to do this are to use property pages to group relevant information and to have a cascade of options.Perhaps the most important design principle is to present the vision system’s capabilities in a way that minimizes mental effort. The interface should not leave the operator wondering what to do next. The operator’s mental effort should be focused on the vision task-not on how to operate the software. Aside from grouping relevant interface options, some vision software uses wizards or tools to provide guidance, for example walking the operator through parameter selection for an algorithm. Extensive help and documentation is important, even though no one likes to read manuals.
Another important way to reduce mental effort is to present the system’s capabilities in familiar terms. For example, the interface should have “calipers” not “edge detectors.” This allows operators to develop and use the vision system without being forced to learn vision algorithms. Access to the underlying algorithms might available for more experienced developers.
When evaluating a vision system, look beyond the hardware specifications and into what the software can do and how easy it is to use. This is best done by trying the software while keeping in mind the factors described above. Easy-to-use software can solve a vision problem in days, but the lack thereof can kill a project.
Ben Dawson is director of strategic development at Dalsa Corp. (Waterloo, Ontario, Canada). For more information, call (978) 670-2050, e-mail [email protected] or visit www.dalsa.com.
