Luwu Dynamics ha pubblicato XGO Duck, un piccolo robot bipede in forma di anatra progettato come piattaforma DIY e derivato esplicitamente dal lavoro sviluppato da Pollen Robotics con Microduck. Il progetto combina una struttura in larga parte stampabile in 3D, quindici servomotori seriali, una scheda Arduino UNO Q e policy di movimento addestrate tramite reinforcement learning. La documentazione hardware e software è distribuita pubblicamente attraverso repository GitHub dedicati, insieme a file STL, distinta base, schema e layout della scheda di espansione, firmware, interfaccia web e ambiente di training. È quindi un progetto molto più aperto di una semplice replica estetica, ma va descritto con precisione: XGO Duck non è un clone identico di Microduck, non utilizza la stessa elettronica o gli stessi attuatori e adatta le policy di movimento a una meccanica e a una distribuzione delle masse proprie. Inoltre, il termine “open source” va riferito correttamente ai file, al software e all’hardware effettivamente pubblicati da Luwu Dynamics, senza trasformarlo automaticamente in una dichiarazione su ogni elemento dell’intero ecosistema originale Microduck.
Il punto di partenza è proprio Microduck, presentato da Pollen Robotics nell’agosto 2026. Il robot originale è alto circa 25 cm, pesa meno di 800 grammi e utilizza quindici motori, una videocamera, un piccolo sensore di profondità, due IMU e un becco articolato capace di contribuire alla presa di piccoli oggetti. Pollen Robotics lo propone come piattaforma open source per sperimentare il trasferimento sim-to-real delle policy di controllo: i comportamenti vengono addestrati in simulazione e successivamente eseguiti sul robot reale. XGO Duck riprende questa impostazione generale, mantenendo forma del corpo, disposizione dei quindici giunti e ordine articolare utilizzato dalle policy, ma sostituendo una parte importante dell’hardware.
Da Microduck a XGO Duck: stessa logica cinematica, elettronica diversa
Luwu Dynamics dichiara apertamente che forma dell’anatra, disposizione dei 15 servomotori e ordine dei giunti derivano da Microduck. Questa compatibilità è importante perché le reti neurali utilizzate per controllare il movimento producono comandi secondo una struttura precisa: se l’ordine delle articolazioni cambiasse, una policy addestrata sulla configurazione originale non potrebbe essere semplicemente trasferita sul nuovo robot.
XGO Duck utilizza invece quindici servo Feetech 1910, mentre Microduck usa una diversa famiglia di attuatori Dynamixel. Questo significa che il progetto non si limita a sostituire una scheda di controllo lasciando invariata la meccanica dinamica. Coppia, velocità, inerzia, risposta del servo, controllo interno e comportamento sotto carico possono essere differenti.
Per questo Luwu Dynamics ha sviluppato anche un proprio ambiente di reinforcement learning nel quale geometria, masse, momenti d’inerzia e modello degli attuatori corrispondono a XGO Duck invece di limitarsi a utilizzare il modello originale senza modifiche. È un dettaglio tecnico essenziale: nel controllo sim-to-real, una policy che funziona perfettamente in un simulatore con dinamica errata può comportarsi male o diventare instabile quando viene trasferita sull’hardware reale.
Arduino UNO Q come architettura “a due cervelli”
Il cuore del robot è Arduino UNO Q, una scheda significativamente diversa dagli Arduino tradizionali basati soltanto su microcontrollore. UNO Q combina un microprocessore Qualcomm Dragonwing QRB2210, sul quale viene eseguito un ambiente Linux Debian, con un microcontrollore STM32U585 basato su Arm Cortex-M33 e Zephyr.
La scelta consente a XGO Duck di suddividere il lavoro tra due domini.
Il processore Qualcomm gestisce le attività ad alto livello: esecuzione delle policy neurali tramite ONNX Runtime, logica applicativa e interfaccia web. Il microcontrollore STM32 gestisce invece il ciclo di comunicazione con servomotori e sensori con vincoli temporali più stretti.
Secondo il repository runtime di Luwu Dynamics, la policy neurale opera a 50 Hz, mentre il ciclo sul microcontrollore lavora a 100 Hz. Il sottosistema STM32 acquisisce lo stato del robot, gestisce il bus dei quindici servomotori e comunica con l’IMU QMI8658; il lato Linux utilizza l’ultimo stato disponibile per calcolare l’azione successiva.
| Livello | Hardware | Frequenza dichiarata | Compito principale |
|---|---|---|---|
| High level | Qualcomm QRB2210 / Linux | 50 Hz | policy ONNX, logica, web UI |
| Real-time | STM32U585 / Zephyr | 100 Hz | servo bus, IMU, stato robot |
| Attuazione | 15 Feetech 1910 | bus seriale | movimento articolazioni |
| Sensore inerziale | QMI8658A | gestito dall’MCU | accelerometro e giroscopio |
Questa separazione è più robusta rispetto a un’architettura nella quale una sola applicazione Linux gestisce direttamente anche tutti i timing dei motori. Un sistema operativo general purpose non garantisce infatti automaticamente latenze deterministiche; delegare il bus e la gestione delle periferiche a un MCU permette di mantenere un ciclo più prevedibile.
Perché 50 Hz possono bastare per una policy locomotoria
Una frequenza di 50 Hz significa che la rete neurale produce un nuovo comando ogni 20 millisecondi. Può sembrare bassa rispetto ai loop di controllo industriali eseguiti a centinaia o migliaia di hertz, ma è necessario distinguere fra livelli di controllo.
La policy non sta necessariamente regolando direttamente corrente e coppia dei motori. Produce target articolari o comandi di livello superiore che vengono poi eseguiti dai servomotori e dal controllo embedded.
Questa architettura gerarchica è comune nella robotica: il controllo motorio più veloce avviene localmente, mentre l’intelligenza che coordina l’intero corpo lavora a frequenze inferiori.
Anche il Microduck originale esegue il proprio loop neurale a 50 Hz. La scelta di XGO Duck di mantenere questa frequenza facilita quindi il riutilizzo concettuale delle policy e delle strategie di training.
La meccanica viene in larga parte dalla stampante 3D
Uno degli aspetti più accessibili del progetto è la quantità di componenti meccanici riproducibili mediante stampa 3D. Nel repository hardware sono disponibili file per corpo, testa, collo, gambe e altri elementi della struttura. Per alcune parti vengono fornite versioni distinte per lato destro e sinistro.
Il becco e le suole dei piedi devono essere realizzati in TPU, mentre numerosi elementi strutturali possono essere prodotti con materiali rigidi.
La distinzione fra questi materiali ha una funzione precisa. Una suola leggermente deformabile può aumentare la superficie reale di contatto con il pavimento e la capacità di adattarsi alle piccole irregolarità della superficie. Un elemento completamente rigido potrebbe invece ridurre il grip, soprattutto durante movimenti dinamici.
Il TPU nel becco consente inoltre una presa più conformabile rispetto a una superficie rigida.
Questo non significa che il TPU generi automaticamente una buona capacità di manipolazione: geometria, durezza Shore, infill, spessore delle pareti e forza applicata dal servo incidono significativamente sul comportamento.
Il materiale di stampa conta più di quanto suggerisca il file STL
La disponibilità di un file STL permette di replicare la forma, ma non definisce da sola le proprietà del componente prodotto. Un pezzo realizzato in PLA con orientamento verticale può comportarsi diversamente dallo stesso modello in PETG stampato con gli strati orientati rispetto ai principali carichi.
Nei robot articolati, soprattutto nelle regioni vicine ai servomotori, possono svilupparsi momenti flettenti e carichi ciclici. L’adesione tra layer diventa quindi un parametro strutturale.
Per componenti non particolarmente sollecitati il PLA può offrire rigidezza e semplicità di stampa. PETG può essere preferibile quando servono maggiore tenacità e una minore tendenza alla frattura fragile. Materiali rinforzati possono aumentare la rigidezza, ma richiedono ugelli resistenti all’abrasione e non eliminano automaticamente l’anisotropia della stampa FFF.
Il progetto XGO Duck non costituisce quindi una certificazione universale del materiale: chi realizza il robot deve mantenere coerenza fra materiale, orientamento, parametri e geometria prevista dalla documentazione.
Servomotori seriali e architettura distribuita
L’impiego di quindici servomotori seriali riduce la quantità di cablaggio rispetto a un sistema nel quale ogni motore riceve un segnale PWM separato. Gli attuatori possono essere organizzati su un bus comune, ciascuno con un proprio identificativo.
Nel runtime XGO Duck vengono utilizzati ID organizzati per gruppi: 10-14, 20-24 e 30-34. Questo schema segue l’organizzazione articolare di Microduck.
La configurazione consente al controller di inviare comandi e acquisire lo stato di numerosi giunti attraverso una sola interfaccia seriale.
Il vantaggio non è soltanto il cablaggio. Disporre di feedback su posizione e stato degli attuatori permette alla policy di lavorare con una rappresentazione del robot reale, anziché assumere che il motore abbia raggiunto esattamente il target comandato.
15 servomotori non significano necessariamente 15 gradi di libertà controllati dalla policy
La presenza di quindici motori può essere facilmente trasformata nella frase “robot con 15 DOF”, ma le due cose non sono necessariamente equivalenti nel significato del controllo.
Nel progetto originale Microduck il quindicesimo servo aziona il becco e non viene necessariamente incluso nello stesso vettore di azioni locomotorie delle altre articolazioni. La locomozione bipede utilizza soprattutto gambe, caviglie, collo e testa.
XGO Duck conserva la stessa organizzazione generale dei quindici servo e delle policy adattate.
È quindi preferibile parlare di 15 attuatori/servomotori, evitando di dedurre automaticamente un modello cinematico specifico senza considerare come ciascun giunto viene effettivamente comandato.
Una scheda di espansione dedicata collega robot e UNO Q
Luwu Dynamics non utilizza soltanto UNO Q in configurazione standard. Il progetto comprende una scheda di espansione dedicata che gestisce alimentazione, bus dei servo e sensori.
La board integra un QMI8658A, sensore inerziale MEMS a sei assi che combina accelerometro e giroscopio. Contiene inoltre regolatori per le tensioni necessarie, buffer seriali, connessioni dedicate ai servo, interruttore di alimentazione, connettore per alimentatore e connessione della batteria.
I file della scheda vengono pubblicati nel repository hardware insieme a schema elettrico, PCB layout, BOM e dati necessari alla produzione.
Questo è un elemento importante quando si parla di open hardware. Non è stato distribuito soltanto uno schema semplificato: gli sviluppatori hanno pubblicato documentazione utile alla replica della board.
La stampante 3D non produce tutto il robot
La definizione “robot stampato in 3D” può essere fuorviante. L’additive manufacturing produce gran parte della struttura, ma numerosi componenti funzionali restano convenzionali.
| Componente | Processo/origine |
|---|---|
| Corpo e carter | stampa 3D |
| Gambe e supporti | stampa 3D |
| Becco | stampa 3D in TPU |
| Suole | stampa 3D in TPU |
| Servomotori | componenti commerciali |
| Scheda UNO Q | elettronica commerciale |
| Expansion board | PCB convenzionale |
| IMU | componente elettronico |
| Cuscinetti | commerciali |
| Viteria M2 | commerciale |
| Batteria | commerciale |
Il valore della stampa 3D è soprattutto nella possibilità di realizzare economicamente una geometria complessa e modificarla senza tooling.
Per un robot sperimentale questo è particolarmente vantaggioso perché il telaio può essere aggiornato durante lo sviluppo senza dover produrre nuovi stampi.
Dal modello CAD al robot funzionante resta comunque molto assemblaggio
L’utente non deve aspettarsi di scaricare gli STL, avviare una stampa e ottenere automaticamente un robot funzionante.
L’assemblaggio comprende decine di viti M2, cuscinetti, cablaggi, posizionamento dei motori, configurazione degli ID, elettronica e calibrazione.
Luwu Dynamics distribuisce una guida illustrata proprio perché errori di orientamento dei servo o di montaggio possono alterare la cinematica.
In un robot controllato con reinforcement learning questo problema è ancora più critico. Una policy è stata addestrata assumendo che a un certo angolo comandato corrisponda una precisa posizione meccanica. Se un servo viene installato con un offset errato, la postura reale può divergere sensibilmente da quella prevista dal simulatore.
Il reinforcement learning è il vero elemento tecnico del progetto
La caratteristica più interessante di XGO Duck non è probabilmente la struttura stampata, ma il modo in cui vengono prodotti i comportamenti.
Il repository di training utilizza PPO, Proximal Policy Optimization, all’interno di un ambiente basato su mjlab e MuJoCo. MuJoCo è un motore fisico ampiamente utilizzato nella robotica per simulare sistemi articolati, contatti e dinamica.
Durante il training, la policy riceve osservazioni relative allo stato del robot e produce comandi articolari. Attraverso milioni di iterazioni in simulazione impara a massimizzare una funzione di reward.
Per una locomozione questa funzione può includere, per esempio, mantenimento dell’equilibrio, raggiungimento di una velocità desiderata, riduzione dei movimenti inutili e penalizzazione delle cadute.
Al termine, la rete viene esportata nel formato ONNX e può essere eseguita sull’UNO Q mediante ONNX Runtime.
Training e inferenza sono due operazioni molto diverse
Una distinzione importante riguarda la potenza di calcolo richiesta.
XGO Duck può eseguire una rete neurale sul proprio processore embedded, ma questo non significa necessariamente che l’intero training venga eseguito sul robot.
Il repository ufficiale di Luwu Dynamics specifica che l’ambiente di training richiede una GPU CUDA. Il robot utilizza invece la rete già addestrata per inferenza a 50 Hz.
Il training può richiedere l’esecuzione parallela di numerosi ambienti simulati per accumulare rapidamente esperienza. L’inferenza consiste invece nel valutare una rete relativamente compatta poche decine di volte al secondo.
Affermare che UNO Q “addestra autonomamente il robot” sarebbe quindi scorretto rispetto al workflow documentato.
Sim-to-real: perché il robot virtuale deve assomigliare a quello vero
Il principale problema del reinforcement learning applicato alla robotica è il reality gap. Una policy può imparare ad approfittare di caratteristiche irrealistiche del simulatore e fallire quando viene trasferita sull’hardware reale.
Nel caso XGO Duck, Luwu Dynamics specifica che il proprio modello differisce da Microduck in geometria, masse e inerzie. Il progetto utilizza inoltre un modello degli attuatori FeeTech HLS1910 invece di quello relativo ai servo originali.
Sono modifiche cruciali.
Se il simulatore assumesse che un motore raggiunga istantaneamente il target, mentre quello reale ha ritardi, saturazione o una curva di coppia differente, la rete potrebbe generare movimenti impossibili da riprodurre.
Per ridurre il gap possono essere utilizzate tecniche come domain randomization, variazione di attrito, massa e parametri dei motori durante il training. Il repository XGO Duck deriva in parte dall’ambiente Microduck, ma ciò non significa che ogni strategia o risultato ottenuto sul robot Pollen possa essere automaticamente trasferito senza ulteriore verifica.
Camminare, rialzarsi e raccogliere oggetti sono policy differenti
Il runtime pubblicato include policy per più comportamenti: locomozione, recupero dopo una caduta e presa di piccoli oggetti.
È utile sottolineare che il robot non dispone necessariamente di un’unica rete “intelligente” capace di comprendere autonomamente qualsiasi situazione. Le capacità vengono implementate attraverso policy e logiche specifiche.
Una policy di camminata risolve un problema differente da quella utilizzata per rialzarsi. Il sistema superiore seleziona il comportamento adeguato e passa alla rete gli input necessari.
Questo è molto diverso dall’immagine di un robot generalista capace di inventare autonomamente nuove azioni.
La web interface riduce la barriera di ingresso
XGO Duck mette a disposizione anche una web UI eseguita sul lato Linux dell’UNO Q. La possibilità di accedere al sistema tramite browser consente di controllare funzioni, configurazione e calibrazione senza costruire necessariamente un’applicazione desktop dedicata.
È una scelta coerente con il posizionamento educativo e maker del progetto.
L’interfaccia web non sostituisce però gli strumenti di sviluppo necessari per creare nuove policy. Chi vuole modificare il comportamento a livello di reinforcement learning deve comunque lavorare con Python, ambiente simulativo, GPU e pipeline di esportazione ONNX.
La piattaforma presenta quindi più livelli di accessibilità: uso e configurazione per l’utente, modifica software per lo sviluppatore e training per chi vuole intervenire sulla robotica basata su machine learning.
XGO Duck non è un semplice fork software di Microduck
Il termine “replica” può far immaginare un clone diretto, ma tecnicamente il progetto è meglio descritto come un adattamento downstream.
XGO Duck mantiene elementi chiave dell’architettura concettuale Microduck – morfologia, disposizione dei giunti, policy neurali a 50 Hz e workflow sim-to-real – ma modifica elettronica, servomotori, scheda di espansione, modello fisico e runtime.
| Elemento | Microduck | XGO Duck |
|---|---|---|
| Sviluppatore | Pollen Robotics | Luwu Dynamics |
| Altezza/peso | circa 25 cm / <800 g | modello RL scalato a circa 0,8 kg |
| Motori | 15 servo Dynamixel | 15 Feetech 1910 |
| Computer | piattaforma RK3566 | Arduino UNO Q |
| MCU dedicato | architettura propria | STM32U585 |
| High-level CPU | Rockchip RK3566 | Qualcomm QRB2210 |
| Policy | reinforcement learning | derivate/adattate da Microduck |
| Frequenza policy | 50 Hz | 50 Hz |
| Struttura DIY | non coincidente con XGO | STL pubblicati da Luwu |
| PCB dedicato | architettura Microduck | expansion board Luwu |
Le specifiche devono comunque essere interpretate come confronto architetturale, non come benchmark prestazionale.
Attenzione anche alla definizione “open source” di Microduck
Pollen Robotics stessa presenta Microduck come robot open source e ha reso pubblico il software necessario all’esecuzione e all’addestramento delle policy. Esiste tuttavia una differenza fra software open source e disponibilità di un pacchetto completo di produzione hardware comprendente ogni CAD, PCB e specifica meccanica.
Progetti indipendenti che documentano Microduck hanno infatti sottolineato che la pubblicazione del software non implica automaticamente che ogni elemento del design produttivo sia disponibile nello stesso modo.
XGO Duck affronta proprio questo spazio con una struttura progettata per essere riproducibile: pubblica direttamente STL, distinta base e documentazione della propria scheda.
È quindi più preciso parlare di una reinterpretazione DIY basata sul progetto e sul software Microduck, non semplicemente di “Microduck open source stampato in casa”.
Il progetto è già anche un kit, non soltanto un repository sperimentale
Luwu Dynamics non si limita a distribuire i file. Sul proprio sito ha aperto il preordine di un kit elettronico XGO Duck a 2.328 yuan, con consegne previste fra metà e fine ottobre 2026.
Il prodotto non è una macchina completamente assemblata: l’acquirente deve completare l’assemblaggio e stampare autonomamente la struttura esterna. Il contenuto del kit segue la distinta base pubblicata nel repository.
Questo cambia lo status del progetto. XGO Duck è contemporaneamente un progetto open source e un prodotto commerciale in forma di kit.
Le due cose non sono incompatibili: la disponibilità pubblica dei file consente a un maker di procurarsi direttamente i componenti, mentre il kit riduce il lavoro di sourcing.
Il prezzo del kit non equivale al costo totale del robot
I 2.328 yuan non devono essere interpretati come costo definitivo per realizzare XGO Duck. Servono anche parti stampate, materiale, tempo macchina e potenzialmente strumenti, minuteria o componenti non inclusi.
Chi dispone già di una stampante FFF sostiene soprattutto il costo del filamento e del tempo di produzione. Chi non dispone dell’attrezzatura deve acquistare o commissionare le parti.
Va inoltre considerato il costo dell’ambiente necessario per sviluppare nuove policy se si vuole andare oltre i comportamenti forniti. Una GPU CUDA non è necessaria semplicemente per far camminare il robot con policy già esportate, ma entra nel workflow quando si vuole addestrarne di nuove.
Una piattaforma educativa più che un giocattolo finito
La comunicazione di Luwu Dynamics insiste sull’apprendimento e sulla sperimentazione. È una definizione coerente con la natura del prodotto.
XGO Duck permette di osservare direttamente diversi livelli della robotica moderna: progettazione meccanica, additive manufacturing, elettronica embedded, bus seriali, sensori inerziali, Linux embedded, controllo real-time, simulazione fisica, reinforcement learning e deployment di reti neurali.
Un giocattolo commerciale tende invece a nascondere questi livelli dietro un’interfaccia semplice.
Nel caso di XGO Duck, dover assemblare il robot e comprendere la calibrazione fa parte dell’esperienza.
Questo comporta anche che l’affidabilità non debba essere confrontata automaticamente con quella di un prodotto consumer completamente chiuso e certificato per un utilizzo plug-and-play.
Il becco come manipolatore mostra i vantaggi e i limiti della morfologia
Uno degli elementi più caratteristici è il becco articolato, che può essere utilizzato per raccogliere piccoli oggetti.
La soluzione evita un manipolatore separato e sfrutta direttamente la morfologia del robot. È un esempio interessante di embodied design, nel quale la forma fisica stessa contribuisce alla funzione.
Le capacità di presa rimangono però molto lontane da quelle di un gripper robotico industriale. Forza, precisione e geometria degli oggetti afferrabili sono limitate.
L’obiettivo è soprattutto dimostrare coordinazione dell’intero corpo: il robot deve abbassarsi, mantenere l’equilibrio, posizionare la testa e chiudere il becco.
Da un punto di vista del controllo è quindi un compito più interessante della sola apertura e chiusura del servo.
La stampa 3D permette di modificare anche la “morfologia” del robot
Una conseguenza particolarmente interessante dell’architettura aperta è che un utilizzatore potrebbe modificare gambe, piedi o distribuzione delle masse.
Ma qui compare un problema tipico della robotica basata su policy apprese: modificare la geometria significa cambiare il sistema fisico sul quale la rete è stata addestrata.
Allungare una gamba, per esempio, cambia cinematica, inerzia e posizione del centro di massa. Una policy precedentemente stabile potrebbe non esserlo più.
Per questo la possibilità di modificare liberamente gli STL deve essere collegata alla possibilità di aggiornare il modello simulativo e riaddestrare le policy.
La stampante 3D rende facile cambiare l’hardware; il reinforcement learning permette teoricamente di adattare il software alla nuova morfologia. È proprio la combinazione fra queste due tecnologie a rendere XGO Duck un progetto interessante.
Un robot open source diventa realmente utile quando hardware e simulazione rimangono allineati
La disponibilità di file STL è soltanto il primo livello dell’apertura. Per un robot dinamico è altrettanto importante disporre del modello utilizzato in simulazione, dei parametri dei motori e degli strumenti di training.
Luwu Dynamics pubblica un repository separato proprio per questo motivo. Il modello XGO Duck utilizzato nel training contiene geometrie, masse e inerzie specifiche e non si limita al Microduck originale.
Questo permette, almeno in linea di principio, di mantenere una catena completa:
modello fisico → simulazione → training → esportazione ONNX → esecuzione sul robot.
È una pipeline notevolmente più interessante dal punto di vista educativo rispetto a un robot nel quale l’utente possa modificare la carrozzeria ma non comprendere come vengano generati i movimenti.
Non basta scaricare una nuova policy e provarla direttamente sull’hardware
La stessa Luwu Dynamics avverte che policy personalizzate devono essere verificate per compatibilità, calibrate e testate progressivamente prima del deployment.
È una precauzione fondamentale.
Un errore software su un robot fisico può generare movimenti improvvisi, portare i servo contro i limiti meccanici o causare una caduta. Nei test di reinforcement learning è normale che le prime policy abbiano comportamenti instabili: in simulazione non rappresenta un problema grave; sul robot reale può danneggiare hardware.
Un workflow corretto prevede quindi validazione nel simulatore, controllo delle escursioni articolari, test con limiti conservativi e progressivo aumento della libertà di movimento.
XGO Duck dimostra bene cosa può fare oggi la manifattura distribuita
Il progetto rappresenta anche un esempio concreto di produzione distribuita. Luwu Dynamics non deve necessariamente produrre, imballare e spedire ogni componente meccanico. Pubblica il file e lascia che parte della produzione avvenga vicino all’utilizzatore.
Questo modello è particolarmente efficace quando il componente è relativamente leggero, voluminoso rispetto al proprio valore e facilmente realizzabile con una stampante FFF.
La logistica viene quindi trasformata: si trasferiscono dati invece di alcune parti fisiche.
Non tutti i componenti possono essere digitalizzati in questo modo. Servo, elettronica, cuscinetti e batterie continuano a richiedere una supply chain tradizionale.
XGO Duck è quindi un esempio di produzione ibrida distribuita, non di robot integralmente fabbricabile con una stampante 3D.
Una reinterpretazione interessante di Microduck, non un sostituto equivalente
La disponibilità del progetto potrebbe far nascere spontaneamente un confronto economico con Microduck, proposto da Pollen Robotics in preordine a 399 dollari prima di tasse e spedizione. Ma i due sistemi non devono essere considerati equivalenti solo perché condividono forma e filosofia di controllo.
Microduck è un prodotto sviluppato direttamente da Pollen Robotics con una piattaforma hardware specifica, videocamera, sensore di profondità, due IMU e un ecosistema software integrato. XGO Duck è un adattamento DIY con un’architettura diversa e orientata alla sperimentazione.
Il valore di XGO Duck non è quindi necessariamente quello di essere un “Microduck più economico”. È soprattutto quello di rendere più esplicita e riproducibile la relazione fra struttura, elettronica, simulazione e policy.
Quando la stampa 3D incontra il reinforcement learning
La parte più interessante del progetto emerge proprio dall’unione di due tecnologie spesso trattate separatamente. La stampa 3D permette di modificare rapidamente il corpo del robot; il reinforcement learning permette di sviluppare comportamenti adattati a quel corpo.
In un robot tradizionale, cambiare la lunghezza di una gamba potrebbe richiedere una notevole revisione manuale del controller. In un approccio basato su simulazione e policy apprese, la nuova configurazione può essere modellata virtualmente e utilizzata per una nuova sessione di training.
Questo non rende il processo automatico: resta necessario costruire un modello fisico sufficientemente accurato e verificare il trasferimento alla realtà. Ma riduce il legame fra una particolare meccanica e un controller progettato manualmente una volta per tutte.
XGO Duck è quindi interessante meno come “anatra robotica stampata in 3D” e più come piattaforma nella quale la morfologia fisica è modificabile e il comportamento può essere nuovamente appreso.
È una direzione significativa per la robotica maker ed educativa: non limitarsi a stampare parti di un robot, ma mettere a disposizione l’intera catena necessaria per capire perché quel robot riesce a camminare, rialzarsi e interagire con il mondo reale.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI).
