Sempre più diffusi e investendo vari settori, i robot ne migliorano le performance all’insegna di efficienza e produttività. Tuttavia, per garantire la sicurezza delle persone e delle attrezzature nelle immediate vicinanze, questi robot devono essere in grado di rilevare le collisioni e di fermarsi. I rilevatori di safety bubble sono progettati per individuare la presenza di oggetti o persone all’interno di una determinata area di sicurezza.
I Safety Bubble Detector che utilizzano la piattaforma time of flight EVAL-ADTF3175D-NXZ
Questo articolo si focalizza sull’implementazione di un’applicazione di Safety Bubble Detector utilizzando la piattaforma time of flight EVAL-ADTF3175D-NXZ. Il modulo ADTF3175D ha un campo visivo (Field of View, FoV) di 75°. Per coprire un FoV più ampio nelle applicazioni reali, vengono combinati più sensori. Ad esempio, per coprire un FoV di 270°, vengono utilizzati quattro moduli. L’algoritmo di rilevamento della safety bubble viene eseguito sul processore i.MX8MP presente nella piattaforma EVAL-ADTF3175D-NXZ. L’algoritmo acquisisce le immagini di profondità dal sensore e rileva qualsiasi oggetto all’interno del raggio della bolla. Per facilitare l’integrazione nelle applicazioni robotiche, l’applicazione di Safety Bubble Detection viene implementata utilizzando il framework ROS (Robot Operating System). L’algoritmo è altamente ottimizzato per raggiungere un frame rate di 30 FPS su questa piattaforma. I rilevatori di safety bubble sono una componente fondamentale dei veicoli a guida automatica (AGV) e dei robot mobili autonomi (AMR). La zona di sicurezza è tipicamente rappresentata come un’area circolare virtuale attorno a un AGV/AMR, indicata dal cerchio rosso nella Figura 1.
Figura 1. Rilevatore di safety bubble.
I rilevatori di safety bubble sono fondamentali per qualsiasi sistema AGV/AMR. Come mostrato nella Figura 2, è stato costruito un rilevatore di bolla utilizzando quattro moduli EVAL-ADTF3175DNXZ per coprire un FoV di 278°. I moduli sono disposti in configurazione orizzontale, con ogni modulo time of flight (ToF) posizionato a 67,5° l’uno rispetto all’altro. Questa configurazione aiuta a ridurre i punti ciechi e fornisce un campo visivo di 278°.
Per facilitare la comunicazione tra i moduli ToF e il sistema host, viene utilizzato il modello ROS publisher-subscriber, come illustrato nella Figura 3. In questa configurazione, la comunicazione avviene tramite Ethernet su USB per garantire l’integrità dei dati e migliorare la velocità di comunicazione.
Un algoritmo di rilevamento della safety bubble viene utilizzato per rilevare gli oggetti all’interno del raggio della bolla stessa. Il flag di rilevamento viene trasmesso come topic ROS, consentendo alla macchina host di sottoscrivere tutti i topic dei moduli e combinare i risultati del rilevamento. Inoltre, i moduli pubblicano immagini di profondità, IR e di output per ulteriori analisi. ROS fornisce strumenti di visualizzazione efficaci, come rviz, che possono visualizzare i topic pubblicati. L’applicazione è progettata per essere altamente configurabile e passa i parametri ai nodi ROS per regolare la posizione della telecamera, la rotazione e altri valori di configurazione.
Nell’applicazione è implementata un’architettura multithread, come mostrato nella Figura 4. Tre thread, ovvero input, process e output, vengono eseguiti in parallelo. Il progetto mira a ridurre al minimo la latenza e garantire che il blocco di elaborazione operi continuamente sul fotogramma accessibile più recente. Il thread di input legge l’immagine dal modulo ToF e aggiorna la coda di input, mentre il thread di processo prende la coda di input ed esegue l’algoritmo di rilevamento della safety bubble, pubblicando il flag rilevato e spingendo l’output nella coda di uscita. Il thread di output legge la coda di uscita e pubblica i topic per la visualizzazione. Negli scenari in tempo reale, in cui il blocco di elaborazione ha un frame rate inferiore rispetto al thread di input, i frame precedenti vengono scartati per dare priorità al frame più recente con una latenza minima.
La comunicazione tra l’host e i moduli ToF avviene tramite il modello ROS publisher-subscriber, utilizzando il protocollo TCP/IP. L’host combina le immagini di output pubblicate dai nodi ROS (moduli ToF) e pubblica l’output combinato.
Come mostrato nella Figura 5, la macchina host è la NVIDIA® Jetson Xavier NX, che alimenta e comunica con tutti e quattro i moduli ToF utilizzando Ethernet su un protocollo USB.
Il raggio predefinito della safety bubble è di un metro, che può essere configurato nei file di avvio ROS. Se un oggetto viene rilevato all’interno di quest’area, il flag di rilevamento dell’oggetto viene attivato e inviato all’host tramite un topic ROS. La macchina host esegue il subscribe al topic di rilevamento dell’oggetto da ciascun modulo ToF. I risultati vengono combinati utilizzando una semplice operazione logica di range operativo (OR), che indica la presenza di un oggetto se uno qualsiasi dei sensori lo rileva all’interno della safety bubble.
Per la visualizzazione, i sensori convertono l’immagine acquisita nella sua vista dall’alto e contrassegnano gli oggetti con pixel verdi e rossi a seconda che si trovino all’interno o all’esterno della safety bubble. Questa immagine viene anche pubblicata come topic ROS da ciascun sensore e la macchina host li associa in un’immagine combinata.
La Figura 6 mostra l’immagine combinata di tutti i topic di immagine di output pubblicati.
Per la visualizzazione, nell’angolo in alto a sinistra viene disegnato un riquadro per mostrare lo stato di rilevamento degli oggetti (verde: oggetti non rilevati, rosso: oggetti rilevati). Vedi Figura 7.
Queste immagini possono essere visualizzate utilizzando lo strumento ROS rviz. Inoltre, NVIDIA Jetson Xavier NX può essere collegato a un monitor utilizzando un cavo HDMI per vedere l’output. Per l’analisi è possibile abilitare visualizzazioni come l’immagine di profondità, la nuvola di punti e la vista dall’alto dell’immagine di input. Queste visualizzazioni forniscono informazioni più dettagliate e approfondimenti sugli oggetti rilevati e sulle loro relazioni spaziali. Vedi Figura 8.
Processo SQA Utilizzato
Per garantire la sicurezza e la qualità del software vengono utilizzate metodologie standard di controllo della qualità del software (Software Quality Assurance, SQA).
- Test unitario: il ROS supporta diversi livelli di test unitario.
- Test unitario delle librerie: vengono testate le librerie indipendenti dal ROS.
- Test unitario del nodo ROS: i test unitari del nodo avviano il nodo stesso e ne testano l’API esterna, ovvero i temi pubblicati, i temi sottoscritti e i servizi.
- Copertura del codice: l’analisi della copertura del codice viene eseguita da uno dei pacchetti del ROS, che aiuta a eliminare il codice inattivo e ad aumentare la qualità del test unitario.
- Documentazione: il ROS ha un pacchetto chiamato ros_doc_lite, che fornisce un documento in formato doxygen per i file sorgente.
- Il formato Clang viene utilizzato per formattare il codice e Clang-tidy per mantenere le linee guida sullo stile di programmazione ROS.
Il rilevatore di safety bubble identifica in modo affidabile oggetti di varie forme, colori e dimensioni, compresi cavi di soli 5 mm di spessore.
La bassa latenza di 30 ms dell’algoritmo garantisce la risposta e il rilevamento degli oggetti in tempo reale.
Sfruttando ampiamente il framework ROS per l’interfaccia e la visualizzazione, l’applicazione è altamente portabile. È compatibile con qualsiasi macchina host che utilizza ROS e ridurrà il time to market dei clienti.
La precisione di un sensore ToF è inferiore per gli oggetti trasparenti e poco riflettenti. Ciò si traduce in un rilevamento tardivo di alcuni elementi come bottiglie di vetro e palline di plastica. Ad esempio, la Figura 9 mostra la distanza alla quale gli oggetti vengono rilevati dall’algoritmo (il raggio di sicurezza è impostato su 100 cm). L’asse y rappresenta gli oggetti di prova. Bottiglia di vetro (12, 7) significa che la bottiglia di vetro è alta 12 cm e larga 7 cm; se tra parentesi è presente un solo parametro, è indicato il raggio dell’oggetto o la lunghezza del cubo. Si veda la Tabella 1 per un riepilogo delle specifiche del rilevatore di safety bubble.
Tabella 1. Specifiche del rilevatore di Safety Bubble
In conclusione
Questo rilevatore di safety bubble, composto dalla piattaforma ADTF3175D e EVAL-ADTF3175DNXZ ToF, presenta molti vantaggi. È altamente ottimizzato per la piattaforma i.MX8MP, consentendo prestazioni fluide a 30 FPS. Utilizza un approccio multithread per ridurre al minimo la latenza, garantendo un funzionamento rapido e reattivo. Implementa inoltre metodologie SQA per garantire la sicurezza del software e mantenere gli standard di qualità.
