Robot autònom de Wallace - Part 4: afegir sensors de distància i amplificadors IR: 6 passos

2024 Autora: John Day | [email protected]. Última modificació: 2024-01-30 08:15

Hola, avui comencem la següent fase de millora de les capacitats de Wallace. En concret, intentem millorar la seva capacitat per detectar i evitar obstacles mitjançant sensors de distància infrarojos, i també aprofitem la capacitat del controlador de motor Roboclaw per controlar el corrent i convertir-lo en un "sensor" virtual (de programari). Finalment, veurem com navegar sense SLAM (localització i mapeig simultanis) (per ara), ja que el robot encara no disposa de sensors IMU (unitat de mesura d’inèrcia) ni ToF (temps de vol).

Per navegació, inicialment només seran dos objectius principals:

1. evitar obstacles
2. reconeix quan està enganxat en algun lloc i no avança. ("progrés" significa que va avançar cap distància significativa)
3. un possible tercer objectiu podria ser que intentés alinear-se directament amb una paret.

Aquest projecte va començar amb un kit de robot i va aconseguir que els moviments bàsics funcionessin mitjançant un teclat i una connexió ssh.

La segona fase consistia a afegir suficients circuits de suport per preparar-se per afegir molts sensors.

A l’anterior Instructable, vam afegir diversos sensors acústics HCSR04 i el robot ara pot evitar obstacles mentre es mou per l’apartament.

Tot i que funciona bé a la cuina i al passadís amb bones superfícies planes sòlides, és totalment cec quan s’apropa al menjador. No pot "veure" la taula i les cames de la cadira.

Una millora pot ser fer un seguiment dels corrents de motor típics i, si els valors salten, el robot ha d’haver colpejat alguna cosa. És un bon "pla B" o fins i tot C. Però això no ajuda realment a navegar pel menjador.

(Actualització: en realitat, de moment, la supervisió actual és el pla A quan es fa la marxa enrere, ja que he eliminat temporalment i els sensors de la part posterior).

El vídeo d'aquesta secció constitueix la fase final dels sensors d'evitació d'obstacles.

El que veieu al vídeo són sis sensors acústics frontals HCSR04 i dos sensors IR Sharp. Els sensors IR no van entrar en joc gaire al vídeo. El seu fort és sobretot quan el robot es troba a la zona de menjador, davant de la taula i les cames de la cadira.

A més dels sensors, el monitor de corrent va entrar en joc especialment durant la marxa enrere, en cas que topés amb alguna cosa.

Finalment, utilitza la història dels darrers 100 moviments i algunes anàlisis bàsiques per respondre a una pregunta:

"Recentment s'ha produït un progrés real (o està encallat en algun ball que es repeteix)?"

Per tant, al vídeo, quan es veu repetir cap endavant-enrere, es gira, vol dir que sí que reconeixia el patró cap endavant-enrere i, per tant, intenta una altra cosa.

L'únic objectiu programat d'aquesta versió del programari era intentar avançar contínuament i evitar obstacles.

Pas 1: afegiu circuits de suport (MCP3008)

Abans d’afegir els sensors IR, necessitarem els circuits d’interfície entre ells i el Raspberry Pi.

Afegirem un convertidor analògic-digital MCP3008. Hi ha molts recursos en línia sobre com connectar aquest xip al Raspberry Pi, de manera que no hi aprofundiré molt.

Essencialment, tenim una opció. Si la versió dels sensors IR funciona a 3V, el MCP3008 també ho pot fer i ens podem connectar directament al gerd.

[Sensor IR 3V] - [MCP3008] - [Raspberrry Pi]

En el meu cas, però, estic executant majoritàriament 5 V, de manera que això significa un canvi de nivell bidireccional.

[Sensor IR 5V] - [MCP3008] - [Bus bidireccional de 5V a 3V] - [Raspberry Pi]

Nota: només hi ha una sortida de senyal del sensor IR. Va directament a una de les línies de senyal analògica d’entrada del MCP3008. Des del MCP3008, hi ha 4 línies de dades que hem de connectar (mitjançant el bus bidireccional) al Raspberry Pi.

De moment, el nostre robot funcionarà amb només dos sensors IR, però fàcilment en podríem afegir més. El MCP3008 vuit canals d'entrada analògica.

Pas 2: muntar els sensors IR

Sharp fabrica diversos sensors IR diferents, i tenen diferents rangs i àrea de cobertura. Vaig haver demanat el model GP2Y0A60SZLF. El model que trieu afectarà la ubicació i l'orientació del sensor. Per desgràcia per a mi, realment no vaig investigar exactament quins sensors aconseguir. Va ser més aviat una decisió "quines puc obtenir a un preu i un temps raonables d'una font de bona reputació, de les que ofereixen"?

(Actualització: no obstant això, potser no importa, ja que aquests sensors semblen confondre's amb la il·luminació ambiental interior. Encara estic explorant aquest problema)

Hi ha almenys tres maneres de muntar aquests sensors al robot.

1. Col·loqueu-los en una posició fixa, a la part frontal, orientats lleugerament els uns dels altres.
2. Col·loqueu-los en un servo, a la part frontal, orientats lleugerament els uns dels altres.
3. Col·loqueu-los en una posició fixa, a la part frontal, però a les cantonades més a l’esquerra i a la dreta, inclinades les unes cap a les altres.

En comparar l’elecció número 1 amb l’elecció número 3, crec que el número 3 cobrirà més de l’àrea de col·lisió. Si doneu una ullada a les imatges, l’elecció número 3 es pot fer no només perquè els camps del sensor es superposin, sinó que també puguin cobrir el centre i més enllà de l’amplada exterior del robot.

Amb l’elecció número 1, com més separats siguin els sensors els uns dels altres, més serà un punt cec al centre.

Podríem fer el número 2, (he afegit algunes imatges amb el servo com a possibilitat) i fer-los fer un escombrat, i òbviament això pot cobrir la major part de l'àrea. Tanmateix, vull retardar l’ús d’un servo el màxim temps possible, per almenys dues raons:

• Farem servir un dels canals de comunicació PWM al Raspberry Pi. (És possible millorar això, però …)
• El consum actual del servo pot ser important
• S’afegeix més al maquinari i al programari

M'agradaria deixar l'opció servo més endavant per afegir-hi sensors més importants, com ara Time-of-Flight (ToF), o potser una càmera.

Hi ha un altre avantatge possible amb l’elecció número 2 que no està disponible amb les altres dues opcions. Aquests sensors IR es poden confondre, segons la il·luminació. Podria ser que el robot obtingui una lectura d’un objecte que sigui imminent a prop quan de fet no hi ha cap objecte proper. Amb l’elecció número 3, ja que els seus camps es poden superposar, tots dos sensors poden registrar el mateix objecte (des de diferents angles).

Així doncs, anem amb l’opció d’ubicació núm. 3.

Pas 3: Temps de prova

Després d’haver fet totes les connexions entre el Raspberry Pi, l’MCP3008 ADC i els sensors Sharp IR, és hora de provar. Només una prova senzilla per assegurar-vos que el sistema funciona amb els nous sensors.

Com en Instructables anteriors, faig servir la biblioteca wiringPi C tant com sigui possible. Facilita les coses. Una cosa que no és molt evident en revisar el lloc web wiringPi és que hi ha assistència directa per a l'MCP3004 / 3008.

Fins i tot sense això, només podríeu utilitzar l'extensió SPI. Però no cal. Si mireu de prop el dipòsit de git de Gordon per a wiringPi, trobareu un llistat de xips compatibles, dels quals un d’ells és per a MCP3004 / 3008.

Vaig decidir adjuntar el codi com a fitxer perquè no podia aconseguir que es visualitzés correctament en aquesta pàgina.

Pas 4: un sensor virtual: AmpSensor

Com més diferents maneres de fer que el robot rebi informació sobre el món exterior, millor serà.

Actualment, el robot té vuit sensors de sonar acústic HCSR04 (no són el focus d’aquest instructable) i ara té dos sensors de distància IR nítids. Com s'ha dit anteriorment, podem aprofitar una altra cosa: la funció de detecció de corrents motors de Roboclaw.

Podem convertir aquesta trucada de consulta al controlador del motor en una classe C ++ i anomenar-la AmpSensor.

En afegir alguns "smarts" al programari, podem controlar i ajustar el corrent típic de corrent durant els moviments rectes (cap endavant, cap enrere) i també els moviments de rotació (esquerra, dreta). Un cop coneixem aquests rangs d'amplificadors, podem seleccionar un valor crític, de manera que si l'AmpSensor obté una lectura actual del controlador del motor que supera aquest valor, sabem que els motors probablement s'han estancat i això sol indicar que el robot s'ha topat. en alguna cosa.

Si afegim una mica de flexibilitat al programari (arguments de línia de comandes i / o entrada de teclat durant el funcionament), podem augmentar / disminuir el llindar dels "amplificadors crítics" mentre experimentem deixant que el robot es mogui i toqui objectes, tots dos rectes o girant.

Atès que la nostra part de navegació del programari coneix la direcció del moviment, podem utilitzar tota aquesta informació per tal d’aturar el moviment i provar d’invertir el moviment durant un breu període de temps abans de provar una altra cosa.

Pas 5: Navegació

Actualment, el robot té una retroalimentació limitada. Té uns quants sensors a distància propera per evitar obstacles, i té una tècnica de reculada per controlar la captació de corrent en cas que els sensors de distància perdin un obstacle.

No té motors amb codificadors i no té una IMU (unitat de mesura inercial), de manera que fa més difícil saber si realment es mou o gira i per quant.

Tot i que es pot obtenir una mena d’indicació de distància amb els sensors que hi ha actualment al robot, el seu camp de visió és ampli i hi ha imprevisibilitat. És possible que el sonar acústic no es reflecteixi correctament; l'infraroig es pot confondre amb altres il·luminacions, o fins i tot amb diverses superfícies reflectants. No estic segur que valgui la pena intentar rastrejar el canvi de distància com a tècnica per saber si el robot es mou i per quant i en quina direcció.

Vaig escollir intencionadament NO utilitzar un microcontrolador com ara un Arduino perquè a) no m'agrada que sigui un entorn psuedo-C ++, b) i que un desenvolupament excessiu gasti la memòria de lectura-escriptura (?), I que necessitaria un ordinador amfitrió per desenvolupar-se (?). O potser em passa com el Raspberry Pi.

El Pi que executa Raspbian, però, no és un sistema operatiu en temps real, de manera que, entre la inestabilitat d’aquests sensors i el sistema operatiu que no llegeix exactament cada vegada, vaig sentir que el propòsit d’aquests sensors era més adequat per evitar obstacles i no mesura de distància real.

Aquest enfocament semblava complicat i amb pocs beneficis, quan podem utilitzar millors sensors ToF (temps de vol) (més endavant) amb aquest propòsit (SLAM).

Un enfocament que podem utilitzar és fer un seguiment de quines ordres de moviment s'han emès durant els darrers X segons o ordres.

Com a exemple, digueu que el robot està enganxat cap a una cantonada en diagonal. Un conjunt de sensors li diu que està massa a prop d’una paret, de manera que pivota, però l’altre conjunt de sensors li diu que és massa a prop de l’altra paret. Acaba repetint un patró de costat a costat.

L'exemple anterior és només un cas molt senzill. Afegir alguns intel·ligents pot augmentar el patró repetit a un nou nivell, però el robot roman atrapat a la cantonada.

Exemple, en lloc de girar endavant i enrere en el seu lloc, gira d'una manera, fa una inversió momentània (que després neteja les indicacions de distància crítica) i, fins i tot si gira en l'altra direcció, encara avança en algun angle cap a la cantonada, repetint un toc més complicat essencialment del mateix.

Això vol dir que realment podríem utilitzar un historial d’ordres i fer una ullada a com explotar i utilitzar aquesta informació.

Se m’acudeixen dues maneres molt bàsiques (rudimentàries) d’utilitzar la història del moviment.

• coincideixen amb el model Y de l'últim nombre de moviments? Un exemple senzill podria ser (i això va passar) "AVANÇAR, REVERSAR, AVANT, REVERSAR, …..". Per tant, hi ha aquesta funció de coincidència que retorna TRUE (patró trobat) o FALSE (no trobat). Si és CERT, a la part de navegació del programa, proveu altres seqüències de moviment.
• per al darrer nombre X de moviments, hi ha un moviment general o net cap endavant. Com es pot determinar què és el moviment real cap endavant? Bé, una fàcil comparació és que per als darrers moviments X, "FORWARD" es produeix més que "REVERSE". Però això no ha de ser l’únic. Què tal això: "DRETA, DRETA, ESQUERRA, DRETA". En aquest cas, el robot ha de fer girs a la dreta per sortir d’una cantonada o perquè s’acostava a la paret en un angle que es podria considerar un progrés real real. D'altra banda, "ESQUERRA, DRETA, ESQUERRA, DRETA …" pot no considerar-se un progrés real real. Per tant, si "DRET" es produeix més que "ESQUERRA" o "ESQUERRA es produeix més que" DRET ", llavors podria ser un progrés real.

Al començament d'aquest instructiu, he esmentat que un possible tercer objectiu podria ser el quadrat o l'alineació a una paret. Per a això, però, necessitem més que "estem a prop d'algun objecte". Per exemple, si podem obtenir dos sensors acústics orientats cap endavant (que no són el focus d’aquest article) per donar respostes raonablement bones i estables respecte a la distància, evidentment si un reporta un valor molt diferent a l’altre, el robot s’ha apropat a la paret en un angle, i podria intentar algunes maniobres per veure si aquests valors s'aproximen (enfrontats directament a la paret).

Pas 6: Pensaments finals, següent fase …

Espero que aquest instructiu doni algunes idees.

Afegir més sensors introdueix alguns avantatges i reptes.

En el cas anterior, tots els sensors acústics funcionaven bé junts i eren força senzills amb el programari.

Un cop introduïts els sensors IR a la barreja, es va convertir en una mica més difícil. La raó és que alguns dels seus camps de visió es van superposar amb els dels sensors acústics. Els sensors IR semblaven una mica sensibles i impredictibles amb les condicions canviants de llum ambiental, mentre que, per descomptat, els sensors acústics no es veuen afectats per la il·luminació.

Per tant, el desafiament consistia en què fer si un sensor acústic ens indica que no hi ha cap obstacle, però sí el sensor IR.

De moment, després de la prova i error, les coses van acabar en aquesta prioritat:

1. sensors d'amplificadors
2. Detecció IR
3. detecció acústica

I el que vaig fer va ser només per reduir la sensibilitat dels sensors IR, de manera que només detectessin objectes molt propers (com ara potes de cadira imminents)

Fins ara, no hi ha hagut cap necessitat de fer cap programa multi-threading o basat en interrupcions, tot i que ocasionalment trobo pèrdues de control entre el Raspberry Pi i el controlador de motor Roboclaw (pèrdua de comunicacions en sèrie).

Aquí és on normalment s’utilitzaria el circuit E-Stop (veure instruccions anteriors). No obstant això, com que no vull (encara) haver de fer front a haver de restablir el Roboclaw durant el desenvolupament, i el robot no va tan de pressa, i estic present per supervisar-lo i apagar-lo, no ho he fet ha connectat l'E-Stop.

Finalment, és probable que sigui necessari fer múltiples fils.

Propers passos…

Gràcies per arribar fins aquí.

Vaig obtenir uns sensors ToF (temps de vol) làser IR VL53L1X, de manera que és probable que sigui el tema de la següent instrucció, juntament amb un servo.