L’accord conclu par Qualcomm en vue d’acquérir PickNik, entreprise spécialisée dans les logiciels de robotique, constitue un événement important dans un domaine qui produit rarement des vidéos spectaculaires : la couche logicielle qui planifie les mouvements d’une machine, évite les collisions et lui permet de manipuler des objets. L’opération ne livre ni nouvel humanoïde, ni flotte d’entrepôt, ni véhicule autonome. Elle vise une infrastructure capable de se placer sous de nombreux types de robots.

Un bras robotique collaboratif planifie un mouvement sans collision autour d’objets dans un laboratoire industriel, représentant les logiciels robotiques ouverts et l’IA en périphérie.

C’est ce qui rend l’opération facile à sous-estimer. Un robot peut disposer de moteurs performants, de caméras, d’un grand modèle multimodal et d’une démonstration soignée, puis échouer à accomplir une tâche utile si son planificateur de mouvement ne sait pas transformer une instruction de haut niveau en séquence physiquement valide. Le système doit comprendre la géométrie du robot, le monde qui l’entoure, les contraintes de ses articulations et les conséquences du déplacement d’une pince dans un espace encombré.

Le 23 septembre, Qualcomm a annoncé un accord pour acquérir PickNik et indiqué que MoveIt, MoveIt Pro et les futures technologies de PickNik seraient intégrés plus étroitement à ses plateformes robotiques Dragonwing. Qualcomm a également précisé que MoveIt 1 et MoveIt 2 resteraient open source, pilotés par la communauté et compatibles avec du matériel tiers. L’opération reste soumise aux conditions habituelles de clôture : il s’agit donc d’un changement de propriétaire prévu, et non d’une intégration déjà achevée. L’annonce de Qualcomm constitue la source principale de ces engagements.

La bonne manière de lire cette opération est d’y voir un test : la robotique peut-elle construire une couche logicielle commune et fiable alors que le marché du matériel reste fragmenté ? Elle soulève aussi une question qui comptera davantage pour les développeurs que le titre de l’acquisition : un framework ouvert peut-il bénéficier de ressources commerciales et d’optimisations pour l’informatique en périphérie sans devenir, dans les faits, dépendant d’une seule plateforme de puces ?

Ce que fait réellement MoveIt

MoveIt est construit sur le Robot Operating System et sert à la manipulation robotique ainsi qu’à la planification des mouvements. Ce n’est pas un cerveau robotique généraliste et il ne décide pas seul de ce qu’un robot d’usine, d’hôpital, de laboratoire ou de maison doit faire. Il fournit plutôt des outils permettant au développeur de décrire un robot et son environnement, de calculer des mouvements réalisables, de vérifier les collisions et d’exécuter un plan à travers la pile de contrôle de la machine.

La distinction est importante, car « le robot comprend la tâche » et « le robot peut effectuer le prochain mouvement en toute sécurité » sont deux problèmes d’ingénierie différents. Un modèle vision-langage-action peut interpréter une demande comme « prends le récipient à côté de l’outil ». Un framework de planification doit encore déterminer si le bras peut atteindre le récipient, si la prise choisie est compatible avec l’objet, si le poignet heurtera l’établi, si un autre robot est entré dans le même espace et si la trajectoire respecte les limites articulaires et de vitesse.

La scène de planification de MoveIt est la représentation centrale de ce travail. La documentation officielle la décrit comme un modèle de l’état actuel du robot, de sa géométrie, de sa cinématique, de sa dynamique et du monde environnant. Ces informations permettent de calculer la cinématique directe et inverse, d’évaluer les contraintes et de vérifier les collisions. Le framework peut tester le robot par rapport à son environnement, mais aussi le robot contre lui-même.

Ces fonctions ne sont pas très glamour, mais c’est là que de nombreuses promesses d’IA physique rencontrent le sol. Un modèle de langage peut suggérer une séquence qui paraît logique tout en restant impossible pour le matériel. Une politique apprise peut produire une trajectoire convaincante dans une démonstration sans disposer d’une représentation fiable d’un obstacle nouvellement apparu. La planification des mouvements fournit une couche de raisonnement géométrique explicite et de validation entre l’intention d’une politique et les commandes envoyées aux actionneurs.

C’est aussi la raison pour laquelle MoveIt ne constitue pas une garantie de sécurité prête à l’emploi. La vérification des collisions dépend de la qualité et de l’actualité du modèle du robot, des données des capteurs, de l’étalonnage, de la géométrie des objets, des règles de collision autorisées et du système de contrôle. Un planificateur peut rejeter une trajectoire qu’il sait invalide, mais il ne peut pas raisonner correctement au sujet d’un obstacle qui n’a jamais été représenté ou d’une pince mal étalonnée. Un plan valide n’est pas la même chose qu’une machine certifiée sûre.

Pourquoi Qualcomm veut cette couche

Qualcomm construit depuis des années des plateformes de calcul basse consommation et hétérogènes pour des appareils qui doivent traiter les données près de l’endroit où elles sont produites. Sa marque Dragonwing couvre désormais des plateformes de calcul destinées à l’industrie et à la robotique. L’accord avec PickNik lui apporte une équipe logicielle et un projet robotique ouvert largement utilisé, capable de relier ces processeurs à des tâches réelles de manipulation.

L’objectif déclaré de l’entreprise est de faciliter le passage de modèles d’IA, notamment les modèles vision-langage et vision-langage-action, à la planification, à la manipulation et au contrôle en temps réel. Qualcomm a également mis en avant l’intégration avec les cartes Arduino VENTUNO Q, présentée comme un moyen d’atteindre une vaste communauté de développeurs. En pratique, Qualcomm cherche à rendre son matériel plus pertinent au moment où un robot doit percevoir, planifier et agir en continu, plutôt que simplement exécuter une inférence isolée dans un benchmark.

Cette stratégie diffère de la vente d’un robot complet. Le fabricant d’un robot contrôle l’ensemble du produit et peut dissimuler une grande partie de sa pile logicielle derrière une application unique. Un fabricant de puces veut au contraire que de nombreux constructeurs, équipes de recherche, intégrateurs et développeurs utilisent sa plateforme de calcul avec des machines différentes. Un framework robotique indépendant du matériel peut servir de pont entre ces marchés.

L’avantage recherché par Qualcomm ne se résume pas au fait que MoveIt puisse fonctionner sur une carte Dragonwing. L’occasion plus large consiste à optimiser un flux de développement familier autour des accélérateurs d’IA, des cœurs CPU, de la connectivité et des capacités temps réel du processeur. Si un développeur peut employer les mêmes concepts de planification avec un bras posé sur une table, un manipulateur mobile, un robot d’inspection ou une plateforme de recherche personnalisée, le fournisseur de puces peut espérer devenir une composante de la pile par défaut plutôt qu’un élément interchangeable choisi tard dans le projet.

Cette ambition a toutefois une limite pratique. La planification des mouvements n’est qu’une partie d’un robot déployé. La perception, l’estimation de l’état, le choix de la prise, l’enchaînement des tâches, le contrôle des actionneurs, la surveillance de sécurité certifiée, le réseau, la simulation, la gestion de flotte et la maintenance restent des sujets distincts. Une inférence plus rapide ou une intégration plus étroite peuvent réduire la latence et le travail de développement, mais elles ne suppriment pas la difficulté de l’intégration.

La promesse open source est le détail le plus important

L’annonce de Qualcomm affirme explicitement que MoveIt 1 et MoveIt 2 resteront open source sous leur licence actuelle, avec des feuilles de route pilotées par la communauté, des ressources ouvertes et la prise en charge de matériel tiers. Dave Coleman, fondateur de PickNik, a formulé le même engagement dans son récit de l’opération : le projet resterait indépendant du matériel et l’entreprise continuerait à soutenir MoveIt et ROS open source. L’explication de PickNik fournit aussi un contexte utile sur l’histoire du projet et sa base de contributeurs.

Cette promesse répond à la préoccupation évidente que suscite une acquisition commerciale. Les contributeurs peuvent se détourner d’un projet ouvert s’ils pensent que le nouveau propriétaire orientera le développement vers une plateforme propriétaire ou reléguera le matériel concurrent au second plan. Même lorsque le code source reste public, la gouvernance, les priorités de publication, la qualité de la documentation, la disponibilité des mainteneurs et le traitement des contributions externes peuvent modifier profondément l’expérience réelle.

La déclaration initiale est rassurante, mais l’épreuve de long terme sera opérationnelle. Les développeurs observeront si les fonctions importantes arrivent d’abord sur le matériel Qualcomm, si les pilotes tiers continuent de recevoir de l’attention, si les instructions de compilation et de déploiement restent pratiques en dehors de l’écosystème Dragonwing et si la gouvernance du projet donne aux mainteneurs externes un rôle réel.

Il existe ici une tension véritable, et non une contradiction simple. Un projet ouvert peut profiter des effectifs d’ingénierie, des ressources de test, des relations avec les développeurs et de la capacité de financement d’une grande entreprise pour assurer sa maintenance sur la durée. Le même projet peut aussi devenir moins neutre si les priorités commerciales de son propriétaire influencent les travaux de performance, la documentation ou les décisions de feuille de route. Le résultat dépendra de l’indépendance accordée par Qualcomm aux mainteneurs et de la visibilité de ces décisions pour la communauté.

L’Open Source Robotics Alliance fait partie de ce contexte. Qualcomm et PickNik en sont tous deux membres fondateurs, et Qualcomm a indiqué qu’il continuerait à soutenir ROS ainsi que des projets comme Space ROS. Cela ne crée pas de garantie juridique de neutralité, mais inscrit l’opération dans un effort institutionnel plus large visant à préserver une infrastructure robotique partagée, au lieu de laisser chaque composant majeur sous le contrôle d’un seul fournisseur de produits.

Pourquoi le calendrier compte

Les entreprises de robotique cherchent actuellement à combiner des politiques apprises avec le contrôle et la planification classiques. Les systèmes les plus ambitieux promettent des comportements plus flexibles dans les entrepôts, les usines, les maisons et d’autres environnements qui ne peuvent pas être entièrement décrits à l’avance. Pourtant, les robots ont encore besoin d’interfaces et de contraintes prévisibles lorsqu’ils évoluent près de personnes, d’équipements coûteux ou d’objets fragiles.

L’architecture qui en résulte comporte de plus en plus de couches. Un modèle de haut niveau interprète le langage, les images ou les démonstrations. Un système au niveau des tâches choisit les sous-objectifs à poursuivre. Un planificateur de mouvements transforme ces sous-objectifs en trajectoires. Un contrôleur traduit les trajectoires en commandes pour les actionneurs. Des systèmes de surveillance vérifient que le robot réel ne s’écarte pas de l’état attendu. Des opérateurs humains peuvent intervenir lorsque l’incertitude ou le risque d’échec franchit un seuil.

MoveIt se situe au milieu de cette pile. Il peut recevoir des objectifs de systèmes plus intelligents sans prétendre les remplacer, et fournir des capacités de mouvement structurées à des systèmes qui n’utilisent aucun grand modèle d’IA. Cela le rend utile pendant le passage de l’automatisation industrielle conventionnelle à une IA physique plus adaptative.

La transition est moins nette que ne le laisse entendre l’expression « IA pour la robotique ». L’automatisation traditionnelle fonctionne souvent parce que l’environnement, l’outillage, la présentation des objets et la séquence sont strictement contrôlés. Les politiques apprises peuvent gérer davantage de variations, mais elles introduisent de nouvelles incertitudes et exigent des données, des évaluations et une surveillance. Une couche de planification partagée peut aider à relier les deux approches, mais elle ne transforme pas à elle seule une tâche non structurée en tâche structurée.

Les applications crédibles à court terme seront donc probablement des applications bornées : un robot connu, un espace de travail défini, une famille limitée d’objets et une procédure claire de récupération. Cela peut néanmoins avoir une grande valeur. La manipulation mobile, l’automatisation des laboratoires, la manutention en entrepôt, la transformation alimentaire et pharmaceutique ainsi que la robotique spatiale comportent toutes des tâches pour lesquelles un peu de flexibilité évite une programmation personnalisée coûteuse. L’objectif n’est pas l’autonomie universelle dans une seule version, mais un chemin plus court entre une capacité testée et un déploiement répétable.

Ce qui pourrait changer pour les développeurs

Si Qualcomm exécute correctement sa stratégie, les développeurs pourraient constater des progrès dans plusieurs domaines. Le premier concerne la mise en route du matériel. Les équipes robotiques consacrent souvent trop de temps à relier capteurs, calcul, middleware, planification des mouvements et contrôle avant même de pouvoir évaluer l’application réelle. Des plateformes de référence mieux prises en charge pourraient réduire ce travail d’intégration initial.

Le deuxième domaine est le déploiement en périphérie. Un prototype de laboratoire peut s’appuyer sur une station de travail, un refroidissement généreux et un réseau stable. Un robot mobile ou industriel ne le peut généralement pas. Il doit parfois prendre ses décisions localement, car la latence du réseau, les pertes de connectivité, les exigences de confidentialité ou les contraintes de sécurité rendent la dépendance au cloud inadaptée. Un calcul embarqué plus efficace pourrait faciliter l’exécution conjointe de modèles de perception et de politiques avec la planification et le contrôle.

Le troisième est le passage de l’expérience au produit. MoveIt Pro est la plateforme commerciale de PickNik pour les systèmes robotiques avancés, tandis que MoveIt reste la base open source. Cette séparation offre aux organisations une voie possible entre les outils publics et le support payant, l’aide au déploiement ainsi que les fonctions destinées à la production. Les ressources de Qualcomm pourraient élargir cette voie si l’entreprise investit dans la documentation, les tests, les conceptions de référence et le support, au lieu de se concentrer uniquement sur les performances du silicium.

Le quatrième concerne l’accès des petites équipes. Un groupe de robotique n’a pas besoin d’inventer chaque composant d’une pile de manipulation, mais il doit souvent les intégrer lui-même. Une combinaison bien prise en charge de ROS, MoveIt, calcul en périphérie et cartes de développement pourrait rendre des prototypes crédibles plus abordables pour les universités, les fabricants spécialisés et les jeunes entreprises. L’effet serait particulièrement important lorsque la valeur du robot vient d’une tâche spécialisée plutôt que d’un immense volume de production.

Aucun de ces bénéfices ne découle automatiquement d’une acquisition. L’abstraction matérielle peut masquer des différences importantes plutôt que les supprimer. Une carte capable d’exécuter une démonstration peut encore manquer de pilotes, de comportement temps réel, de marge thermique, de voie de certification ou d’engagement de support nécessaires à un client industriel. Les développeurs devront évaluer l’ensemble du système, et pas seulement le nombre de modèles pris en charge ou la vitesse d’un benchmark d’inférence.

Qui en bénéficiera en premier

Les premiers bénéficiaires seront probablement les équipes qui utilisent déjà ROS et MoveIt ou qui envisagent ces outils pour des projets de manipulation. Elles pourraient profiter de cibles de calcul mieux prises en charge sans abandonner un framework familier. Les groupes de recherche pourraient disposer de plateformes en périphérie plus capables et bénéficier de la faculté d’une grande entreprise à maintenir les logiciels sur une période plus longue.

Les intégrateurs de systèmes constituent un autre groupe important. Ils doivent combiner robots, caméras, pinces, systèmes de sécurité, convoyeurs et logiciels métier pour des clients dont les exigences diffèrent. Une couche de planification commune peut réduire le travail d’ingénierie répété, surtout lorsqu’un intégrateur travaille avec plusieurs marques de robots ou doit adapter une cellule à un nouveau produit.

Les fabricants de bras robotisés et de manipulateurs mobiles pourraient également y gagner, à condition que la prise en charge du matériel reste réellement multiplateforme. Ils pourraient se concentrer sur la conception mécanique, les capteurs, les effecteurs terminaux et les comportements propres à leur application, tout en s’appuyant sur un framework de planification mature pour les fonctions communes de manipulation.

Les utilisateurs finaux en bénéficieront plus tard et de façon moins visible. Un responsable d’usine ne se souciera pas nécessairement de savoir si MoveIt se trouve sous la machine. Les résultats pertinents seront une mise en service plus courte, moins d’échecs, une reconfiguration plus simple, une maintenance facilitée et un coût total de possession inférieur. Ces résultats exigent une validation dans l’environnement du client, et pas seulement une démonstration logicielle réussie.

Les consommateurs ne devraient pas observer d’effet direct à court terme. Les robots domestiques rencontrent des problèmes de perception et de sécurité plus difficiles que les cellules industrielles contrôlées, et un framework de planification des mouvements ne résout ni l’ambiguïté du foyer, ni la confidentialité, ni la responsabilité juridique. Il pourrait un jour entrer dans la pile d’un robot grand public, mais cette opération concerne d’abord les développeurs et les déploiements industriels, plutôt que les personnes qui attendent un assistant domestique généraliste.

Coût et maturité : ce que l’opération ne dit pas

Ni l’annonce de Qualcomm ni l’explication publique de PickNik ne donnent de prix d’achat ou de calendrier pour la clôture de l’acquisition. Elles ne fournissent pas non plus de feuille de route détaillée sur la manière dont MoveIt sera intégré à Dragonwing. Il serait donc prématuré d’annoncer une amélioration précise des performances, une baisse du prix des robots ou une accélération du calendrier de déploiement.

Il n’y a pas non plus de raison de considérer l’acquisition comme la preuve que les robots généralistes sont prêts pour les lieux de travail ordinaires. MoveIt peut rendre la planification des mouvements plus accessible, mais un robot déployable a toujours besoin d’un matériel fiable, d’une perception précise, d’effecteurs adaptés, de comportements de récupération, d’une ingénierie de sécurité, d’une formation des opérateurs et d’un modèle économique. Le même logiciel peut soutenir un prototype de recherche et une machine de production présentant des niveaux de robustesse très différents.

La maturité doit être évaluée au niveau du système. Les questions utiles incluent notamment :

  • Le robot peut-il détecter que son modèle du monde est erroné ?
  • Peut-il s’arrêter sans danger lorsqu’une personne ou un objet inattendu entre dans l’espace de travail ?
  • Un opérateur peut-il inspecter, modifier et rejouer les plans ?
  • Le système récupère-t-il un échec de prise sans provoquer un second échec ?
  • La latence, la dérive d’étalonnage et la perte du réseau sont-elles testées dans les conditions réelles d’exploitation ?
  • Le client peut-il continuer à faire fonctionner le robot si la plateforme de calcul privilégiée change ?

Un planificateur de mouvements aide à répondre à certaines de ces questions, en particulier celles qui portent sur la géométrie, les contraintes et la validité des trajectoires. Il ne répond pas à toutes. Cette distinction compte, car l’industrie robotique a souvent confondu un sous-système performant avec un produit terminé.

Le risque stratégique pour Qualcomm

Qualcomm entre sur un marché où la confiance des développeurs peut compter davantage qu’un benchmark isolé. Les équipes robotiques construisent souvent leurs systèmes pendant des années, accumulent des pilotes personnalisés et des données d’étalonnage, et choisissent leurs outils en partie pour éviter de dépendre d’un seul fournisseur. Si Qualcomm est perçu comme utilisant MoveIt principalement pour pousser les développeurs vers Dragonwing, certains des utilisateurs les plus engagés du projet pourraient chercher des solutions de remplacement ou maintenir leurs propres forks.

Le meilleur argument de l’entreprise n’est donc pas que le matériel Qualcomm serait plus rapide. C’est que les développeurs pourraient obtenir de meilleures performances et un meilleur support tout en conservant la possibilité d’utiliser un autre matériel lorsque leur application l’exige. Cet argument sera vérifié dans les détails : contributions en amont, cadence des versions, prise en charge des plateformes non Qualcomm, gouvernance transparente et qualité des exemples fonctionnant en dehors d’un environnement de démonstration.

Qualcomm devra également montrer qu’elle comprend la robotique comme un problème d’exploitation. Un fabricant de puces met naturellement l’accent sur le calcul, mais les robots échouent pour des raisons situées en dehors du processeur : lentilles sales, pinces usées, modèles d’objets incorrects, palettes mal placées, instructions ambiguës, éclairage variable, interruptions du réseau et comportement humain. Une pile logicielle qui tient compte de ces conditions aura plus de valeur qu’une pile qui accélère uniquement le parcours nominal.

L’occasion stratégique pour PickNik

Pour PickNik, l’opération offre un moyen d’élargir la portée du projet sans abandonner l’identité qui lui a donné sa crédibilité. Le propre récit de l’entreprise indique que plus de 560 personnes ont contribué à MoveIt, avec des milliers de forks et une utilisation étendue dans la recherche et l’industrie. Ces chiffres décrivent un actif communautaire, et non un simple produit propriétaire classique.

Un propriétaire plus important pourrait financer des tests sur davantage de configurations robotiques, améliorer la documentation, soutenir des versions maintenues sur le long terme et aider à transformer des intégrations de recherche réussies en méthodes de déploiement répétables. Il pourrait aussi faciliter l’alignement des outils ouverts avec les exigences de l’IA en périphérie, des systèmes temps réel et du support commercial.

Le danger est que l’échelle rende le projet plus lourd et plus lent. Les développeurs apprécient les logiciels robotiques ouverts notamment parce qu’ils peuvent les inspecter, les adapter et les combiner avec du matériel inhabituel. Si de nouvelles couches deviennent difficiles à comprendre ou si des fonctions importantes passent derrière des offres commerciales, le projet pourrait perdre la flexibilité qui en a fait une base commune. Le succès de l’acquisition se mesurera à la quantité de capacités supplémentaires apportées à la couche ouverte, et pas seulement à la taille de l’activité robotique de Qualcomm.

Ce qu’il faut surveiller ensuite

Les signaux les plus instructifs viendront après l’annonce, et non de l’annonce elle-même. Les développeurs devraient surveiller les premières versions d’intégration concrètes, les configurations Dragonwing et Arduino prises en charge, ainsi que les preuves que les mêmes flux de travail continuent de fonctionner sur du matériel tiers. Ils devraient aussi suivre les éventuelles modifications de la gouvernance de MoveIt, de la structure des mainteneurs, du traitement des tickets et du processus de publication.

Les équipes techniques qui évaluent l’écosystème devraient tester des flux complets plutôt que des démonstrations isolées. Une évaluation sérieuse inclurait les mises à jour de scène, les objets de collision, la cinématique inverse, l’exécution des trajectoires, les délais des capteurs, l’intervention d’un opérateur et la récupération après l’échec d’un plan. Elle devrait comparer les performances et la fiabilité sur au moins deux cibles de calcul lorsque la neutralité matérielle est une exigence.

Les clients devraient demander aux fournisseurs quelles parties de leur pile robotique dépendent de MoveIt, lesquelles sont propriétaires et ce qui se passerait si un composant était abandonné. Ils devraient réclamer des données provenant de l’environnement d’exploitation visé : distributions des temps de cycle, taux d’intervention, journaux de défauts, procédures d’étalonnage et besoins de maintenance. Une vidéo de manipulation bien produite ne suffit pas à estimer le coût d’un déploiement.

Pour les chercheurs, l’acquisition crée à la fois une occasion et une responsabilité. Des plateformes en périphérie plus capables pourraient faciliter le test de politiques apprises au plus près du robot. En parallèle, l’ouverture continue de MoveIt doit être considérée comme une pratique communautaire qui a besoin de contributeurs, de revues, de documentation et de tests indépendants. L’open source n’est pas seulement une mention de licence : c’est une manière de garder la pile utilisable lorsque les priorités d’aucun fournisseur ne correspondent à tous les besoins.

La leçon plus large

Les progrès de la robotique sont souvent racontés à travers des corps : un humanoïde qui marche, un drone qui navigue ou un bras robotisé qui réussit une prise difficile. L’accord entre Qualcomm et PickNik met en lumière une contrainte plus discrète. Pour de nombreuses machines, le goulet d’étranglement ne réside pas seulement dans le corps ou le modèle. Il se trouve dans le tissu conjonctif qui permet à différents modèles, capteurs, planificateurs, contrôleurs et plateformes matérielles de fonctionner ensemble de manière prévisible.

Posséder ce tissu conjonctif peut avoir une valeur stratégique, mais il est aussi facile de l’endommager. Qualcomm a l’occasion de rendre les logiciels ouverts de manipulation plus simples à déployer sur du matériel efficace en périphérie. PickNik obtient des ressources pour prolonger un projet qui couvre déjà la recherche et la production. Les développeurs peuvent espérer une meilleure intégration, mais ils ont aussi intérêt à observer de près la neutralité et la gouvernance.

L’opération doit donc être jugée selon un critère pratique : aide-t-elle davantage d’équipes à construire des robots capables d’exécuter des tâches bornées de manière répétée, de récupérer lorsque les conditions changent et de rester maintenables à travers plusieurs générations de matériel ? Si la réponse est oui, l’acquisition dépassera largement la gamme de produits de Qualcomm. Si elle est non, le secteur aura acquis une nouvelle pile robotique reconnue sans résoudre le problème de déploiement qui sépare un plan affiché à l’écran d’une machine installée dans l’atelier.

Pour l’instant, la conclusion vérifiée la plus solide reste plus étroite. Qualcomm a accepté d’acquérir une entreprise responsable d’un framework robotique ouvert important et s’est publiquement engagée à maintenir MoveIt ouvert et indépendant du matériel. L’étape suivante ne constitue pas une promesse d’autonomie généraliste. C’est un test : l’échelle commerciale peut-elle renforcer une infrastructure robotique partagée sans la transformer en entonnoir déguisé vers un fournisseur unique ?

Sources