Acceso Facial para Tienda No Atendida: Hardware, Distribución de la Biblioteca de Rostros y Límites Medidos
No es un producto de seguridad certificado ni un sistema de seguridad vital. Los pesos de referencia de rostros (InsightFace buffalo_l) tienen licencia solo para investigación no comercial; un despliegue comercial necesita un modelo con licencia comercial.
Qué hace esta solución
Una cámara en una puerta detrás de la cual no hay nadie reconoce un rostro, requiere que se supere una comprobación de prueba de vida pasiva, verifica a la persona contra la biblioteca de rostros actual, el horario y la lista de bloqueo y — solo si todo eso se cumple — activa por pulsos un relé que conmuta una cerradura alimentada por su propia fuente de 12/24 V. Cada decisión, tanto permitida como denegada, se publica en MQTT y se añade a un registro de auditoría encadenado por hash que la consola puede verificar.
Encaja en la entrada de personal, almacén o puerta trasera de una tienda sin personal o con personal parcial; en una oficina compartida donde la plantilla cambia semanalmente y el registro debe ser autoservicio; en una sala de equipos donde el registro de quién pasó importa más que el rendimiento; y en un sitio que ya tiene cámaras RTSP en la puerta y no quiere sustituirlas.
- Selección y despliegue: página de diseño de referencia
- Repositorio ascendente: no publicado; el código está en un repositorio interno.
Abre sin conexión (tres de cinco preajustes)
El reconocimiento, la prueba de vida, la decisión y el desbloqueo ocurren en la puerta. Un dispositivo que pierde la nube sigue abriendo con la última biblioteca de rostros que cargó correctamente. En los dos preajustes de relé por MQTT, la señal de desbloqueo cruza la red hasta el relé.
Biblioteca de rostros distribuida y verificada automáticamente
Los dispositivos consultan si hay nuevas versiones, descargan por fragmentos, comprueban el SHA-256 por archivo y la firma del manifiesto, y luego cambian de forma atómica. Cualquier fallo mantiene la versión anterior. Activación medida en una reCamera estándar: p50 491,6 ms.
Un rollback no puede restaurar a una persona eliminada
Eliminar a alguien produce una nueva versión sin esa persona y escribe una barrera de eliminación. Un rollback a cualquier versión que aún contenga a esa persona se rechaza por nombre.
Cada decisión se audita
Tanto las decisiones permitidas como las denegadas van a MQTT y a un registro de auditoría encadenado por hash. Editar cualquier registro pasado rompe la cadena, y la comprobación de cadena de la consola lo informa.
Lo que ve el dispositivo en la puerta
Reconocimiento en una reCamera Pro: el recuadro de la cara lleva el id de la persona coincidente y la decisión para ese fotograma. Cuando no hay nadie delante, la vista es solo el encuadre.
Qué hardware necesitas
Tres roles de dispositivo en la puerta, más un host en la nube o on-prem.
① La cámara en la puerta. Puede ser el propio sensor del dispositivo (reCamera Pro o reCamera estándar) o una cámara RTSP existente que alimenta a un host separado. Móntala aproximadamente a la altura de la cara, encuadrada de modo que una cara llene una parte utilizable del fotograma a la distancia a la que la gente realmente se detiene. Las puertas a contraluz y los reflejos en el vidrio son causas habituales de fallos de reconocimiento.
② Lo que reconoce y decide.
| Host de reconocimiento | Dónde se ejecuta el reconocimiento | Forma de instalación | Cuándo elegirlo | |
|---|---|---|---|---|
 | reCamera Pro (RV1126B) Cámara inteligente de alto rendimiento | En la cámara, junto a su aplicación de reconocimiento facial existente | Instalado en la cámara, sin contenedor (Buildroot, sin Docker) | Aún no hay cámara en la puerta; se necesita prueba de vida y coincidencia rápidas en el dispositivo |
 | reCamera 2002 (SG2002) Cámara inteligente de entrada | En la cámara, en un único proceso nativo: detección, embedding, prueba de vida y coincidencia | Un pequeño daemon copiado en la cámara, sin contenedor | Puerta única autónoma y rentable |
 | reComputer J3011 / J4012 Host perimetral Jetson Orin | En contenedores, contra un flujo RTSP existente | Contenedores sobre SSH | Cámara RTSP existente; una caja centraliza varias puertas |
 | reComputer Industrial R2035-12 Controlador industrial sin ventilador | En contenedores, contra un flujo RTSP existente | Contenedores sobre SSH | Instalación en armario, E/S multicanal aislada e interfaces de relé |
③ El relé. La cerradura debe estar detrás de un relé o contacto seco, con su propia fuente de 12/24 V, separada de la de la placa de cómputo. Una cerradura consume de 300 mA a 1 A; un pin GPIO y una salida digital optoaislada transportan miliamperios. Cuatro ajustes — active_high, pulse_ms, relay_contact y fail_mode — se configuran por instalación y no tienen valores predeterminados: una cerradura magnética a prueba de fallo cableada a través del contacto normalmente abierto queda permanentemente abierta, y nada lo muestra hasta que se prueba la puerta.
④ El host en la nube o on-prem. Cualquier caja Linux amd64 o arm64 con Docker; sin GPU. Ejecuta el servicio de biblioteca de rostros, la consola de gestión y el broker MQTT. Debe ser accesible desde cada dispositivo de puerta, y su reloj debe ser correcto: los dispositivos sin RTC toman su corrección de hora de la cabecera HTTP Date.
Límites de selección negativa
- Tamaño de la base de datos de rostros: Se recomienda que la base de datos de rostros en cámara sea ≤ 1.000 usuarios registrados. Por encima de 3.000 usuarios, la latencia de comparación aumenta; usa en su lugar un host perimetral dedicado.
- Contraluz severo: La luz solar exterior directa sin sombra satura la detección IR de prueba de vida; instala un parasol o iluminación de relleno antirreflejos.
Cómo desplegar en el sitio
Dos partes, y el orden importa.
Uno: cablear la puerta — LED, luego relé, luego cerradura
Confirma la polaridad y el ancho de pulso con un LED. Confirma que el contacto hace clic en el relé. Solo entonces pon una cerradura en él. Una cerradura magnética a prueba de fallo pasa por COM y NC; una cerradura de resorte a prueba de intrusión pasa por COM y NO. Si esto se conecta al revés, la puerta queda permanentemente abierta, por lo que relay_contact no tiene valor predeterminado.
Comprueba que el pin GPIO esté libre. En una reCamera Pro inspeccionada, gpio131 ya estaba exportado y controlado por otra aplicación. El actuador se niega a arrancar en un pin cuyo estado actual no coincide con el estado inactivo configurado, y no tomará el control de un pin a menos que se le indique explícitamente. En la base PoE HQ de 6 pines de la reCamera 2002, el conector de 6 pines lleva tres líneas de E/S — D1 = sysfs 490 (la única que no está multiplexada), CLK = 487, SMD = 488 — pero la polaridad de nivel del encabezado y la corriente de accionamiento disponible no están en la documentación del proveedor, así que no conectes una cerradura ahí antes de que un multímetro y un LED las hayan confirmado. En el J20 la especificación de diseño sitúa DO1–DO4 en sysfs 463/464/465/462; si la imagen de destino las expone de esa forma o a través de Jetson.GPIO no se ha confirmado en hardware.
Dos: levanta primero la parte en la nube y luego la del dispositivo
Los pasos completos por preajuste están en la página del diseño de referencia, donde responder a unas pocas preguntas sobre el sitio también te da el paquete de aplicación correspondiente para descargar.
La parte en la nube es el servicio de biblioteca de rostros, la consola y un bróker, a partir de los archivos de compose en assets/cloud/. La consola se niega a arrancar sin un token configurado. Un token compartido sobre HTTP plano no es autenticación; termina TLS en un proxy inverso delante de ella. La configuración del bróker incluida es texto plano anónimo y es solo para pruebas; producción necesita TLS, identidades por dispositivo y ACL de temas, nada de lo cual está en la configuración incluida.
La parte del dispositivo difiere según el preajuste: contenedores sobre SSH en los preajustes reComputer, una copia de un demonio en ambas reCameras.
Una vez que la parte en la nube esté levantada, comprueba en la página de dispositivos de la consola que el dispositivo de la puerta está en línea, enviando latidos y en la versión de biblioteca de rostros esperada:
Luego inscribe a las personas que pueden pasar en la página de personas. La inscripción genera una nueva versión de la biblioteca de rostros, que el dispositivo recoge en su siguiente sondeo.
A continuación se muestra un ciclo completo: inscribir a una persona, publicar la versión, el dispositivo la descarga y conmuta, la puerta la reconoce.
Antes de poner una cerradura, confirma en la placa base PoE que la línea GPIO realmente se puede accionar:
Se permite una URL de biblioteca en texto plano http:// en una LAN, pero solo con una firma HMAC-SHA256 sobre el manifiesto; sin una clave el dispositivo se niega a arrancar. La firma protege contra la manipulación en tránsito; cualquier clave de dispositivo filtrada se puede usar para falsificar una biblioteca.
Qué interfaces expone
La interfaz son cinco temas MQTT y dos superficies HTTP.
| Tema / endpoint | Carga útil | Retenido |
|---|---|---|
access/v1/events (MQTT 8883, QoS 1) | Un JSON por decisión — ver más abajo | No |
access/v1/status/{device_id} | Latido cada 30 segundos: estado del actuador, versión de la biblioteca y etiqueta del modelo, si la detección de vida está cargada | Solo último testamento |
access/v1/commands/{door_id} | unlock, hold_open, lock | Nunca |
access/v1/receipts/{command_id} | El estado final de un comando | No |
access/v1/relay/{relay_id}/set y /state | Solo preajustes con relé MQTT; state informa el contacto físico y no refleja si la puerta está abierta | set no, state sí |
GET /v1/facedb/current, GET /v1/facedb/{version} (HTTP 8080) | Toda la superficie de distribución de la biblioteca. Range para descargas fragmentadas y reanudables | — |
/api/events, /api/devices, /api/persons, /api/audit/verify (HTTP 8088) | API de la consola detrás de la puerta de token de tres roles. Sin lectura anónima | — |
Los tres roles de token de la consola: viewer lee, operator emite unlock / hold_open / lock, admin inscribe, borra y revierte. /api/audit/verify comprueba la cadena de hashes del registro de auditoría: el registro es NDJSON solo de anexado, cada registro lleva el hash del registro anterior, y cualquier alteración de un registro histórico se informa.
La carga útil del evento
{
"schema": "access-event/v1",
"event_id": "6f1a2c3d-4e5f-4a6b-8c7d-9e0f1a2b3c4d",
"time": "2026-09-06T03:20:11Z",
"device_id": "door-front-01",
"person_id": "p_alice",
"anonymous_id": null,
"score": 0.7412,
"threshold": 0.62,
"liveness": { "passed": true, "score": 0.958 },
"decision": { "allow": true, "reason": "allowed" },
"door_action": "pulse",
"actuator_id": "door-front",
"facedb_version": 3,
"model_sha": "3a7f...",
"clock": { "valid": true, "reason": null, "offset_ms": 12 }
}
Tres campos a vigilar al integrar. facedb_version es null antes de la primera sincronización correcta, lo que significa que el dispositivo aún no tiene biblioteca (no es lo mismo que la versión 0); el motivo de denegación se informa por separado como no_facedb. threshold es el valor en vigor para esa decisión, así que un cambio de umbral aparece en el flujo de eventos. clock.valid indica si se puede confiar en la marca de tiempo corregida; los dispositivos nunca ajustan su reloj del sistema, solo llevan un desplazamiento. Un resultado de detección de vida null significa que la comprobación no se ejecutó; se trata como un fallo y se informa como liveness_unknown.
La puerta de comandos
Un comando debe llevar un conjunto de campos exacto, un command_id UUIDv4, un issued_at RFC3339 con zona horaria y un TTL dentro de los límites, y se comprueba contra una tabla de reintentos por identidad. Un comando reentregado no abre la puerta por segunda vez; el dispositivo devuelve el recibo original para que el llamador lo concilie. Uno caducado vuelve como TTL_EXPIRED. Se rechaza una identidad anónima.
Los temas set y de comandos nunca se retienen. Un desbloqueo retenido se reproduce en cada reconexión, así que la puerta se abriría sola después de un corte de energía.
Distribución de la biblioteca de rostros
El dispositivo sondea current, compara versiones y solo descarga archivos cuando la versión ha cambiado, con fragmentación y reanudación sobre Range estándar. Cada archivo se comprueba con SHA-256 y se verifica la firma del manifiesto antes de un cambio atómico; un fallo en cualquier paso deja la versión antigua en su lugar. Eliminar a una persona produce una nueva versión sin ella más una barrera de eliminación, y cualquier reversión posterior a una versión que aún la contenga se rechaza por nombre.
El manifiesto de cada versión lleva cinco campos de licencia — license_id, use_scope, redistributable, source_revision, sha256 — de modo que los términos de la licencia viajan con el artefacto.
Rendimiento y datos medidos
Latencia de activación de la biblioteca de rostros
El tiempo desde que se publica una nueva versión de la biblioteca hasta que el dispositivo la está ejecutando.
| Plataforma | Activación completa | Condiciones |
|---|---|---|
| reCamera estándar (SG2002 / CV181x riscv64, firmware 0.2.2) | p50 491.6 ms, p95 507.8 ms (n=20) | USB-RNDIS, 2 personas, biblioteca de 16.5 KB. Viaje de ida y vuelta op:reload p50 100.0 ms (n=25) |
| reCamera Pro (RV1126B, Buildroot 2023.02.6) | 62.2 ms (v1), 45.4 ms (v2); ciclo sin cambios al día 6.2 ms | Ethernet, 1–2 personas, biblioteca de menos de 20 KB |
Escalado con el tamaño de la biblioteca. Dos puntos de escala en la reCamera estándar, una ejecución cada uno: 402 personas / 2.86 MB en 9 801.7 ms, y 1502 personas / 10.66 MB en 22 278.7 ms. El tiempo de activación crece con el tamaño de la biblioteca; usa estas dos cifras para planificar la primera sincronización de una biblioteca grande.
Reproducir: en el repositorio ascendente unmanned-store-access, evaluation/runs/2026-09-06-recamera-std-p3-r2/results.md y evaluation/runs/2026-09-07-recamera-pro-p1/results.md.
Tiempo de apertura de puerta (reCamera Pro, vídeo reproducido)
Desde el primer fotograma reproducido entregado a la aplicación hasta que el pin GPIO se lleva a su nivel activo, pasando por captura, detección, detección de vida, emparejamiento, política y la escritura del pin. p50, p95 entre paréntesis, 12 ejecuciones por punto (con n=12 lee la columna p95 como un límite superior).
| Cámara / host | 10 personas | 1 000 personas |
|---|---|---|
| reCamera Pro (RV1126B), f1-access 0.1.1 | 0.62 s (0.67) | 0.66 s (0.68) |
Condiciones: fotogramas 1280x720 reproducidos a 12.5 fps, detección de vida activada, cara mínima 40 px, umbral de coincidencia 0.40; la sonda es un clip de vídeo estándar reproducido a través del propio flujo de procesamiento del dispositivo, no una persona en vivo. El pin se activó en 24 de 24 ejecuciones. La retención de contacto de 1 500 ms tras la escritura del pin no se cuenta; no hay relé ni cerradura conectados, así que estas cifras no contienen respuesta mecánica.
Rechazos (reCamera Pro, vídeo reproducido)
20 ejecuciones por fila, mismo dispositivo y aplicación.
| Ejecución | Biblioteca de rostros | Pin activado |
|---|---|---|
| Persona no registrada | 9 identidades sintéticas | 0 / 20 |
| Persona no registrada | 999 identidades sintéticas | 0 / 20 |
| Reproducción en pantalla de teléfono, clip A | 10, plantilla construida a partir del clip de ataque | 0 / 20 |
| Reproducción en pantalla de teléfono, clip B | 10, plantilla construida a partir del clip de ataque | 0 / 20 |
| Imagen fija en pantalla | 10, plantilla construida a partir del clip de ataque | 0 / 20 |
Condiciones: en las dos filas de persona no registrada la biblioteca solo contiene vectores sintéticos, por lo que la persona del clip no está registrada; en las tres filas de pantalla la plantilla se construye a partir del propio clip de ataque, por lo que la cara en la biblioteca y la cara en la pantalla son de la misma persona; la fila de pantalla fija es un fotograma de visualización mantenido inmóvil.
Otras mediciones
| Métrica | Valor | Condiciones |
|---|---|---|
| Evento de reconocimiento a lectura de pin GPIO | p50 1.448 ms, p95 2.709 ms (n=22) | reCamera Pro, eventos de reconocimiento sintéticos inyectados, lectura vía sysfs, sin circuito externo; una cota superior de un eslabón de la ruta de software, acción de la puerta no incluida |
| Servicio de reconocimiento, un fotograma: caja de cara + veredicto de vivacidad + embedding de 512 d | 24-26 ms de tiempo de servidor, 30.3 ms p50 sobre HTTP (12 peticiones) | reComputer J40 Serie (Orin NX 16 GB, JetPack 6), un fotograma de un flujo RTSP 1280x720 |
| Primer arranque del servicio de reconocimiento | Motores TensorRT construidos en el equipo en 61 s + 62 s + 73 s; el endpoint de salud responde 214 s después del arranque | reComputer J40 Serie (Orin NX 16 GB, JetPack 6) |
La lectura de gpio130 en la reCamera Pro es uno de los pines UART4 M0 del puerto de expansión reconfigurado como GPIO — la familia de 3.3 V, no una de las dos salidas nativas de 12–21 V de la placa.
Reproducir (lectura GPIO): evaluation/runs/2026-09-07-recamera-pro-p1/results.md.
Tiempos de ejecución y parámetros clave
| Host de reconocimiento | Modelo de reconocimiento y dónde se ejecuta |
|---|---|
| reCamera Pro | El propio modelo de reconocimiento del dispositivo, rv1126b:scrfd500m+mbf512@fp16 |
| reCamera estándar | Un proceso nativo en el dispositivo realiza detección, embedding, vivacidad y emparejamiento |
| Presets de reComputer | Un servicio de reconocimiento en un contenedor; los motores TensorRT se construyen en el equipo en el primer arranque |
La vivacidad se hace cumplir: si el servicio de reconocimiento no informa que la vivacidad está cargada, el adaptador se niega a ejecutarse.
Parámetros que cambian el comportamiento del despliegue:
- Intervalo de sondeo de la biblioteca de caras (30 s por defecto): el dispositivo sondea nuevas versiones en este intervalo, por lo que la latencia de activación de la biblioteca depende de él.
- Umbral de coincidencia: el umbral enviado es un valor inicial; ajústalo barriendo pares positivos y negativos en la cámara instalada. El
thresholddel evento informa del valor en vigor para cada decisión. - Los cuatro ajustes del relé
active_high,pulse_ms,relay_contact,fail_mode: sin valores por defecto; se configuran por instalación.
Degradaciones conocidas
- Registro para reCamera Pro. El
buffalo_lusado para el registro en la nube y el propiorv1126b:scrfd500m+mbf512@fp16del dispositivo se sitúan en espacios de modelo cuya similitud coseno es aproximadamente cero, por lo que la ruta de registro incluida aún no puede producir una biblioteca utilizable en producción para este dispositivo. La reCamera estándar calcula embeddings en el dispositivo y no se ve afectada. - La vivacidad en el backend RKNN no está implementada upstream. Los presets que se ejecutan en RKNN no pueden cumplir con "vivacidad aplicada".
- Cambiar el backbone de cara implica reconstruir todas las versiones de la biblioteca de caras. Los embeddings no son comparables entre modelos, por lo que todas las versiones antiguas se vuelven inutilizables; la protección
model_tagen el manifiesto impide que un dispositivo cargue una por error.
Próximos pasos
- Una prueba de bucle de contacto con un Grove Relay en reCamera Pro (20 ciclos), registrando la latencia de cierre de contacto y el tiempo de retención, antes de conectar un controlador de puerta.
Fuentes de datos y recursos
Licencias. El código del paquete de la solución y del repositorio upstream es Apache-2.0. Los pesos del modelo no lo son. La detección de caras y el embedding usan buffalo_l de InsightFace; la propia declaración de InsightFace es que el código es MIT sin limitación de uso comercial, pero que los datos de entrenamiento — y los modelos entrenados con esos datos — están disponibles solo para fines de investigación no comerciales. buffalo_l es uno de esos modelos: license_id: non-commercial, use_scope: non-commercial, redistributable: false. El paquete de la solución no incluye los pesos, y un despliegue comercial debe sustituir el backbone de cara por uno con licencia comercial.
El modelo de vivacidad pasiva, Silent-Face-Anti-Spoofing de MiniVision, es Apache-2.0: use_scope: commercial, redistribuible, usado sin modificar.
- Términos de la licencia:
gallery/ATTRIBUTION.mden el paquete de la solución, y la sección de licencias de la descripción del paquete. - Brecha de espacio de modelo de registro: upstream
docs/user-guide.md§5.1. - Los fotogramas de reconocimiento de puerta provienen de una reCamera Pro; la persona en ellos es un miembro del proyecto que tomó la toma.
- Las capturas de pantalla de la consola son datos de demostración sintéticos; las personas, puntuaciones y eventos no son resultados de campo.