Expertise · Systèmes pour robots

Logiciel pour robots : la couche qui décide du mouvement, le module de vision et celui d’audition. Aujourd’hui, nous avons une vérification hors ligne et une simulation — nous n’avons rien qui commande un moteur réel.

Nous écrivons la cinématique, la vérification de trajectoire et la simulation physique reproductible, avec des gates qui bloquent lorsque la preuve manque. Pour la vision, nous avons un prototype sur caméra fixe, pas sur robot. Pour l’audio sur robot, nous n’avons rien construit, et la page le dit au lieu d’emprunter des preuves à la téléphonie. Nous ne travaillons pas avec ROS.

Discuter d'un projet

Offre, avec conditionsAm rulat azi tot ce se poate rula. Stratul de control există și e serios, dar e offline: un modul propriu de cinematică pentru un braț cu șase axe, care a rezolvat 8.400 din 8.400 de puncte de traseu, și un validator de fizică pe MuJoCo 3.10.0 cu 34 de teste trecute, plus 14 teste pe partea de vizualizare. Amândouă declară în propria sursă că nu au transport către hardware și nu pot comanda un robot real. La vedere avem un prototip propriu — detecție și urmărire de persoane pe cameră IP fixă — cu un singur comit și cu directorul de teste gol. La audio pe robot avem zero: tot ce e pe disc e voce de call-center sau bibliotecă terță de telefonie, iar singura lucrare acustică proprie s-a încheiat cu un rezultat negativ, scris în aplicație. ROS: zero instalat, zero scris. Regula cere minimum două implementări proprii pentru „am făcut”; pe control le am, dar niciuna nu atinge hardware, iar celelalte două straturi ale serviciului sunt sub prag. Deci: ofertă cu condiții, cu granițele desenate.

Le logiciel d’un robot a trois couches qui se cassent différemment : ce qu’il voit et entend, ce qu’il décide, et ce qu’il envoie vers les moteurs. Sur les deux premières, nous avons des travaux propres avec des tests qui s’exécutent. Sur la troisième — le pont vers le matériel — nous n’avons rien, et c’est la limite du service, pas un détail d’implémentation. Deux de nos codes le disent dans leur propre en-tête, en anglais, précisément pour ne pas pouvoir être lus de travers : le module de cinématique n’a pas de transport vers le matériel et ne peut pas commander un robot réel.

Ce qui existe sur la partie mouvement, c’est une vérification avant mouvement. Un module propre calcule la cinématique directe, le jacobien et la cinématique inverse pour un bras à six axes, avec une réserve imposée par rapport aux limites de chaque axe, et il a été utilisé pour vérifier une trajectoire entière : 8.400 points demandés, 8.400 résolus, avec la vitesse maximale par axe restée sous 8 % de la limite du catalogue. À part cela, un validateur de physique s’exécute sur MuJoCo 3.10.0 sur processeur, avec un pas de calcul d’une milliseconde, dans six scénarios, chacun exécuté deux fois, avec la même graine — et les deux exécutions donnent des empreintes identiques. Le déterminisme n’est pas une affirmation, c’est une comparaison de sommes de contrôle.

Ce qu’il y a du côté de la vision est moins important, et il est honnête de dire à quel point. Un prototype propre détecte et suit des personnes sur des flux de caméra IP, avec un petit détecteur de la famille YOLO, un suiveur multi-objets, une estimation de posture pour cinq états et le contrôle du pivotement, de l’inclinaison et du zoom de la caméra. Il n’a qu’un seul commit et un répertoire de tests vide. Et la différence entre cela et la vision d’un robot est réelle, pas formelle : la caméra d’un robot se déplace avec lui, la scène est proche, l’exposition change à chaque pas, et le budget de latence est différent, parce que l’image doit parvenir à une décision de mouvement, pas à un écran. Nous n’avons pas de caméra de profondeur, nous n’avons pas d’étalonnage de caméra, nous n’avons pas d’odométrie visuelle.

Du côté audio pour robots, nous n’avons rien construit, et nous n’emprunterons pas de preuves ailleurs. Nous avons de vrais travaux vocaux pour la téléphonie et pour des assistants conversationnels, mais un microphone sur un robot a d’autres problèmes : le bruit propre de la machine, des ventilateurs et des servomoteurs qui se déclenchent בדיוק lorsque le robot se met en mouvement, la direction d’où vient la voix, l’écho dans la pièce et la distance variable. Le seul travail acoustique propre que nous avons s’est terminé par un résultat négatif, écrit dans l’application, et nous le publions tel quel — parce qu’un résultat négatif mesuré est plus utile qu’une promesse.

Ce que cela comprend

Le travail, par composantes

Nous vérifions la cinématique avant de déplacer quoi que ce soit

Cinématique directe, jacobien analytique construit à partir de produits vectoriels, cinématique inverse numérique avec quatre positions de départ et une réserve imposée de 10° par rapport à la limite de chaque axe, avec convergence à 0,05 mm sur la position. Avec cela, nous avons vérifié un emplacement en 1.331 positions de grille et un trajet complet de 8.400 points, tous résolus. Résultats : vitesse maximale par axe à 7,86 % de la limite catalogue et marge minimale par rapport aux limites de 19,9°. Le rapport écrit lui-même sa nature : screening discret hors ligne, sans sortie vers le matériel.

Nous exécutons la physique séparément de l’image, et de manière reproductible

Le validateur de physique est un programme séparé de la partie visuelle, sur MuJoCo 3.10.0, sur processeur, avec un pas d’une milliseconde et un échantillonnage à 20 millisecondes. Six scénarios, chacun exécuté deux fois avec la même graine, avec des empreintes identiques entre les exécutions. Les tolérances sont déclarées dans le code, pas sous-entendues : dérive d’énergie inférieure à 1 % relatif, pénétration dans le sol inférieure à 3 cm, violation de limite articulaire inférieure à 0,03 radian. Ce qui est mesuré en chute libre est l’accélération du centre de masse, comparée à la gravité configurée — 9,80665, 1,62 et 3,72076 mètres par seconde au carré.

Nous mettons une porte qui bloque, pas une qui se contente d’étiqueter

Le registre des actions demande à chaque mouvement de déclarer sa provenance, et les 15 actions enregistrées sont toutes marquées cinématiques, validées à zéro — parce qu’aucun de ces contrôleurs n’est piloté par un simulateur de corps rigides avec limites d’actionneur et validation de contact. Au-dessus, une gate de libération lit le fichier de preuve et échoue si une constante clé n’est pas calibrée sur le matériel. Aujourd’hui elle échoue : une seule constante d’arrêt articulaire, de 5 millisecondes, est déclarée dans le code comme paramètre provisoire, et non comme valeur mesurée — et cela suffit pour que la vérification complète renvoie une erreur. C’est une règle écrite par nous contre nous-mêmes.

Nous lisons la description du robot avec notre propre parser, et nous disons ce qu’il laisse de côté

Pour l’affichage et l’inspection des modèles, nous avons écrit notre propre analyseur du format MJCF : corps, articulations de type charnière, libre, glissière et sphérique, géométries, matériaux et chargement des maillages, avec cache de géométrie. Il laisse volontairement de côté les géométries de collision, parce que c’est un analyseur visuel, pas un analyseur de contact — écrit dans le code, pas découvert après coup. Les modèles utilisés sont les officiels, avec 29 degrés de liberté pour l’humanoïde et 12 pour le quadrupède.

Nous ne confondons pas les valeurs commandées avec les valeurs mesurées

Les angles qui apparaissent à l’écran sont ceux commandés par le contrôleur, publiés dans une seule direction vers l’interface. Ils ne contiennent ni bruit d’encodeur, ni état mesuré, ni couple, ni vitesse, ni température — écrit explicitement dans l’audit technique du projet. Cette distinction paraît petite jusqu’au moment où quelqu’un prend un joli graphique pour de la télémétrie de robot ; c’est pourquoi nous l’écrivons dans le code, dans l’audit et ici.

Vision : détection et suivi de personnes, sur caméra fixe

Un prototype propre qui prend des flux de caméra IP, détecte des personnes avec un petit modèle de la famille YOLO, les suit d’image en image avec un suiveur multi-objets à un seuil de confiance de 0,5, estime la posture en cinq états — inconnu, assis, debout, en marche, penché — et peut faire pivoter la caméra via le protocole de contrôle standard. Il s’exécute de force sur processeur, à cause d’une incompatibilité notée dans le code. Son état réel : un seul commit et un répertoire de tests vide. C’est un prototype, pas un module de production, et il n’a jamais été sur un robot.

Audio sur robot : nous disons ce qui manque, au lieu d’emprunter à la téléphonie

Nous n’avons pas de détecteur de mot d’activation, nous n’avons pas de détecteur vocal exécuté localement, nous n’avons pas de formation de faisceau, nous n’avons pas d’estimation de direction et nous n’avons pas de code d’annulation de l’écho écrit par nous. Ce que nous avons dans la zone vocale est pour les appels téléphoniques et pour des assistants conversationnels : l’interruption de l’interlocuteur se fait soit par le détecteur du service du fournisseur, soit par l’appui sur une touche dans le menu téléphonique, et l’annulation de l’écho vient des bibliothèques du navigateur ou d’une pile tierce de téléphonie. Ce sont des choses réelles, mais elles résolvent un autre problème qu’un microphone monté sur une machine qui bouge et fait elle-même du bruit.

ROS : nous n’en avons pas, et nous ne faisons pas semblant

Il n’est installé sur aucune de nos machines et nous n’avons jamais écrit un nœud, un fichier de lancement ou un package propre. Le seul package avec un système de construction spécifique à ROS sur le disque est la description publique d’un robot industriel, téléchargée comme fichier de modèle et utilisée exactement telle quelle, non compilée. Si votre projet suppose ROS 2 comme acquis, c’est une information que vous devez avoir avant la première réunion, pas après.

Ce que nous acceptons et ce que nous n’acceptons pas

Nous accepterions : vérification cinématique et de trajectoire avant un achat, simulation avec tolérances déclarées, un module de perception mesuré sur vos données, et un pont vers le hardware réalisé avec l’intégrateur responsable de la sécurité. Nous n’accepterions pas : écrire nous-mêmes la couche qui arrête un robot en cas d’urgence, promettre un module audio sur robot sans une mesure préalable du bruit propre de votre machine, ni dire que notre expérience de la voix au téléphone couvre l’ouïe d’un robot.

À quoi cela ressemble

Le parcours, étape par étape.

Nous définissons la tâche et les limites physiques, puis nous vérifions si elles tiennent

Ce que le robot doit atteindre, dans quel volume, à quelle vitesse et avec quelle charge. Puis la vérification : couverture du volume, marge par rapport aux limites de chaque axe, vitesse et accélération sur la trajectoire, collisions sur géométrie réelle comme filtrage. Nous livrons le rapport avec ses limites écrites. Cette étape présente un bon rapport entre coût et dommage évité, car elle se fait avant un achat.

Nous simulons avec des tolérances déclarées et un déterminisme vérifié

Scénarios, graine fixe, exécutions répétées, comparaison d’empreintes, tolérances écrites dans le code. Nous livrons aussi la liste des éléments que la simulation NE démontre PAS — chez nous, par exemple, un validateur qui confirme la chute libre et le maintien de position sur un plan de test ne confirme pas la marche, le contact complexe ou la dynamique de l’actionneur, et l’écrit lui-même.

Nous construisons la perception sur vos données, pas sur un ensemble public

Un détecteur qui fonctionne sur des images d’internet ne dit rien de votre halle. Cette étape signifie une capture dans l’environnement réel, un ensemble d’évaluation propre, une mesure de référence et seulement ensuite le choix du modèle et de l’endroit où il s’exécute. Nous livrons les chiffres de référence et la méthode avec laquelle vous pouvez les reproduire, y compris lorsqu’ils sont faibles.

Le pont vers le hardware — l’étape que nous n’avons jamais réalisée

Nous l’écrivons en dernier et avec des conditions, car c’est la seule de la liste pour laquelle nous n’avons pas d’expérience propre. Elle se fait avec l’intégrateur ou le fabricant du robot, et les fonctions d’arrêt d’urgence, de limitation et de sécurité restent sous la responsabilité de celui qui répond de la machine. Ce que nous pouvons porter jusque-là, c’est la couche de décision, vérifiée, avec son interface documentée.

Lanțul unui robot, de la stânga la dreapta, cu starea reală a fiecărei verigi. Vedere: prototip pe cameră fixă, un singur comit, fără teste. Auz: gol — nimic construit pentru un microfon pe o mașină care se mișcă. Decizie și cinematică: verificat, cu 8.400 de puncte rezolvate și cu o poartă care blochează atunci când o constantă nu e calibrată. Ultima săgeată, cea către motoare, e întreruptă: niciun cod al nostru nu are transport către hardware. Desenul e făcut ca să se vadă unde se oprește serviciul, nu ca să pară complet.

Les données

Ce que nous touchons, où elles sont et combien de temps elles restent

Les questions que pose toute personne ayant un délégué à la protection des données — posées ici avant qu'il ne les pose.

La caméra d’un robot filme des personnes, et cela change tout: Un module de vision qui détecte et suit des personnes produit des données personnelles au sens propre du terme, même si personne n’est identifié par son nom. Les questions se posent avant la première ligne de code : l’image est-elle conservée ou seulement le résultat, où le traitement a-t-il lieu, qui a accès aux enregistrements, combien de temps ils sont conservés, que montre-t-on aux personnes filmées. Notre prototype a été construit comme expérience technique, et non comme système mis en fonctionnement, et nous ne le proposons pas comme tel.
Sur l’appareil ou sur le serveur — une décision de latence, pas de préférence: Si l’image doit parvenir à une décision de mouvement, le trajet jusqu’à un serveur et retour entre directement dans le budget de réaction. Si le résultat est seulement affiché ou enregistré, le serveur est acceptable. La décision est prise à partir du budget de latence mesuré sur votre cas, et elle est écrite. Notre prototype fonctionne de force sur le processeur, ce qui constitue une limitation réelle de vitesse, notée dans le code.
Les simulations sont conservées avec graine et empreinte: Un résultat de simulation sans graine de générateur et sans somme de contrôle des entrées n’est pas une preuve, c’est une histoire. Nos rapports de physique portent la graine, le nombre d’exécutions par scénario, la version du moteur et l’état de déterminisme ; les rapports de cinématique portent l’empreinte des fichiers d’entrée. C’est ainsi qu’on peut vérifier, des mois plus tard, si une valeur citée est encore valide.
Audio signifie enregistrer une pièce: Un microphone sur un robot entend tout ce qui se passe autour, pas seulement la commande qui lui est donnée. La règle que nous appliquerions est que l’enregistrement continu n’existe pas par défaut, mais seulement la fenêtre nécessaire à la décision, et que ce qui est conservé pour l’amélioration soit un choix explicite, avec un délai. Nous n’avons pas encore construit un tel système, donc il s’agit d’une position déclarée, pas d’une pratique démontrée.
Les modèles et les descriptions de robot ont leurs licences: Les modèles de robot que nous utilisons en simulation proviennent de collections publiques, sous licences permissives, et les descriptions de robots industriels sont des fichiers publics des fabricants. Ils ne sont pas à nous et nous ne les revendiquons pas ; dans votre projet, la licence de chaque source externe est vérifiée avant d’entrer dans le livrable.

Un cas

Une mesure acoustique propre qui s’est achevée par « non », et pourquoi nous la publions

La situation

Dans une application propre de macOS, nous avons voulu savoir si le haut-parleur et le microphone d’un appareil grand public peuvent être utilisés comme un sonar simple — un signal émis, son écho mesuré, une distance déduite. La question est exactement celle qui apparaît aussi sur un robot : combien pouvez-vous apprendre sur l’espace autour de vous en utilisant le matériel audio que vous avez déjà, sans capteurs supplémentaires.

Ce que nous avons construit

Nous avons construit la chaîne complète, pas un schéma : un signal balayé de 12 millisecondes qui monte de 2 à 8 kilohertz, fenêtré, émis à faible amplitude ; corrélation croisée entre le signal émis et celui enregistré ; détection de l’arrivée directe avec une fenêtre de garde de 1,5 milliseconde, afin que les lobes latéraux de l’autocorrélation ne soient pas pris pour un écho ; recherche de l’écho dans une fenêtre allant jusqu’à 60 millisecondes, avec des seuils séparés de corrélation et de gain relatif ; vitesse du son corrigée en fonction de la température de l’air. Près de 800 lignes de Swift, avec détection du trajet audio — si l’émetteur et le récepteur sont sur des appareils différents, la géométrie est bistatique et un seul temps de retard définit une ellipse, pas un point.

Ce qui en est sorti

La conclusion est écrite dans l’application, dans l’écran qui dit ce qu’elle peut et ne peut pas mesurer : sur le haut-parleur et le microphone du même ordinateur, on peut détecter des changements grossiers des réflexions après calibration, car la latence est relativement stable. Avec des écouteurs sans fil, en revanche, la réduction active du bruit, la formation de faisceau, le codec et la latence variable détruisent la mesure métrique précise — ils peuvent donc être utilisés pour l’orientation de la tête, pas comme sonar précis. Nous avons écrit cela dans le produit, pas dans une note interne.

Ce que le cas ne dit pas

Le résultat concerne du matériel grand public sur une liaison sans fil, pas un robot avec des microphones montés et câblés. Ce qui se transfère n’est pas la conclusion, mais la méthode : on mesure le canal avant de promettre la fonction. Pour un robot, la même investigation commencerait par le bruit propre de la machine en mouvement — et seul le résultat de cette mesure dirait ce qui est possible.

Questions

Ce que les gens nous demandent avant d'appeler

Avez-vous déjà installé votre logiciel sur un robot physique ?

Non. Aucun de nos codes n’a jamais commandé un moteur réel, et deux de nos codebases le déclarent même dans l’en-tête du fichier, pour ne pas pouvoir être mal lus. Ce que nous avons exécuté, c’est de la simulation et de la vérification hors ligne. Si c’est un problème pour votre projet, il vaut mieux le savoir dès la première phrase que de le découvrir à la troisième réunion.

Alors qu’avez-vous, concrètement ?

Trois choses, toutes exécutables devant vous. Un module de cinématique pour un bras à six axes, qui a vérifié une trajectoire de 8.400 points sans aucun échec, avec une marge minimale de 19,9° par rapport aux limites des axes. Un validateur de physique sur MuJoCo 3.10.0, avec 34 tests qui passent et un déterminisme prouvé par des empreintes identiques sur des exécutions répétées. Et un démonstrateur dans le navigateur avec 14 tests, dont la porte de qualification tombe aujourd’hui volontairement. Plus un prototype de vision, à propos duquel nous disons ouvertement qu’il n’a qu’un seul commit et aucun test.

Travaillez-vous avec ROS ?

Non. Il n’est pas installé chez nous, nous n’avons écrit aucun nœud, aucun fichier de lancement et aucun paquet. Le seul paquet de type ROS sur nos disques est la description publique d’un robot industriel, téléchargée comme fichier de modèle pour les calculs de cinématique — utilisée comme données, pas construite. Si votre équipe travaille déjà sous ROS 2 et que c’est une exigence, nous partons de zéro là-bas, et il faut l’inclure dans le calcul.

Pouvez-vous faire le module de vision pour notre robot ?

Avec une étape de mesure en amont, pas sur la base du prototype que nous avons. Ce qui en est transféré, c’est la manière de travailler — détecteur, suivi entre images, seuil de confiance, où s’exécute le calcul. Ce qui ne se transfère pas, c’est la situation : la caméra d’un robot bouge, le sujet est proche, la lumière change à chaque pas, et le résultat doit conduire à une décision de mouvement, pas à un écran. En plus, nous n’avons ni caméra de profondeur, ni calibration de caméra, ni odométrie visuelle dans aucun projet propre. La première étape serait une capture depuis votre environnement et une mesure de référence.

Vous avez des agents vocaux. N’est-ce pas la même chose que l’écoute d’un robot ?

Non, et nous ne voulons pas que cela y ressemble. Au téléphone, le canal est connu et étroit, le locuteur est collé au micro, et l’interruption du locuteur est gérée soit par le service du fournisseur, soit par une touche appuyée. Sur un robot, le micro est placé sur une machine qui fait elle-même du bruit au moment précis où elle bouge, la voix vient d’une direction qui change, la pièce produit de l’écho et la distance varie. Ce sont des problèmes d’acoustique, pas de conversation. Nous pourrions commencer par une mesure du bruit propre de votre robot — mais ce serait un nouveau travail, pas une extension de celui de téléphonie.

Pourquoi publiez-vous une gate de qualification qui échoue ?

Parce que l’alternative, c’est qu’elle passe sans rien signifier. Notre gate lit un fichier de preuve et vérifie si une constante critique — le temps d’arrêt à la fin de course de l’articulation — a été calibrée sur le matériel. Ce n’est pas le cas : c’est une valeur provisoire de 5 millisecondes, mise pour qu’une simulation stable existe. Tant qu’elle est provisoire, la vérification complète renvoie une erreur, et toutes les actions restent marquées cinématiques. Le jour où elle passera signifiera quelque chose précisément parce qu’aujourd’hui elle ne passe pas.

Que ne démontrent pas vos simulations ?

Plus qu’elles ne démontrent, et c’est écrit dans les rapports. Le validateur de physique confirme la chute libre et le maintien de position sur un plan de test — pas la marche, pas le contact complexe, pas la dynamique de l’actionneur, pas les capteurs synthétiques. Le screening de trajectoire confirme la cinématique et la géométrie — pas le matériau, pas les flexibles, pas les délais de processus, pas les rampes de démarrage-arrêt du contrôleur. Et le mouvement dans le navigateur est un aperçu, pas un résultat de simulation.

Nous avons besoin d’une certification de sécurité. La faites-vous ?

Non. Nous pouvons concevoir l’architecture de sécurité — circuit séparé du contrôle du mouvement, contrôleur de sécurité indépendant, arrêt sûr du couple, freins avec retour d’information, états de défaut qui tombent en sécurité ; c’est aussi ce que nous avons fait dans un projet propre de machine. Mais l’évaluation de conformité et la responsabilité pour la machine mise sur le marché restent au fabricant ou à l’intégrateur. Nous n’assumons pas ce rôle et nous ne signons pour personne.

Pourquoi est-il écrit « offre » sur cette page ?

Parce que le service comporte trois couches et qu’aucune ne franchit complètement le seuil que nous nous sommes fixé. Pour le contrôle, nous avons deux travaux propres avec des tests qui passent, mais aucun ne touche au matériel. Pour la vision, nous avons un prototype avec un commit et sans tests. Pour l’audio pour robots, nous n’avons rien. Nous aurions pu écrire une page qui sonne comme une expérience, en utilisant des mots comme « perception » et « contrôle » sans chiffres. Elle aurait tenu jusqu’à la première question d’un ingénieur.

Sur quoi reposent les affirmations ci-dessus (17 sources)

`vision.megapromoting.com` nu e un sistem de vederehttps://vision.megapromoting.com · 2026-09-06

16 d'entre elles sont du code et des fichiers de nos dépôts. Nous n'en publions ni le nom ni la ligne : réunies sur une seule page, elles décriraient trop précisément comment sont construits des systèmes qui ne sont pas seulement les nôtres. Nous les parcourons avec vous, dans le dépôt, sur demande — la vérification reste possible, elle se fait simplement lors d'un échange.

Comment nous travaillons Tous les services

Qu'est-ce que vous voudriez voir mieux fonctionner ?

Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.

Discutons