Hacer que el espacio entienda el movimiento humano: cómo edge AI cambia la captura de movimiento

Idea central: edge AI no consiste en añadir un número TOPS a la ficha técnica de una cámara, sino en redistribuir el cálculo de la captura de movimiento: la cámara entiende primero la imagen y el centro reconstruye después el espacio. Puede reducir la presión del procesamiento centralizado de múltiples flujos de video, acortar la cadena de retroalimentación en sitio y reforzar el control local, pero también introduce nuevos requisitos de sincronización, versiones y operación de dispositivos.

1. Por qué los sistemas multicámara no pueden depender solo de “enviar todos los videos a una computadora”

Cuando un espacio de captura de movimiento se amplía, aumentan el número de cámaras, la resolución, la frecuencia de cuadros y el número de personas. Si cada cámara envía continuamente video HD completo a un único servidor, el centro debe asumir al mismo tiempo decodificación, detección humana, segmentación, puntos clave, coincidencia de identidad y reconstrucción 3D, y la presión sobre la red y el GPU crece con la escala. Añadir servidores puede resolver parte del problema, pero también aumenta cableado, sala técnica, consumo energético, mantenimiento y riesgo de punto único de falla.

La idea básica del edge computing es colocar parte del procesamiento cerca de donde se generan los datos. NIST SP 500-325 señala que los sistemas IoT tradicionales en la nube pueden enfrentar escala, heterogeneidad y alta latencia, y que distribuir aplicaciones y análisis dentro de la red es un valor importante del fog/edge computing.[1] Para mocap, “cerca” puede ser dentro de la cámara, en un servidor de borde del espacio o en un centro local. Diferentes capas se encargan de diferentes tareas, por lo que el sistema no necesita mover cada píxel a un extremo remoto antes de empezar a entender.

Conviene evitar un malentendido común: edge AI no significa que no exista centro. Una sola cámara puede ver una imagen 2D, pero no puede obtener por sí sola un cuerpo humano 3D completo en un espacio unificado; un sistema multicámara sigue necesitando calibración, alineación temporal, coincidencia de identidad entre vistas y triangulación. La verdadera cuestión arquitectónica es qué tareas conviene distribuir, cuáles deben concentrarse y cómo mantener la coherencia de los resultados distribuidos.

2. Qué colocamos en el lado de la cámara

En Semcam Live, el lado de la cámara ejecuta detección humana, seguimiento, segmentación, puntos clave 2D, ReID y cálculo de confianza; Active Center completa la coincidencia entre cámaras, triangulación, puntos clave 3D, resolución esquelética, IK, filtrado y retargeting.[2][3] PRO, PRO+ y ULTRA están especificados respectivamente en 40, 55 y 100 TOPS, con consumos por unidad de 10, 15 y 18W.[2] Estas son las especificaciones públicas actuales. No interpretamos TOPS directamente como precisión del modelo, rendimiento o desempeño de extremo a extremo; en primer lugar refleja una clase teórica de cómputo.

El lado de la cámara extrae primero resultados estructurados. En teoría, esto puede reducir la carga del centro al procesar repetidamente cada flujo de imágenes y también puede vincular la detección, los puntos clave y la confianza de un mismo cuadro con el número de frame. El centro se enfoca más en relaciones multivista y resolución 3D. Esta división de trabajo es adecuada para expandir espacios fijos; cuántas cámaras pueden escalarse en la práctica, qué ancho de banda requiere la red, cómo debe configurarse el hardware central y si las actualizaciones del modelo de cámara están sincronizadas deben confirmarse con el proyecto específico y la documentación técnica correspondiente.

Edge AI también cambia la localización de fallas. Cuando un sistema centralizado falla, el usuario puede ver solo un esqueleto final anormal; un sistema por capas puede revisar si una cámara tiene exposición anómala, si la confianza de puntos clave baja en cierta vista, si la coincidencia entre cámaras entra en conflicto o si la triangulación carece de observaciones. La condición es que el software exponga realmente información de diagnóstico al usuario. Por eso también mostraremos “cómo el sistema encuentra problemas”, no solo imágenes normales.

3. Cambio uno: hacer que el tiempo real sea control de calidad, no solo demostración

La captura de movimiento en tiempo real suele presentarse como un personaje que se mueve de inmediato, pero en investigación, robótica y espacios de entrenamiento, el primer valor del tiempo real es evitar capturas inválidas. El operador necesita saber antes de que termine la acción si el cuerpo salió del encuadre, si articulaciones clave quedaron ocluidas, si se intercambiaron identidades entre varias personas, si se perdió una herramienta o si los dispositivos externos están sincronizados. Si cada problema se descubre solo después de la captura, cuanto más rápida sea la captura continua, más datos desechables puede generar.

Nuestra información pública actual muestra que Semcam Live admite salida en tiempo real a 120fps y latencia de extremo a extremo inferior a 100ms.[2][3] Estos números deben entenderse junto con los límites de prueba: si el conteo empieza desde la exposición de la cámara, si incluye red, resolución central, envío por protocolo y renderizado de la aplicación objetivo; además deben indicarse número de cámaras, número de personas, complejidad del esqueleto y configuración de hardware. Los proyectos específicos se basarán en pruebas reales de la cadena.

Si la cadena en tiempo real también puede emitir confianza y estado, las aplicaciones en sitio pueden establecer umbrales de calidad: baja confianza persistente en articulaciones clave puede sugerir ajustar la acción; una cámara desconectada puede pausar una prueba oficial; identidad inestable entre varias personas puede añadir una etiqueta de repetición. Estas reglas requieren implementación conjunta de Active Center y aplicaciones sectoriales, y no pueden afirmarse sin evidencia. Una forma adecuada de comunicación es publicar un verdadero “flujo de control de calidad de datos” que deje clara la fuente de cada aviso y la acción correspondiente.

4. Cambio dos: facilitar la expansión del número de cámaras y la cobertura del espacio

Al escalar una arquitectura centralizada, añadir una cámara significa añadir ancho de banda de video, decodificación y tareas de inferencia. En una arquitectura edge, cuando se añade una cámara, la propia cámara asume parte de la inferencia y el centro recibe resultados estructurados más compactos. En teoría, esto favorece ampliar el área de cobertura y la redundancia de vistas. También planificamos ULTRA para grandes espacios con 12 personas y hasta 45 metros.[2] Pero “la arquitectura es escalable” y “el producto ya ha funcionado de forma estable en sitio a 45 metros con 12 personas” son dos afirmaciones distintas.

La expansión no es linealmente gratuita. Más cámaras aumentan la complejidad de calibración, las combinaciones de coincidencia entre vistas, los puertos de switch, el presupuesto PoE, la sincronización de reloj y el mantenimiento en sitio. Los datos estructurados también crecen con el número de personas, puntos clave y frecuencia de cuadros. Los dispositivos edge tienen requisitos de temperatura, consumo, firmware y consistencia de modelo. Si algunas cámaras ejecutan versiones distintas, las salidas pueden mostrar diferencias sistemáticas.

Por ello iremos complementando guías de configuración a escala: cuántas cámaras corresponden a espacios típicos, cómo planificar el solapamiento de campos de visión, requisitos de switches y cables, configuración del centro, distancias permitidas entre cámaras, frecuencia de revisión de calibración, pruebas de funcionamiento prolongado y recuperación ante fallas. ULTRA sigue actualmente en estado “coming soon”; los indicadores de gran espacio relacionados se describen como información previa al lanzamiento y se verificarán en proyectos reales con planos del espacio y registros de operación.

5. Cambio tres: hacer más controlables los límites de datos, pero no automáticamente seguros

El video de movimiento puede contener rostros, características corporales, estado de salud, flujos de trabajo e información del espacio. Las demostraciones robóticas también pueden incluir productos y procesos no publicados. Los servicios en la nube pueden operar de forma segura mediante contratos, cifrado y sistemas de cumplimiento, pero no todas las organizaciones están dispuestas a enviar por defecto video original al exterior. NIST SP 800-144 recomienda que las organizaciones evalúen los problemas de seguridad y privacidad correspondientes al externalizar datos, aplicaciones e infraestructura a una nube pública.[4]

Adoptamos un despliegue completamente local. La reconstrucción en tiempo real, HPE, la gestión de proyectos y la exportación pueden completarse localmente; después del procesamiento en la cámara se transmiten datos estructurados como puntos clave y confianza.[2][3] Esto ofrece a los clientes un límite de datos más directo: pueden operar en una intranet y gestionar la retención de video y el acceso externo según los requisitos del proyecto. Pero un sistema local sigue necesitando cuentas, permisos, registros, copias de seguridad, parches, cifrado de disco y seguridad física.

Edge AI también trae nuevas cuestiones de gobernanza. Los modelos pueden necesitar actualizaciones: de dónde vienen los paquetes de actualización, si están firmados, si pueden usarse sin conexión, si cambian la salida; si las cámaras almacenan imágenes en caché; si un dispositivo devuelto por reparación contiene datos; si los registros guardan información personal. Todo esto debe entrar en la documentación de seguridad del producto. Si el marketing de marca convierte “local” solo en miedo a la nube, pierde objetividad; una expresión más creíble es permitir que el cliente elija local, nube privada o híbrido según la tarea, y aclarar los límites de responsabilidad.

6. Cambio cuatro: de transmitir video a transmitir “datos con semántica”

El video es evidencia original rica pero pesada; los puntos clave y el esqueleto son resultados estructurados ligeros pero interpretados por un modelo. Edge AI permite que el sistema empiece la semantización en el punto de captura: quién es, qué píxeles le pertenecen, dónde están las articulaciones y cuál es la confianza. El centro vuelve a fusionar varias vistas en 3D. Este tipo de datos entra más fácilmente en tiempo real en ROS 2, motores o aplicaciones Python.

Los Topic de ROS 2 están diseñados para flujos continuos como datos de sensores y estado del robot,[5] lo que coincide con el modo de publicación de esqueletos en tiempo real y poses de cuerpos rígidos. MuJoCo puede usarse para estimación de estado, dinámica inversa, control y muestreo de aprendizaje automático.[6] Active Center enumera interfaces con ROS, C++, Python, Matlab, MuJoCo, Isaac, OpenSim, C3D y motores de contenido.[3] Deben publicarse formatos de mensaje, marcas de tiempo, sistemas de coordenadas, unidades, confianza y versiones.

Los datos estructurados también implican pérdida de información. Una vez que solo se guardan puntos clave, los algoritmos futuros no podrán volver a identificar en el video original los detalles ignorados en ese momento; si el modelo juzga mal, el resultado estructurado puede fijar el error. Por eso el sistema debe permitir decidir por proyecto si se guarda video original, cuánto tiempo se guarda, qué fragmentos entran en HPE y cuáles conservan solo el esqueleto. La madurez de la infraestructura no consiste en transmitir solo datos ligeros, sino en poder elegir explícitamente entre revisabilidad, privacidad y costo.

7. Cinco preguntas de aceptación para edge AI

Primero, cómo se mide la latencia de extremo a extremo. Deben indicarse punto inicial y final de tiempo, número de cámaras, número de personas, esqueleto de salida y aplicación objetivo. Segundo, cómo se mide la escala. Después de añadir cámaras y personas, cómo cambian la frecuencia de cuadros, la latencia, la identidad y los cuadros perdidos. Tercero, cómo se ven las anomalías. Si existen diagnósticos legibles para anomalías de una sola cámara, red, calibración o modelo. Cuarto, cómo se gestionan las versiones. Si el software de cámaras y centro es compatible, y si una actualización afecta datos históricos. Quinto, cómo se protegen los datos. Dónde están respectivamente video, puntos clave, registros y paquetes de actualización, y quién puede acceder.

Las acciones de prueba también deben cubrir dificultades reales: giros rápidos, bajar y subir del suelo, brazos cruzados, ropa holgada, intercambio de posiciones entre varias personas, zonas de borde, cambios entre luz fuerte y débil y oclusión por accesorios. Para cada fallo debe registrarse si el problema corresponde a detección 2D, coincidencia entre cámaras, triangulación, restricciones esqueléticas o retargeting posterior. Solo cuando una falla puede localizarse en la cadena, la arquitectura edge se convierte realmente en una ventaja operativa.

Hemos organizado estas cinco preguntas en una lista pública de aceptación, y también invitamos a los clientes a traer sus propios movimientos, condiciones del espacio y software para un PoC. Presentar completamente las condiciones de prueba, los límites de falla y el costo de limpieza ayuda más a los clientes profesionales a juzgar si el sistema se adapta a su workflow que mostrar solo salidas ideales.

8. Conclusión: el destino de edge AI es un espacio de movimiento operable

Edge AI cambia la captura de movimiento no porque cada cámara tenga un chip de cálculo adicional, sino porque se reorganiza la relación entre percepción, cálculo, datos y aplicaciones. El lado de la cámara entiende primero la imagen 2D, el centro local fusiona 3D, los datos en tiempo real entran en aplicaciones sectoriales y los fragmentos clave pasan después por HPE; esta estructura por capas ofrece la oportunidad de soportar espacios más grandes, menor latencia de retroalimentación y límites de datos más claros.

Para los clientes, juzgar si una arquitectura edge tiene valor también exige comparar el costo operativo completo, no solo el GPU central. El cálculo en la cámara puede reducir la carga de inferencia centralizada, pero aumenta el número de dispositivos, la gestión de firmware y el diagnóstico en sitio; la operación local puede reducir la dependencia de Internet público, pero exige que el cliente gestione servidores, cuentas y copias de seguridad. En proyectos reales registraremos horas de despliegue, configuración de red, utilización del centro, número de fallas, tiempo de recuperación y proporción de datos válidos, y compararemos la misma tarea con otras arquitecturas. Sin estos registros de largo plazo, la formulación más rigurosa sigue siendo “la arquitectura busca mejorar la expansión y el control en sitio”, no prometer directamente una reducción de costo determinada.

La dirección arquitectónica de Semcam Live coincide con esta tendencia, y seguiremos complementando protocolos de prueba de extremo a extremo, guías de despliegue a escala, registros de funcionamiento prolongado, ejemplos de interfaces, explicaciones de gobernanza de datos y casos reales de clientes. No trataremos TOPS como una conclusión de rendimiento, ni equipararemos lo local con seguridad automática. Lo que Semcam Live realmente quiere lograr es que el espacio deje de ser solo una grabación de video y pueda entender el movimiento en sitio, emitir datos y hacerse responsable de los resultados.

Información y notas de citas

- Información de producto: tareas en la cámara, TOPS, consumo, 120fps, latencia, especificaciones ULTRA e interfaces se basan en nuestra información pública actual de producto; escalabilidad, ancho de banda, funcionamiento prolongado y latencia completa deben combinarse con pruebas del proyecto.

- Materiales del sector: las explicaciones sobre edge computing, seguridad en la nube, ROS y MuJoCo provienen de documentación oficial.

- Recomendaciones de implementación: las cinco preguntas de aceptación y las recomendaciones de gobernanza del texto son métodos que hemos resumido para despliegues profesionales, y no representan que todas las capacidades se cumplan automáticamente en todas las configuraciones.

Referencias

1. NIST SP 500-325: modelo conceptual de fog computing (https://csrc.nist.gov/pubs/sp/500/325/final)

2. Página de producto Semcam Live (https://semcamlive.com/zh/SemcamLive)

3. Página de producto Semcam Active Center (https://semcamlive.com/zh/active-center)

4. NIST SP 800-144: guía de seguridad y privacidad en computación de nube pública (https://csrc.nist.gov/pubs/sp/800/144/final)

5. Documentación oficial de ROS 2: Topics (https://docs.ros.org/en/ros2_documentation/kilted/Concepts/Basic/About-Topics.html)

6. Documentación oficial de MuJoCo: Overview (https://mujoco.readthedocs.io/en/stable/overview.html)