Case Overview
This case covers an offline smoke and black-smoke detection system deployed on an RK3588 industrial PC for a fixed industrial scene. The system connects to a single RTSP, HTTP or local video source through a LAN-based web console, decodes the stream with OpenCV and FFmpeg, converts it to MJPEG for browser preview, and runs a two-stage visual recognition pipeline in the background. The first stage determines whether smoke is present. The second stage runs only after smoke is confirmed and classifies the result as black smoke, non-black smoke or color-uncertain. When black smoke is confirmed, the system can drive a configured logic level through an MCP2221A GP pin for relay, audible-light alarm or PLC input integration.
The public case presents the project method, engineering deliverables, verified results and delivery boundaries. It does not disclose the customer name, field credentials, camera URLs, raw video samples or internal access data. The conclusions apply to the tested fixed scene and recorded samples, not to every site, weather condition, camera exposure or regulatory monitoring scenario.
Project Background
The project requirement was to detect smoke in an industrial monitoring scene and generate a local output only after black smoke was confirmed. At the beginning, the available material was limited. The initial video mainly contained white or light-gray smoke and did not include sufficient no-smoke negative samples, black-smoke positive samples, different weather conditions or varied exposure cases. For that reason, the project did not start with a generic black-smoke claim. The delivery path was staged: detect smoke first, classify smoke color second, complete a fixed-scene edge prototype and then iterate with field videos, false-alarm samples and verified black-smoke evidence.
The engineering scope included video stream input, real-time preview, algorithm switch, color-confidence threshold, day-night strategy, image and video testing, GPIO output linkage, alarm hold time, device status display, service autostart, persistent configuration, deployment rollback and field troubleshooting documentation. Since browsers cannot play RTSP directly, the server performs video conversion. Since MCP2221A provides only logic-level output, downstream loads must be connected through a driver or optocoupler module.
Technical Architecture
The model runs offline on an RK3588 industrial PC with Ubuntu ARM64. The first stage is a three-frame early-fusion MobileNetV3-Small ONNX classifier for smoke presence. It uses consecutive frames to reduce single-frame noise and static-graphic false positives. The second stage is a black-smoke versus non-black-smoke color classifier and is invoked only when a smoke candidate exists. The deployment side does not require PyTorch; OpenCV DNN loads the ONNX model for field inference.
The system is organized into video input, model inference, rule-based protection, web console, output management and operation scripts. Video input covers real-time streams and uploaded video tests. Inference handles smoke and smoke-color decisions. Rule-based protection handles fixed-position clear backgrounds, static frames, pure black frames, binary graphics, dark gradients and noisy black screens. The web console provides configuration and state display. Output management controls MCP2221A GP0-GP3. Deployment scripts manage installation, service configuration, network changes and rollback.
Algorithm Strategy and False Alarm Control
The system does not classify the entire frame directly as black smoke. Industrial images may include sky, clouds, reflections, dark equipment, shadows, compression noise and low-light night scenes. The system first checks whether smoke exists, then applies color judgement to the smoke candidate. In low-light mode, the system keeps smoke detection but outputs unknown_night for color and does not trigger a black-smoke level.
During field iteration, the project added fixed-position clear-background protection, structure-constrained static-frame protection, adaptive dark-region sampling for uploaded videos, pure-black and binary-graphic guards, live static-frame gating and overall-dark abnormal-frame protection. These rules reduce false alarms caused by dark furniture, reflections, exposure changes, near-static live video and noisy black screens. Each rule has a defined boundary so it is not relaxed without evidence.
Verification Results
The model evaluation record shows that, on the current 107-group test set, the three-frame temporal smoke model detected 85 smoke groups, missed 7 smoke groups, correctly rejected 15 no-smoke groups and produced 0 no-smoke false positives. This is a project test-set result and should not be read as a universal field guarantee.
A 37-second customer black-smoke video was used to reproduce a second-stage color issue. Before the fix, the old threshold detected smoke but produced 0/74 black-smoke frames and returned color-uncertain. After v1.9.4 adjusted the relative dark-region sampling threshold for bright backgrounds, the local full interface produced 73/74 smoke frames and 72/74 black-smoke frames. On the RK3588 field service, the uploaded video test produced 74/74 smoke frames and 73/74 black-smoke frames and met the alarm condition. The video test path is isolated from live GPIO output and does not directly change the real-time alarm state.
In v2.0.3 validation, automated testing reported 70 passed tests and 18 passed subtests. Thirteen synthetic black-screen variants were classified as no smoke. A reverse scan of 1760 readable images in the current dataset did not trigger the newly added overall_dark guard, while the preserved black-smoke benchmark still passed the two-stage judgement. On the customer RK3588 device, the service was active and enabled, health check returned smoke_acceptance_model_v2.6, the stream state was connected, and six consecutive status samples showed no smoke, alarm inactive, GP0 low level and MCP2221A connected.
Deliverables
The delivery includes the smoke recognition web console, model configuration, ONNX weights, deployment scripts, Nginx and systemd configuration, MCP2221A udev rules, network configuration utilities, test APIs, image and video test functions, field upgrade notes, deployment and acceptance documentation, false-alarm repair records, rollback backups and operation commands. The service runs as a low-privilege account, and the configuration file is readable only by the service account to avoid exposing complete video-stream addresses in logs or screenshots.
The frontend supports real-time monitoring, image tests and video tests. Image and video tests can be configured to link or not link output. After a test output ends, the system returns to real-time automatic control. Desktop and mobile viewports were checked for layout overlap and text overflow. The service supports autostart after reboot, persistent configuration, health checks and field troubleshooting commands.
Applicable Boundary
This case is suitable for fixed-position, single-stream, LAN-deployed, offline edge recognition projects that need local alarm linkage. If the camera moves, zooms, becomes occluded, operates in strong night noise, backlight, rain or fog, changes stack distance, uses multiple concurrent cameras, serves multiple preview clients or is exposed beyond the LAN, the project needs new samples, acceptance tests, compute and network assessment, authentication, access control and HTTPS. MCP2221A GP pins are logic-level outputs. Before connecting a relay, PLC or audible-light alarm, the actual level and isolation design should be verified with a multimeter or oscilloscope.
FAQ
Is this system equivalent to a certified environmental monitoring instrument?
No. This is a fixed-scene visual recognition and local alarm linkage project. The result is limited to tested samples and field conditions and does not replace legally required monitoring instruments or third-party inspection conclusions.
Why use a two-stage pipeline?
The pipeline first confirms smoke and then classifies smoke color. This reduces false alarms from background objects, clouds, vapor, reflections and dark equipment being classified directly as black smoke.
What must be confirmed before formal deployment?
The customer should validate real black smoke, no-smoke, white smoke, gray smoke, night, backlight, rain/fog and camera-disconnect samples, plus output level, load linkage, network stability and service restart recovery.