FirstBot Project

> First Bot Project
> Studio teorico/pratico

> | <--Indietro | Inizio | Avanti--> |

> Domenica 25-8-2002
> Accendiamo i motori...

> Sembrava esserci molto tempo ed ora che mancano solo 4 mesi alla gara mi ritrovo ancora in alto mare... i circuiti per il riconoscimento dei bersagli sono ancora da montare, anzi, da ideare... la posizione dei sensori sulla torretta portabussola e' risultata infelice e dovro' mettere altre due colonnine sul davanti del bot... un ponticello da gia' segni di cedimento... la rilevazione IR e' meno precisa di quello che pensavo e la strategia di wall following che volevo realizzare va notevolmente semplificata (ora ho quattro telemetri ottici IR che da soli mi avrebbero evitato tutta la circuiteria e il software che ho studiato, ma ormai tengo tutto cosi' che vale comunque come bella esperienza:)

> Ho pensato diversi modi per strutturare il programma principale di navigazione. Alla fine, anche considerando che scrivo in assembler e che nelle grandi strutture IF THEN mi perdo tra le label, mi e' risultato piu' semplice creare una specie di rete logica, i cui bit rappresentano via via una conoscenza sempre piu' ad alto livello e sintetizzata dell'ambiente esterno.

> Si parte dai valori grezzi delle letture dei sensori IR che vengono normalizzati in "fasce di percorribilita', questo significa che abbiamo dei flag che indicano gia' "sensore troppo vicino" "oggetto nei paraggi" ecc... Per un primo abbozzo di navigazione pero' anche questo livello di riconoscimento e' troppo basso, allora un'ulteriore associazione dei dati precedenti imposta dei flags che indicano "oggetto davanti" "oggetto a sinistra" ecc... Per semplificare ulteriormente il ciclo del programma principale (sempre nell'ottica di togliere di mezzo gli IF THEN) ho ulteriormente associato e sintetizzato le informazioni sulla presenza e la direzione degli oggetti in due flag di altissimo livello, che indicano la direzione in cui ruotare (senza che il main debba preoccuparsi di deciderlo da solo in quanto rappresentano gia' la conoscenza completa dello spazio attorno). Inoltre un' ultima subroutine "sente" se stiamo andando a sbattere e blocca i motori.

> Usando una rete di flags di questo tipo abbiamo virtualmente accesso ad ogni tipo di informazione, dallo stato di un sensore alla presenza di un oggetto, alla direzione da scegliere in base alla situazione attuale... praticamente ogni IF puo' essere spostato nella rete di riconoscimento, e il main si riduce veramente all'osso, funzionando un po'come la coscienza del bot, a cui arrivano gia' tutte le informazioni distillate e le possibilita' di azione, e deve solo decidere cosa farne.

> A questo punto, realizzare una navigazione "dummy strategy" e' diventato molto semplice:

> 1) Comanda motori avanti
> 2) Se senti condizione di STOP blocca tutto
> 3) Fai una piccola retromarcia
> 4) Ruota nella direzione possibile finche' davanti non hai la visuale libera
> 5) GOTO 1

> Condizione di "stop", "direzione possibile" e "visuale libera", sono semplicemente tre bit impostati dalla rete di riconoscimento, il main usa queste informazioni per creare la strategia di movimento, in questo caso molto semplice. La rete attuale obbliga il bot a ruotare nella direzione dello spazio piu' grande, quindi se a destra c'e' una parete lui ruota a sinistra. Nel caso in cui vi siano pareti da entrambe le parti, oppure da nessuna delle due, il verso di rotazione e' random (viene determinato dal valore di un bit del registro TMR0 del timer0 che conteggia a circa 19kHz).

> Di seguito riporto alcuni filmati delle prime "prove su strada autonome". Considerando l'approssimazione del rilevamento, la semplicita' della rete di riconoscimento e il movimento puramente reattivo (che creano inevitabili e ripetitivi percorsi chiusi) se la cava anche benino:)

> I filmati sono .mov da quasi 4M ciascuno... (a parte il secondo che e' una prova da 1,7M)
> Se qualcuno sa indicarmi qualche programma per convertirli in leggero mpeg lo farei volentieri...

> In questi filmati non si vede, ma qualche volta uno spigolo e' stato centrato (e una volta ha pure "sfondato" senza accorgersi di nulla), inoltre ho provato a mettere un'asse di legno verniciata di bianco al posto del polistirolo e molte volte non viene vista... avessi avuto prima quei telemetri;)

> Ora con la sola aggiunta dei circuiti per il riconoscimento dei bersagli potrei gia' essere pronto per la "zero strategy competition", intendendo con queste parole il movimento quasi completamente alla cieca. Implementando l'allineamento con le pareti e il "wall following" sarei all'incirca al livello qualitativo della competizione a cui ho assistito.

> I prossimi passi sono quindi preparare completamente i sensori luce/suono/gas sia dal punto di vista hardware che software, scrivere le routinette per la calibrazione e pilotaggio dei LED, ed infine migliorare la navigazione di base, su cui appoggero' poi l'uso della bussola (per ora inerte). Ho deciso anche di cambiare forma alla torretta, sia per alleggerirla, sia per motivi estetici.

> Visti i mancati riconoscimenti degli ostacoli non so poi se e' il caso di aggiungere anche un paio di "wiskers", baffi metallici da usare come antibump meccanici (quasi tutti gli altri bot li hanno come arresto di emergenza quando gli IR o gli ultrasuoni falliscono)... il loro stato verrebbe semplicemente inglobato e propagato nella rete di riconoscimento (sensor fusion), e ad alto livello nel programma non cambierebbe nulla.

> Riporto il sorgente attuale del programma anche se ci sono molti "orrori" che verranno cambiati e/o semplificati: explor1.asm

> Domenica 1-9-2002
> Il rilevamento delle sorgenti sonore

> Per rilevare le sorgenti sonore ho deciso di usare due microfoni posti su due "antenne" messe lateralmente sul davanti del bot. I segnali dei microfoni li ho sommati e amplificati con un unico operazionale, e il risultato e' inviato al PLL tone decoder NE567 che svolge la funzione di passabanda strettissimo e riconoscitore di frequenza (sul pin di uscita abbiamo uno 0 quando viene rilevato il tono). Il trimmer da 10k all'uscita dell'LM358 serve per regolare la sensibilita' e va tarato sul posto.

> Ho pensato di non distinguere tra destra e sinistra perche' credo che la rilevazione sonora messa in OR con la presenza di un ostacolo vicino sia sufficiente.

> Quello che ho notato con estrema desolazione e' invece il livello elevato di spurie che arrivano al 567 con il solo movimento dei motori... in pratica la rilevazione e' sporchissima, e bisognera' trovare un modo software per ricavarne qualcosa di piu' attendibile (per esempio far fermare un attimo il bot quando gli sembra di avvertire qualcosa e applicare una strategia di debounching come se stessimo leggendo un pulsante dal contatto imperfetto).

> | Per migliorare un po' la situazione ho successivamente aggiunto un filtro passabasso, con questo filtro una parte di "rumore" nel riconoscimento viene eliminato, per contro il valore di out e'da leggere con un ingresso analogico, e vale 5V quando non viene rilevato nessun suono, e 0V quando c'e' piena rilevazione dei 4kHz.

> Il rilevamento delle sorgenti di gas

> | La rilevazione del gas verra' effettuata a software, pertanto e' sufficiente disaccoppiare e filtrare il sensore e portarne l'uscita ad un ingresso analogico del PIC. Una rilevazione ok dovrebbe esserci quando per un certo tempo la tensione fornita continua a salire rapidamente.

> La segnalazione luminosa di sorgente riconosciuta

> | La segnalazione di sorgenti riconosciute va fatta arrestando il bot per almeno 3 secondi e accendendo una luce di colore opportuno. Tre uscite del PIC sono dedicate per questo scopo e comandano tre coppie di LED jumbo attraverso i transistor contenuti nel driver di potenza ULN2003.

> Sabato 21-9-2002
> Il rilevamento delle sorgenti di luce

> Per quanto riguarda la rilevazione delle sorgenti luminose (comuni faretti alogeni) ho pensato di acquisire il livello separato per la sinistra e la destra, questo perche' l'alta luminosita' ambientale potrebbe creare dei falsi riconoscimenti se non fossero anche messi in AND con la rilevazione di ostacolo vicino.

> I trimmer da 4,7k servono per regolare la sensibilita' e vanno tarati sul posto.

> | <--Indietro | Inizio | Avanti--> |

> Pagina, disegni e foto realizzati da Claudio Fin - Ultimo aggiornamento 22-9-2002