Detección de Ocupación de Aparcamiento Basada en Cámara — Selección, Despliegue y Datos Medidos
Las plazas deben ser visibles en la imagen de la cámara: una plaza totalmente oculta por su vecina, o una que sea muy pequeña y esté muy lejos, no se evalúa de forma fiable.
Qué hace esta solución
En lugar de un sensor magnético o ultrasónico en cada plaza, usa las cámaras IP que ya hay en el aparcamiento: todas las plazas que una cámara pueda ver se comprueban al mismo tiempo. Dibujas y nombras un recuadro por plaza en un navegador; el host en el edge sigue decidiendo si hay un vehículo en ella y envía el estado de cada plaza — ocupada, libre o desconocida — a tu sistema para paneles de plazas libres, guiado de aparcamiento o gestión de plazas reservadas.
- Paquete de despliegue (Docker Compose y configuración): github.com/suharvest/sensecraft-solutions
- Selección y despliegue: página de diseño de referencia
El vídeo se queda en el sitio
La imagen se analiza en el host en el edge en el propio sitio; solo salen de él los estados de las plazas.
Varios streams por host
Un reComputer J30 Serie ejecutó 6 streams durante 620 s sin fotogramas perdidos; consulta "Rendimiento y datos medidos".
Dibuja tus propias plazas
Dibuja y nombra recuadros sobre la imagen en vivo en un navegador; al guardar se aplica al instante y sobrevive a un reinicio.
Las cámaras perdidas se detectan
Unos 10 s después de que se caiga el stream de una cámara, sus plazas pasan a "unknown" en lugar de repetir el estado antiguo.
En un dispositivo real
El propio editor de plazas del host en el edge: cada recuadro es una plaza, rojo para ocupada y verde para libre, con totales y la lista de plazas a la derecha.
En la captura de pantalla P01, P02, P04 y P06 están ocupadas y P03 y P05 libres. La entrada es un fotograma fijo en bucle de un aparcamiento en superficie, no imágenes del sitio.
Hardware necesario
Tres elementos en el sitio: las cámaras IP del aparcamiento, un host en el edge y un broker MQTT (por ejemplo un Mosquitto existente).
① Cámaras IP: cámaras existentes con un stream RTSP H.264; el sub‑stream es suficiente.
② Host en el edge: elige uno; un host admite varias cámaras, cada una analizada a un fotograma por segundo.
| Host en el edge | Medido | Elígelo cuando | |
|---|---|---|---|
 | reComputer Super J3011 Jetson Orin Nano, JetPack 6.2 | 6 streams, sin pérdidas; p50 6.5 ms por fotograma | Varias cámaras en un host; opción por defecto |
 | reComputer Super J4012 Jetson Orin NX, JetPack 6.2 | Mismo paquete que J30 | El host también ejecuta otros modelos |
 | reComputer RK3588 Serie NPU integrada | Un stream; p50 36.6 ms por fotograma | El sitio se estandariza en Rockchip |
 | reComputer RK3576 Serie NPU integrada | Un stream a 1 fps, sin pérdidas | Pocas cámaras, el coste es lo primero |
En hosts RK, añade streams de uno en uno y comprueba que cada uno siga actualizándose.
El host en el edge, las cámaras y el broker MQTT comparten una LAN, y el host puede alcanzar las direcciones RTSP de las cámaras (normalmente puerto 554). El despliegue descarga el runtime y los modelos; después de eso funciona sin conexión.
Despliegue en el sitio
1. Comprueba la vista de la cámara
Cada plaza debe ser claramente visible y no estar totalmente oculta por su vecina. Dibuja un recuadro por plaza: un vehículo tiene que cubrir aproximadamente un tercio del recuadro para contar como ocupada, y un recuadro grande que abarque varias plazas nunca cuenta como ocupado.
2. Instala el software: tres pasos
Los pasos por dispositivo están en la página de diseño de referencia; esto es el esquema general.
- Despliega el host en el edge: introduce la dirección RTSP de cada cámara y el broker MQTT, luego despliega.
- Dibuja las plazas: abre el editor de plazas en el puerto 8080, elige una cámara, arrastra un rectángulo sobre una zona vacía, arrastra sus esquinas para ajustarlo, introduce el ID de la plaza (por ejemplo B1-023) y guarda.
- Comprueba: cuando una plaza cambie, su color en el editor la seguirá y el mensaje de estado de la cámara llegará por MQTT.
Interfaces
Los estados de las plazas van por MQTT a tu broker, un topic por cámara.
- Paneles de plazas libres / guiado: suscríbete al topic de cada cámara y suma los contadores de ocupadas, libres y desconocidas en el mensaje.
- Plazas reservadas: dibuja las plazas de recarga de VE o de visitantes como sus propios recuadros y actúa según sus IDs de plaza.
- Home Assistant o tu propio sistema: el mismo topic, leído por ID de plaza.
| Topic / puerto | Contenido |
|---|---|
MQTT <site>/parking/<camera>/slots | Cada plaza bajo esta cámara (occupied / free / unknown) más los tres contadores; se envía siempre que cambie alguna plaza |
HTTP 8080 /slots/editor | Editor de plazas: dibujar, nombrar, estado en vivo |
HTTP 8099 /healthz | Estado del servicio |
Los estados se mantienen para que no parpadeen de un fotograma a otro: una plaza pasa a ocupada unos 3 s después de que el vehículo se estabilice y a libre unos 5 s después de que se vaya; unos 10 s después de que se caiga un stream sus plazas pasan a desconocidas.
Rendimiento y datos medidos
Varios streams y un stream
| Dispositivo | Entrada | Resultado |
|---|---|---|
| reComputer J30 Serie (Orin Nano) | 6 streams, 1 fps cada uno, 620 s | 0 fotogramas perdidos en cada stream, alrededor de 1.0 fps cada uno (medido) |
| reComputer J30 Serie (Orin Nano) | Un stream | 0.988 fps, p50 6.5 ms por fotograma, 15 cambios de estado informados por plaza (medido) |
| reComputer RK3588 Serie | Un stream | p50 36.6 ms por fotograma, 17 cambios de estado informados (medido) |
| reComputer RK3576 Serie | Un stream | 1.0 fps, 21 mensajes de estado de plaza recibidos, 0 fotogramas perdidos (medido) |
La entrada de un solo stream alterna un fotograma fijo de un aparcamiento en superficie con fotogramas oscuros para forzar cambios ocupado/libre.
Reproducir: sensecraft-solutions/solutions/edge_parking_occupancy (paquete de despliegue) con el clip de entrada slots-occ20-empty20-400s.mp4
Stream de cámara perdido
| Dispositivo | Resultado |
|---|---|
| reComputer RK3576 Serie | Las plazas pasaron a unknown 9.98 s después de que se detuviera el stream, unos 11 s después del último fotograma (medido) |
Modelos y runtimes
| Dispositivo | Detección de vehículos | Runtime |
|---|---|---|
| reComputer J30 / J40 Serie | YOLOX, 640×640, FP16 | TensorRT |
| reComputer RK3588 / RK3576 Serie | YOLOX, 640×640, INT8 (w8a8) | RKNN, decodificación hardware MPP |
Parámetros que afectan a la decisión (paquete de despliegue config/slots*.json):
slot_coverage.occupied_ratio/free_ratio: ocupada por encima de 0.3 del área del recuadro, libre por debajo de 0.2.slot_coverage.hold_s/free_hold_s: un estado debe mantenerse durante 3 s / 5 s antes de que cambie.unknown_after_s: las plazas pasan a estado desconocido 10 s después de que se interrumpe el flujo.
Degradación conocida
- Distorsión de perspectiva gran angular y oclusión: Las plazas cercanas al perímetro de las vistas de cámara gran angular sufren estiramiento de perspectiva; los vehículos de gran altura (SUV, furgonetas) en primer plano pueden bloquear las plazas traseras adyacentes. Se recomienda restringir cada cámara a ≤ 30 plazas.
- Condiciones de invasión de línea y de contorno: Cuando un vehículo invade las líneas de las plazas, si ambas plazas caen dentro del intervalo de cobertura transicional de 0.2–0.3, puede producirse un aleteo temporal del estado. Aumentar
hold_sestabiliza las transiciones. - Reflejos en charcos y sombras dinámicas: El agua estancada después de la lluvia o las sombras dinámicas intensas de pilares/árboles pueden degradar la confianza en la detección de bordes. Debe mantenerse una iluminación funcional básica (iluminancia de superficie ≥ 30 Lux) durante la noche.
Fuentes de datos y recursos
- Las capturas de pantalla y los resultados de flujo único utilizan una imagen fija de un aparcamiento en superficie cuyo origen original aún está por confirmar.
- Código del modelo de detección YOLOX: Apache-2.0.