RK3588 industrial computer smoke recognition and black smoke alarm linkage delivery case

Case Overview

This case is oriented to the linkage requirements of smoke recognition and black smoke alarm in fixed industrial scenes. The goal is to deploy a video recognition service that can run offline on the RK3588 industrial computer. The system accesses a single RTSP, HTTP or local video source through the LAN Web console. The server uses OpenCV and FFmpeg to decode and convert it to MJPEG for preview. At the same time, a two-stage smoke recognition algorithm is run in the background: the first stage determines whether there is smoke in the picture, and the second stage determines black smoke, non-black smoke or uncertain color after the smoke is established. The system can output the effective alarm level through the GP pin of MCP2221A, which can be used to connect relays, audible and visual alarms or PLC input modules.

Public cases only present the project technical route, project delivery content, verified results and applicable boundaries, and do not disclose customer names, on-site accounts, camera addresses, complete video samples or internal credentials. The project conclusions are limited to the accepted fixed scenes and recorded samples, and are not written as a generalized commitment to any site, any weather, or any camera exposure conditions.

Project background and requirements

The customer site needs to identify smoke in industrial emission and equipment inspection scenarios, and form a local alarm output after confirming black smoke. At the beginning of the project, there were only limited video materials, and the materials were mainly white smoke and light gray smoke. There was a lack of sufficient smokeless negative samples, black smoke positive samples, different weather and different exposure conditions. Based on this condition, the project did not directly commit to a universal black smoke model, but first formulated a two-stage route: first identify smoke, and then judge the smoke color; first complete the fixed scene prototype and edge-end console, and then gradually iterate through live videos, false alarm samples, and real black smoke samples.

After dismantling the requirements, the system needs to cover video stream access, real-time preview, model switch, color confidence threshold configuration, day and night strategy, picture and video testing, GPIO linkage output, alarm retention time, device status display, service auto-start, configuration persistence, deployment rollback and on-site troubleshooting documents. Since the browser cannot directly play RTSP, the system completes transcoding on the server side; since the output interface only provides logic levels, the downstream load must be isolated through a driver or optocoupler module.

Technical architecture

The algorithm model adopts edge-side offline deployment and runs on the RK3588 industrial computer of Ubuntu ARM64. The first stage is a three-frame early fusion MobileNetV3-Small ONNX smoke classifier. The input is three consecutive frames of images, which is used to reduce misjudgments caused by single-frame noise and static graphics. The second stage is a black smoke and non-smoky color classifier, which is only triggered when there is a smoke candidate in the first stage. The deployment end does not rely on PyTorch and uses OpenCV DNN to perform ONNX inference, reducing the complexity of the on-site installation environment.

System engineering is divided into six parts: video input, model inference, rule protection, Web console, output management and operation and maintenance scripts. Video input supports real-time streaming and uploaded video testing; model inference is responsible for smoke and smoke color judgment; rule protection is used to handle fixed camera positions with clear backgrounds, static images, pure black images, binary graphics, dark gradients and noisy black screens; the Web console provides parameter configuration and status display; output management controls MCP2221A GP0-GP3; operation and maintenance scripts are responsible for installation, service management, network port configuration and rollback.

Algorithm strategy and false alarm control

The project did not adopt the solution of "directly judging black smoke in the entire frame".The reason is that sky, clouds, reflections, dark equipment, shadows, compression noise and low illumination at night in industrial sites can all affect color judgment. The system first determines whether there is smoke, then confirms the color of the smoke candidate areas, and combines day and night strategies to handle low-light scenes. By default, only smoke judgment is retained at night, the color output is unknown_night, and the black smoke level is not triggered.

With the increase of on-site samples, the system has iterated on fixed-position clear background protection, structurally constrained static picture protection, video test adaptive dark area sampling, pure black and binary graphics protection, real-time static picture gating, and overall extremely dark abnormal picture protection. Fixed camera position protection is used to suppress smoke-free false alarms caused by dark tables and chairs, glass reflections, and exposure changes; static gating is used to handle situations where the real-time image hardly changes but the first-stage model generates smoke candidates; extremely dark image protection is used to intercept high-noise black screens and dark gradient images. Each type of rule retains boundary descriptions to avoid further unwarranted relaxation.

On-site verification results

The model evaluation report shows that the three-frame temporal smoke model obtained 85 smoke sample hits, 7 smoke sample misses, 15 smokeless samples correctly identified, and 0 smokeless false alarms on the 107 sample groups in the current test set. The results are from the project test set and are not representative of all external scenarios.

The customer's 37-second original video of black smoke is used to reproduce the second-stage color determination problem. Before the fix, the old threshold was able to identify smoke, but the black smoke frame was 0/74, resulting in an indeterminate color. After adjusting the relatively dark area sampling threshold under the highlight background in v1.9.4, the local complete interface obtained 73/74 smoke frames and 72/74 black smoke frames; on the official service of the RK3588 industrial computer, the uploaded video test obtained 74/74 smoke frames and 73/74 black smoke frames, and met the alarm conditions.This video test is isolated from the real-time GPIO output, and the test process will not directly change the on-site real-time alarm status.

In v2.0.3 verification, the automated test results were 70 passes and 18 subtests passed. The regression results of 13 synthetic black screen variants are all smokeless; the reverse check of 1760 current dataset images misses the new overall_dark rule; the real black smoke benchmark can still pass the two-stage judgment. In the customer industrial computer verification, the service is active and enabled, the health check returns the model version smoke_acceptance_model_v2.6, the video stream is connected, and the 6 consecutive status samples are smoke-free, alarm off, GP0 low level, and MCP2221A connected.

Delivery content

Project delivery includes smoke recognition Web console, model configuration, ONNX weight, deployment script, Nginx and systemd configuration, MCP2221A udev rules, network port configuration tool, test interface, picture and video test function, on-site upgrade instructions, deployment acceptance instructions, false positive repair report, rollback backup record and operation and maintenance commands. The service is run as a low-privileged user, and the configuration file is restricted to the service account to avoid exposing the complete video stream address in logs and screenshots.

The front-end page supports real-time monitoring, picture testing and video testing. You can choose whether to output pictures and videos in conjunction with each other; real-time automatic control will resume after the test output is completed. The page has completed layout check under desktop and mobile viewports, and the main controls have no overlap or text overflow. The system supports automatic recovery after service restart, and retains configuration persistence, health check and on-site troubleshooting commands.

Applicable boundaries

This case is suitable for fixed camera positions, single-channel video streaming, LAN deployment, edge terminal offline identification and local alarm linkage projects. For camera movement, zoom, occlusion, strong noise at night, backlighting, different weather, changes in chimney distance, multi-camera concurrency, multi-client distribution and external network access, it is necessary to re-collect samples, supplement acceptance, evaluate computing power and network, and add authentication, access control and HTTPS. The GP pin of MCP2221A is a logic level output. Before actually connecting the relay, PLC or audible and visual alarm, you should use a multimeter or oscilloscope to confirm the level and isolation method according to the electrical specifications.

FAQ