Test-Driven Agentic Framework for Reliable Robot Controller

Titolo: Framework Agente Guidato dai Test per Controller Robotici Affidabili

Autori: Shivanshu Tripathi, Reza Akbarian Bafghi, Maziar Raissi

---

1. Il Problema

La pianificazione del movimento è fondamentale nella robotica, ma esiste un divario significativo tra l'esistenza teorica di un piano e la sua esecuzione affidabile nella realtà.

• Limiti dell'esecuzione: I controller devono gestire vincoli reali come la risoluzione discretizzata dei sensori, i campi visivi limitati, la saturazione degli attuatori e i limiti di velocità.
• Fragilità dei metodi tradizionali: Colmare questo gap richiede tradizionalmente un'ingegneria manuale intensiva, tuning dei parametri e debug estensivo, che sono processi lenti e difficili da scalare.
• Limiti della generazione "One-Shot" con LLM: Sebbene i Large Language Models (LLM) possano sintetizzare controller da descrizioni ad alto livello, la generazione di codice in un singolo passaggio ("one-shot") è spesso inaffidabile. Gli LLM tendono a commettere errori di sintassi, violazioni di sicurezza o fallimenti nel completamento del compito, specialmente quando i prompt sono sottodeterminati (mancano dettagli su dinamiche, conversioni di unità o contratti API). Senza un feedback di verifica, gli LLM fanno affidamento su assunzioni "allucinate" che non reggono nell'ambiente hardware specifico.

2. Metodologia

Gli autori propongono un framework agente a ciclo chiuso che combina sintesi basata su LLM con verifica automatizzata e riparazione iterativa. L'obiettivo è trasformare istruzioni ad alto livello in un controller eseguibile (controller.py) che soddisfi tutti i requisiti di sicurezza e prestazioni prima del deployment.

Il flusso di lavoro segue un paradigma "Genera e Migliora" in due fasi principali:

A. Architettura del Workflow

Il sistema utilizza due LLM distinti in un ciclo iterativo:

1. Learner (LLM1): Genera il codice del controller basandosi su un prompt e sul contesto ambientale.
2. Optimizer (LLM2): Analizza i feedback di fallimento e decide come riparare il sistema.

B. Strategia di Riparazione a Due Livelli (Dual-Tier)

Se il controller generato fallisce i test, l'Optimizer attiva una strategia di riparazione che alterna due approcci:

1. Riparazione a livello di codice (Code-level repair): Modifica diretta del file controller.py per risolvere errori specifici riportati dai test. Questo viene tentato per un numero limitato di volte (patienza di modifica).
2. Riparazione a livello di prompt (Prompt-level repair): Se le modifiche al codice non risolvono il problema entro il limite di tentativi, l'Optimizer aggiorna il template del prompt (prompt.py), aggiungendo regole di riparazione o dettagli contestuali mancanti, per generare un nuovo candidato di codice.

C. Ambienti di Sperimentazione

Il framework è stato validato in due scenari distinti, mantenendo la stessa logica di sintesi:

1. Ambiente 2D basato su mappe:
   • Preprocessing: Un'immagine della mappa grezza viene convertita in una griglia di occupazione (occupancy grid) binaria. Un algoritmo di ottimizzazione (ricerca a griglia) determina la polarità corretta (pixel scuri vs chiari come ostacoli), la pulizia morfologica e il raggio di inflazione degli ostacoli.
   • Input: Mappa pre-processata, parametri di configurazione (params.json) e immagine del robot.
   • Output: Controller per un robot differenziale che naviga sulla griglia.
2. Ambiente 3D basato su simulatore (Webots):
   • Non richiede preprocessing della mappa. Il controller opera direttamente sulla configurazione del mondo del simulatore.
   • Input: File del mondo Webots (.wbt) che definisce la geometria, il robot (es. e-puck) e gli ostacoli, più il prompt umano.
   • Output: Controller Python eseguibile in Webots.

D. Validazione e Metriche

• Test Suite: Ogni controller candidato viene valutato tramite una suite di test strutturata in PyTest. I test verificano la correttezza funzionale, la sicurezza (assenza di collisioni) e il raggiungimento dell'obiettivo.
• Feedback: I report di fallimento dei test (errori di sintassi, eccezioni runtime, violazioni di sicurezza) vengono forniti come feedback strutturato all'Optimizer.
• Metriche di Performance:
  • Success Rate (SR): La frazione di candidati che passano tutti i test.
  • Cumulative Success (CS): La frazione di esecuzioni che hanno avuto successo entro l'iterazione $k$ (funzione di distribuzione cumulativa empirica).

3. Contributi Chiave

1. Framework Agente Iterativo: Introduzione di un flusso di lavoro che supera i limiti della generazione "one-shot" attraverso un ciclo di raffinamento guidato dai test, garantendo correttezza sintattica e conformità ai requisiti.
2. Metodologia Unificata: Sviluppo di pipeline coerenti per due contesti rappresentativi: navigazione 2D (da immagini grezze a griglie di occupazione) e navigazione 3D (interfaccia diretta con simulatori fisici).
3. Strategia di Riparazione Ibrida: Proposta di un meccanismo che alterna la modifica diretta del codice e l'aggiornamento del prompt, massimizzando l'efficienza della correzione degli errori.
4. Validazione Empirica: Dimostrazione che l'approccio test-driven produce controller autonomi e deployabili senza bisogno di intervento umano o di un LLM in tempo reale durante l'esecuzione.

4. Risultati Sperimentali

Gli esperimenti sono stati condotti su diversi modelli LLM (GPT-4o, GPT-4.1, GPT-5.2, Claude-Sonnet-4.5, Claude-Opus-4.5) con 5 esecuzioni indipendenti per modello e un massimo di 20 iterazioni.

• Navigazione 2D:
  • I modelli migliori (GPT-5.2 e Sonnet-4.5) hanno raggiunto un tasso di successo (SR) del 45%.
  • Il framework iterativo ha permesso a tutti i modelli di convergere verso un controller affidabile. Ad esempio, GPT-5.2 e Sonnet-4.5 hanno raggiunto il successo cumulativo (CS=1) entro la 5ª iterazione, mentre GPT-4o ha richiesto 15 iterazioni.
  • La generazione "one-shot" ha fallito completamente per i modelli più deboli (GPT-4o, GPT-4.1) in tutte le esecuzioni.
• Navigazione 3D (Webots):
  • Le prestazioni sono state generalmente migliori rispetto al caso 2D, probabilmente a causa di un minor numero di parametri sconosciuti e di una definizione più precisa dell'ambiente.
  • Claude-Opus-5.2 ha ottenuto il miglior SR del 71%.
  • Anche in questo caso, l'approccio iterativo ha permesso a tutti i modelli di convergere: Opus-4.5 ha raggiunto il successo in 2 iterazioni, mentre GPT-4o ne ha richieste 7.

5. Significato e Implicazioni

Questo lavoro rappresenta un passo significativo verso l'automazione nella robotica:

• Spostamento del Paradigma: Trasforma l'ingegneria robotica da un processo manuale di implementazione e debug a un flusso di lavoro automatizzato guidato dai test.
• Affidabilità e Sicurezza: Garantisce che i controller siano verificati contro una suite di test completa prima del deployment, riducendo il rischio di fallimenti critici in ambienti reali.
• Indipendenza dal LLM in Runtime: Una volta sintetizzato e verificato, il controller è un file Python autonomo che non richiede più la presenza di un LLM per funzionare, eliminando latenza e costi computazionali durante l'operazione del robot.
• Scalabilità: L'approccio è progettato per gestire specifiche sottodeterminate, rendendolo adatto a scenari reali dove le specifiche complete potrebbero non essere disponibili a priori.

In sintesi, il framework dimostra che l'uso combinato di agenti LLM e verifiche automatizzate può colmare il divario tra la pianificazione ad alto livello e l'esecuzione robotica affidabile, rendendo la sintesi di controller un processo robusto e scalabile.