Microduck de Pollen Robotics : pourquoi je l'ai commandé

Je n’avais pas prévu d’acheter un robot bipède cette année. J’ai pourtant payé 523,20 € TTC pour un Microduck Cream, un Charger Pack et un Accessory Pack Yellow, alors que je ne l’ai encore jamais eu entre les mains.

À ce prix, ce n’est pas un gadget acheté pour le faire marcher cinq minutes dans le salon. L’expérience que j’ai en tête est précise : donner une présence physique à l’instance Hermes Agent qui tourne déjà dans mon homelab.

Hermes sait analyser des documents, utiliser des outils et me répondre dans Matrix. Son monde s’arrête encore aux serveurs et aux API. En clair, je veux lui donner des yeux, des oreilles et des jambes, mais pas les clés du bus moteur.

La fiche produit a attiré mon attention. Les dépôts GitHub ont fait pencher la décision : boucle de contrôle à 50 Hz, services écrits en Rust, simulateur MuJoCo et chaîne d’entraînement jusqu’au déploiement des politiques de mouvement.

Les premières livraisons sont visées avant Noël 2026. En attendant, ce texte n’est pas un test, mais le raisonnement derrière la commande, ce que les sources publiques permettent de vérifier et le programme que je compte suivre à la réception.

En bref

#

• Microduck est un bipède assemblé de 25 cm et d’environ 780 g.
• Il embarque 15 moteurs, un Rockchip RK3566, 1 Go de RAM et 32 Go de stockage.
• Une caméra, une matrice ToF 8 x 8, deux IMU, des microphones, un haut-parleur et deux antennes NFC complètent le matériel.
• Une manette et plusieurs comportements entraînés sont fournis pour l’utiliser sans coder.
• Les politiques sont entraînées dans MuJoCo, exportées en ONNX puis exécutées à bord.
• Le logiciel est publié sous licence Apache 2.0, mais les plans mécaniques et électroniques ne sont pas ouverts.
• L’autonomie annoncée est d’environ une heure avec une batterie NP-F550 amovible.
• Ma commande complète, avec deux packs et la livraison, revient à 523,20 € TTC.

Pourquoi je l’ai commandé

#

J’aurais pu partir d’un kit, d’une carte ARM et d’une poignée de servos. Le résultat aurait sans doute été plus facile à réparer et plus ouvert sur le plan matériel. Mais j’aurais surtout passé les premiers mois sur la mécanique, l’alimentation et le câblage. Ce n’est pas la partie du projet que je veux explorer en priorité.

Ce qui m’intéresse se situe à la frontière entre l’agent et la machine physique : quelles actions exposer au LLM, quelles décisions conserver dans le robot, comment arrêter un mouvement douteux et comment observer ce qui s’est réellement passé après une mauvaise consigne.

Microduck me permet en principe de commencer à cet endroit. Il arrive assemblé, fonctionne avec une manette et dispose déjà de politiques de mouvement. Pollen publie en parallèle le logiciel embarqué, le simulateur et les outils d’entraînement. Je paie donc aussi pour ne pas devoir reconstruire toute la plateforme avant de travailler sur cette interface.

L’ordre d’apprentissage me paraît logique : commencer par piloter le robot dans sa configuration d’origine, observer son fonctionnement, modifier une politique existante et seulement ensuite le relier à Hermes Agent. Aller directement à la commande vocale rendrait impossible de savoir quelle couche est responsable lorsque quelque chose ne fonctionne pas.

L’expérience de Pollen Robotics compte aussi dans la décision. L’équipe bordelaise, intégrée à Hugging Face depuis avril 2025, développe déjà Reachy 2 et Reachy Mini. Microduck est plus modeste, mais il reprend la même idée : fournir une plateforme suffisamment ouverte pour ne pas rester prisonnier de la démonstration constructeur.

Le matériel annoncé

#

Les spécifications ne sont pas toutes définitives. Pollen indique encore travailler sur la définition et le champ de la caméra, la portée du capteur de profondeur, les versions des radios et les langages couverts par le SDK.

Le « LiDAR » mis en avant sur la page produit est une matrice de mesure par temps de vol de 8 x 8 points. Ce n’est pas un capteur rotatif capable de produire une carte détaillée d’une pièce. Ses 64 mesures devraient surtout être utiles à courte distance, par exemple pour repérer le sol, une main ou un obstacle devant le bec. Je vérifierai ce qu’il permet réellement au lieu de déduire ses capacités du mot LiDAR.

Le RK3566 est un SoC ARM raisonnable pour ce type de machine. Il dispose de quatre cœurs Cortex-A55 et d’un accélérateur IA, mais seulement de 1 Go de RAM. Microduck n’est clairement pas destiné à faire tourner un gros modèle de langage en local. Son calculateur sert d’abord au contrôle moteur, à la perception prévue par le projet et à l’inférence des politiques ONNX.

Ce qu’il doit savoir faire dès la sortie de boîte

#

Pollen annonce sept mouvements entraînés. La liste publique couvre la marche, la position assise et le retour debout, l’accroupissement, le coup de pied, la prise d’un objet avec le bec, la locomotion avec les roulettes optionnelles et le relevage après une chute.

La manette incluse doit permettre de les essayer sans installer un environnement de développement. Je préfère cette approche à un robot inutilisable tant que le SDK n’est pas installé. Avant de modifier quoi que ce soit, je veux pouvoir vérifier que les moteurs, les capteurs et l’équilibre fonctionnent normalement dans leur configuration d’origine.

Je reste prudent sur les termes « autonome » et « IA ». Microduck n’est pas présenté comme un assistant domestique capable de comprendre son environnement et de décider seul d’une tâche complexe. C’est d’abord une plateforme de locomotion et d’expérimentation.

Les conditions de vente la classent d’ailleurs parmi les plateformes de développement recommandées à partir de 16 ans, et non parmi les jouets pour enfants. Le dossier de presse précise encore que la recommandation d’âge définitive reste à finaliser.

La partie logicielle est la plus intéressante

#

La page produit m’a rendu curieux. Le dépôt principal, pollen-robotics/microduck, m’a convaincu de commander. Il ne contient pas seulement un SDK posé au-dessus d’un firmware fermé : il documente les services qui doivent tourner sur le robot et une bonne partie de leurs choix d’architecture.

robotd possède le bus moteur et exécute la boucle de contrôle à 50 Hz. D’autres services gèrent le réseau, le Bluetooth, la manette, la caméra, l’audio, le capteur ToF et les mises à jour. Ils échangent en JSON-RPC 2.0 sur des sockets Unix. Une panne du streaming vidéo ne devrait donc pas interrompre directement la boucle motrice.

La documentation prévoit aussi des mises à jour signées, contrôlées par un test de santé et réversibles. Ce mécanisme m’intéresse davantage qu’une animation supplémentaire dès lors que l’on commence à charger ses propres politiques.

Les premières commandes de diagnostic donnent une idée de ce qui sera observable :

robotctl version
robotctl health
robotctl monitor

robotctl monitor doit afficher la fréquence réelle de la boucle, les angles mesurés, l’orientation, la batterie, les températures et la politique chargée. Il peut aussi enregistrer la télémétrie en JSON :

robotctl monitor --json --hz 50 > run.jsonl

Pour mes tests, cette télémétrie sera plus utile qu’une interface graphique soignée. Sans chronologie commune entre les consignes, les articulations, les IMU et l’état de la politique, le débogage devient vite approximatif.

L’entraînement se trouve dans le dépôt pollen-robotics/microduck_rl. Il utilise mjlab, MuJoCo Warp et PPO. Les environnements simulent notamment la physique des actionneurs, le jeu des engrenages et des variations de paramètres destinées à éviter une politique trop adaptée à un robot virtuel parfait.

Les politiques documentées partagent un vecteur d’observation de 61 dimensions et sont exportées en ONNX. Le logiciel embarqué peut ainsi charger une politique de marche, de relevage ou un autre mouvement derrière une interface commune.

L’entraînement local demande actuellement un GPU CUDA. Il est également possible de passer par Hugging Face Jobs. Acheter le robot ne signifie donc pas que toute la chaîne d’expérimentation fonctionnera confortablement sur un simple ordinateur portable.

Enfin, le dépôt est encore très actif. Au 29 août 2026, la feuille de route indique que l’application, le SDK final, le canal de distribution des modèles et certaines fonctions autonomes restent en chantier. Je préfère le savoir avant la livraison : la documentation actuelle décrit un produit en développement, pas un logiciel figé.

Ce que je veux faire avec Hermes

#

Le premier scénario que je veux faire fonctionner tient en une phrase : « Hey Hermes, tourne la tête de Microduck vers la gauche ». Le microphone capte la demande, Hermes l’interprète, le pont vérifie que l’action est autorisée, robotd l’exécute puis le haut-parleur confirme le résultat. C’est une séquence courte, mais elle traverse toutes les couches qui m’intéressent.

La documentation de robotd prévoit explicitement l’arrivée de clients téléphone, navigateur et LLM par mediad, le relais WebRTC et JSON-RPC du robot. L’idée n’est donc pas de détourner une interface conçue uniquement pour la manette. En revanche, aucun connecteur Hermes prêt à l’emploi n’est annoncé à ce stade.

Hermes tourne déjà sur un serveur de mon homelab et Matrix est aujourd’hui mon canal principal pour lui transmettre des demandes. Avec Microduck, je veux y ajouter une interface vocale directe. Le modèle de langage resterait sur le serveur, ou chez un fournisseur distant selon le modèle choisi. Avec 1 Go de RAM, le robot n’a pas vocation à exécuter lui-même un LLM généraliste.

L’architecture que j’envisage est la suivante :

Texte    : Matrix -> Hermes Agent -> pont MCP -> robotd
Voix     : micro -> WebRTC -> STT -> Hermes -> pont MCP -> robotd
Réponse  : haut-parleur <- WebRTC <- TTS <- Hermes
Contexte : caméra et télémétrie -> WebRTC -> Hermes

La documentation d’architecture de Microduck prévoit une session WebRTC transportant la caméra, le microphone, le haut-parleur et les canaux de contrôle. L’audio doit être bidirectionnel pour la téléprésence. Le même flux pourrait donc envoyer la voix captée par le robot vers Hermes, puis ramener une réponse synthétisée vers son haut-parleur. Cette documentation décrit toutefois la cible de la première version livrée, pas une fonction déjà validée sur le matériel commercial.

Le mot « voix » utilisé par le projet prête à confusion. Pollen précise que Microduck ne parle pas avec des mots, mais communique par de petites vocalisations. Sa banque sonore est générée à partir du numéro de série du SoC afin de conserver une identité propre à chaque robot. La documentation mentionne notamment des sons de canard, un son d’accueil, un roucoulement, un mode thérémine et une chorale. On est donc plus proche des sons d’une créature que de la voix d’un assistant.

Si je veux entendre une réponse articulée d’Hermes, ce sera une couche distincte que j’ajouterai : Hermes produira la parole par TTS sur le serveur, puis l’enverra au haut-parleur via WebRTC. Ce n’est pas une capacité conversationnelle native de Microduck.

Hermes possède déjà les autres briques : reconnaissance vocale (STT), synthèse vocale (TTS), mode vocal et mot de réveil. Il reste à connecter la piste audio WebRTC de Microduck à cette chaîne. C’est précisément la pièce que je compte développer et documenter.

La qualité de cette interaction dépendra moins du LLM que de l’audio réel : bruit des moteurs, écho du haut-parleur dans les microphones, latence du STT et faux déclenchements du mot de réveil. Un ordre vocal d’arrêt devra suivre un chemin court et prioritaire, sans dépendre d’un raisonnement long du modèle. Il ne remplacera pas pour autant un arrêt manuel pendant les premiers essais.

Le microphone pose aussi une question de confidentialité. Je veux que l’écoute permanente se limite au mot de réveil traité localement dans le homelab et que tout streaming distant soit visible et désactivable. C’est également l’orientation retenue dans la documentation de Microduck, qui demande un consentement explicite et un indicateur actif pendant une session distante.

Un petit serveur MCP ferait l’interface entre les outils de Hermes et les commandes du robot. Il n’exposerait que des actions de haut niveau et volontairement limitées : lire l’état du robot, observer la caméra et les capteurs, orienter la tête, avancer pendant une durée définie, lancer un mouvement autorisé ou demander un arrêt.

Hermes pourrait alors recevoir dans Matrix une consigne comme : « regarde devant toi, avance lentement pendant une demi-seconde, arrête-toi puis vérifie ton état ». Le LLM choisirait la séquence d’actions, mais ne calculerait ni les consignes articulaires ni la boucle motrice à 50 Hz. robotd resterait l’unique propriétaire du bus moteur et appliquerait les limites locales.

Le pont devra ajouter ses propres garde-fous : vitesse et durée maximales, arrêt automatique, liste fermée de mouvements, contrôle de la batterie et des températures, ainsi qu’une journalisation de chaque action. Je ne compte pas non plus publier cette interface directement sur Internet. Un accès sur le réseau local, éventuellement derrière un VPN, suffit. Le Bluetooth n’est de toute façon pas une solution de repli pour le pilotage : duckctl refuse volontairement les commandes motrices sur BLE.

Le premier objectif restera modeste : observer, exécuter une action courte, s’arrêter puis observer de nouveau. Les scénarios plus ambitieux, comme demander au robot de rejoindre une personne, supposent de résoudre correctement la perception, la localisation et les obstacles. Le branchement à un LLM est réaliste ; l’autonomie fiable dans une pièce est un autre projet.

Open source, mais pas open hardware

#

Pollen publie le logiciel du robot, le simulateur et les outils d’entraînement sous licence Apache 2.0. Il est donc possible de lire, modifier et redistribuer cette partie de la plateforme dans les limites de la licence.

En revanche, les plans mécaniques et électroniques ne sont pas publiés. Microduck n’est pas un robot que l’on peut reconstruire intégralement à partir de fichiers ouverts.

Ce n’est pas rédhibitoire, mais cela change la question de la réparabilité. Le Dev Pack contient des moteurs, des câbles et de la visserie de rechange. Reste à voir si les coques, les cartes spécifiques et les autres pièces seront disponibles séparément dans la durée.

Prix et accessoires

#

Le prix affiché seul ne représentait pas le montant réellement débité. Sur ma facture, les 340 € du robot et les 33 € de chaque pack servent de bases hors taxes. La TVA française de 20 % s’applique également aux 30 € de livraison.

La boîte doit contenir le robot assemblé, une batterie, un câble USB-C et une manette. Quatre couleurs sont proposées : Cream, Graphite, Lavender et Sky. J’ai choisi Cream.

Trois packs optionnels sont proposés au lancement :

• le Charger Pack, avec deux batteries et un chargeur double ;
• l’Accessory Pack, avec les roulettes, un laser, une balle et des accessoires NFC ;
• le Dev Pack, avec notamment trois moteurs, des câbles, deux batteries, un chargeur et de la visserie.

J’ai pris les deux premiers. Le Charger Pack permettra d’alterner les batteries si l’autonomie réelle se rapproche de l’heure annoncée. J’ai choisi l’Accessory Pack Yellow pour tester les roulettes, le laser, la balle et les interactions NFC. Je n’ai pas commandé le Dev Pack.

La facture classe le robot et les deux packs sous le code douanier 902300 et indique la Chine comme pays d’origine. La commande est expédiée depuis l’entrepôt français : aucun droit d’importation ne m’a été facturé, uniquement la TVA française.

Le paiement est prélevé immédiatement, mais les conditions publiées au lancement permettent d’annuler la précommande avant l’expédition avec remboursement intégral.

Mes réserves avant la réception

#

Au lancement, il n’existe pas encore de retour indépendant sur un exemplaire commercial. Les vidéos montrent des prototypes convaincants, pas la régularité d’une série produite et expédiée à grande échelle.

L’autonomie annoncée d’environ une heure devra aussi être mesurée selon les usages. Marcher, se relever plusieurs fois et diffuser la caméra n’imposent pas la même charge à la batterie.

Les capteurs restent modestes. Une matrice ToF 8 x 8 apporte de la proximité, pas une perception 3D détaillée. Avec 1 Go de RAM, les traitements plus lourds devront probablement être déportés sur une autre machine ou un service distant.

La mécanique reste la plus grosse inconnue. Le relevage après une chute est intéressant, mais il faudra observer le bruit, la chauffe, le jeu des engrenages et l’usure après plusieurs heures. Une vidéo de lancement ne permet pas de répondre à ces questions.

Ce que je testerai

#

Je publierai un retour complet après réception. Je compte notamment vérifier :

• démarrage initial et qualité de l’expérience avec la manette ;
• marche sur parquet, carrelage et tapis court ;
• relevage depuis plusieurs positions de chute ;
• autonomie, temps de charge, alternance des batteries, bruit et température des moteurs ;
• qualité des microphones et du haut-parleur, ainsi que latence de la boucle STT/TTS avec Hermes ;
• comportement réel de la caméra, du ToF et du NFC ;
• services réseau ouverts, accès SSH et flux sortants ;
• utilisation de duckctl, récupération des logs et retour arrière d’une mise à jour ;
• lancement du jumeau MuJoCo, export d’une politique ONNX et déploiement sur le robot ;
• création d’un pont MCP entre Hermes Agent et les commandes de haut niveau de Microduck ;
• accès aux moteurs et aux pièces susceptibles de s’user.

Le test décisif ne sera pas de le faire marcher pendant cinq minutes. Je veux surtout vérifier qu’une personne extérieure à Pollen peut partir des dépôts publics, modifier une politique puis exposer des actions limitées à Hermes sans reconstituer une chaîne d’outils implicite.

Conclusion

#

Je ne sais pas encore si Microduck vaut les 523,20 € dépensés. C’est précisément pour le vérifier que je l’ai commandé : la mécanique est assemblée, la pile logicielle est lisible et les points d’entrée semblent suffisants pour tenter autre chose que les démonstrations fournies.

À la réception, je commencerai par la manette et les comportements d’origine. Ensuite viendront les logs, le trafic réseau, MuJoCo, les politiques ONNX et enfin le pont vers Hermes. Si je branche tout en même temps, le premier dysfonctionnement sera impossible à attribuer correctement.

Le moment intéressant ne sera pas le premier pas du robot. Ce sera la première fois que je pourrai lui parler, voir Hermes choisir une action limitée, observer robotd l’exécuter puis vérifier que le robot s’arrête comme prévu. Si cette chaîne échoue, j’aurai au moins la télémétrie et les dépôts pour comprendre où elle a cassé.

Maintenant, il ne reste plus qu’à attendre le colis. La suite sera écrite avec le robot sur le bureau et les logs ouverts.

Sources

#

• Page officielle de Microduck
• Fiche produit et précommande
• Dossier de presse et spécifications
• Présentation de Microduck et de son identité sonore
• Conditions de vente
• Politique d’expédition
• Acquisition de Pollen Robotics par Hugging Face
• Fiche officielle du Rockchip RK3566
• Code du logiciel embarqué Microduck
• Environnements d’entraînement Microduck RL
• Architecture logicielle du robot
• Conception de robotd et interface destinée aux clients LLM
• Commandes d’administration et de diagnostic
• Interface Bluetooth duckctl et restrictions des commandes motrices
• Feuille de route du logiciel
• Documentation des outils Hermes Agent
• Intégration MCP de Hermes Agent
• Mode vocal de Hermes Agent
• Mot de réveil de Hermes Agent