I framework per la robotica moderna soffrono di un’obesità infrastrutturale cronica.
Se stai costruendo un veicolo autonomo con LIDAR, camera di profondità e algoritmi SLAM per mappare un ambiente tridimensionale, ROS 2 è una scelta obbligata. L’ecosistema di pacchetti e la maturità degli algoritmi di navigazione spaziale non hanno rivali.
Ma cosa succede quando dobbiamo gestire l’automazione di un impianto di processo, un banco di collaudo, un sistema di erogazione o una cella meccatronica?
Succede che ci ritroviamo a installare gigabyte di dipendenze, a lottare con il middleware DDS e a configurare complessi file di launch… solo per leggere tre sensori I2C, eseguire un ciclo di controllo PID e azionare un relè.
È il momento di ammettere una verità taciuta: per la meccatronica di processo, ROS 2 è una scelta sbagliata.
1. L’illusionismo del middleware: l’overhead dei messaggi
ROS 2 basa la propria comunicazione sul middleware DDS (Data Distribution Service). In teoria, il DDS garantisce un’architettura distribuita e flessibile; in pratica, su sistemi con risorse contenute o schedulazione rigida, introduce un costo computazionale inaccettabile.
Ogni singola informazione scambiata tra i nodi passa attraverso un processo di serializzazione, allocazione dinamica della memoria nei buffer e deserializzazione.
Quando un ciclo di controllo deve campionare un encoder o modulare un segnale PWM a 1 kHz (1 ms di periodo), l’interposizione di un layer di messaggistica pesante introduce un jitter temporale non deterministico. Per chi fa controllo di processo, il jitter è il nemico numero uno: trasforma un’equazione differenziale discreta ideale in un sistema di controllo instabile.
2. L’inferno della build chain e l’illusione dei moduli
Sviluppare in ROS 2 significa accettare la tirannia di colcon, delle dipendenze rosdep e di workspace di compilazione enormi.
Un aggiornamento di sistema o un cambio di distribuzione (da Humble a Jazzy) può compromettere interi workspace a causa di disallineamenti nelle librerie sottostanti.
Nelle PMI o nelle aziende di automazione speciale, il software deve possedere tre requisiti fondamentali:
- Manutenibilità nel tempo: il codice scritto oggi deve compilare senza modifiche tra dieci anni.
- Dipendenze minime: l’applicazione non deve dipendere da centinaia di pacchetti esterni mantenuti da terzi.
- Trasparenza: ogni riga di codice eseguita sul microcontrollore o sul PC industriale deve essere nota e tracciabile.
Costruire un’architettura critica sopra centinaia di megabyte di astrazioni significa rinunciare al controllo dell’hardware.
3. Il vero determinismo non usa messaggi, usa la memoria
Nella robotica e nell’automazione industriale reale (PLC, motion controller, CNC), il ciclo di controllo non attende la pubblicazione di un topic di rete. Gira su una scansione deterministica a frequenza fissa.
L’architettura ideale per la meccatronica di processo si basa su tre pilastri essenziali:
- Un solo loop hard real-time: un ciclo in C++ nativo ancorato a un timer di sistema ad alta risoluzione. Il ciclo legge gli ingressi, esegue la macchina a stati e i cicli PID, ed emette le uscite. Senza allocazione dinamica della memoria, senza serializzazione.
- Buffer circolari lock-free in RAM: i dati del loop di controllo vengono scritti in strutture dati condivise ad altissima velocità, prive di mutex bloccanti.
- Disaccoppiamento totale tra controllo e osservabilità: la logica di controllo non attende l’invio dei dati alla rete. Un thread secondario a bassa priorità legge il buffer circolare e trasmette la telemetria via MQTT verso la dashboard di supervisione.
Se la rete cade, se l’interfaccia web si blocca o se il database va in saturazione, il loop in C++ non perde un singolo microsecondo.
4. La risposta: un engine C++ da pochi megabyte
Per risolvere questa inefficienza ho eliminato la sovrastruttura di ROS 2 per le applicazioni di processo e ho sviluppato APEX: un motore di esecuzione deterministico, scritto in C++ nativo e progettato per l’automazione essenziale.
APEX non vuole sostituire ROS 2 dove il mapping 3D è indispensabile. Nasce per fare esattamente l’opposto: restituire alle aziende di automazione e agli sviluppatori meccatronici uno strumento essenziale, deterministico e leggero.
- Footprint di memoria ridicolo: pochissimi megabyte di occupazione RAM.
- Zero dipendenze pesanti: compilazione immediata tramite CMake standard.
- Integrazione nativa: comunicazione diretta tramite bus MQTT verso Kaspian, la dashboard di monitoraggio e analisi Time-Series.
Conclusione
La vera innovazione software oggi non consiste nell’aggiungere ulteriori strati di astrazione o nel caricare gigabyte di librerie per compiti elementari. La vera innovazione consiste nel saper togliere tutto ciò che è superfluo per lasciare unicamente il determinismo, la velocità e il controllo diretto dell’hardware.
Se stai sviluppando automazione di processo o meccatronica speciale e ti sei stancato di combattere con la complessità di ROS 2, è ora di tornare all’architettura essenziale.