Tempo reale non significa semplicemente velocità
Nel controllo di un robot, definire un’attività in tempo reale non significa semplicemente che venga eseguita rapidamente. Significa che il risultato deve essere disponibile entro una scadenza rilevante per l’applicazione. Se un’attività di controllo deve leggere i sensori, calcolare una risposta e aggiornare gli attuatori prima di un limite stabilito, contano sia il tempo di esecuzione sia la sua variabilità, oltre alla possibilità di non rispettare la scadenza. Una media bassa non basta a dimostrare un comportamento prevedibile.
La distinzione è importante perché un’attività può essere rapida nella maggior parte delle esecuzioni e richiedere comunque troppo tempo in altre. La media descrive il comportamento abituale, ma da sola non indica cosa accade nei casi più lenti né quanto spesso si verificano. Per valutare il requisito temporale bisogna osservare la risposta rispetto alla scadenza da rispettare, non limitarsi a confrontare le velocità medie. La questione è se l’attività termina in tempo nelle condizioni valutate, non se di solito è veloce.
Il requisito specifico cambia a seconda della funzione. Un’interfaccia di supervisione può tollerare ritardi inaccettabili in un anello di controllo. Anche acquisizione dei dati, elaborazione e comunicazione con gli attuatori possono avere scadenze diverse. Prima di scegliere un’architettura, quindi, è opportuno definire quale attività deve rispondere, la sua scadenza, la frequenza di ripetizione e le conseguenze di una risposta tardiva. Senza questi requisiti, «tempo reale» rischia di diventare un’etichetta imprecisa invece di un criterio verificabile. Definirli separatamente evita inoltre di considerare equivalenti fasi con funzioni ed esigenze temporali differenti.
Cosa offre ROS 2 all’esecuzione
La documentazione di ROS 2 tratta la programmazione in tempo reale come una questione che comporta requisiti e difficoltà di implementazione, non come una proprietà ottenuta automaticamente usando il framework. È quindi utile distinguere gli strumenti offerti da ROS 2 dalla dimostrazione che una determinata applicazione rispetti le proprie scadenze. La documentazione tecnica può guidare la configurazione e l’analisi, ma non sostituisce la definizione dei requisiti del robot né i test dell’implementazione scelta.
In particolare, la presenza di meccanismi di configurazione non va interpretata come garanzia che il risultato arrivi entro una scadenza end-to-end. Un percorso dei dati può comprendere comunicazione, pianificazione, elaborazione e risposta degli attuatori; il tempo osservato dipende dal percorso valutato e dalle condizioni di esecuzione. L’interpretazione corretta è condizionale: ogni meccanismo va valutato all’interno di una configurazione specifica e insieme al resto dell’applicazione.
Nel valutare una configurazione, conviene descrivere quali componenti partecipano al percorso rilevante e quale limite temporale viene verificato. Questa descrizione aiuta a interpretare le misurazioni ed evita di attribuire il risultato a una sola opzione di configurazione. La documentazione consultata tratta la programmazione in tempo reale come una questione di implementazione; non stabilisce una garanzia generale applicabile a ogni robot. Una valutazione utile mantiene quindi chiari l’ambito di ciascuna misurazione e quello di ogni conclusione.
Executor, callback e pianificazione
Gli executor fanno parte dell’architettura di esecuzione di ROS 2. La ricerca accademica sulla pianificazione di catene di elaborazione in un executor ROS 2 multithread analizza la pianificazione e i tempi di risposta nel contesto della catena, anziché limitarsi a misurare la velocità di un singolo nodo. Ciò conferma la necessità di valutare l’organizzazione del lavoro e le dipendenze tra attività per la configurazione che si intende utilizzare.
In pratica, valutare un executor significa esaminare come è organizzato il lavoro, non soltanto quanto impiega una funzione quando viene eseguita senza altre attività. La gestione delle callback fa parte del percorso che conduce da un ingresso a una risposta; le scelte di distribuzione ed esecuzione vanno quindi considerate insieme al resto del percorso. Il solo numero di thread non descrive tutta la pianificazione: conta anche il modo in cui si rapporta alle attività realmente eseguite dall’applicazione.
Per una catena di elaborazione, l’analisi può comprendere le diverse fasi coinvolte e le loro relazioni. La struttura dell’executor e le dipendenze tra attività fanno parte del sistema valutato. I risultati di un’analisi o di un esperimento associati a una versione e a una configurazione non vanno trasferiti automaticamente ad altre versioni, carichi o piattaforme. La ricerca citata riguarda una specifica configurazione multithread; non equivale a una garanzia per tutti i sistemi ROS 2.
Ciò che rimane fuori dal framework
ROS 2 non elimina l’influenza del sistema operativo o della piattaforma su cui viene eseguito. La documentazione del progetto sulla programmazione in tempo reale presenta l’argomento come un insieme di requisiti e difficoltà di implementazione, non come una proprietà che si attiva semplicemente utilizzando ROS 2. Come esempio specifico, la documentazione del driver ROS 2 di Universal Robots consiglia un sistema Ubuntu con capacità in tempo reale per il proprio driver e segnala che un kernel a bassa latenza può essere sufficiente in molte delle situazioni descritte nella guida. La raccomandazione riguarda quel driver e non va generalizzata a tutti i robot o a tutte le applicazioni.
Questo significa che due implementazioni che utilizzano ROS 2 non devono necessariamente mostrare lo stesso comportamento temporale se differiscono la piattaforma o il carico di lavoro. Le osservazioni vanno collegate alle condizioni in cui sono state ottenute: componenti del sistema e configurazione sono importanti per interpretare il risultato. Senza queste informazioni, un dato isolato non permette di capire se rappresenti le condizioni che l’applicazione dovrà affrontare.
Non basta neppure verificare che i messaggi arrivino o che una dimostrazione funzioni in condizioni controllate. Un test dovrebbe rappresentare il carico e la sequenza di lavoro dell’applicazione, registrare i tempi rilevanti e considerare i casi più lenti, non solo le medie. È opportuno misurare end-to-end, dall’evento che avvia il lavoro alla risposta importante per il robot. Se il requisito riguarda la sicurezza o una missione critica, le evidenze sulle prestazioni dovrebbero rientrare in una valutazione più ampia dell’architettura e del rischio; un test prestazionale isolato non equivale a una certificazione.
Una verifica utile prima di adottare ROS 2
Iniziate documentando ogni scadenza: quale evento la avvia, quale risposta la soddisfa, con quale frequenza si ripete e quale margine è disponibile. Disegnate poi la catena di elaborazione che collega sensori, nodi e attuatori. Per ogni tratto, annotate i componenti coinvolti, il lavoro che svolgono e le dipendenze da altre attività. Questa descrizione trasforma un’aspettativa generale in domande verificabili e aiuta a individuare se il ritardo dipende dalla comunicazione, dalla pianificazione o dal lavoro dell’applicazione.
La descrizione di ciascuna scadenza dovrebbe anche distinguere chiaramente l’inizio del lavoro dalla risposta considerata valida. Questa precisione consente di confrontare le misurazioni con il requisito corrispondente, anziché misurare per comodità una fase diversa. Se le fasi sono più d’una, mantenere le loro relazioni all’interno della catena facilita l’interpretazione dei punti in cui si accumula il tempo ed evita di confondere le prestazioni locali di un componente con la risposta completa richiesta dal robot.
Poi definite la versione di ROS 2, il middleware, il sistema operativo, l’hardware e la configurazione da valutare. Provate il carico previsto e condizioni sfavorevoli plausibili, misurate sia le singole fasi sia la risposta completa e conservate la configurazione insieme ai risultati. Ripetete i test dopo modifiche importanti e confrontate ogni conclusione con la documentazione applicabile a quella versione. L’obiettivo non è dimostrare che ROS 2 sia «in tempo reale» in astratto, ma determinare se un’implementazione definita rispetta requisiti definiti in condizioni documentate. Le fonti consultate supportano capacità di configurazione e analisi, ma non stabiliscono una garanzia universale di conformità per ogni robot.