Deploy a Custom YOLO Model on NE503: From ONNX to a Verified Camera App

The Verified Result

CamThink trained a two-class YOLOv8n safety helmet model, exported it as a static ONNX model, compiled it for Hailo-15H, loaded the resulting HEF on NE503 and connected it to an on-camera application.

The model reached 0.931 mAP50 on its validation set. The deployed application then passed a live NE503 verification with nine people in the scene: six labelled Helmet and three labelled No Helmet.

What each result proves

The validation metric measures the trained model on a held-out dataset. The device test confirms that the compiled model, NE503 AI Runtime and application can work together on the camera. A production project should still test its own scene, lens, lighting and event rules.

What You Need Before Starting

• A trained object detection model and the class definitions used by the application.
• Representative images for calibration and later site testing.
• A Linux x86_64 environment with a Hailo Dataflow Compiler version compatible with the target NE503 software.
• Access to the NE503 Web Console for model and application deployment.
• An ARM64 container application that can consume NE503 inference results and apply business logic.

The reference workflow used YOLOv8n and Hailo DFC v5.3.0. Treat those as a tested baseline, not a universal compatibility promise for every model or software release.

The Path from Trained Weights to a Camera Application

1. Lock the model contract. Define the input shape, class order and output behavior that the application will consume.
2. Export a static ONNX model. The verified example used [1,3,384,640], opset 11 and dynamic axes disabled.
3. Compile for Hailo-15H. Parse ONNX into HAR, optimize and quantize it with representative calibration images, then compile the optimized HAR into HEF. The tested helmet workflow used 2,048 calibration images.
4. Register the HEF on NE503. Import the file in Model Management, assign the model ID expected by the application and confirm that the model reaches Loaded status.
5. Deploy the application independently. Upload its app.yaml and ARM64 image.tar through the Web Console.
6. Close the application loop. The container subscribes to inference results, applies PPE logic and produces detection events that another service or system can use.

ONNX is the portable model handoff. HEF is the Hailo-15H deployment artifact. The application turns inference output into product behavior.

Why the HEF and Application Stay Separate

The Safety Helmet Detection package does not embed the custom HEF. The model is loaded through NE503 Model Management, while the application is installed as its own package.

This separation gives each layer a clear job:

A model can be updated without rebuilding the base camera firmware. Application logic can also evolve without treating the model file as the complete product. The model and application still need a compatible contract: model ID, input stream, classes and output handling must agree.

How the Helmet App Closes the Loop

The verified app connects four working parts:

1. NE503 provides a camera stream to the loaded helmet model.
2. Hailo-15H runs the two-class detector and returns inference results.
3. The container application consumes those results and distinguishes Helmet from No Helmet detections.
4. The application outputs detection events for PPE monitoring logic.

This is the last mile that a model export guide does not cover. A HEF can prove that inference runs. The matched camera application proves that the inference can become a useful device behavior.

If you already have a trained model, send CamThink its framework, input shape, class list and expected application output. That is enough to begin mapping the model-to-app path.

Verification Gates for Your Own Model

Use one observable result at each boundary:

If ONNX inference works but the camera returns no detections, check the compiled output contract and the custom-model output handling documented for the current NE503 release. If accuracy drops after quantization, review the calibration images and optimization settings. If the application starts before finding its model, confirm that the separately deployed HEF is loaded under the exact model ID expected by the app.

Use the Wiki for Commands and Files

This article explains the deployment logic and verified outcome. The CamThink Wiki maintains the version-specific training commands, ONNX export settings, Hailo compilation steps, downloadable artifacts and current custom-model output handling.

• NE503 Model Training and HEF guide
• NE503 Verified Apps

FAQ

What NE503 Lets Your Team Ship

A trained model is only one part of an edge AI product. On NE503, the model can move through a defined accelerator path, run beside a separately managed container application and produce results at the camera endpoint.

For algorithm companies and solution teams, that changes the deliverable. The work no longer ends with weights or a demo script. It can become a camera application with a repeatable model, runtime and event path.