Resumen del caso
Beijing Winge Technology Co., Ltd. entregó un sistema de monitorización de humo industrial de un canal en un equipo de borde RK3588 Ubuntu. Un modelo MobileNetV3-Small ONNX evalúa tres fotogramas para detectar humo; durante el día, una segunda etapa clasifica humo negro, no negro o color incierto. Si la condición de humo negro permanece durante el tiempo de confirmación, un GPIO MCP2221A entrega el nivel de alarma configurado.
La entrega incluyó modelo, acceso RTSP, consola web, pruebas de imagen y vídeo, despliegue systemd/Nginx, integración GPIO, paquete ARM64, copia de reversión, checksums y registros de verificación. «Humo negro» es una etiqueta visual del proyecto, no una escala Ringelmann, una medición de contaminantes ni una decisión regulatoria sobre emisiones.
Contexto del proyecto
El cliente necesitaba conectar una cámara industrial a un RK3588 en una LAN controlada, mantener una vista previa y evaluar el humo localmente. También requería niveles lógicos alto o bajo en MCP2221A GP0-GP3 para PLC, relé, baliza o sirena.
El alcance cubrió decodificación de vídeo, despliegue ARM64, inicio automático, configuración en navegador, tratamiento de errores, aislamiento de la salida de prueba, materiales de instalación y reversión. El entorno fue RK3588, Ubuntu 22.04 ARM64, Nginx, Gunicorn, OpenCV DNN y ONNX.
Alcance entregado
| Componente | Contenido |
|---|---|
| Etapa de humo | Clasificación MobileNetV3-Small ONNX de tres fotogramas |
| Etapa de color | Humo negro, no negro o incierto durante el día |
| Vídeo | RTSP, HTTP o archivo local con vista MJPEG |
| Consola web | URL, algoritmo, umbral de color, pin GPIO y nivel activo |
| Pruebas | Imagen y vídeo con enlace MCP2221A opcional |
| Alarma | GP0-GP3, activo alto o activo bajo |
| Operación | Nginx, Gunicorn, systemd, udev, health check, IP fija y rollback |
| Artefactos | Paquete ARM64, modelos, scripts, pruebas, documentos y SHA-256 |
Arquitectura técnica
Flujo: cámara o medio subido → decodificación OpenCV/FFmpeg → clasificación temporal de tres fotogramas → protecciones de vista fija y fotograma anómalo → color diurno → confirmación continua → GPIO MCP2221A → estado web y registros.
El RK3588 carga ONNX mediante OpenCV DNN y no necesita PyTorch. Nginx ofrece HTTP en la LAN y Gunicorn solo escucha en 127.0.0.1:8000. La aplicación está en /opt/smoke-control, la configuración en /var/lib/smoke-control/config.json y smoke-control.service gestiona el arranque.
Decisión en dos etapas y alarma
La primera etapa evalúa tres fotogramas consecutivos. El color solo se ejecuta tras detectar humo. De día devuelve black_smoke, no negro o incierto. De noche mantiene la detección de humo, pero devuelve unknown_night para el color y no genera alarma de humo negro.
La alarma requiere humo, color negro, confianza por encima del umbral y duración de confirmación. La base del proyecto usó dos segundos. Las pruebas subidas pueden aislarse del GPIO; si se habilita el enlace, se mantiene el nivel de prueba y después se restaura el control automático.
Problemas de campo y correcciones
La vista fija incluía muebles oscuros, reflejos, escenas oscuras estáticas, fotogramas negros, gráficos binarios, ruido y gradientes. Se añadieron protecciones de fondo verificado, escena estática con restricción estructural, fotograma negro, gráfico binario, stream estático y oscuridad global.
La regla global oscura solo actúa con media de gris de hasta 24 y percentil 99 de hasta 50. La revisión inversa de 1.760 imágenes tuvo 0 coincidencias. La muestra positiva más oscura tenía media 19,32, pero percentil 99 de 62, por lo que no fue rechazada.
Con humo negro sobre fondo claro, la regla anterior exigía 14% de píxeles oscuros; el vídeo de 37 segundos midió 9,03%–11,38%. El límite de 8% solo se aplica cuando el P90 del fondo es al menos 250; las escenas oscuras comunes no usan esta compensación.
Resultados de verificación
Las cifras proceden de registros internos del 26 al 29 de julio de 2026 y solo se aplican a las versiones, modelos, muestras, dispositivo y método indicados; no son una afirmación de precisión general para cualquier sitio.
| Elemento | Resultado y condición |
|---|---|
| Vídeo del cliente | 37 s, 1024×540, 30 FPS, 1.110 fotogramas, 74 muestras cada 0,5 s |
| Resultado en dispositivo | Humo 74/74, candidatos negros 73/74, condición simulada cumplida |
| Límite de salida | La aceptación usó output_isolated=true; GPIO no accionado |
| Regresión v1.9.4 | TP 57, FN 8, FP 2, TN 83; sin FP adicional |
| Pruebas v2.0.3 | 70 pruebas más 18 subpruebas aprobadas |
| Imágenes oscuras | 13 variantes negras, casi negras, con ruido, gradiente, JPEG y PNG siguieron como sin humo |
| Revisión inversa | La nueva regla coincidió con 0/1.760 imágenes |
| Pruebas oscuras en cliente | Tres imágenes de ruido/gradiente no activaron la salida enlazada |
| Positivo de humo negro | Confianza de humo 98,53%, color 99,99%, positivo conservado |
| Estado final | Seis muestras: stream conectado, sin humo, sin alarma, GP0 bajo |
| Integridad | SHA-256 de cuatro archivos coincidió; servicio active/enabled |
Resultado del proyecto
- Ruta completa desde RTSP e inferencia ARM64 hasta decisión en dos etapas y GPIO.
- Gestión de stream, algoritmo, umbral, pin y nivel activo desde la consola web.
- Separación clara entre prueba de medios, monitorización en vivo y salida física.
- Protecciones con regresión para escenas oscuras, fotogramas negros, gráficos binarios, ruido, gradientes y fondos claros.
- Paquetes, modelos, scripts, pruebas, documentación, hashes y puntos de rollback.
Escenarios adecuados
- Prototipos y verificación de humo con vista fija en instalaciones industriales.
- Visión de borde y control LAN en RK3588 ARM64.
- Conversión de una decisión visual en entrada de PLC, relé, baliza o sirena.
- Monitorización local de un canal para reducir la subida de vídeo sin procesar.
Límites y riesgos
El sistema no es un instrumento legal de emisiones. No proporciona escala Ringelmann ni concentración de contaminantes y no sustituye pruebas ambientales, certificación o decisiones regulatorias. Exposición, balance de blancos, compresión, clima, luz, fondo, ángulo y distancia afectan al color.
MCP2221A solo proporciona nivel lógico y no acciona directamente una carga de alta corriente. PLC, relés, luces o sirenas requieren driver u optoaislamiento según tensión, corriente, aislamiento y seguridad, además de aceptación eléctrica en campo.
La consola base está diseñada para una LAN controlada. El acceso público exige autenticación, control de acceso, HTTPS, protección de credenciales de cámara y redacción de registros. Antes de producción deben fijarse el conjunto local y criterios de Precision, Recall, falsas alarmas, omisiones, recuperación, duración y reinicio.
Preguntas frecuentes
¿Cómo decide el sistema que el humo es negro?
Detecta humo en tres fotogramas y después clasifica el color de día. Deben cumplirse humo, color negro, umbral de confianza y tiempo de confirmación.
¿Clasifica humo negro de noche?
La base solo detecta humo de noche y devuelve unknown_night para el color. La clasificación nocturna necesita datos y criterios propios.
¿Equivale a monitorización Ringelmann?
No. Humo negro es una etiqueta visual; el sistema no da escala Ringelmann, concentración de partículas ni resultado legal de emisiones.
¿Puede integrar una cámara y PLC existentes?
Se evalúan RTSP/HTTP, códec, resolución, FPS, red y especificación eléctrica del PLC. La salida MCP2221A necesita accionamiento y aislamiento.
¿Otro RK3588 requiere nueva verificación?
Sí. Sistema, OpenCV/FFmpeg, stream, red, temperatura, carga y ángulo pueden cambiar el resultado. Se repiten build, función, falsas alarmas, omisiones, salida y endurance.
Online
Phone
WeChat
Top