Permettre aux espaces de comprendre le mouvement humain : comment l’edge AI transforme la capture de mouvement

Idée centrale : l’edge AI ne consiste pas à ajouter un chiffre TOPS dans la fiche technique d’une caméra, mais à redistribuer le calcul de la capture de mouvement : la caméra comprend d’abord l’image, puis le centre reconstruit l’espace. Elle peut réduire la pression du traitement centralisé de plusieurs flux vidéo, raccourcir la boucle de retour sur site et renforcer le contrôle local, tout en introduisant de nouvelles exigences de synchronisation, de version et d’exploitation des équipements.

1. Pourquoi les systèmes multi-caméras ne peuvent pas seulement “envoyer toutes les vidéos vers un ordinateur”

Quand un espace de capture de mouvement s’agrandit, le nombre de caméras, la résolution, la fréquence d’images et le nombre de personnes augmentent tous. Si chaque caméra envoie en continu une vidéo HD complète vers un seul serveur, le centre doit prendre en charge simultanément le décodage, la détection humaine, la segmentation, les points clés, l’appariement d’identité et la reconstruction 3D, tandis que la pression sur le réseau et le GPU augmente avec l’échelle. Ajouter simplement des serveurs peut résoudre une partie du problème, mais cela accroît aussi le câblage, la salle machine, la consommation électrique, la maintenance et le risque de point de défaillance unique.

L’idée de base de l’edge computing est de placer une partie du traitement près de l’endroit où les données sont produites. NIST SP 500-325 indique que les systèmes IoT cloud traditionnels peuvent rencontrer des problèmes d’échelle, d’hétérogénéité et de forte latence, et que distribuer les applications et l’analyse à l’intérieur du réseau constitue une valeur importante du fog/edge computing.[1] Pour la mocap, “près” peut signifier dans la caméra, dans un serveur en bordure du site ou dans un centre local. Différentes couches prennent en charge différentes tâches, de sorte que le système n’a pas besoin de déplacer chaque pixel vers un point distant avant de commencer à comprendre.

Il faut éviter une idée reçue : l’edge AI ne signifie pas absence totale de centre. Une seule caméra peut voir une image 2D, mais elle ne peut pas obtenir seule un corps humain 3D complet dans un espace unifié ; un système multi-caméras exige toujours calibration, alignement temporel, appariement d’identité entre vues et triangulation. La vraie question d’architecture est de savoir quelles tâches se prêtent à la distribution, lesquelles doivent rester centralisées, et comment maintenir la cohérence des résultats distribués.

2. Ce que nous avons placé côté caméra

Dans Semcam Live, le côté caméra exécute la détection humaine, le suivi, la segmentation, les points clés 2D, ReID et le calcul de confiance ; Active Center réalise l’appariement entre caméras, la triangulation, les points clés 3D, la résolution squelettique, IK, le filtrage et le retargeting.[2][3] PRO, PRO+ et ULTRA sont respectivement annoncés à 40, 55 et 100 TOPS, avec une consommation par unité de 10, 15 et 18W.[2] Ce sont les spécifications publiques actuelles. Nous n’interprétons pas directement TOPS comme précision du modèle, débit ou performance de bout en bout ; cela reflète d’abord une classe de puissance de calcul théorique.

Le côté caméra extrait d’abord des résultats structurés. En théorie, cela peut réduire la charge du centre, qui n’a plus à retraiter chaque flux image de manière répétée, et permet de lier la détection, les points clés et la confiance d’une même image au numéro de frame. Le centre se concentre davantage sur les relations multi-vues et la résolution 3D. Cette répartition convient à l’extension de sites fixes ; le nombre réel de caméras extensibles, la bande passante réseau requise, la configuration matérielle du centre et la synchronisation des mises à niveau de modèles caméra doivent être confirmés selon le projet et la documentation technique correspondante.

L’edge AI change aussi la localisation des pannes. Quand un système centralisé échoue, l’utilisateur peut ne voir qu’un squelette final anormal ; un système en couches peut vérifier si une caméra a une exposition anormale, si la confiance des points clés baisse dans une vue, si l’appariement entre caméras entre en conflit ou si la triangulation manque d’observations. La condition est que le logiciel expose réellement les informations de diagnostic aux utilisateurs. Nous montrerons donc aussi “comment le système détecte les problèmes”, et pas seulement les images normales.

3. Changement un : faire du temps réel un contrôle qualité, pas seulement une démonstration

La capture de mouvement en temps réel est souvent présentée comme un personnage qui bouge immédiatement, mais dans la recherche, la robotique et les espaces d’entraînement, sa première valeur est d’éviter les acquisitions invalides. L’opérateur doit savoir avant la fin du mouvement si le corps sort du cadre, si des articulations clés sont occultées, si l’identité de plusieurs personnes a été échangée, si un outil est perdu ou si des équipements externes sont synchronisés. Si chaque problème n’est découvert qu’après l’acquisition, plus l’acquisition continue est rapide, plus les données inutilisables peuvent augmenter.

Nos informations publiques actuelles indiquent que Semcam Live prend en charge une sortie temps réel à 120fps, avec une latence de bout en bout inférieure à 100ms.[2][3] Ces chiffres doivent être compris avec leurs limites de test : départ à l’exposition de la caméra ou non, inclusion du réseau, de la résolution centrale, de l’envoi protocolaire et du rendu de l’application cible ; il faut aussi préciser le nombre de caméras, le nombre de personnes, la complexité du squelette et la configuration matérielle. Les projets concrets seront évalués selon les tests réels de la chaîne.

Si la chaîne temps réel peut également produire confiance et état, les applications sur site peuvent fixer des seuils qualité : une faible confiance persistante sur des articulations clés déclenche une demande d’ajustement du mouvement ; une caméra hors ligne suspend l’essai officiel ; une identité multi-personnes instable ajoute une étiquette de reprise. Ces règles nécessitent une implémentation conjointe par Active Center et les applications métiers, et ne peuvent pas être revendiquées sans preuve. La bonne manière de communiquer consiste à publier un véritable “workflow de contrôle qualité des données” qui précise la source de chaque alerte et l’action associée.

4. Changement deux : faciliter l’extension du nombre de caméras et de la couverture du site

Lorsqu’une architecture centralisée s’étend, chaque caméra ajoutée signifie davantage de bande passante vidéo, de décodage et de tâches d’inférence. Dans une architecture edge, quand une caméra est ajoutée, elle prend elle-même en charge une partie de l’inférence, et le centre reçoit des résultats structurés plus compacts. En théorie, cela favorise l’extension de la zone couverte et la redondance des vues. Nous prévoyons aussi ULTRA pour de grands espaces avec 12 personnes et jusqu’à 45 mètres.[2] Mais “l’architecture est extensible” et “le produit a déjà fonctionné de manière stable sur site à 45 mètres avec 12 personnes” sont deux affirmations différentes.

L’extension n’est pas linéairement gratuite. Plus de caméras augmentent la complexité de calibration, les combinaisons d’appariement entre vues, les ports de switch, le budget PoE, la synchronisation d’horloge et la maintenance sur site. Les données structurées elles-mêmes croissent avec le nombre de personnes, de points clés et la fréquence d’images. Les équipements edge ont des exigences de température, de puissance, de firmware et de cohérence de modèle. Si certaines caméras exécutent des versions différentes, les sorties peuvent présenter des différences systématiques.

Nous compléterons donc progressivement les guides de configuration à grande échelle : nombre de caméras pour les espaces typiques, planification du chevauchement des champs de vision, exigences de switch et de câbles, configuration du centre, distances de caméra autorisées, fréquence de vérification de calibration, tests de fonctionnement longue durée et reprise après panne. ULTRA reste actuellement “à venir” ; les indicateurs de grand espace associés sont décrits comme des informations de pré-lancement et seront vérifiés dans des projets réels avec plans de site et journaux d’exploitation.

5. Changement trois : rendre les frontières de données plus contrôlables, sans sécurité automatique

La vidéo de mouvement peut contenir des visages, des caractéristiques corporelles, des informations de santé, des workflows et des informations sur le site. Les démonstrations robotiques peuvent aussi impliquer des produits et procédés non publiés. Les services cloud peuvent fonctionner de manière sûre grâce aux contrats, au chiffrement et aux systèmes de conformité, mais toutes les organisations ne souhaitent pas envoyer par défaut la vidéo brute vers l’extérieur. NIST SP 800-144 recommande aux organisations d’évaluer les questions de sécurité et de confidentialité correspondantes lorsqu’elles externalisent données, applications et infrastructure vers un cloud public.[4]

Nous adoptons un déploiement entièrement local. La reconstruction temps réel, HPE, la gestion de projet et l’export peuvent tous être réalisés localement ; après traitement côté caméra, des données structurées comme les points clés et la confiance sont transmises.[2][3] Cela donne aux clients une frontière de données plus directe : ils peuvent fonctionner sur un intranet et gérer la conservation vidéo et les accès externes selon les exigences du projet. Mais un système local a toujours besoin de comptes, permissions, journaux, sauvegardes, correctifs, chiffrement disque et sécurité physique.

L’edge AI apporte aussi de nouvelles questions de gouvernance. Les modèles peuvent nécessiter des mises à jour : d’où viennent les paquets, sont-ils signés, fonctionnent-ils hors ligne, modifient-ils les sorties ; les caméras mettent-elles les images en cache ; les appareils renvoyés en réparation contiennent-ils des données ; les journaux enregistrent-ils des informations personnelles. Tout cela doit entrer dans la documentation de sécurité produit. Si le marketing de marque présente seulement le “local” comme une peur du cloud, il perd en objectivité ; une formulation plus crédible consiste à laisser les clients choisir local, cloud privé ou hybride selon la tâche, en clarifiant les frontières de responsabilité.

6. Changement quatre : passer de la transmission vidéo à la transmission de “données sémantiques”

La vidéo est une preuve brute riche mais lourde ; les points clés et les squelettes sont des résultats structurés légers mais interprétés par un modèle. L’edge AI permet au système de commencer la sémantisation dès l’acquisition : qui est la personne, quels pixels lui appartiennent, où sont les articulations, quelle est la confiance. Le centre fusionne ensuite plusieurs vues en 3D. Ce type de données entre plus facilement en temps réel dans ROS 2, les moteurs ou les applications Python.

Les Topic de ROS 2 sont conçus pour les flux continus tels que les données de capteurs et l’état robotique,[5] ce qui correspond au mode de publication des squelettes temps réel et des poses de corps rigides. MuJoCo peut servir à l’estimation d’état, à la dynamique inverse, au contrôle et à l’échantillonnage en apprentissage automatique.[6] Active Center liste des interfaces avec ROS, C++, Python, Matlab, MuJoCo, Isaac, OpenSim, C3D et les moteurs de contenu.[3] Il faut publier les formats de messages, horodatages, systèmes de coordonnées, unités, confiances et versions.

Les données structurées impliquent aussi une perte d’information. Une fois seuls les points clés sauvegardés, les futurs algorithmes ne peuvent plus réidentifier dans la vidéo originale les détails ignorés à l’époque ; si le modèle se trompe, le résultat structuré peut figer l’erreur. Le système doit donc permettre à chaque projet de décider s’il conserve la vidéo brute, combien de temps, quels extraits passent dans HPE et lesquels ne gardent que le squelette. Une infrastructure mature ne transmet pas seulement des données légères : elle permet de choisir explicitement entre vérifiabilité, confidentialité et coût.

7. Cinq questions d’acceptation pour l’edge AI

Premièrement, comment mesurer la latence de bout en bout. Il faut fournir le point de départ et le point d’arrivée, le nombre de caméras, le nombre de personnes, le squelette de sortie et l’application cible. Deuxièmement, comment mesurer l’échelle. Après ajout de caméras et de personnes, comment changent la fréquence d’images, la latence, les identités et les pertes d’images. Troisièmement, comment voir les anomalies. Existe-t-il un diagnostic lisible pour les anomalies de caméra unique, réseau, calibration ou modèle. Quatrièmement, comment gérer les versions. Les logiciels caméra et centre sont-ils compatibles, et la mise à niveau affecte-t-elle les données historiques. Cinquièmement, comment protéger les données. Où se trouvent respectivement vidéo, points clés, journaux et paquets de mise à niveau, et qui peut y accéder.

Les mouvements de test doivent aussi couvrir les difficultés réelles : rotation rapide, montée et descente au sol, bras croisés, vêtements amples, échange de positions entre plusieurs personnes, zones périphériques, changement entre lumière forte et faible, occlusion par accessoires. Pour chaque échec, il faut enregistrer si le problème vient de la détection 2D, de l’appariement entre caméras, de la triangulation, des contraintes squelettiques ou du retargeting aval. L’architecture edge ne devient un avantage opérationnel réel que si la panne peut être localisée dans la chaîne.

Nous avons organisé ces cinq questions en checklist d’acceptation publique, et nous invitons aussi les clients à apporter leurs propres mouvements, conditions de site et logiciels pour un PoC. Présenter complètement les conditions de test, les limites d’échec et les coûts de nettoyage aide davantage les clients professionnels à juger si le système convient à leur workflow que de ne montrer que des sorties idéales.

8. Conclusion : le point d’arrivée de l’edge AI est un espace de mouvement exploitable

L’edge AI transforme la capture de mouvement non parce que chaque caméra reçoit une puce de calcul supplémentaire, mais parce que la relation entre perception, calcul, données et applications est réorganisée. Le côté caméra comprend d’abord l’image 2D, le centre local fusionne la 3D, les données temps réel entrent dans les applications métiers, puis les extraits clés passent dans HPE ; cette structure en couches peut soutenir des espaces plus grands, une latence de retour plus faible et des frontières de données plus claires.

Pour les clients, juger la valeur d’une architecture edge exige aussi de comparer le coût d’exploitation complet, et pas seulement le GPU central. Le calcul côté caméra peut réduire la charge d’inférence centralisée, mais augmente le nombre d’équipements, la gestion des firmware et le diagnostic sur site ; le fonctionnement local peut réduire la dépendance à l’Internet public, mais oblige le client à gérer serveurs, comptes et sauvegardes. Dans les projets réels, nous enregistrerons temps de déploiement, configuration réseau, taux d’utilisation du centre, nombre de pannes, temps de récupération et proportion de données valides, puis comparerons la même tâche avec d’autres architectures. Sans ces enregistrements de long terme, la formulation la plus rigoureuse reste “l’architecture vise à améliorer l’extension et le contrôle sur site”, et non une promesse directe de réduction de coût certaine.

La direction architecturale de Semcam Live est cohérente avec cette tendance, et nous continuerons à compléter les protocoles de test de bout en bout, guides de déploiement à grande échelle, journaux de fonctionnement longue durée, exemples d’interfaces, notes de gouvernance des données et cas clients réels. Nous ne traiterons pas TOPS comme une conclusion de performance, et nous n’assimilerons pas le local à une sécurité automatique. Ce que Semcam Live veut réellement faire, c’est permettre au site de ne plus être seulement un enregistreur vidéo, mais de comprendre le mouvement sur place, produire des données et assumer la responsabilité des résultats.

Informations et notes de citation

- Informations produit : les tâches côté caméra, TOPS, la consommation, 120fps, la latence, les spécifications ULTRA et les interfaces sont basés sur nos informations produit publiques actuelles ; l’extensibilité, la bande passante, le fonctionnement longue durée et la latence complète doivent être combinés aux tests projet.

- Sources sectorielles : les explications sur l’edge computing, la sécurité cloud, ROS et MuJoCo proviennent de documents officiels.

- Recommandations de mise en œuvre : les cinq questions d’acceptation et les recommandations de gouvernance de l’article sont des méthodes que nous avons synthétisées pour des déploiements professionnels, et ne signifient pas que toutes les capacités s’appliquent automatiquement à toutes les configurations.

Références

1. NIST SP 500-325 : modèle conceptuel du fog computing (https://csrc.nist.gov/pubs/sp/500/325/final)

2. Page produit Semcam Live (https://semcamlive.com/zh/SemcamLive)

3. Page produit Semcam Active Center (https://semcamlive.com/zh/active-center)

4. NIST SP 800-144 : recommandations sur la sécurité et la confidentialité dans le cloud public (https://csrc.nist.gov/pubs/sp/800/144/final)

5. Documentation officielle ROS 2 : Topics (https://docs.ros.org/en/ros2_documentation/kilted/Concepts/Basic/About-Topics.html)

6. Documentation officielle MuJoCo : Overview (https://mujoco.readthedocs.io/en/stable/overview.html)