Sistema di visione tramite piattaforma embedded

[dimaios]

Provo a fare dei calcoli:
Quindi credo che con una telecamere da 20-25 FPS dovrebbe farcela;

Dipende da come è fatto il sistema.

ora non so come i tempi di latenza (calcoli di: image processing, image analysis etc...) ed i tempi rubati all'esecuzione del programma da parte del SO e degli altri processi presenti sulla macchina possano degradare le prestazioni.

Il problema non è il tempo necessario per calcolare la posizione ma il fatto che durante quel tempo il target si è spostato.
Se il nastro procede a velocità costante ed il delta robot è sincronizzato con il tuo sistema di image processing allora puoi predirre dov'è il pezzo nell'istante di pick.
La condizione necessaria è quindi che i due sistemi abbiano un timer sincronizzato ( la precisione dipende da quanto veloce è il processo ) e che la predizione sia fatta a bordo del robot il quale calcola in tempo reale la posizione predetta in base a quella fornita.
E' altresì importante analizzare il bus di campo utilizzato per trasferire il dato della posizione dal PC al robot.

Essendo l'applicazione dinamica devi impiegare una telecamera con global shutter.
Le Basler sono ottime ( es. acA640-90gm ). Driver e le librerie di gestione della telecamera sono gratuite e molto ben fatte ( non male neanche l'efficienza ).
Ti consiglio ovviamente una telecamera in bianco e nero e preferibilmente GigE. Evita le USB3.0 perché non ti permettono di collocare la telecamera distante dal PC.

Per il PC puoi iniziare con un qualsiasi PC con un i7 a bordo e almeno 16 GB di RAM.
Per le ottimizzazioni CUDA puoi aspettare i risultati delle prove con il processore centrale.

Ti consiglio di iniziare le prove con Windows perché il Visual Studio aiuta molto nello sviluppo. Inoltre si riescono ad avere frame-rate di tutto rispetto ( sono arrivato fino a 100 Hz senza particolari problemi ).
Se poi vuoi fare il porting del software sotto Linux la cosa è abbastanza immediata perché le librerie sono le medesime ed i driver sono disponibili.

[jmonty]

La velocità del nastro trasportatore è costante (il nastro è azionato da un motore sincrono controllato da inverter Siemens mediante retroazione di un encoder incrementale 12 bit). Per sincronizzare la posizione di un oggetto individuato dal sistema di visione ed il controller ho pensato alla seguente soluzione:

passo 1)

Leggo un frame dalla telecamera.

passo 2)

Leggo il numero di impulsi provenienti dall''encoder(devo capire come e se esiste in commercio una telecamera dotata già di ingresso encoder che al frame in uscita mi associ il conteggio dell'encoder).

passo 3)

Prelevo dal frame la posizione dell'oggetto in ascisse e ordinate.

passo 4)

Invio al controller del robot la posizione dell'oggetto (ascisse e ordinate) con il conteggio encoder.

passo 5)

Il controller del robot calcola la posizione assoluta dell'oggetto mediante la posizione stimata dall'algoritmo di visione e la posizione dell'encoder trasmessa.

[dimaios]

passo 2)
Leggo il numero di impulsi provenienti dall''encoder(devo capire come e se esiste in commercio una telecamera dotata già di ingresso encoder che al frame in uscita mi associ il conteggio dell'encoder).

Non serve che la velocità la sappia la telecamera, lei calcola la posizione in un certo istante. Siccome questo istante temporale è sincronizzato con il robot, il robot deve ricevere un pacchetto del tipo :

Codice: Seleziona tutto

long timestamp ; // Istante di campionamento microsecondi
int   posizione   ; // Posizione calcolata nell'istante di campionamento


A questo punto il robot calcola la differenza tra il timer attuale e quello al momento del campionamento ecc. ecc.

Ancora più facilmente, senza scomodare IEEE1588 e sincronizzare il sistema, puoi dare il trigger di campionamento alla telecamera facendolo generare dall'elettonica di controllo del robot.
In questo modo il robot sa già quando è stato campionata l'immagine per cui non ci sono problemi.
Questo metodo di sincronizzazione nel tuo caso è più conveniente visto che impieghi solo una telecamera.

[jmonty]

La soluzione di generare il segnale di trigger per la telecamera dal controller mi va bene. Per quel che riguarda la comunicazione tra sistema di visione e controller mi sorgono i seguenti dubbi:

1) Tralasciando l'architettura di comunicazione (profibus, ethernet/ip, profinet etc...), nel caso in cui il mio sistema di visione individui più di un oggetto in un frame, deve inviare un pacchetto al controller in cui oltre al tempo di campionamento (da omettere se il trigger lo genera il controller) sono specificate le posizione dei singoli oggetti?

2) poiché tra un frame ed il successivo c'è la possibilità che il sistema di visione individui gli stessi oggeti, ovviamente con posizioni traslate secondo il verso di rotazione del nastro trasportatore, se invio un nuovo pacchetto al controller (che racchiude le stesse informazioni degli oggetti del pacchetto inviato in precedenza), come si comporterà il controller?

3)Tralasciando il comportamento del controller del robot inerente al punto 2, dovrei prevedere un algoritmo che mi tenga conto degli oggetti già individuati ed inviati al controller, in modo da non duplicare al controller informazioni già processate?

[dimaios]

Giusto per dare un'indicazione, procederei in questo modo.

La zona di tracking è praticamente quella vista dalla telecamera ovvero il range di misura.
La parte finale è la zona di invio del dato.
Quando un pezzo entra nella zona di tracking lo si segue e si capisce come associare l'immagine precedente con quella successiva analizzando per esempio lo spostamento dei baricentri.
Tutta la storia di un pezzo viene memorizzata in una coda. Quindi una coda contiene tutte le posizioni di un determinato pezzo durante il tracking.
Solo quando il pezzo entra nella zona di invio ( molto stretta ) allora viene cancellato dalle code di tracking e le coordinate sono spedite al robot per l'operazione di pick.

Sorgente FidoCadJ | Ingrandisci | Cos'è Fidocad

[jmonty]

Ora mi è tutto più chiaro!