Wallace Autonomous Robot - Del 4 - Legg til IR -avstands- og "Amp" -sensorer: 6 trinn

2024 Forfatter: John Day | [email protected]. Sist endret: 2024-01-30 11:24

Hei, i dag starter vi neste fase med å forbedre Wallaces evner. Spesielt prøver vi å forbedre evnen til å oppdage og unngå hindringer ved hjelp av infrarøde avstandssensorer, og også dra nytte av Roboclaw motorstyrings evne til å overvåke strøm og gjøre den til en virtuell (programvare) "sensor". Til slutt tar vi en titt på hvordan du navigerer uten SLAM (samtidig plassering og kartlegging) (foreløpig), siden roboten ennå ikke har en IMU (treghetsmåleenhet) eller ToF (flytid).

Ved navigasjon vil det i utgangspunktet bare være to hovedmål:

1. unngå hindringer
2. gjenkjenne når den sitter fast et sted og ikke gjør noen fremgang. ("fremgang" betyr at den gikk fremover noen meningsfull avstand)
3. et mulig tredje mål kan være at det prøver å justere seg helt til en vegg.

Dette prosjektet begynte med et robotsett og få grunnleggende bevegelser til å fungere ved hjelp av et tastatur og ssh -tilkobling.

Den andre fasen var å legge til tilstrekkelig støttekrets for å forberede tillegg av mange sensorer.

I forrige Instructable la vi til flere HCSR04 akustiske sensorer, og roboten kan nå unngå hindringer når den beveger seg rundt i leiligheten.

Selv om det gjør det bra på kjøkkenet og gangen med gode, solide flate overflater, er det helt blind når du nærmer deg spisestuen. Det kan ikke "se" bord- og stolbena.

En forbedring kan være å holde oversikt over typiske motorstrømmer, og hvis verdiene hopper, må roboten ha truffet noe. Det er en god "plan B" eller til og med C. Men det hjelper egentlig ikke det å navigere rundt i spisestuen.

(Oppdatering: for øyeblikket er strømovervåking plan A ved reversering da jeg midlertidig har fjernet og sensorer bakfra).

Videoen for denne seksjonen er den siste fasen av hindringssensorer.

Det du ser i videoen er seks akustiske sensorer foran HCSR04 og to skarpe IR -sensorer. IR -sensorene spilte ikke mye inn i videoen. Forten deres er stort sett når roboten befinner seg i spisestuen mot bord og stolben.

I tillegg til sensorene kom strømmonitoren til spill, spesielt under reversering, hvis den støter på noe.

Til slutt bruker den historien til de siste 100 trekkene, og noen grunnleggende analyser for å svare på ett spørsmål:

"Har det nylig vært virkelig fremgang (eller er det fast i noen gjentagende dans)?"

Så i videoen når du ser en fremover-bakover gjentatt, så snur den, det betyr at den gjenkjente mønsteret forover-bakover, og dermed prøver noe annet.

Det eneste programmerte målet med denne versjonen av programvaren var å prøve å gjøre kontinuerlige fremskritt fremover, og prøve å unngå hindringer.

Trinn 1: Legg til støttekretser (MCP3008)

Før vi kan legge til IR -sensorene, trenger vi grensesnittkretsene mellom dem og Raspberry Pi.

Vi vil legge til en MCP3008 analog-til-digital-omformer. Det er mange elektroniske ressurser for hvordan du kan koble denne brikken til Raspberry Pi, så jeg skal ikke gå så mye inn på det her.

I hovedsak har vi et valg. Hvis versjonen av IR -sensorer fungerer på 3V, kan MCP3008 også, og vi kan deretter koble til bringebæret direkte.

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

I mitt tilfelle kjører jeg imidlertid for det meste 5V, så det betyr en toveis nivåskifter.

[5V IR-sensor]-[MCP3008]-[5V-til-3V toveis buss]-[Raspberry Pi]

Merk: Det er bare ett signal fra IR -sensoren. Den går direkte til en av de analoge inngangssignallinjene til MCP3008. Fra MCP3008 er det 4 datalinjer vi må koble (via toveis bussen) til Raspberry Pi.

For øyeblikket kommer roboten til å kjøre med bare to IR -sensorer, men vi kan enkelt legge til flere. MCP3008 åtte analoge inngangskanaler.

Trinn 2: Monter IR -sensorer

Sharp lager flere forskjellige IR -sensorer, og de har forskjellige områder og dekningsområde. Jeg har tilfeldigvis bestilt modellen GP2Y0A60SZLF. Modellen du velger vil påvirke plasseringen og retningen til sensoren. Dessverre for meg undersøkte jeg ikke nøyaktig hvilke sensorer jeg skulle få. Det var mer en "hvilke kan jeg få til en rimelig tid og pris fra en anerkjent kilde, ut av de de tilbyr" -avgjørelsen.

(Oppdatering: Det kan imidlertid ikke ha noen betydning, da disse sensorene ser ut til å bli forvirret av innvendig omgivelsesbelysning. Jeg utforsker fortsatt dette problemet)

Det er minst tre måter å montere disse sensorene på roboten.

1. Plasser dem i en fast posisjon, foran, vendt litt bort fra hverandre.
2. Legg dem på en servo foran, vendt litt bort fra hverandre.
3. Plasser dem i en fast posisjon, foran, men lengst til høyre og lengst lengst, vinklet mot hverandre.

Ved å sammenligne valg nr. 1 med valg nr. 3, tror jeg at nr. 3 vil dekke mer av kollisjonsområdet. Hvis du tar en titt på bildene, kan valg nr. 3 gjøres ikke bare slik at sensorfeltene overlapper hverandre, men også de kan dekke midten og utenfor robotens utvendige bredde.

Med valg nr. 1, jo mer fra hverandre er sensorene vinklet fra hverandre, jo mer er en blind flekk i midten.

Vi kunne gjøre nr. 2, (jeg la til noen bilder med servo som en mulighet) og få dem til å feie, og dette kan åpenbart dekke det meste av området. Imidlertid vil jeg utsette bruken av en servo så lenge som mulig, av minst to grunner:

• Vi bruker en av PWM -kommunikasjonskanalene på Raspberry Pi. (Det er mulig å forbedre dette, men likevel …)
• Den nåværende trekningen med servoen kan være betydelig
• Det legger mer til maskinvare og programvare

Jeg vil gjerne forlate servo-alternativet for senere når jeg legger til flere viktige sensorer, for eksempel Time-of-Flight (ToF), eller kanskje et kamera.

Det er en annen mulig fordel med valg nr. 2 som ikke er tilgjengelig med de to andre valgene. Disse IR -sensorene kan bli forvirret, avhengig av belysningen. Det kan være at roboten får en avlesning av et objekt som er nært nært når det faktisk ikke er noen objekt i nærheten. Med valg nr. 3, siden feltene deres kan overlappe hverandre, kan begge sensorene registrere det samme objektet (fra forskjellige vinkler).

Så vi går med plasseringsvalg nr. 3.

Trinn 3: Tid til å teste

Etter at vi har gjort alle forbindelsene mellom Raspberry Pi, MCP3008 ADC og Sharp IR -sensorene, er det på tide å teste. Bare en enkel test for å sikre at systemet fungerer med de nye sensorene.

Som i tidligere instrukser, bruker jeg wiringPi C -biblioteket så mye som mulig. Gjør ting lettere. Noe som ikke er veldig åpenbart ved å gjennomgå wiringPi -nettstedet, er at det er direkte støtte for MCP3004/3008.

Selv uten det kan du bare bruke SPI -utvidelsen. Men det er ikke nødvendig. Hvis du ser nærmere på Gordons git -depot for wiringPi, kommer du over en liste over støttede sjetonger, hvorav en av dem er for MCP3004/3008.

Jeg bestemte meg for å legge ved koden som en fil fordi jeg ikke kunne få den til å vises riktig på denne siden.

Trinn 4: En virtuell sensor - AmpSensor

Jo flere forskjellige måter du kan få roboten til å motta informasjon om omverdenen, desto bedre.

Roboten har for tiden åtte HCSR04 akustiske ekkoloddssensorer (de er ikke i fokus for denne Instructable), og den har nå to Sharp IR -avstandssensorer. Som nevnt tidligere kan vi dra nytte av noe annet: Roboclaws motorstrømfølerfunksjon.

Vi kan pakke forespørselsanropet til motorstyringen inn i en C ++-klasse og kalle det en AmpSensor.

Ved å legge til noen "smarts" i programvaren, kan vi overvåke og justere typisk strømtrekk under rette bevegelser (fremover, bakover), og også rotasjonsbevegelser (venstre, høyre). Når vi kjenner disse områdene av forsterkere, kan vi velge en kritisk verdi, slik at hvis AmpSensor får en strømavlesning fra motorstyringen som overstiger denne verdien, vet vi at motorene trolig har stoppet, og det indikerer vanligvis at roboten har støtt inn i noe.

Hvis vi legger til litt fleksibilitet til programvaren (kommandolinjearg og / eller tastaturinngang under drift), kan vi øke / redusere terskelen for "kritiske forsterkere" mens vi eksperimenterer ved å bare la roboten bevege seg og støte på objekter, både rett inn, eller mens du roterer.

Siden vår navigasjonsdel av programvaren kjenner bevegelsesretningen, kan vi bruke all den informasjonen til å kanskje stoppe bevegelsen og prøve å reversere bevegelsen i en kort periode før vi prøver noe annet.

Trinn 5: Navigasjon

Roboten er for øyeblikket begrenset i virkelige tilbakemeldinger. Den har noen få nærdistanse sensorer for hindring av hindringer, og den har en tilbakeslagsteknikk for å overvåke strømtrekk hvis avstandssensorene skulle gå glipp av et hinder.

Den har ikke motorer med kodere, og den har ikke en IMU (inertial-måleenhet), så det gjør det vanskeligere å vite om den virkelig beveger seg eller roterer, og hvor mye.

Selv om man kan få en slags indikasjon på avstand med sensorene som for øyeblikket er på roboten, er synsfeltet bredt og det er uforutsigbarhet. Den akustiske ekkoloddet reflekterer kanskje ikke riktig tilbake; infrarød kan forveksles med annen belysning, eller til og med flere reflekterende overflater. Jeg er ikke sikker på at det er verdt bryet å faktisk prøve å spore endringen i avstand som en teknikk for å vite om roboten beveger seg og hvor mye og i hvilken retning.

Jeg valgte bevisst å IKKE bruke en mikrokontroller som en Arduino fordi a) jeg ikke liker det psuedo-C ++ miljøet, b) og at for mye utvikling vil slite ut skrive-skrive-minnet (?), Og at jeg trenger en vertsmaskin for å utvikle (?). Eller kanskje jeg bare skjer som Raspberry Pi.

Pi som kjører Raspbian er imidlertid ikke et sanntids-operativsystem, så mellom disse sensorernes ustabilitet og operativsystemet som ikke leser nøyaktig hver gang, følte jeg at formålet med disse sensorene var bedre egnet for hindring av hindringer og ikke faktisk avstandsmåling.

Denne tilnærmingen virket komplisert og med ikke så stor fordel, når vi kan bruke bedre ToF (time-of-flight) sensorer (senere) til det formålet (SLAM).

En tilnærming vi kan bruke er å holde oversikt over hvilke bevegelseskommandoer som er blitt utstedt i løpet av de siste X sekundene eller kommandoene.

Som et eksempel, si at roboten sitter fast vendt mot et hjørne diagonalt. Ett sett med sensorer forteller det at det er for nær den ene veggen, så det svinger, men så forteller det andre settet med sensorer at det er for nær den andre veggen. Det ender opp med å bare gjenta et side-til-side-mønster.

Eksemplet ovenfor er bare en veldig enkel sak. Å legge til noen smarte kan bare heve det gjentatte mønsteret til et nytt nivå, men roboten forblir fast i hjørnet.

Eksempel, i stedet for å rotere frem og tilbake på plass, roterer den en vei, gjør øyeblikkelig revers (som deretter fjerner de kritiske avstandsindikasjonene), og selv om den roterer i den andre retningen, går den fremover i en vinkel tilbake i hjørnet, gjentar en mer komplisert mønster av egentlig det samme.

Det betyr at vi virkelig kan bruke en historie med kommandoer, og ta en titt på hvordan vi kan utnytte og bruke denne informasjonen.

Jeg kan tenke meg to helt grunnleggende (rudimentære) måter å bruke bevegelseshistorien på.

• for de siste X antall trekk, stemmer de overens med Y -mønsteret. Et enkelt eksempel kan være (og dette skjedde) "FREM, REVERSE, FORWARD, REVERSE, …..". Så det er denne matchende funksjonen som returnerer enten SANN (mønster funnet) eller FALSK (ikke funnet). Hvis SANN, i navigasjonsdelen av programmet, prøv andre bevegelsessekvenser.
• for det siste X -antallet trekk, er det en generell eller netto fremoverbevegelse. Hvordan kan man avgjøre hva som er ekte bevegelse fremover? Vel.. en enkel sammenligning er at for de siste X -trekkene skjer "FORWARD" mer enn "REVERSE". Men det trenger ikke å være den eneste. Hva med dette: "HØYRE, HØYRE, VENSTRE, HØYRE". I så fall må roboten ta høyresving for å komme seg ut av et hjørne eller fordi den nærmet seg veggen i en vinkel, noe som kan betraktes som virkelig fremgang. På den annen side kan det hende at "VENSTRE, HØYRE, VENSTRE, HØYRE …" ikke regnes som virkelig fremgang. Så hvis "RIGHT" forekommer mer enn "LEFT", eller "LEFT forekommer mer enn" RIGHT ", kan det være reell fremgang.

I begynnelsen av denne instruksjonsboken nevnte jeg at et mulig tredje mål kan være å firkantes eller justere til en vegg. For det trenger vi imidlertid mer enn "er vi i nærheten av et objekt". For eksempel, hvis vi kan få to fremovervendte akustiske sensorer (ikke fokuset på denne artikkelen) for å gi rimelig gode, stabile svar angående avstand, er det åpenbart at hvis den ene rapporterer en mye annen verdi enn den andre, har roboten nærmet seg veggen på skrå, og kan prøve å manøvrere for å se om disse verdiene nærmer seg hverandre (vendt mot veggen helt).

Trinn 6: Avsluttende tanker, neste fase …

Håper denne instruksjonsboken ga noen ideer.

Å legge til flere sensorer introduserer noen fordeler og utfordringer.

I tilfellet ovenfor fungerte alle de akustiske sensorene godt sammen, og det var ganske rett frem med programvaren.

Når IR -sensorene ble introdusert i blandingen, ble det litt mer utfordrende. Årsaken er at noen av deres synsfelt overlapper dem med de akustiske sensorene. IR-sensorene virket litt følsomme og uforutsigbare med endrede omgivelseslysforhold, mens selvfølgelig de akustiske sensorene ikke påvirkes av belysning.

Og så var utfordringen hva vi skulle gjøre hvis en akustisk sensor forteller oss at det ikke er noen hindring, men IR -sensoren er det.

For nå, etter prøving og feiling, endte ting i denne prioriteten:

1. amp-sensing
2. IR-sensing
3. akustisk sensing

Og det jeg gjorde var bare å senke sensitiviteten til IR -sensorene, slik at de bare ville oppdage svært nære objekter (for eksempel forestående stolbein)

Så langt har det ikke vært behov for å gjøre programvare med flere tråder eller avbrudd, selv om jeg av og til støter på tap mellom Raspberry Pi og Roboclaw motorstyring (tap av seriell kommunikasjon).

Det er her E-Stop-kretsen (se tidligere instrukser) normalt ville komme i bruk. Siden jeg imidlertid ikke ønsker (ennå) å måtte forholde meg til å måtte nullstille Roboclaw under utviklingen, og roboten ikke går så fort, og jeg er tilstede for å overvåke den og slå den av, har jeg ikke koblet til E-Stop.

Etter hvert vil multitråding mest sannsynlig være nødvendig.

Neste skritt…

Takk for at du kom så langt.

Jeg skaffet meg noen VL53L1X IR laser ToF (time-of-flight) sensorer, så det er mest sannsynlig temaet for den neste Instructable, sammen med en servo.