No sto provando a cercare ma non trovo più le discussioni, mi pare fosse astro che prova la cosa e riferiva che era riuscito a identificare un quadrato rosso su sfondo bianco, cerchi, ecc. il nome era una roba del tipo pix... qualcosa
astrobeed:
Pixy non è Arduino, è una periferica autonoma che sfrutta un processore a 32 bit.
Si, certo Astro ma era per dare un riferimento a Rob123 che per fare certe cose serve hardware di un certo tipo (nonché conoscenze), così magari ha un'alternativa essendo impossibilitato a fare ciò che desidera con la poca potenza a disposizione di arduino
Ricordavo anch'io sta mattina la pixy... Ma non credo che faccia al caso suo... La domanda specifica riconoscere forme geometriche triangoli quadrati dal perimetro oggetto, non seguire l'oggetto in base al colore o la sua forma
Esattamente, devo riconoscere un quadrato o un rettangolo per poterlo ruotare.
Fate conto di dover incollare un francobollo. O di dover completare quel gioco per bambini con le forme.
Io penso che un immagine b/n a 8 bit con risoluzione 128x128 sia utilizzabile con arduino. l'immagine sarebbe composta da 16384 pixel. non sarebbe come leggere 16384 volte un pin analogico?
b/n è a 1 bit, te la vuoi in scala di grigi.
Fai i tuoi conti con la memoria se ci stai dentro.. alla fine il discorso è li se non hai vincoli di realtime
Si intendevo scala di grigi. se ne trovassi una in b/n ad 1 bit potrebbe essere anche piu facile. se non altro potrei saltare la parte di programma che deve decidere se considerare il pixel impegnato o vuoto.
allora, una volta capito il meccanismo sono due le cose che vorrei fare. la prima è fare un sistema per orientare i componenti che vengono prelevati da una macchina pick and place.
in queste macchine il componente andrebbe controllato:
prima di essere preso, per prendere la mira diciamo;
prima di essere posizionato, per correggere offset e orientamento,
dopo il posizionamento per sapere se ha fatto scherzi.
Questa è la prima cosa, che potrebbe o meno interessarvi.
La seconda sono sicuro che sia molto più interessante. Si tratta far atterrare un areomodello autoguidato con il mio sistema di autoguida, che altro non è che una versione un po' personalizzata del sistema apm, ardupilot o comunque lo si voglia chiamare.
Attualmente nessun aereo atterra da solo se non in piste piu larghe di quanto sbaglia il gps. (anche 30 metri)
Ho parlato di non realtime, ed in effetti resta non realtime. una lettura al secondo va piu che bene. ma anche una ogni tre non va male. sottolineando che la lettura verrebbe fatta a richiesta, non a ciclo continuo, in quel momento se anche il loop impiega tre secondi l'aereo non cade, ne si sposta di chilometri. ci sono altri sensori ad integrare la posizione, la visione artificiale deve solo dare un riferimento preciso.
Personalmente penso che non ci siano differenze tra riconoscere una retta oppure un quadrato. quando scorrendo il valore di ogni singolo pixel si individua una variazione da bianco a nero significa che in quel punto passa una retta. Memorizzando in un array tutti i punti trovati, che sarebbero molti meno rispetto all'intera risoluzione della camera, si potrebbe definire la retta. e qui mi fermo, perchè a livello porgrammazione non saprei andare oltre.
Mettendo una striscia catarinfrangente rossa sulla pista si potrebbe anche usare una telecamera a colori e memorizzare solo i pixel con un certo livello di rosso. Penso che analizzando i pixel uno per volta arduino ce la potrebbe tranquillamente fare senza tanti limiti di risoluzione.
La domanda qui diventa un altra, come si fa a leggere un pixel per volta (o anche dieci) dal buffer della telecamera?
