Semplificare l'integrazione di AMR e AGV con i componenti ROS 2

I robot mobili autonomi (AMR) e i veicoli a guida automatica (AGV) richiedono lo stretto coordinamento tra più sottosistemi, quali sensori, motori, navigazione e processi decisionali basati sull'intelligenza artificiale (IA). L'integrazione di tutti questi sottosistemi rappresenta una sfida per gli sviluppatori.

Robot Operating System (ROS) offre un percorso attraverso questa complessità. Si tratta di un middleware robotico open-source che fornisce framework di comunicazione standardizzati e un ampio ecosistema di pacchetti riutilizzabili. Scegliendo componenti con supporto ROS nativo, i progettisti possono utilizzare moduli hardware pre-costruiti con funzionalità indirizzabili via software, riducendo i tempi di produzione e migliorando l'interoperabilità.

Questo articolo passa brevemente in rassegna le sfide che i progettisti di AMR e AGV devono affrontare e come i ROS possono aiutarli. Presenta quindi l'hardware compatibile con ROS di Analog Devices (ADI), compresi i controller per motori, le unità di misurazione inerziale (IMU) e i sensori di tempo di volo (ToF), e spiega come questi componenti si integrino con lo stack software ROS per accelerare lo sviluppo del prodotto.

La sfida dell'integrazione per AMR e AGV

Il lavoro di integrazione può dominare la programmazione iniziale di un progetto AMR o AGV. A livello hardware, i team devono selezionare i componenti, progettare le interfacce e convalidare l'integrità del segnale e la temporizzazione. A livello software, devono caricare i driver, definire i flussi di dati e garantire che il sistema si comporti in modo prevedibile in condizioni reali.

I team più talentuosi possono raggiungere questi obiettivi procedendo internamente alla progettazione, ma spesso ciò significa ricreare funzionalità che potrebbero essere disponibili già pronte. Questo sforzo può essere difficile da giustificare, soprattutto quando gli approcci tradizionali possono vincolare i team all'impiego di interfacce proprietarie. Quando i requisiti evolvono, la sostituzione di un componente può richiedere la rilavorazione di porzioni sostanziali dello stack software.

Come ROS affronta le sfide dell'integrazione

ROS è stato creato per risolvere questi problemi. Nonostante il nome (Robot Operating System), ROS non è un sistema operativo in senso classico. È piuttosto un framework open-source che offre un'ampia gamma di strumenti, librerie e convenzioni.

Il concetto chiave di ROS è la strutturazione delle applicazioni robotiche complesse in nodi modulari (Figura 1). I processi così ridimensionati eseguono compiti specifici, come la lettura dei dati dei sensori o il controllo della velocità del motore.

Figura 1: ROS è composto da pacchetti, nodi, messaggi e servizi. (Immagine per gentile concessione di Analog Devices, modificata da Kenton Williston)

I nodi comunicano attraverso due meccanismi principali:

• Topic: un modello publisher-subscriber adatto allo streaming continuo di dati, come i feed dei sensori
• Servizi: un modello request-response, ideale per azioni poco frequenti, come la configurazione e l'inizializzazione del dispositivo

Per fornire una funzionalità più completa, è possibile combinare in un pacchetto più nodi con le relative dipendenze (compresi i topic e i servizi associati). Ad esempio, Analog Devices ha creato pacchetti di driver ROS per i suoi moduli sensore e attuatore progettati per AGV e AMR. Questi pacchetti incapsulano i nodi, le definizioni dei messaggi e i file di configurazione necessari per integrare l'hardware in un sistema basato su ROS.

Come ROS semplifica la progettazione di AMR e AGV

Questa architettura modulare consente l'interoperabilità e accelera lo sviluppo. A livello hardware, ROS fornisce interfacce standardizzate per componenti quali telecamere e controller per motori. Questo accelera l'integrazione e libera i progettisti dal vincolo di uno specifico fornitore e dai costi di licenza.

A livello software, ROS offre strumenti e middleware che aiutano i progettisti a sviluppare, testare, distribuire e manutenere robot complessi. La versione attuale del framework, ROS 2, offre funzionalità particolarmente utili per AMR e AGV. Ad esempio:

• Lo stack di navigazione Nav2, che supporta gli alberi di comportamento, le zone di non ritorno, i limiti di velocità e altro ancora
• Sofisticati algoritmi di posizionamento, compresi strumenti di mappatura e localizzazione che consentono ad AMR e AGV di comprendere l'ambiente circostante
• Integrazione con strumenti di simulazione, visualizzazione e logging che aiutano lo sviluppo e la diagnostica

ROS 2 funziona tipicamente su un computer basato su Linux, anche se sono supportati altri sistemi operativi. ROS 2 supporta anche micro-ROS, una variante che funziona in modo nativo su microcontroller (MCU) con sistemi operativi in tempo reale (RTOS) come Zephyr e FreeRTOS.

Controllo motori con integrazione di ROS 2

Per illustrare il potenziale di ROS 2, prendiamo in considerazione la complessità del controllo di guida. La maggior parte degli AMR e degli AGV utilizza una configurazione differenziale in cui due set di ruote controllati in modo indipendente consentono sia il movimento in avanti che le curve. Questa architettura richiede un controller per motori in grado di azionare entrambe le ruote simultaneamente, accettando al contempo comandi coordinati dal sistema di navigazione.

TMCM-2611-AGV di ADI (Figura 2) risponde direttamente a questa esigenza. Questa scheda della famiglia TMCM (Trinamic Motor Controller Module) è una piattaforma di servoazionamento a doppio asse per motori c.c. brushless (BLDC) trifase, progettata per applicazioni di trazione per AGV e AMR. Ciascun asse può azionare motori fino a 14 A RMS a 48 V, con retroazione di posizione tramite encoder incrementali in quadratura o sensori digitali a effetto Hall.

Figura 2: TMCM-2611-AGV è un controller/driver a doppio asse per motori BLDC trifase. (Immagine per gentile concessione di Analog Devices)

Il driver ROS 2 adi_tmcl collega questo hardware all'ecosistema ROS 2 principalmente attraverso i topic (Figura 3). Ad esempio, uno stack di navigazione può inviare (publish) i comandi di velocità a ciascun set di ruote attraverso i topic /cmd_vel_X. Il driver adi_tmcl si iscrive (subscribe) a questi topic, traduce i comandi in frame di Trinamic Motion Control Language (TMCL) e li invia sul bus CAN tramite l'interfaccia SocketCAN nativa di Linux.

Figura 3: Il pacchetto di driver ROS2 TMCL incorpora una robusta serie di interfacce. (Immagine per gentile concessione di Analog Devices)

Nell'altra direzione, il driver adi_tmcl invia (publish) il feedback del motore ai topic /tmc_info_X, fornendo informazioni su velocità, posizione, coppia e stato. Altri nodi possono iscriversi a questi dati per il calcolo dell'odometria, la diagnostica o il controllo a circuito chiuso a livello di applicazione.

Questo flusso bidirezionale illustra come ROS 2 consenta la progettazione di sistemi modulari. L'algoritmo di navigazione non ha bisogno di conoscere il TMCL o il bus CAN; si limita a inviare messaggi di velocità standard e a ricevere un feedback.

Il driver adi_tmcl utilizza anche servizi per compiti quali l'inizializzazione e l'accesso ai parametri. Ad esempio, /tmcl_gap_all recupera tutti i valori dei parametri degli assi e /tmcl_ggp_all tutti i valori dei parametri globali della scheda controller.

Misurazione inerziale per il tracciamento della posizione

Sebbene gli encoder delle ruote consentano al sistema di stimare la posizione in base alla corsa delle ruote, la sola odometria delle ruote è spesso insufficiente per un accurato tracciamento della posizione. Lo slittamento delle ruote e le superfici irregolari possono introdurre errori significativi con il passare del tempo. Questo è un problema particolare in molti ambienti chiusi, dove i segnali GPS sono inaffidabili e non possono fornire correzioni continue.

Le IMU forniscono un riferimento di movimento indipendente che AMR e AGV possono utilizzare per migliorare la precisione della determinazione del punto stimato. Un esempio lampante è la famiglia ADIS16500/05/07, che offre il rilevamento inerziale di precisione a sei gradi di libertà tramite giroscopi triassiali e accelerometri triassiali, il tutto in un contenitore BGA di 15 × 15 × 5 mm. La calibrazione di fabbrica caratterizza sensibilità, polarizzazione, allineamento e compensazione della temperatura di ciascun sensore, riducendo l'onere di integrazione per i progettisti di sistemi.

Un esempio rappresentativo è ADIS16500AMLZ (Figura 4). Questo componente ha un intervallo del giroscopio di ±2000°/s, una stabilità in-run bias del giroscopio di 8,1˚/h e ARW di 0,29°/√h. Queste specifiche aiutano a ridurre la deriva nel tempo, migliorando le prestazioni di determinazione del punto stimato tra le diverse correzioni esterne.

Figura 4: ADIS16500AMLZ è una IMU MEMS di precisione in un contenitore BGA compatto. (Immagine per gentile concessione di Analog Devices)

Per l'integrazione di ROS 2, la famiglia ADIS16500/05/07 è supportata dal driver imu_ros2. Il driver sfrutta il sottosistema Linux Industrial I/O tramite LibIIO. Il suo output è compatibile con i comuni pacchetti di fusione sensoriale di ROS 2, come robot_localization, che implementano filtri di Kalman estesi per combinare i dati IMU e odometrici.

I progettisti interessati a sperimentare l'IMU possono iniziare con la scheda di valutazione ADIS16500/PCBZ (Figura 5). Questa scheda espone l'interfaccia SPI dell'IMU tramite una basetta a 16 pin compatibile con i cavi a nastro standard con passo di 2 mm.

Figura 5: La scheda di valutazione ADIS16500/PCBZ espone l'interfaccia SPI tramite una basetta a 16 pin. (Immagine per gentile concessione di Analog Devices)

Rilevamento della profondità per il rilevamento degli ostacoli

Il rilevamento degli ostacoli è un'altra caratteristica standard degli AMR/AGV. Sebbene la tecnologia LiDAR sia eccellente per rilevare gli ostacoli a distanze maggiori, molte applicazioni richiedono anche il rilevamento in campo vicino per rilevare ostacoli bassi, discontinuità del pavimento o oggetti esterni al piano di scansione del LiDAR. Le telecamere di profondità ToF colmano questa lacuna fornendo immagini di profondità dense su un ampio campo visivo.

Il modulo ToF ADTF3175BMLZ (Figura 6) si adatta perfettamente a questi requisiti. Combinando un sensore di profondità CMOS con un'ottica di illuminazione, il modulo acquisisce fotogrammi di profondità e luminosità attiva (AB) con una risoluzione fino a 1024 × 1024 e un campo visivo di 75° × 75°. Questa combinazione di risoluzione e copertura lo rende particolarmente adatto al monitoraggio delle zone di sicurezza e al rilevamento del pavimento in magazzini e ambienti di produzione, dove gli ostacoli possono apparire ad altezze variabili.

Figura 6: Il modulo ToF ADTF3175BMLZ integra un sensore di profondità CMOS con un'ottica di illuminazione. (Immagine per gentile concessione di Analog Devices)

Il driver adi_3dtof_adtf31xx semplifica l'accesso ai dati della telecamera pubblicando i fotogrammi di profondità e AB utilizzando formati di messaggio standard ROS 2. Queste uscite si integrano direttamente con i comuni pacchetti di percezione per attività quali la generazione di nuvole di punti, il rilevamento del pavimento e il monitoraggio delle bolle di sicurezza. Il driver supporta anche una modalità di riproduzione dei file, che consente di sviluppare e testare gli algoritmi senza una connessione hardware fisica.

Per lo sviluppo e la prototipazione, il kit EVAL-ADTF3175D-NXZ (Figura 7) fornisce una piattaforma di sensori completa. La caratteristica più importante del kit è una scheda basata su Arm® con Linux che può ospitare direttamente il nodo ROS 2. In alternativa, il sensore può trasmettere i dati di profondità via Ethernet a un host ROS 2 separato, offrendo flessibilità su diverse architetture di sistema.

Figura 7: Il kit di valutazione EVAL-ADTF3175D-NXZ comprende un host Linux basato su Arm. (Immagine per gentile concessione di Analog Devices)

La piattaforma di riferimento Analog Devices Autonomous Mobot (ADAM) dimostra come questi componenti compatibili con ROS si integrino con soluzioni aggiuntive per la gestione delle batterie, la conversione dell'energia e le comunicazioni per formare un sistema AMR completo.

Conclusione

La complessità della progettazione e dello sviluppo di AMR e AGV può essere considerevolmente ridotta scegliendo componenti compatibili con ROS e utilizzando un fornitore di componenti affidabile come ADI, che fornisce driver ROS 2 per un'ampia gamma di sensori e attuatori e può essere un partner prezioso.