Robot autonomo Wallace - Parte 4 - Aggiungi sensori di distanza IR e "Amp": 6 passaggi

2024 Autore: John Day | [email protected]. Ultima modifica: 2024-01-30 10:03

Ciao, oggi iniziamo la prossima fase di miglioramento delle capacità di Wallace. In particolare, stiamo cercando di migliorare la sua capacità di rilevare ed evitare gli ostacoli utilizzando sensori di distanza a infrarossi e di sfruttare anche la capacità del controller del motore Roboclaw di monitorare la corrente e trasformarla in un "sensore" virtuale (software). Infine, daremo un'occhiata a come navigare senza SLAM (localizzazione e mappatura simultanee) (per ora), poiché il robot non ha ancora un sensore IMU (unità di misura dell'inerzia) o ToF (tempo di volo).

Con la navigazione, inizialmente saranno solo due obiettivi principali:

1. evitare gli ostacoli
2. riconoscere quando è bloccato da qualche parte e non fa alcun progresso. ("progresso" significa che si è spostato in avanti di una distanza significativa)
3. un possibile terzo obiettivo potrebbe essere quello di cercare di allinearsi perfettamente a un muro.

Questo progetto è iniziato con un kit robot e facendo funzionare i movimenti di base utilizzando una tastiera e una connessione ssh.

La seconda fase consisteva nell'aggiungere circuiti di supporto sufficienti per preparare l'aggiunta di molti sensori.

Nel precedente Instructable, abbiamo aggiunto diversi sensori acustici HCSR04 e il robot ora può evitare gli ostacoli mentre si muove nell'appartamento.

Mentre va bene in cucina e in corridoio con superfici piatte buone e solide, è totalmente cieco quando si avvicina alla sala da pranzo. Non può "vedere" le gambe del tavolo e della sedia.

Un miglioramento può essere quello di tenere traccia delle tipiche correnti del motore, e se i valori saltano, allora il robot deve aver colpito qualcosa. È un buon "piano B" o anche C. Ma questo non aiuta molto a navigare nella sala da pranzo.

(Aggiornamento: in realtà, per ora, il monitoraggio della corrente è il piano A in retromarcia poiché ho rimosso temporaneamente e sensori dal retro).

Il video di questa sezione costituisce la fase finale dei sensori di evitamento ostacoli.

Quello che vedi nel video sono sei sensori acustici HCSR04 anteriori e due sensori IR Sharp. I sensori IR non sono entrati molto in gioco nel video. Il loro forte è soprattutto quando il robot si trova nella zona pranzo di fronte alle gambe del tavolo e della sedia.

Oltre ai sensori, il monitor di corrente è entrato in gioco soprattutto in retromarcia, nel caso in cui urtasse qualcosa.

Infine, utilizza la cronologia delle ultime 100 mosse e alcune analisi di base per rispondere a una domanda:

"C'è stato di recente un vero progresso in avanti (o è bloccato in qualche ballo ripetuto)?"

Quindi, nel video, quando si vede un avanti-indietro ripetuto, poi gira, significa che ha riconosciuto lo schema avanti-indietro, quindi prova qualcos'altro.

L'unico obiettivo programmato di questa versione del software era cercare di fare progressi continui e cercare di evitare gli ostacoli.

Passaggio 1: aggiungere il circuito di supporto (MCP3008)

Prima di poter aggiungere i sensori IR, avremo bisogno del circuito di interfaccia tra loro e il Raspberry Pi.

Aggiungeremo un convertitore analogico-digitale MCP3008. Ci sono molte risorse online su come collegare questo chip al Raspberry Pi, quindi non ne parlerò molto qui.

In sostanza, abbiamo una scelta. Se la versione dei sensori IR funziona a 3V, anche l'MCP3008 può farlo e possiamo quindi collegarci direttamente al Raspberry.

[Sensore IR 3V] - [MCP3008] -- [Raspberry Pi]

Nel mio caso, tuttavia, utilizzo principalmente 5V, quindi questo significa un cambio di livello bidirezionale.

[Sensore IR 5V] -- [MCP3008] -- [Bus bidirezionale da 5 V a 3 V] -- [Raspberry Pi]

Nota: c'è solo un segnale in uscita dal sensore IR. Va direttamente a una delle linee di segnale analogico di ingresso dell'MCP3008. Dall'MCP3008 ci sono 4 linee dati che dobbiamo connettere (tramite il bus bidirezionale) al Raspberry Pi.

Al momento, il nostro robot funzionerà utilizzando solo due sensori IR, ma potremmo facilmente aggiungerne altri. L'MCP3008 otto canali di ingresso analogico.

Passaggio 2: montare i sensori IR

Sharp produce diversi sensori IR e hanno portate e aree di copertura diverse. Mi è capitato di aver ordinato il modello GP2Y0A60SZLF. Il modello scelto influenzerà il posizionamento e l'orientamento del sensore. Sfortunatamente per me, non ho davvero studiato esattamente quali sensori ottenere. Era più di una decisione "quali posso ottenere in un tempo e un prezzo ragionevoli da una fonte affidabile, tra quelle che offrono".

(Aggiornamento: tuttavia, potrebbe non avere importanza, poiché questi sensori sembrano essere confusi dall'illuminazione ambientale interna. Sto ancora esplorando il problema)

Esistono almeno tre modi per montare questi sensori sul robot.

1. Adagiateli in una posizione fissa, davanti, leggermente distanti l'uno dall'altro.
2. Posizionali su un servo, nella parte anteriore, leggermente distanti l'uno dall'altro.
3. Mettili in una posizione fissa, nella parte anteriore, ma negli angoli più a sinistra e più a destra, inclinati l'uno verso l'altro.

Confrontando la scelta n. 1 con la scelta n. 3, penso che la n. 3 coprirà più dell'area di collisione. Se dai un'occhiata alle immagini, la scelta n. 3 può essere eseguita non solo in modo che i campi del sensore si sovrappongano, ma possano anche coprire il centro e oltre la larghezza esterna del robot.

Con la scelta n. 1, più i sensori sono angolati l'uno dall'altro, maggiore è il punto cieco al centro.

Potremmo fare #2, (ho aggiunto alcune immagini con servo come possibilità) e fargli fare uno sweep, e ovviamente questo può coprire la maggior parte dell'area. Tuttavia, voglio ritardare il più possibile l'uso di un servo, per almeno due motivi:

• Useremo uno dei canali di comunicazione PWM sul Raspberry Pi. (È possibile migliorarlo ma comunque…)
• L'assorbimento di corrente con il servo può essere significativo
• Aggiunge altro all'hardware e al software

Vorrei lasciare l'opzione servo per dopo quando si aggiungono sensori più importanti, come Time-of-Flight (ToF) o forse una fotocamera.

C'è un altro possibile vantaggio con la scelta n. 2 che non è disponibile con le altre due scelte. Questi sensori IR possono confondersi, a seconda dell'illuminazione. Potrebbe essere che il robot ottenga una lettura di un oggetto che è imminentemente vicino quando in realtà non c'è nessun oggetto vicino. Con la scelta n. 3, poiché i loro campi possono sovrapporsi, entrambi i sensori possono registrare lo stesso oggetto (da diverse angolazioni).

Quindi stiamo andando con la scelta di posizionamento #3.

Passaggio 3: è ora di testare

Dopo aver effettuato tutte le connessioni tra Raspberry Pi, MCP3008 ADC e i sensori Sharp IR, è il momento di testare. Basta un semplice test per assicurarsi che il sistema funzioni con i nuovi sensori.

Come nei precedenti Instructables, utilizzo il più possibile la libreria di cablaggioPi C. Rende le cose più facili. Qualcosa che non è molto ovvio dalla revisione del sito Web di cablaggioPi, è che esiste un supporto diretto per MCP3004/3008.

Anche senza quello, potresti semplicemente usare l'estensione SPI. Ma non ce n'è bisogno. Se dai un'occhiata da vicino al repository git di Gordon per cablaggioPi, ti imbatterai in un elenco di chip supportati, di cui uno è per MCP3004/3008.

Ho deciso di allegare il codice come file perché non riuscivo a visualizzarlo correttamente in questa pagina.

Passaggio 4: un sensore virtuale - AmpSensor

Più diversi sono i modi in cui puoi fare in modo che il robot riceva informazioni sul mondo esterno, meglio è.

Il robot ha attualmente otto sensori sonar acustici HCSR04 (non sono al centro di questo Instructable) e ora ha due sensori di distanza Sharp IR. Come affermato in precedenza, possiamo sfruttare qualcos'altro: la funzione di rilevamento delle correnti del motore di Roboclaw.

Possiamo avvolgere quella chiamata di query al controller del motore in una classe C++ e chiamarla AmpSensor.

Aggiungendo alcuni "intelligenti" al software, possiamo monitorare e regolare il tipico assorbimento di corrente durante il movimento rettilineo (avanti, indietro) e anche i movimenti di rotazione (sinistra, destra). Una volta che conosciamo questi intervalli di ampere, possiamo selezionare un valore critico, in modo che se l'AmpSensor ottiene una lettura di corrente dal controller del motore che supera questo valore, sappiamo che i motori si sono probabilmente bloccati e questo di solito indica che il robot ha urtato in qualcosa.

Se aggiungiamo una certa flessibilità al software (argomenti da riga di comando e/o input da tastiera durante il funzionamento), possiamo aumentare/diminuire la soglia degli "amplificatori critici" mentre sperimentiamo semplicemente lasciando che il robot si muova e urta gli oggetti, sia direttamente all'interno, sia durante la rotazione.

Poiché la nostra parte di navigazione del software conosce la direzione del movimento, possiamo forse usare tutte queste informazioni per fermare il movimento e provare a invertire il movimento per un breve periodo prima di provare qualcos'altro.

Passaggio 5: navigazione

Il robot attualmente è limitato nel feedback del mondo reale. Ha alcuni sensori a distanza ravvicinata per evitare gli ostacoli e ha una tecnica di ripiego per monitorare l'assorbimento di corrente se i sensori di distanza mancano un ostacolo.

Non ha motori con encoder, e non ha IMU (unità di misura inerziale), quindi è più difficile sapere se si sta realmente muovendo o ruotando, e di quanto.

Mentre si può ottenere una sorta di indicazione della distanza con i sensori attualmente sul robot, il loro campo visivo è ampio e c'è imprevedibilità. Il sonar acustico potrebbe non riflettere correttamente; l'infrarosso può essere confuso da altre luci o anche da più superfici riflettenti. Non sono sicuro che valga la pena provare effettivamente a monitorare il cambiamento di distanza come tecnica per sapere se il robot si sta muovendo e di quanto e in quale direzione.

Ho scelto volutamente di NON usare un microcontrollore come un Arduino perché a) non mi piace il suo ambiente pseudo-C++, b) e che troppo sviluppo consumerà la memoria di lettura-scrittura (?), e che io avrebbe bisogno di un computer host per sviluppare (?). O forse mi capita semplicemente come il Raspberry Pi.

Il Pi che esegue Raspbian, tuttavia, non è un sistema operativo in tempo reale, quindi tra le instabilità di questi sensori e il sistema operativo che non legge esattamente ogni volta, ho sentito che lo scopo di questi sensori era più adatto per evitare ostacoli e non misurazione della distanza effettiva.

Quell'approccio sembrava complicato e con non così tanti benefici, quando possiamo usare migliori sensori ToF (tempo di volo) (in seguito) per quello scopo (SLAM).

Un approccio che possiamo usare è quello di tenere traccia di quali comandi di movimento sono stati emessi negli ultimi X secondi o comandi.

Ad esempio, supponiamo che il robot sia bloccato di fronte a un angolo in diagonale. Un set di sensori gli dice che è troppo vicino a un muro, quindi ruota, ma poi l'altro set di sensori gli dice che è troppo vicino all'altro muro. Finisce solo per ripetere uno schema da lato a lato.

L'esempio sopra è solo un caso molto semplice. L'aggiunta di alcuni accorgimenti potrebbe semplicemente portare il modello ripetuto a un nuovo livello, ma il robot rimane bloccato nell'angolo.

Ad esempio, invece di ruotare avanti e indietro sul posto, ruota in un senso, esegue una momentanea retromarcia (che quindi cancella le indicazioni della distanza critica) e anche se ruota nell'altra direzione, continua ad andare avanti con una certa angolazione nell'angolo, ripetendo uno schema più complicato essenzialmente della stessa cosa.

Ciò significa che potremmo davvero utilizzare una cronologia dei comandi e dare un'occhiata a come sfruttare e utilizzare tali informazioni.

Mi vengono in mente due modi molto basilari (rudimentali) di usare la storia del movimento.

• per l'ultimo numero X di mosse, corrispondono al modello Y. Un semplice esempio potrebbe essere (e questo è successo) "AVANTI, INDIETRO, AVANTI, INDIETRO, …..". Quindi c'è questa funzione di corrispondenza che restituisce TRUE (schema trovato) o FALSE (non trovato). Se TRUE, nella parte di navigazione del programma, tenta altre sequenze di movimento.
• per l'ultimo numero X di mosse, c'è un movimento in avanti generale o netto. Come si potrebbe determinare qual è il vero movimento in avanti? Bene.. un confronto facile è che per le ultime X mosse, "FORWARD" si verifica più di "REVERSE". Ma questo non deve essere l'unico. Che ne dici di questo: "DESTRA, DESTRA, SINISTRA, DESTRA". In tal caso, il robot deve svoltare a destra per uscire da un angolo o perché si è avvicinato al muro in un angolo, che potrebbe essere considerato un vero avanzamento in avanti. D'altra parte, "SINISTRA, DESTRA, SINISTRA, DESTRA…" potrebbe non essere considerato un vero progresso in avanti. Quindi, se "DESTRA" si verifica più di "SINISTRA" o "SINISTRA" si verifica più di "DESTRA", allora questo potrebbe essere un vero progresso.

All'inizio di questo Instructable, ho accennato al fatto che un possibile terzo obiettivo potrebbe essere l'allineamento o l'allineamento a un muro. Per questo, tuttavia, abbiamo bisogno di più di "siamo vicini a qualche oggetto". Ad esempio, se possiamo ottenere due sensori acustici rivolti in avanti (non il focus di questo articolo) per dare risposte ragionevolmente buone e stabili riguardo alla distanza, ovviamente se uno riporta un valore molto diverso dall'altro, il robot si è avvicinato al muro ad angolo, e potrebbe tentare qualche manovra per vedere se quei valori si avvicinano l'uno all'altro (di fronte al muro ad angolo retto).

Passaggio 6: considerazioni finali, fase successiva…

Spero che questo Instructable abbia dato alcune idee.

L'aggiunta di più sensori introduce alcuni vantaggi e sfide.

Nel caso sopra, tutti i sensori acustici hanno funzionato bene insieme ed è stato piuttosto semplice con il software.

Una volta che i sensori IR sono stati introdotti nel mix, è diventato un po' più impegnativo. Il motivo è che alcuni dei loro campi visivi si sovrapponevano a quelli dei sensori acustici. I sensori IR sembravano un po' sensibili e imprevedibili con le mutevoli condizioni di luce ambientale, mentre ovviamente i sensori acustici non sono influenzati dall'illuminazione.

E quindi la sfida era cosa fare se un sensore acustico ci dice che non c'è alcun ostacolo, ma il sensore IR sì.

Per ora, dopo tentativi ed errori, le cose sono finite in questa priorità:

1. rilevamento dell'amplificatore
2. Rilevamento IR
3. rilevamento acustico

E quello che ho fatto è stato solo abbassare la sensibilità dei sensori IR, in modo che rilevassero solo oggetti molto vicini (come le gambe delle sedie imminenti)

Finora, non è stato necessario eseguire alcun software multi-threading o basato su interrupt, anche se occasionalmente ho riscontrato una perdita di controllo tra il Raspberry Pi e il controller del motore Roboclaw (perdita di comunicazioni seriali).

È qui che normalmente entrerebbe in uso il circuito E-Stop (vedi Instructables precedenti). Tuttavia, dal momento che non voglio (ancora) avere a che fare con il ripristino del Roboclaw durante lo sviluppo, e il robot non sta andando così veloce, e sono presente per monitorarlo e spegnerlo, non ho collegato il pulsante di emergenza.

Alla fine, molto probabilmente sarà necessario il multi-threading.

Prossimi passi…

Grazie per essere arrivato fino a qui.

Ho ottenuto alcuni sensori ToF (time-of-flight) laser IR VL53L1X, quindi questo è probabilmente l'argomento del prossimo Instructable, insieme a un servo.