Un proof of concept (PoC) con un robot umanoide non è una demo. Una demo mostra che il robot si muove, un PoC risponde a una domanda di business misurabile, per esempio: "un G1 può prelevare questi componenti da questo scaffale con un tasso di successo accettabile, in sicurezza, in queste condizioni?". Questa guida descrive come impostiamo un PoC umanoide in azienda: discovery, KPI, sicurezza, fase di laboratorio, pilota e report go/no-go.
Perché molti PoC robotici non portano a una decisione
I PoC che finiscono in un cassetto hanno quasi sempre gli stessi problemi:
- Obiettivo vago ("vediamo cosa sa fare") invece di una domanda precisa.
- KPI definiti a posteriori, che si adattano ai risultati invece di misurarli.
- Sicurezza affrontata tardi, quando il robot è già in reparto.
- Salto diretto al reparto senza una fase di laboratorio controllata.
- Nessun criterio di uscita: il progetto non finisce mai, o finisce senza una raccomandazione chiara.
Le fasi che seguono servono a evitare ognuno di questi errori.
Fase 1: discovery
La discovery trasforma un'idea in una domanda verificabile. Si lavora con chi conosce il processo (produzione, logistica, HSE, IT) e si producono pochi documenti chiari:
- Descrizione del compito: sequenza di azioni, oggetti coinvolti con peso e dimensioni, postazioni, variabilità.
- Vincoli dell'ambiente: pavimenti, spazi di passaggio, illuminazione, rete Wi-Fi, presenza di persone.
- Fattibilità rispetto alle specifiche: per esempio, il carico al braccio dichiarato da Unitree è di circa 2–3 kg per il G1 e di circa 7 kg nominali per l'H2. Se il compito richiede di più, lo si scopre qui e non dopo l'acquisto. Vedi il confronto G1, H2 e R1.
- Scelta della piattaforma e della configurazione: per un PoC che richiede sviluppo serve una versione EDU, perché solo le EDU prevedono lo sviluppo di terze parti.
- Domanda del PoC e KPI, scritti e condivisi prima di iniziare.
Un esito possibile e legittimo della discovery è "un umanoide non è la tecnologia giusta". In quel caso è meglio saperlo subito: vedi umanoidi vs robotica tradizionale.
Definire i KPI
I KPI devono essere misurabili, legati alla domanda del PoC e fissati prima dei test. Quelli che usiamo più spesso:
| KPI | Cosa misura | Come si rileva |
|---|---|---|
| Tasso di successo del compito | Percentuale di tentativi completati correttamente | Protocollo di prova con N ripetizioni e criteri di successo scritti |
| Tempo ciclo | Durata media del compito e variabilità | Log con timestamp dal software del robot |
| Interventi umani | Quante volte un operatore deve intervenire, ogni ora o ogni ciclo | Registro degli interventi con causa |
| Disponibilità | Tempo operativo rispetto al tempo pianificato | Log di stato, fermi e ricariche |
| Autonomia effettiva | Durata reale della batteria sul compito | Telemetria della batteria |
| Eventi di sicurezza | Arresti, cadute, quasi incidenti | Registro HSE e log |
Per ogni KPI si fissa una soglia di successo concordata con il committente. Senza soglie, il report finale non può dire go o no-go.
Sicurezza fin dal primo giorno
Un umanoide è una macchina mobile, dinamicamente stabile e con una massa significativa: circa 35 kg il G1, circa 70 kg l'H2. La sicurezza va progettata insieme al PoC, non aggiunta alla fine. Gli elementi di base:
- Valutazione dei rischi dell'applicazione specifica, con il metodo della ISO 12100 e coinvolgendo l'RSPP aziendale.
- Area di prova segregata, con accessi controllati e distanze adeguate.
- Sistema di sostegno (imbracatura o gantry) nelle fasi di sviluppo e nei primi test di locomozione.
- Procedure di arresto documentate e provate prima di eseguire codice personalizzato.
- Formazione di chi opera vicino al robot.
Per il quadro normativo: la revisione 2025 della ISO 10218 tratta robot e applicazioni industriali, inclusa la parte collaborativa che prima era nella ISO/TS 15066. Per i robot dinamicamente stabili, come gli umanoidi, è in sviluppo la ISO 25785-1. In Europa il Regolamento Macchine (UE) 2023/1230 si applica dal 20 gennaio 2027. Un PoC in area segregata è un contesto molto diverso da un impiego in produzione, e il report deve dirlo chiaramente.
Fase 2: laboratorio
In laboratorio si riduce il compito alla sua forma più semplice e si costruisce lo stack software. Attività tipiche:
- Messa in servizio: firmware, rete, accesso all'SDK ufficiale (unitree_sdk2) e, se serve, ROS 2 (unitree_ros2). Dettagli nella guida alla programmazione G1.
- Simulazione: riprodurre il compito in simulazione per iterare senza rischi. Unitree pubblica ambienti ufficiali come unitree_mujoco e unitree_sim_isaaclab.
- Raccolta di dati di dimostrazione, se il compito si presta all'imitation learning: teleoperazione con xr_teleoperate e addestramento con unitree_lerobot.
- Prove ripetute con il protocollo dei KPI, su un banco che riproduce le condizioni del reparto.
La fase di laboratorio si chiude con un primo set di misure. Se i KPI sono molto lontani dalle soglie, è il momento di fermarsi o di ridefinire il perimetro, prima di spendere tempo in reparto.
Fase 3: pilota in sede
Il pilota porta il robot nell'ambiente reale, sempre in area delimitata e con un perimetro ristretto. In questa fase:
- si verifica l'impatto delle condizioni reali: luce, rete, pavimento, variabilità degli oggetti;
- si misurano i KPI con lo stesso protocollo del laboratorio, per avere dati confrontabili;
- si raccolgono i feedback di operatori e responsabili;
- si annotano i costi operativi emersi: tempo di setup, ricariche, supervisione.
Nella nostra impostazione l'intero percorso, dalla discovery al report, dura indicativamente 8–14 settimane. La durata reale dipende dalla complessità del compito e dalla disponibilità di spazi e persone.
Fase 4: report go/no-go
Il report finale è il vero prodotto del PoC. Deve permettere a chi decide di scegliere senza aver seguito ogni test. Una struttura che funziona:
- Domanda del PoC e perimetro concordato.
- Risultati dei KPI rispetto alle soglie, con i dati grezzi in allegato.
- Cosa ha funzionato e cosa no, con le cause.
- Rischi residui e misure di sicurezza necessarie per un eventuale passo successivo.
- Raccomandazione: go (con roadmap), go condizionato (con prerequisiti) oppure no-go (con alternative, ad esempio un cobot o un AMR).
Un no-go ben documentato è un risultato di valore: evita un investimento sbagliato e chiarisce cosa dovrebbe cambiare, nella tecnologia o nel processo, per riprovarci.
Domande frequenti
Quale robot usare per un PoC umanoide?
Per la maggior parte dei PoC esplorativi il G1 EDU è il punto di partenza più pratico: è trasportabile e ha l'ecosistema software ufficiale più ampio. L'H2 ha senso quando servono statura umana o carichi più alti. Vedi la guida operativa G1 e H2 in Italia.
Serve un team software interno?
Aiuta, ma non è indispensabile. Servono però almeno un referente di processo e un referente sicurezza. La parte SDK, ROS 2 e simulazione si può affidare a un partner tecnico.
Il PoC si può finanziare?
Dipende dal progetto e dagli strumenti attivi in quel momento. Vale la pena verificarlo prima di firmare: vedi come finanziare un robot in Italia.
Dopo un go, cosa succede?
Si pianifica la fase successiva sulla base della roadmap del report: ampliamento del perimetro, valutazione di conformità per l'uso previsto, formazione e un piano di supporto.
Avvia una discovery
CALIGO supporta aziende e laboratori in tutte le fasi di un PoC su piattaforme Unitree: discovery, sviluppo su SDK e ROS 2, laboratorio, pilota e report. Trovi i dettagli del servizio in assistenza e sviluppo Unitree. Se hai un compito in mente, raccontacelo: partiamo dalla domanda giusta.
Panoramica commerciale e catalogo: Abra Robotics.