Riepilogo Tecnico: Onto-EV-WM per la Diagnosi dei Guasti e la Riparazione a Ciclo Chiuso

1. Definizione del Problema

I sistemi di IA fisica che utilizzano modelli del mondo (es. EV-WM) predicono futuri candidati e li valutano in base a vettori di caratteristiche o eventi. Tuttavia, questi punteggi scalari o vettori di eventi spesso mancano di informazioni semantiche esplicite riguardo al perché un candidato fallisca. Nello specifico, essi non registrano:

• Quale specifico predicato del compito rimane insoddisfatto (ad esempio, una relazione spaziale o un vincolo di giunto).
• Gli argomenti tipizzati associati al guasto.
• Un'etichetta di percorso che indichi quale meccanismo di correzione debba essere applicato.
• Un risultato di accettazione post-correzione basato sui predicati nativi del compito.

Di conseguenza, sebbene un sistema possa identificare un candidato con un punteggio basso, esso manca di un'interfaccia strutturata per diagnosticare la specifica condizione non soddisfatta, assegnare una strategia di correzione compatibile e verificare il risultato utilizzando un protocolo a ciclo chiuso. Il documento affronta il divario tra la predizione ad alta dimensione e la verifica simbolica del compito, con l'obiettivo di fornire un'interfaccia esplicita per la diagnosi e la riparazione senza sostituire il modello del mondo sottostante o il controllore visuomotorio.

2. Metodologia: Onto-EV-WM

Gli autori propongono Onto-EV-WM, un'interfaccia di diagnosi e correzione con gate di verifica basata su ontologia, stratificata sopra l'architettura EV-WM esistente. Non è un modello del mondo sostitutivo, ma uno strato simbolico che gestisce il flusso dalla predizione alla correzione.

2.1 Architettura e Componenti

Il sistema opera attraverso una pipeline strutturata che coinvolge tre componenti principali:

1. Livello di Registrazione Ontologica (TBox e ABox):
   • TBox (Task Box): Definisce uno schema locale del compito che include tipi di entità (es. Oggetto, Regione, Giunto), firme dei predicati (es. in_region, contact) e vincoli di tipo. Funge da vocabolario riutilizzabile per il compito specifico.
   • ABox (Assertion Box): Istanzia lo stato corrente. Il sistema costruisce tre ABox specifiche per la provenienza:
     • $A^\star_g$: Le asserzioni richieste compilate dalla specifica strutturata del compito ($g$).
     • $\hat{A}^{pred}_{g,t+H}$: Asserzioni derivate dagli output predetti dal modello del mondo.
     • $A^{sim}_{g,t}$: Asserzioni derivate direttamente dallo stato del simulatore.
2. Diagnosi e Routing Deterministici:
   • Diagnosi ($\Pi_D$): Confronta l'ABox richiesto ($A^\star_g$) con l'ABox osservato/predetto. Identifica le asserzioni insoddisfatte ($\Delta F_{src}$), preservando il predicato specifico, i suoi argomenti tipizzati e qualsiasi violazione del margine continuo. Ciò genera un record di guasto tipizzato (es. relation_missing(plate, stove_front)).
   • Routing ($\Pi_R$): Una base di regole deterministiche mappa il guasto tipizzato a un particolare "etichetta di percorso" (route label). Un percorso è un'etichetta di invio per un meccanismo di correzione compatibile (es. "posizione del giunto sorgente", "predicato di relazione dell'oggetto"), non un'azione diretta del robot.
3. Ciclo di Correzione con Gate di Verifica:
   • Generazione della Proposta: Un propositore (appreso, euristico o basato sulla pianificazione) genera una correzione $q$ basata sul record di guasto e sul percorso selezionato.
   • Applicazione: La correzione viene applicata tramite mutazione diretta dello stato del simulatore (es. modifica di $qpos$) o tramite esecuzione mediata dal controllore.
   • Verifica: Un verificatore nativo del compito controlla lo stato risultante rispetto al predicato del compito.
   • Riprova Limitata (Bounded Retry): Se la verifica fallisce, il sistema incrementa un budget di tentativi ($b$), rigrounda lo stato e può riprovare lo stesso percorso o cambiare percorso. Il ciclo termina con successo o esaurimento del budget.

2.2 Flusso Operativo

L'interfaccia separa predizione, grounding, diagnosi, applicazione e verifica.

• Input: Specifica del compito, tag sorgente (predizione o simulazione) e stato.
• Processo: Grounding dello stato in un'ABox $\rightarrow$ Diagnosi dei predicati mancanti $\rightarrow$ Assegnazione di un percorso $\rightarrow$ Generazione della correzione $\rightarrow$ Applicazione $\rightarrow$ Verifica.
• Output: Uno stato accettato, un candidato di pianificazione mantenuto o un tracciamento di guasto tipizzato non risolto.

3. Contributi Chiave

Il documento presenta tre contributi tecnici primari:

1. Ontologia Operativa per Compiti Robotici: Un design per un'interfaccia di grounding esplicita che rappresenta gli stati predetti e osservati dal simulatore come ABox distinte e specifiche per il compito, sotto una vocabolario e vincoli di tipo condivisi.
2. Diagnosi e Routing Deterministici: Un sistema basato su regole che preserva i predicati violati e i loro argomenti tipizzati, mappandoli a percorsi di correzione specifici del compito senza scartare il contesto originale.
3. Contratto di Correzione con Gate di Verifica: Un protocollo che registra l'intero ciclo di vita di un tentativo di correzione (diagnosi, selezione del percorso, proposta, modalità di applicazione e accettazione del predicato nativo) e impone un meccanismo di riprova limitata.

4. Risultati Sperimentali

Gli autori valutano Onto-EV-WM attraverso tre distinti scenari di benchmark utilizzando protocolli di simulazione.

4.1 PointMaze (Confronto Allineato)

• Configurazione: Confronto di pianificazione con stato casuale su 50 prove tra EV-WM e Onto-EV-VWM.
• Risultati: Entrambi i metodi hanno raggiunto un tasso di successo del 94%. Tuttavia, Onto-EV-WM ha ottenuto una distanza media dallo stato finale significativamente inferiore (0.61177) rispetto a EV-WM (0.90573), indicando una maggiore precisione nel soddisfare le condizioni del compito.
• Nota: Una configurazione separata con un budget di ricerca più ampio e una selezione basata sul successo ha raggiunto il 100% di successo, ma questa non è direttamente confrontabile con l'impostazione allineata a causa delle differenze di budget.

4.2 LIBERO-Goal (Correzione di Finestra Campionata)

• Configurazione: Valutazione su 10 compiti di manipolazione utilizzando 4 seed di campionamento della valutazione. Il protocollo campiona finestre di dimostrazione di 25 step. Le correzioni sono applicate tramite un meccanismo fisso appreso di delta $qpos$ di sorgente/giunto direttamente allo stato del simulatore.
• Risultati:
  • Seed 0: 93.8% di successo nella finestra corretta (469/500).
  • Su 4 Seed: 94.05 ± 0.30% di successo corretto.
  • Recupero: Dei 261 fallimenti di riproduzione, 142 sono stati "salvati" (54.4%) dal meccanismo di correzione.
• Contesto: L'ontologia fornisce il record diagnostico che collega il guasto alla testa di correzione fissa; la metrica riportata riflette la configurazione completa basata sull'ontologia.

4.3 LIBERO-Plus (Registro Fisso)

• Configurazione: Valutazione su un registro fisso di 10.030 compiti di perturbazione attraverso quattro suite (LIBERO-10, Goal, Object, Spatial).
• Risultati:
  • Successo Complessivo: 85.00% (8.526/10.030 compiti).
  • Suddivisione per Suite:
    • LIBERO-Goal: 91.39%
    • LIBERO-Object: 91.38%
    • LIBERO-Spatial: 91.38%
    • LIBERO-10: 65.98% (identificata come la suite con il più alto numero di fallimenti residui).
• Confronto: La configurazione Onto-EV-WM supera diversi baseline, inclusi DINO-WM + CEM (61.57%) e vari modelli VLA, sebbene il confronto sia a livello di sistema e non isoli il contributo causale dell'ontologia da sola.

5. Significato e Rivendicazioni

Il documento posiziona Onto-EV-WM come un interfaccia a livello di sistema che migliora i sistemi di IA fisica aggiungendo un ragionamento esplicito e tipizzato al processo di diagnosi e riparazione dei guasti.

• Ambito Modesto: Gli autori dichiarano esplicitamente che i risultati non costituiscono:
  • Recupero su robot reali o validazione sim-to-real.
  • Un grafo di conoscenza open-world generale o un'ontologia robotica universale.
  • Una quota causale basata solo sull'ontologia (i guadagni di prestazione sono attribuiti alla configurazione completa).
  • Una nuova classe di policy appresa che sostituisca i controller esistenti.
• Valore Centrale: La significatività risiede nella capacità di registrare il perché un compito è fallito (predicati tipizzati e argomenti) e nel strutturare il processo di riparazione (percorsi e verifica) in modo da essere scollegato dal modello di predizione sottostante. Ciò consente una riparazione a "ciclo chiuso" all'interno dei protocolli di simulazione dove la verifica funge da gate per l'accettazione delle correzioni.
• Limitazioni: La valutazione si basa su protocolli basati sulla simulazione. Il "ciclo chiuso" si riferisce a un ciclo limitato di verifica-riprova all'interno del simulatore, non al controllo in tempo reale su hardware fisico. I risultati quantitativi riflettono le prestazioni del sistema integrato sotto protocolli specifici piuttosto che l'efficacia isolata dell'ontologia.