Glossary
Definitions of the terminology used throughout the Cheetah docs.
Glossary
The canonical vocabulary for these docs. When a page and the glossary disagree, the glossary wins - and the page has a bug worth reporting.
Core Concepts#
Defect#
A defect is a specific, localized nonconformity found on a part during a program run - a surface flaw, an out-of-tolerance feature, a missing or damaged component. Where a quality check answers "did this measurement pass?", a defect records what is wrong and where. Defects are part of the program run's artifacts and inform the quality report.
Frame#
Within Cheetah inspection data, a frame is an individual capture within a session - an RGB, depth, infrared, or point-cloud capture, stored with the robot's exact pose at capture time. Frames are the finest-grained entity in the data model and the raw input analysis consumes; their files are retrievable over the open REST API.
Operator#
The operator is the person running inspections at the cell: loading the part, starting the program run, and acting on the QC outcome. Cheetah is designed so a single operator can run the full scan → analyze → report pipeline without metrology training. Not to be confused with the Operator application - the on-cell UI the operator uses.
Part number#
A part number identifies a design, product, or component type rather than one individual physical unit. Many physical parts may share the same part number, while a serial number identifies one specific unit.
Depending on the application, a customer's model number or SKU may serve a similar purpose, but these identifiers are not necessarily interchangeable.
Point cloud#
A point cloud is a collection of measured points representing the surface geometry of an object in three-dimensional space. Point-cloud data can be used for dimensional analysis, feature detection, alignment, visualization, and other inspection operations.
Depending on the sensor and inspection workflow, point clouds may be generated directly from captured data or constructed by combining multiple captures.
Program#
A program is the complete, executable definition of an inspection: the motion sequence the hardware follows, the scans captured along the way, and the quality checks evaluated against the captured data. Programs are authored in Program Builder, and every program run records the program it executed - so any result can be traced back to the definition that produced it.
Program run#
A program run is a program executed once against a single part. It is created, begins executing, and ends in exactly one of three ways: completed (a QC outcome was produced), failed (a step errored before producing one), or cancelled (an operator stopped it).
Every program run has a stable run_id, and everything the inspection produced - the quality report, its quality checks, any defects - hangs off that identity. The full life of a program run is covered in Program Lifecycle Events.
Always spelled out in full: these docs never call a program run a "run" or an "execution."
QC outcome#
The QC outcome is the overall result of a program run: pass or fail. It is computed by aggregating every quality check after the program's last step finishes, shown to the operator at the cell, and delivered to your systems as the passed field of the ProgramCompleted event.
A program run that fails or is cancelled ends without a QC outcome - and the reverse holds too: a part that fails inspection still completes its program run and gets a QC outcome of fail.
Quality check#
A quality check is a single named measurement evaluated against a limit - for example flatness measured at 0.04 mm against a 0.10 mm threshold. Each check records its measured value, the threshold it was compared against, the signed delta between them, and a pass/fail status.
The quality report aggregates every check in the program run into the overall QC outcome; the per-check data is delivered in the qc_checks array of the ProgramCompleted event.
Quality report#
The quality report is the primary artifact of a completed program run: the overall QC outcome together with every quality check that was evaluated to reach it.
It is the complete digital record of the inspection outcome - what the operator sees on the cell, what is pushed to your systems when the program run completes, and what you can fetch later by run_id through the open REST API.
Revision#
Within Cheetah inspection data, a revision is the auto-incrementing counter of inspections of a single part. The first program run against a serial number starts the count; each time the same part is inspected again, the new program run is automatically assigned the next revision.
Distinct revisions are distinct inspections of the same physical part - a new revision often means the part was reworked to address a defect and re-inspected. The revision is carried in every lifecycle event payload as revision.
This use of revision is distinct from a hardware, engineering drawing, software, or document revision.
Serial number#
The serial number identifies the individual physical part - the unit on the table, not its design. The design or type is identified by a part number; many units can share a part number, while each unit may have its own serial number.
Every lifecycle event carries serial_number (null if none was captured), and repeated inspections of the same serial number are counted by revision.
Session#
A session groups the frames captured by one scan step of a program run - each capture step creates one. A session carries its own status (active, completed, failed) and is where per-step analysis aggregates.
Sessions are not in event payloads; fetch them by run_id through the open REST API.
Industry Terms#
Calibration#
Calibration is the process of comparing a measurement instrument or system against a known reference to determine its measurement relationship or error. Calibration helps establish that inspection equipment is producing measurements consistent with recognized references.
Calibration is related to, but distinct from, Gage R&R: calibration addresses measurement accuracy relative to a reference, while Gage R&R evaluates variation within the measurement system.
Datum#
A datum is a theoretically exact reference point, axis, line, or plane used to establish the coordinate system from which part geometry is located or measured. Physical features on a part or fixture may be designated as datum features and used to establish those references during inspection.
Datums are fundamental to GD&T and may also be established through fixtures, part geometry, or defined features of an inspection system.
Factory Acceptance Test (FAT)#
A Factory Acceptance Test, or FAT, is a formal evaluation performed before a system is released for shipment or deployment. The FAT verifies that the completed inspection system meets the agreed functional and performance requirements using representative hardware, parts, and inspection programs.
The exact FAT procedure and acceptance criteria are application-specific.
Fixture#
A fixture is hardware used to locate, support, constrain, or orient a part during inspection. Fixtures provide a repeatable relationship between the part and the inspection system and may incorporate locating pins, nests, clamps, datums, or other application-specific features.
Cheetah fixtures are typically designed around the geometry and inspection requirements of a particular part or family of parts.
Gage Repeatability & Reproducibility (GR&R)#
A statistical study that quantifies how much of the variation in a set of measurements comes from the measurement system itself rather than from the parts being measured. Repeatability is the variation when the same system measures the same part again; reproducibility is the variation across different operators or setups.
A measurement system is only trustworthy if its own variation is small relative to the tolerances it judges - Cheetah Validation runs Gage R&R studies of an inspection cell's measurement performance to establish exactly that. The canonical reference is the AIAG MSA manual; ASQ's GR&R overview is a shorter introduction.
Geometric Dimensioning & Tolerancing (GD&T)#
The standardized symbolic language (ASME Y14.5, ISO GPS) that engineering drawings use to specify how much a part's real geometry may deviate from its nominal design: flatness, position, profile, perpendicularity, and so on.
GD&T callouts on a part's drawing are a typical source of the tolerances a program's quality checks evaluate - a flatness check with a 0.10 mm threshold is a GD&T flatness requirement made executable.
Metrology#
The science of measurement - ensuring that a measured value is accurate, repeatable, and traceable to a reference standard. Manufacturers traditionally concentrate this discipline in a dedicated metrology lab with specialist staff; Cheetah's premise is moving dimensional inspection out of that lab and onto the production floor, run by an operator without metrology training.
The rigor doesn't disappear - it moves into the program definition and the cell's validated measurement performance. See Gage R&R.
Nominal#
Nominal describes the intended or theoretically exact value or geometry defined by a design. Actual manufactured parts deviate from nominal geometry by some amount; tolerances define how much deviation is acceptable.
Inspection generally compares measured geometry against nominal dimensions, CAD geometry, or other defined references.
SKU#
SKU stands for Stock Keeping Unit and is an identifier used to distinguish a particular product or product configuration. In Cheetah projects, SKUs are often used to distinguish the different product variants an inspection system must support.
A SKU is not necessarily the same thing as an engineering part number, although some customers use the terms interchangeably.
Tolerance#
A tolerance defines the permitted variation from a specified dimension, geometry, position, or other requirement. A measured feature passes when it satisfies the applicable tolerance or acceptance limits defined by the inspection program.
Tolerances may come from traditional dimensional specifications, GD&T callouts, customer requirements, or other engineering criteria.
Hardware#
3D scanner#
A 3D scanner is a sensor or measurement system that captures the three-dimensional geometry of a part. Cheetah uses industrial laser scanning technologies that generate the spatial measurement data consumed by the inspection software.
Scanner selection depends on the application. Depending on the hardware configuration, a scanner may be carried by a cobot, traversed by a gantry, or integrated into a Rack-Mounted Module Scanner.
3D area scan laser sensor#
A 3D area scan laser sensor captures three-dimensional surface geometry over an area rather than along only a single profile. In the Cobot Scanner, the collaborative robot moves this sensor to multiple positions and orientations around a part so geometry can be captured from multiple vantage points.
The resulting data can be combined and analyzed to inspect features that cannot be effectively measured from a single sensor position.
Cobot#
A cobot, or collaborative robot, is a robot arm designed with features that support collaborative automation applications.
In Cheetah's Cobot Scanner, the cobot carries the 3D scanner through the program's motion sequence and positions it at the required inspection vantage points.
The use of a collaborative robot does not by itself make an application safe for unrestricted human interaction; system safety depends on the complete application and its risk assessment.
Cobot Scanner#
The Cobot Scanner is Cheetah's robot-based hardware platform for parts that benefit from inspection from multiple positions and orientations. A collaborative robot carries a 3D area scan laser sensor around the part, allowing the inspection program to capture geometry from multiple vantage points.
This configuration is particularly useful when important features face different directions or cannot be inspected effectively from a single fixed sensor position.
Control cabinet#
The control cabinet is the factory-integrated enclosure containing the primary electrical and control hardware for an inspection cell. Depending on the hardware configuration, this may include the industrial PC, safety controls, networking equipment, power distribution, robot or motion controls, and laser sensor controllers.
The control cabinet is part of the Cobot Scanner's factory-integrated control system and is not intended as a general-purpose enclosure for customer modification or third-party equipment integration unless otherwise expressly approved by Cheetah.
Other Cheetah hardware platforms use the same general control-cabinet concept, although cabinet layout, location, and installed hardware vary by platform.
Gantry Scanner#
The Gantry Scanner is Cheetah's Cartesian-motion hardware platform for inspecting relatively flat or large-format parts. A multi-axis gantry moves a laser profilometer across the inspection area instead of using a collaborative robot.
Typical applications include sheet-metal assemblies, PCBAs, heat exchangers, and other parts well suited to predominantly top-down scanning.
Hardware platform#
A hardware platform is the physical machine configuration used to perform Cheetah inspections. Cheetah hardware platforms share a common software architecture and operator experience while using different motion systems, sensors, and mechanical layouts for different application requirements.
Current platforms include the Cobot Scanner, Gantry Scanner, and Rack-Mounted Module Scanner.
Inspection bed#
The inspection bed is the configurable mounting surface used for fixtures, tooling, robot mounting, and other application-specific hardware.
On applicable Cheetah platforms, the inspection bed includes a regular threaded-hole grid and additional mounting or datum features that allow fixtures and application hardware to be located repeatably.
Inspection cell#
The inspection cell is the deployable unit on your factory floor: a Cheetah hardware platform plus the onboard compute, controls, sensors, and software required to execute inspections.
One cell runs one program run at a time, end to end - from data acquisition through analysis and reporting.
Laser profilometer#
A laser profilometer is a 3D measurement sensor that projects a laser line onto a surface and measures the resulting cross-sectional profile. As the sensor or part moves, successive profiles can be combined to produce a three-dimensional representation of the inspected surface.
Cheetah uses industrial laser profilometers in applications where precise surface geometry or high-resolution dimensional measurements are required.
Operator panel#
The operator panel is the area of a Cheetah workstation containing physical controls and interfaces used during normal operation.
Depending on the hardware platform, it may include the system power switch, emergency stop, USB connections, and status indicators. The touchscreen HMI provides the software interface used alongside these physical controls.
Rack-Mounted Module (RMM) Scanner#
The Rack-Mounted Module Scanner, or RMM Scanner, is Cheetah's hardware platform for inspecting rack-mounted electronics and similar assemblies.
The system uses Cartesian motion to position scanning sensors over the product and is particularly suited to detailed inspection of connectors, pins, housings, and assembly-level features on server, networking, and other electronic hardware.
Touchscreen HMI#
The touchscreen is the primary human-machine interface, or HMI, used by the operator at an inspection cell. It displays the Cheetah Operator application and provides the interface for starting inspections, viewing system status, responding to prompts, and reviewing inspection outcomes.
Depending on the hardware platform, the touchscreen may be fixed to the workstation or mounted on an articulated arm.
User expansion panel#
The user expansion panel is the external connection area provided for approved integration between a Cheetah inspection cell and surrounding customer equipment.
Depending on the hardware configuration, it may provide connections for discrete I/O, factory networking, device networking, and the external safety interface.
Controls & I/O#
Customer network#
The customer network connection provides the interface between the Cheetah inspection cell and the customer's factory or enterprise network.
It is used for application-level communications such as system integration, data transfer, API access, and other customer-network functions.
Device network#
The device network is intended for Ethernet-connected equipment associated directly with the inspection application, such as sensors, controllers, or other Cheetah-integrated devices.
It is separate in purpose from the customer network, which connects the inspection cell to the customer's broader network infrastructure.
Discrete I/O#
Discrete I/O is a set of individual electrical input and output signals used to exchange simple on/off states with external equipment.
Typical uses include part-present signals, cycle requests, ready or busy states, pass/fail outputs, and coordination with surrounding automation. Cheetah systems provide application-dependent discrete I/O through the user expansion panel.
Emergency stop (E-stop)#
An emergency stop, or E-stop, is a safety control intended to stop hazardous machine motion or operation when an emergency condition occurs.
The E-stop is part of the inspection cell's safety system and should not be used as the normal method for stopping a program or shutting down the workstation.
External safety interface#
The external safety interface allows a Cheetah inspection cell's safety system to be connected to surrounding machinery or facility safety circuits.
Depending on the platform and application, it can allow an external safety device to place the Cheetah system into a safe state and can provide safety-status feedback from the Cheetah cell to other equipment.
PNP and NPN input/output#
PNP and NPN are common 24 VDC industrial I/O conventions that describe how a signal switches electrical current.
- PNP devices source positive voltage when active.
- NPN devices switch the signal toward 0 VDC when active.
Cheetah's standard discrete user I/O uses PNP signaling. External equipment connected to these signals must use compatible electrical interfaces and follow the requirements documented for the specific hardware platform.
Status lights#
Status lights provide an at-a-glance visual indication of inspection-cell state. Cheetah hardware platforms use configurable RGB indicators to communicate conditions such as system state, inspection status, or conditions requiring operator attention.
The exact colors and behaviors are defined by the system software and application configuration.
System power switch#
The system power switch is the illuminated operator control used to start and shut down the inspection workstation during normal operation.
On applicable Cheetah systems, turning the system power switch off initiates a managed shutdown of the onboard computer and control system. It should be used instead of disconnecting workstation power or switching off the internal circuit breaker during normal operation.
Software Integration#
Open REST API#
Cheetah's open REST API, served by cheetah-service. Where lifecycle events push to you as they happen, the open REST API is the pull side: query programs, program runs, and inspection results on your own schedule - reconciliation after downtime, backfill, historical reporting.
Start with the quickstart and the API reference.
Two official client libraries wrap the open REST API, versioned alongside cheetah-service:
Program Lifecycle Events#
The four events Cheetah emits as a program run moves through its life: ProgramStarted, then exactly one of ProgramCompleted, ProgramFailed, or ProgramCancelled.
Each event is about exactly one program run and is pushed to your systems as it happens - this is the real-time half of an integration. See Program Lifecycle Events for what they mean and the event reference for exact payloads.
Support#
Tailscale#
The secure remote-access layer used for Cheetah support. Tailscale is a WireGuard-based mesh VPN; with it enabled, Cheetah support engineers can reach a deployed cell for diagnostics and updates without any inbound ports opened on your factory network.
Traffic is end-to-end encrypted and access is scoped to the cell. See Support for how to engage support.