Integrazione o sviluppo interno

Nei sistemi di visione tradizionali l’hardware ed il software sono due componenti complementari e ben distinte. Ultimamente sta emergendo la tendenza ad una loro integrazione: una più blanda, nei casi in cui il sistema di acquisizione sia dotato di un sistema di pre-elaborazione, una più sostanziale, come nelle smart camera, in cui la telecamera è dotata di un processore embedded e l’utente riceve come output il dato già completamente elaborato. In ogni caso è importante sottolineare il fatto che il successo di un sistema di visione non può prescindere da un’adeguata scelta di entrambi: la scelta di un hardware o di un software non adeguato, così come una loro cattiva integrazione, inficiano l’efficacia e l’utilizzabilità del sistema.
Data la ricchezza dell’offerta presente ormai sul mercato e la grande varietà di tipologia e complessità delle applicazioni che un utente può volere affrontare mediante la visione, non è sempre facile individuare la migliore soluzione disponibile e non è neppure semplice fornire dei precisi criteri di scelta.
La prima scelta da effettuare è se sia preferibile un sistema embedded, come una smart camera, o uno tradizionale. Una smart camera è un dispositivo compatto che si interfaccia normalmente con l’esterno mediante una connessione Ethernet. Il costo è evidentemente più elevato rispetto a una normale telecamera, ma dispone di un processore integrato dedicato all’elaborazione delle immagini e il lavoro (e conseguentemente il tempo) di programmazione richiesto all’utente è decisamente inferiore a quello necessario per la messa in funzione di un sistema tradizionale. Tali dispositivi offrono il massimo dei vantaggi in applicazioni, quali la visione robot, in cui le ridotte dimensioni e la possibilità di non doversi interfacciare con altri moduli per il proprio funzionamento, grazie alla presenza di intelligenza a bordo, sono caratteristiche di grande importanza.
Diversamente, i vantaggi legati al loro utilizzo sono decisamente inferiori qualora si debbano visualizzare le immagini e/o interfacciare con altri dispositivi, oppure se si vogliano acquisire viste multiple. Difatti nel caso sia necessario un interfacciamento con altri moduli, si perdono i vantaggi legati alla compattezza e all’assenza di numerosi cavi di connessione, invece, qualora si desiderino più viste, bisogna predisporre più telecamere e quindi replicare completamente l’hardware. Mentre nei sistemi di visione tradizionali è possibile collegare più telecamere a un unico elaboratore (purché la sua potenza sia sufficiente), ottimizzando così prestazioni e costi, nel caso delle smart camera bisogna replicare anche i costi dei processori, poiché ve ne è uno integrato a ogni telecamera.
Qualora si scelga un dispositivo non embedded, in cui le compatibilità e il funzionamento del sistema non sono a priori garantiti, bisogna svolgere diverse riflessioni aggiuntive, infatti la scelta del software è un momento cruciale nella definizione del sistema di visione. Ovviamente i programmatori esperti possono realizzare tutti gli algoritmi necessari autonomamente.
Tuttavia è estremamente complesso e oneroso relativamente a tempo e risorse da spendere implementare algoritmi di elaborazione di immagini, anche di complessità non molto elevata, che possano competere in efficienza e robustezza con i normali software commerciali. Solitamente questi sono costituiti da librerie di routine di basso livello denominate nel loro insieme SDK (Software Development Kit) e tradizionalmente sono state fornite come API (Application Programme Interface) o come DLL (Dynamic Link Library). Peraltro il crescente successo della programmazione orientata agli oggetti ha portato a una modifica della loro struttura e, sempre più spesso, gli SDK sono forniti come classi C++ o framework: la realizzazione delle applicazioni risulta in tal modo notevolmente semplificata. In passato abbiamo assistito alla presenza di una moltitudine di SDK, ultimamente il trend in atto è, anche in questo campo, una maggiore standardizzazione.
Al giorno d’oggi la standardizzazione più significativa si ha a livello di interfacce, per quanto riguarda algoritmi e librerie, invece, essa è limitata a diverse tipologie di componenti rilasciati dal medesimo produttore. In generale questo tipo di standardizzazione risulta essere un notevole vantaggio per lo sviluppatore, in quanto si semplifica la fase di apprendimento e si agevola la scalabilità e la modularità del sistema. Scalabilità e modularità del sistema sono caratteristiche cruciali per un sistema di visione: in fase di sviluppo non è sempre determinabile a priori l’effettiva architettura del sistema finale e, inoltre, è molto importante essere in grado di replicare parti del sistema per riutilizzarle nello stesso o in sistemi analoghi.
Al momento della scelta del software, il primo passo è la verifica della compatibilità fra software e hardware, intendendo con questo non solo i componenti legati al sistema di visione, ma anche quelli, solitamente già presenti nell’impianto di produzione, con cui il sistema deve interagire (backward compatibility). Inoltre, è importante prevedere i possibili futuri sviluppi del sistema e fare in modo che questi non siano in qualche modo inficiati o ritardati da un’assenza di compatibilità col software (forward compatibility).
Nel campo della visione, si assiste ad una sempre maggiore standardizzazione dei componenti e delle interfacce: ciò ha il doppio vantaggio di consentire il design di sistemi più flessibili e di semplificare decisamente l’analisi della forward compatibility. La struttura del software come gruppi di librerie o classi è adeguata per la fase di sviluppo dell’applicazione, ma molto meno per quella di prototipazione, durante la quale si cerca di elaborare la migliore strategia di analisi per ottenere il risultato desiderato. A meno di non possedere un’enorme esperienza, è necessario eseguire un elevato numero di prove e testare diversi algoritmi. Ne consegue che un software puramente programmabile non è adeguato per tale fase, poiché ogni cambio richiede di modificare, anche in maniera non trascurabile, e di ricompilare ogni volta il codice sorgente (si considerino anche i necessari tempi di debug).
Per ovviare a tali problematiche, i produttori mettono a disposizione dei software configurabili, che sfruttano le medesime librerie di elaborazione presenti nei relativi SDK, cosicché tutti i risultati raggiunti in prototipazione possono essere replicati nell’applicazione finale. Questi programmi sono interattivi e utilizzabili mediante interfacce GUI: permettono allo sviluppatore di creare applicazioni funzionanti rapidamente e senza scrivere codice. Ovviamente queste non sono completamente automatizzabili e non potranno mai possedere le caratteristiche di flessibilità richieste all’applicazione finale, tuttavia permettono di procedere alla fase di sviluppo in tempi rapidi e sulla base di un prototipo funzionante. Alcuni software consentono inoltre di generare automaticamente codice sorgente dal programma opportunamente configurato. In generale questo approccio è in assoluto quello più efficace per creare applicazioni sufficientemente robuste e veloci in tempi rapidi, riducendo così drasticamente il time-to-market del prodotto in esame.
Relativamente alla scelta della piattaforma, la maggior parte dei software disponibili in commercio sono sviluppati per lavorare in ambiente Microsoft Windows, anche se, attualmente, cominciano ad avere una certa diffusione del sistemi funzionanti in ambiente Linux. Tuttavia, al momento, non sono numerosi i produttori di hardware che rilascino driver che ne assicurino la compatibilità ed inoltre, conseguentemente alla natura open source di Linux, è difficile trovare tool di elaborazione delle immagini completi, cosicché è normalmente richiesto allo sviluppatore uno sforzo maggiore nella creazione dell’applicazione.
(Anie – Linee Guida)

Con il patrocinio di

Anipla
Patrocinio Anipla
Patrocinio Cnosfap
IMVG
AIDAM
Facoltà Di Ingegneria Di Pavia