How Industrial Computer Vision Works at the Edge: From Cameras to Machine Controls
An industrial PPE detection application showing what it takes to turn camera data and an AI model into a working embedded system.
Industrial computer vision is most useful when it does more than draw boxes on a screen. A field-ready system must receive video from the actual cameras, run a trained model on suitable edge hardware, interpret the detections, apply decision logic and communicate with the machine.
For one industrial vision application, SwitchBox built that complete path. Automotive Ethernet cameras supplied live video to an embedded platform built around an NXP i.MX 8 QuadMax processor and a Hailo-8 AI accelerator. The application monitored for missing hard hats and high-visibility vests. When either condition was detected, the application triggered an audio output and a red indicator light through the machine controller.
The project demonstrated an important distinction: an object detection model is one component of an industrial computer vision system. The value comes from engineering the full camera-to-action path.
The short answer
An industrial edge vision system normally combines five layers:
1. Cameras that produce usable images in the real operating environment.
2. An application processor that receives video and runs the embedded software.
3. An AI accelerator that performs neural-network inference.
4. Post-processing and decision logic that turn raw model outputs into reliable events.
5. Machine interfaces such as CAN, digital outputs, audio or displays that make the detections useful.
In the SwitchBox application, the i.MX 8 hosted Yocto Linux and the video application, while the Hailo-8 executed the neural network. The surrounding software connected detections to machine I/O. Inference occurred locally, without sending every frame to the cloud.
The real application: detecting missing PPE
The initial use case monitored live camera feeds for two conditions:
• A person without a hard hat
• A person without a high-visibility vest
When the application detected either condition, it activated an audio output and a red indicator light.
That behavior sounds straightforward, but every phrase in the requirement creates an engineering decision. The team must define what counts as a person, how much protective equipment must be visible, how long a condition must persist, how the system should respond to uncertain detections and what happens when a camera or accelerator is unavailable.
The model supplies evidence. The embedded application determines what the machine does with that evidence.
This distinction matters for safety-related applications. Unless the complete system has been engineered and validated to the applicable safety requirements, it should be described as supporting monitoring or operator awareness, not as a safety-rated control function.
The system architecture
The project combined the following components:
Component | Role in the system |
Automotive cameras | Capture live images from the operating environment |
NXP i.MX 8 QuadMax | Runs Yocto Linux, receives camera data and hosts the application |
Hailo-8 accelerator | Executes the compiled object detection model |
GStreamer | Moves video through decoding, conversion, inference, post-processing and display |
Fusion machine interfaces | Connect detections to CAN, digital I/O, audio, displays and other outputs |
The project used a TTControl Fusion platform equipped with Hailo-8 acceleration.
TTControl's Fusion 844AI datasheet identifies this integrated configuration as an NXP i.MX 8 QuadMax host with a Hailo-8 accelerator, Linux, CAN, automotive Ethernet, GMSL2 and GPIO interfaces.
This division of responsibility is important. The i.MX 8 is the host processor for Linux, cameras and machine integration. The Hailo-8 is the dedicated accelerator that runs the neural network.
Start with the machine response, not the AI model
A useful discovery process begins with what the customer wants the equipment to do.
Questions should include:
• What condition needs to be detected?
• What should happen when it is detected?
• Is the output advisory, operational or safety-related?
• Should the response use CAN, GPIO, an indicator, audio, a display or another interface?
• How quickly must the system respond?
• How many consecutive frames should confirm the condition?
• What false-positive and false-negative behavior is acceptable?
• What should happen if the camera, network stream or accelerator fails?
These answers influence the model, camera placement, compute platform, interface design and validation plan. Choosing a neural network before defining the machine behavior can lead to a technically impressive model that does not solve the actual problem.
Camera selection is part of the vision system
The quality of the deployed model depends on the images it receives. Resolution, compression, frame rate, field of view, lens distortion, lighting and camera position all affect detection behavior.
The development system used automotive Ethernet cameras. These cameras sent compressed video over the network, so the embedded pipeline had to receive packets, interpret the compression format, decode the stream and convert frames into the size and format expected by the model.
Automotive Ethernet can be attractive when the equipment already uses networked cameras or needs longer cable runs. It also introduces compression, network configuration and stream-decoding considerations.
GMSL2 cameras offer another path. They can move high-quality sensor data and control signals over a coaxial connection with low latency, but require compatible serializer, deserializer, driver and physical-integration support.
The right choice depends on the application:
Consideration | Automotive Ethernet camera | GMSL2 camera |
Video path | Network stream, often compressed | Direct serialized sensor link |
Integration focus | IP configuration, packets, codec and decode pipeline | Serializer/deserializer, drivers and sensor configuration |
Image quality and latency | Influenced by compression and network path | Often selected for lower-latency raw sensor transport |
Best fit | Existing Ethernet camera architecture or networked equipment | Purpose-built embedded camera architecture |
Neither interface guarantees a better detection result by itself. The camera, lens, mounting location, lighting and pipeline must be validated together.
What images and information does a customer need to provide?
A custom vision project needs data from the environment where the system will operate.
Generic internet images rarely capture the exact camera perspective, clothing, equipment, lighting and background conditions of an industrial application.
Useful source material includes:
• Images or video from the intended camera model
• Day, night, indoor and outdoor conditions when applicable
• Different operator positions and orientations
• Normal examples and difficult edge cases
• Empty scenes and negative examples
• Partial occlusion and motion blur
• Different clothing, equipment and background combinations
• Examples of objects that may be confused with the target classes
The customer and engineering team also need an agreed definition of each class. For PPE detection, that includes questions such as whether a partially visible hard hat counts, how an open jacket affects vest visibility and whether the system detects equipment presence or explicitly identifies its absence.
Clear labeling rules prevent the dataset from teaching inconsistent behavior.
Can an edge vision system communicate with CAN and other machine interfaces?
Yes. Once the application converts model output into a confirmed event, it can communicate through the interfaces available on the controller.
In this project, the Fusion platform exposed CAN, digital inputs, digital outputs and PWM through its libhal hardware abstraction library. The wider platform also provided audio and display capabilities. The initial application used audio and a red light, but the same integration pattern could support:
• A CAN message to another controller
• A digital output to an indicator or relay
• A display warning for the operator
• An event record for later review
• A request for another machine state or workflow
The application should not react to every individual model result without context. Practical logic may require detections across multiple frames, separate activation and deactivation thresholds, alert suppression and defined fallback behavior.
Why perform inference at the edge?
Edge inference processes video near the cameras and machine instead of relying on a continuous cloud connection.
Depending on the application, this can provide:
• Local response without a cloud round trip
• Reduced network bandwidth because every frame does not need to leave the machine
• Greater control over where image data is processed
• Continued operation when an external connection is unavailable
• Direct integration with local CAN, GPIO, audio and display interfaces
Edge processing does not eliminate systems engineering. It shifts responsibility for compute capacity, storage, thermal conditions, software updates and fault handling onto the product.
The difficult work is between the components
The major engineering challenges were not limited to model training.
The complete system needed compatible versions of the Yocto image, HailoRT, Hailo compilation tools, GStreamer plugins and post-processing libraries. The camera pipeline had to match the actual compressed Ethernet stream. The post-processing code had to understand the exact output tensors of the compiled model. A target-compatible shared library had to be built for ARM64. Finally, the detections had to be translated into controlled machine behavior.
These boundaries are where many prototypes become difficult to productize:
• A model runs on a workstation but cannot be compiled for the target accelerator.
• An HEF runs on the accelerator but returns outputs the application interprets incorrectly.
• A sample camera pipeline works with a USB webcam but not with the production camera stream.
• The detection is correct, but the alert logic creates nuisance alarms.
• Individual components meet their targets, but the complete video-to-response latency does not.
Successful embedded vision development verifies the interfaces between layers, not only the components in isolation.
Other industrial computer vision applications
The reusable value of the project extends beyond PPE monitoring. It established a pattern for receiving video, running custom inference, interpreting the result and connecting it to equipment.
With application-specific data, requirements and validation, the same pattern can support:
• Restricted-zone and personnel awareness
• Required tool, component or material verification
• Visual inspection and assembly checks
• Object counting and material tracking
• Machine-state recognition
• Process-step confirmation
• Operator assistance and contextual alerts
• Mobile equipment and off-highway perception features
These are not plug-and-play extensions. Each use case needs its own dataset, thresholds, decision logic and failure analysis. The camera-to-inference-to-I/O architecture, however, can be reused across many applications.
How to scope an industrial edge vision project
Before selecting hardware or collecting thousands of images, define six things:
1. The condition to detect and the business or operational value.
2. The camera environment, including placement, lighting, distance and motion.
3. The machine response and required communication interfaces.
4. The acceptable false-positive, false-negative and response-time behavior.
5. The target hardware, operating system and software-update constraints.
6. The validation plan for the model and the complete application.
That information makes it possible to estimate the data effort, model complexity, compute requirements and integration scope with far more confidence.
The result
The SwitchBox project connected live automotive camera feeds to a custom YOLOv8 model running on Hailo-8, with an i.MX 8 host managing the Linux application and GStreamer pipeline. Custom post-processing produced usable detections, and Fusion I/O translated those detections into audio and visual alerts.
No cloud connection was required for inference. The result was not merely an AI demonstration. It was a complete embedded vision application connected to the machine.
Frequently asked questions
Is the object detection model trained on the i.MX 8?
No. The model is trained and compiled on a separate Linux development workstation. The i.MX 8 hosts the embedded application, and the Hailo-8 executes the compiled neural network.
Does an industrial vision system require cloud connectivity?
Not necessarily. This application performed inference locally. Cloud services may still be useful for fleet management, updates, analytics or long-term storage, but they were not required to process each frame.
Can detections trigger a CAN message or physical output?
Yes, when the selected controller exposes those interfaces and the application is designed to use them. The project connected detections to audio and a red indicator through the Fusion platform, and the same architecture can support CAN or GPIO outputs.
How much training data is required?
There is no universal image count. Data quality, class complexity, environmental variation and performance requirements all matter. Representative images from the real camera and operating environment are more valuable than a large collection of unrelated images.
Is PPE detection automatically a safety-rated function?
No. An AI-based monitoring feature should not be described as safety-rated unless the complete system has been developed and validated to the applicable safety requirements.
Continue the series
Moving forward, we will have Part 2 and Part 3 posted below as they come available. Part 2 will cover How to Train and Compile YOLOv8 for Hailo-8, and Part 3 will cover How to Depoly Yolov8 on i.MX 8 with Hailo-8, GStreamer and Yocto.
Comments