Wallace Autonomous Robot - Del 4 - Lägg till IR -avstånd och "Amp" -sensorer: 6 steg

2024 Författare: John Day | [email protected]. Senast ändrad: 2024-01-30 12:45

Hej, idag börjar vi nästa fas med att förbättra Wallaces kapacitet. Specifikt försöker vi förbättra dess förmåga att upptäcka och undvika hinder med hjälp av infraröda avståndssensorer, och även dra nytta av Roboclaw-motorstyrningens förmåga att övervaka ström och förvandla det till en virtuell (mjukvara) "sensor". Slutligen tar vi en titt på hur man navigerar utan SLAM (samtidig plats och kartläggning) (för närvarande), eftersom roboten ännu inte har en IMU (tröghetsmätningsenhet) eller ToF (flygtid) sensorer.

Med navigering kommer det inledningsvis bara att vara två huvudmål:

1. undvika hinder
2. känner igen när det har fastnat någonstans och inte gör några framsteg. ("framsteg" betyder att det gick framåt på ett meningsfullt avstånd)
3. ett möjligt 3: e mål kan vara att det försöker rikta in sig helt mot en vägg.

Detta projekt började med ett robotkit och fick grundläggande rörelser att fungera med ett tangentbord och ssh -anslutning.

Den andra fasen var att lägga till tillräckligt med stödkretsar för att förbereda införandet av många sensorer.

I föregående Instructable har vi lagt till flera akustiska sensorer HCSR04 och roboten kan nu undvika hinder när den rör sig runt i lägenheten.

Även om det gör det bra i köket och hallen med bra, fasta plana ytor, är det helt blind när man närmar sig matsalen. Det kan inte "se" bordet och stolbenen.

En förbättring kan vara att hålla koll på typiska motorströmmar, och om värdena hoppar måste roboten ha träffat något. Det är en bra "plan B" eller till och med C. Men det hjälper inte riktigt att navigera runt matsalen.

(Uppdatering: faktiskt, för närvarande är strömövervakning plan A vid backning eftersom jag tillfälligt har tagit bort och sensorer bakifrån).

Videon för detta avsnitt utgör den sista fasen av sensorer för att undvika hinder.

Det du ser i videon är sex främre akustiska sensorer HCSR04 och två Sharp IR -sensorer. IR -sensorerna spelade inte in så mycket i videon. Deras styrka är mestadels när roboten befinner sig i matsalen som vetter mot bordet och stolbenen.

Förutom sensorerna kom strömmonitorn till spel, särskilt under backning, om det stöter på något.

Slutligen använder den sig av de senaste 100 dragens historia och några grundläggande analyser för att svara på en fråga:

"Har det nyligen skett riktiga framsteg (eller har det fastnat i någon upprepad dans)?"

Så i videon när du ser en framåt-bakåt upprepad, då vänder den, det betyder att den kände igen fram-bak-mönstret och försöker därmed något annat.

Det enda programmerade målet med denna version av programvaran var att försöka göra kontinuerliga framsteg framåt och försöka undvika hinder.

Steg 1: Lägg till stödkretsar (MCP3008)

Innan vi kan lägga till IR -sensorerna behöver vi gränssnittskretsarna mellan dem och Raspberry Pi.

Vi kommer att lägga till en MCP3008 analog-till-digital-omvandlare. Det finns många online -resurser hur man ansluter detta chip till Raspberry Pi, så jag kommer inte gå in så mycket på det här.

I huvudsak har vi ett val. Om versionen av IR -sensorer fungerar med 3V, så kan MCP3008, och vi kan sedan ansluta direkt till Hallon.

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

I mitt fall kör jag dock mestadels 5V, så det betyder en dubbelriktad nivåväxlare.

[5V IR-sensor]-[MCP3008]-[5V-till-3V dubbelriktad buss]-[Raspberry Pi]

Obs: Det finns bara en signal från IR -sensorn. Den går direkt till en av de analoga ingångssignallinjerna i MCP3008. Från MCP3008 finns det fyra datalinjer vi behöver ansluta (via dubbelriktad buss) till Raspberry Pi.

För närvarande kommer vår robot att köra med bara två IR -sensorer, men vi kan enkelt lägga till fler. MCP3008 åtta analoga ingångskanaler.

Steg 2: Montera IR -sensorer

Sharp tillverkar flera olika IR -sensorer, och de har olika intervall och täckningsområde. Jag råkade ha beställt GP2Y0A60SZLF -modellen. Den modell du väljer påverkar sensorns placering och orientering. Tyvärr för mig undersökte jag inte riktigt vilka sensorer jag skulle få. Det var mer ett "vilka kan jag få till en rimlig tid och pris från en ansedd källa, av de de erbjuder" -beslut.

(Uppdatering: Det kanske inte spelar någon roll, eftersom dessa sensorer tycks bli förvirrade av inre omgivande belysning. Jag utforskar fortfarande den frågan)

Det finns minst tre sätt att montera dessa sensorer på roboten.

1. Placera dem i ett fast läge, framtill, vända något bort från varandra.
2. Lägg dem på en servo på framsidan, vända något bort från varandra.
3. Placera dem i en fast position, längst fram, men längst till vänster och längst längst till höger, vinklade mot varandra.

När jag jämför val #1 med val #3 tror jag att #3 kommer att täcka mer av kollisionsområdet. Om du tittar på bilderna kan val nr 3 göras inte bara så att sensorfälten överlappar varandra, utan också att de kan täcka mitten och bortom robotens yttre bredd.

Med val nr 1 är ju mer isär sensorerna vinklade från varandra, desto mer är en blindpunkt i mitten.

Vi kunde göra #2, (jag lade till några bilder med servo som en möjlighet) och få dem att göra en svepning, och uppenbarligen kan detta täcka det mesta området. Jag vill dock fördröja användningen av en servo så länge som möjligt, av minst två skäl:

• Vi använder en av PWM -kommunikationskanalerna på Raspberry Pi. (Det är möjligt att förbättra detta men ändå …)
• Den nuvarande dragningen med servon kan vara betydande
• Det lägger till mer till hårdvara och programvara

Jag skulle vilja lämna servoalternativet för senare när jag lägger till viktigare sensorer, till exempel Time-of-Flight (ToF), eller kanske en kamera.

Det finns en annan möjlig fördel med val nr 2 som inte är tillgänglig med de andra två alternativen. Dessa IR -sensorer kan bli förvirrade, beroende på belysning. Det kan vara så att roboten avläser ett objekt som är nära förestående när det faktiskt inte finns något objekt i närheten. Med val nr 3, eftersom deras fält kan överlappa varandra, kan båda sensorerna registrera samma objekt (från olika vinklar).

Så vi går med placeringsval #3.

Steg 3: Dags att testa

Efter att vi har gjort alla anslutningar mellan Raspberry Pi, MCP3008 ADC och Sharp IR -sensorerna är det dags att testa. Bara ett enkelt test för att se till att systemet fungerar med de nya sensorerna.

Som i tidigare instruktioner använder jag wiringPi C -biblioteket så mycket som möjligt. Underlättar. Något som inte är särskilt uppenbart från att granska wiringPi -webbplatsen är att det finns direkt stöd för MCP3004/3008.

Även utan det kan du bara använda tillägget SPI. Men det behövs inte. Om du tar en närmare titt på Gordons git -förvar för wiringPi, kommer du att stöta på en lista över chips som stöds, varav en av dem är för MCP3004/3008.

Jag bestämde mig för att bifoga koden som en fil eftersom jag inte kunde få den att visas korrekt på den här sidan.

Steg 4: En virtuell sensor - AmpSensor

Ju fler olika sätt du kan låta roboten ta emot information om omvärlden, desto bättre.

Roboten har för närvarande åtta HCSR04 akustiska ekolodsgivare (de är inte i fokus för denna instruerbara), och den har nu två Sharp IR -avståndssensorer. Som tidigare nämnts kan vi dra nytta av något annat: Roboclaws motorströmavkänningsfunktion.

Vi kan linda det förfrågningsanropet till motorstyrenheten till en C ++-klass och kalla det en AmpSensor.

Genom att lägga till några "smarts" i programvaran kan vi övervaka och justera typiskt strömdrag under rak rörelse (framåt, bakåt), och även rotationsrörelser (vänster, höger). När vi väl känner till dessa intervall av ampere kan vi välja ett kritiskt värde, så att om AmpSensorn får en strömavläsning från motorstyrenheten som överstiger detta värde, vet vi att motorerna förmodligen har stannat, och det indikerar vanligtvis att roboten har stött på in i något.

Om vi lägger till lite flexibilitet i programvaran (kommandoradsargument och / eller tangentbordsinmatning under drift) kan vi öka / minska tröskeln för "kritiska förstärkare" när vi experimenterar genom att bara låta roboten röra sig och stöta på objekt, både rakt in, eller när du roterar.

Eftersom vår navigeringsdel av programvaran känner till rörelseriktningen kan vi använda all den informationen för att kanske stoppa rörelsen och försöka vända rörelsen under en kort period innan vi försöker något annat.

Steg 5: Navigering

Roboten är för närvarande begränsad i verklig feedback. Den har några sensorer på nära avstånd för att undvika hinder, och den har en back-back-teknik för att övervaka strömdragning om avståndssensorerna missar ett hinder.

Den har inte motorer med givare och den har inte en IMU (tröghetsmätningsenhet), så det gör det svårare att veta om den verkligen rör sig eller roterar, och hur mycket.

Även om man kan få någon slags indikation på avstånd med sensorerna som för närvarande finns på roboten, är deras synfält brett och det finns oförutsägbarhet. Det akustiska ekolodet reflekteras kanske inte korrekt; infrarött kan förväxlas med annan belysning, eller till och med flera reflekterande ytor. Jag är inte säker på att det är värt besväret att faktiskt försöka spåra förändringen i avstånd som en teknik för att veta om roboten rör sig och hur mycket och i vilken riktning.

Jag valde avsiktligt att INTE använda en mikrokontroller som en Arduino eftersom a) jag inte gillar den psuedo-C ++-miljön, b) och att för mycket utveckling kommer att slita ut läs-skrivminnet (?), Och att jag skulle behöva en värddator för att utveckla (?). Eller kanske jag bara händer som Raspberry Pi.

Pi som kör Raspbian är dock inte ett operativsystem i realtid, så mellan dessa sensorers instabilitet och operativsystemet som inte läser exakt varje gång kände jag att syftet med dessa sensorer var bättre lämpad för att undvika hinder och inte verklig avståndsmätning.

Det tillvägagångssättet verkade komplicerat och med inte så stor nytta, när vi kan använda bättre ToF (time-of-flight) sensorer (senare) för detta ändamål (SLAM).

Ett tillvägagångssätt som vi kan använda är att hålla koll på vilka rörelsekommandon som har utfärdats under de senaste X sekunderna eller kommandona.

Som ett exempel, säg att roboten har fastnat mot ett hörn diagonalt. En uppsättning sensorer berättar att den är för nära en vägg, så den svänger, men sedan säger den andra uppsättningen sensorer att den är för nära den andra väggen. Det slutar bara med att upprepa ett mönster från sida till sida.

Ovanstående exempel är bara ett mycket enkelt fall. Att lägga till några smarts kan bara höja det upprepade mönstret till en ny nivå, men roboten förblir fast i hörnet.

Exempel, istället för att rotera fram och tillbaka på plats, roterar det åt ett håll, gör ett ögonblick bakåt (vilket sedan rensar de kritiska avståndsindikationerna), och även om det roterar i den andra riktningen, går det fortfarande framåt i någon vinkel bakåt i hörnet, upprepa ett mer komplicerat mönster av i huvudsak samma sak.

Det betyder att vi verkligen kan använda en historik av kommandon och ta en titt på hur vi kan utnyttja och använda den informationen.

Jag kan tänka mig två mycket grundläggande (rudimentära) sätt att använda rörelseshistorien.

• för det sista X -antalet drag, matchar de Y -mönstret. Ett enkelt exempel kan vara (och detta hände) "FRAMÅT, BAKTA, FRAMÅT, BAKA, …". Så det finns denna matchningsfunktion som returnerar antingen SANT (mönster hittat) eller FALSKT (hittades inte). Om SANT, i navigationsdelen av programmet, försök med andra rörelserekvenser.
• för det sista X -antalet drag, finns det en allmän eller nettoförflyttning framåt. Hur kan man avgöra vad som är verklig rörelse framåt? Tja.. en enkel jämförelse är att för de sista X -rörelserna förekommer "FRAMÅT" mer än "BACK". Men det behöver inte vara det enda. Vad sägs om detta: "HÖGER, HÖGER, VÄNSTER, HÖGER". I så fall måste roboten göra höger svängar för att komma ur ett hörn eller för att den närmade sig väggen i en vinkel, det kan betraktas som verkliga framsteg. Å andra sidan kanske "VÄNSTER, HÖGER, VÄNSTER, HÖGER …" inte anses vara verkliga framsteg. Således, om "HÖGER" förekommer mer än "VÄNSTER", eller "VÄNSTER förekommer mer än" HÖGER ", kan det vara verkliga framsteg.

I början av denna instruktionsbok nämnde jag att ett möjligt tredje mål kan vara att kvadrera upp eller anpassa sig till en vägg. För det behöver vi dock mer än "är vi nära något objekt". Till exempel, om vi kan få två framåtriktade akustiska sensorer (inte fokus för den här artikeln) för att ge någorlunda bra, stabila svar när det gäller avstånd, uppenbarligen om den ena rapporterar ett mycket annorlunda värde än den andra, har roboten närmat sig väggen i en vinkel, och kan försöka manövrera för att se om dessa värden närmar sig varandra (mot väggen helt).

Steg 6: Slutliga tankar, nästa fas …

Hoppas att denna instruktör gav några idéer.

Att lägga till fler sensorer introducerar några fördelar och utmaningar.

I ovanstående fall fungerade alla akustiska sensorer bra tillsammans och det var ganska rakt fram med programvaran.

När IR -sensorerna väl introducerades i mixen blev det lite mer utmanande. Anledningen är att några av deras synfält överlappar dem med de akustiska sensorerna. IR-sensorerna verkade lite känsliga och oförutsägbara med förändrade omgivande ljusförhållanden, medan de akustiska sensorerna naturligtvis inte påverkas av belysning.

Och så var utmaningen vad man ska göra om en akustisk sensor berättar att det inte finns något hinder, men IR -sensorn är det.

För närvarande, efter försök och fel, hamnade saker i denna prioritet:

1. förstärkare
2. IR-avkänning
3. akustisk avkänning

Och det jag gjorde var bara att sänka känsligheten hos IR -sensorerna, så att de bara skulle upptäcka mycket nära föremål (som överhängande stolben)

Hittills har det inte varit nödvändigt att göra någon multi-threading eller avbrottsdriven programvara, även om jag ibland stöter på förlust av kontroll mellan Raspberry Pi och Roboclaw motorstyrenhet (förlust av seriell kommunikation).

Det är här E-Stop-kretsen (se tidigare instruktioner) normalt skulle tas i bruk. Men eftersom jag inte (ännu) vill behöva hantera att behöva återställa Roboclaw under utvecklingen, och roboten inte går så snabbt, och jag är närvarande för att övervaka och stänga av det, har jag inte gjort det anslutit E-Stop.

Så småningom kommer troligtvis multi-threading att vara nödvändig.

Nästa steg…

Tack för att du tog dig så här långt.

Jag skaffade några VL53L1X IR laser ToF (time-of-flight) sensorer, så det är troligen ämnet för nästa Instructable, tillsammans med en servo.