Wallace Autonomous Robot - Del 4 - Tilføj IR -afstand og "Amp" sensorer: 6 trin

2024 Forfatter: John Day | [email protected]. Sidst ændret: 2024-01-30 08:29

Hej, i dag starter vi den næste fase med at forbedre Wallaces muligheder. Helt konkret forsøger vi at forbedre dens evne til at opdage og undgå forhindringer ved hjælp af infrarøde distancesensorer og også drage fordel af Roboclaw-motorstyringens evne til at overvåge strøm og gøre det til en virtuel (software) "sensor". Endelig tager vi et kig på, hvordan man navigerer uden SLAM (samtidig placering og kortlægning) (for nu), da robotten endnu ikke har en IMU (inertimåleenhed) eller ToF (flyvetid) sensorer.

Ved navigation vil det i første omgang bare være to hovedmål:

1. undgå forhindringer
2. genkende, når det sidder fast et sted og ikke gør fremskridt. ("fremskridt" betyder, at det gik fremad nogen betydningsfuld afstand)
3. et muligt 3. mål kan være, at det prøver at justere sig helt til en væg.

Dette projekt begyndte med et robotsæt og fik grundlæggende bevægelser til at fungere ved hjælp af et tastatur og ssh -forbindelse.

Den anden fase var at tilføje tilstrækkelig understøttende kredsløb til at forberede tilføjelse af mange sensorer.

I den forrige Instructable tilføjede vi flere HCSR04 akustiske sensorer, og robotten kan nu undgå forhindringer, når den bevæger sig rundt i lejligheden.

Selvom den klarer sig godt i køkkenet og gangen med gode, solide flade overflader, er den totalt blind, når den nærmer sig spisestuen. Det kan ikke "se" bordet og stolens ben.

En forbedring kan være at holde styr på typiske motorstrømme, og hvis værdierne hopper, så må robotten have ramt noget. Det er en god "plan B" eller endda C. Men det hjælper ikke rigtigt med at navigere rundt i spisepladsen.

(Opdatering: faktisk, for øjeblikket er strømovervågning plan A, når jeg bakker, da jeg midlertidigt har fjernet og sensorer bagfra).

Videoen til dette afsnit udgør den sidste fase af forhindringssensorer.

Det, du ser i videoen, er seks akustiske sensorer foran HCSR04 og to skarpe IR -sensorer. IR -sensorerne kom ikke meget i spil i videoen. Deres forte 'er mest, når robotten befinder sig i spisestuen mod bord og stoleben.

Ud over sensorerne kom strømmonitoren i spil især under bakning, hvis den støder på noget.

Endelig udnytter den historien om de sidste 100 træk og nogle grundlæggende analyser til at besvare et spørgsmål:

"Har der for nylig været en reel fremgang (eller sidder den fast i en eller anden gentagende dans)?"

Så i videoen, når du ser en frem-tilbage-gentagelse, så vender den, det betyder, at den genkendte frem-tilbage-mønsteret og dermed prøver noget andet.

Det eneste programmerede mål med denne version af softwaren var at forsøge at gøre kontinuerlige fremskridt fremad og forsøge at undgå forhindringer.

Trin 1: Tilføj understøttende kredsløb (MCP3008)

Inden vi kan tilføje IR -sensorerne, skal vi bruge interfacekredsløbene mellem dem og Raspberry Pi.

Vi tilføjer en MCP3008 analog-til-digital-konverter. Der er mange online ressourcer til, hvordan man forbinder denne chip med Raspberry Pi, så det vil jeg ikke gå meget op i her.

Grundlæggende har vi et valg. Hvis versionen af IR -sensorer fungerer ved 3V, kan MCP3008 også, og vi kan derefter oprette forbindelse direkte til Raspberry.

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

I mit tilfælde kører jeg dog mest 5V, så det betyder en tovejs niveauskifter.

[5V IR-sensor]-[MCP3008]-[5V-til-3V tovejs bus]-[Raspberry Pi]

Bemærk: Der udsendes kun et signal fra IR -sensoren. Den går direkte til en af input analoge signallinjer i MCP3008. Fra MCP3008 er der 4 datalinjer, vi skal forbinde (via tovejsbussen) til Raspberry Pi.

I øjeblikket vil vores robot køre med kun to IR -sensorer, men vi kan sagtens tilføje flere. MCP3008 otte analoge indgangskanaler.

Trin 2: Monter IR -sensorer

Sharp laver flere forskellige IR -sensorer, og de har forskellige områder og dækningsområde. Jeg har tilfældigvis bestilt modellen GP2Y0A60SZLF. Den model, du vælger, påvirker sensorens placering og orientering. Desværre for mig undersøgte jeg ikke rigtigt, hvilke sensorer der skulle hentes. Det var mere en "hvilke kan jeg få til en rimelig tid og pris fra en velrenommeret kilde ud af dem, de tilbyder" -beslutningen.

(Opdatering: Det er dog måske ikke noget, da disse sensorer ser ud til at blive forvirrede af indendørs omgivende belysning. Jeg undersøger stadig dette problem)

Der er mindst tre måder at montere disse sensorer på robotten.

1. Placer dem i en fast position foran, vendt lidt væk fra hinanden.
2. Læg dem på en servo foran, vendt lidt væk fra hinanden.
3. Placer dem i en fast position foran, men i de yderste hjørner længst til højre og længst, vinklet mod hinanden.

Ved at sammenligne valg nr. 1 med valg nr. 3, tror jeg, at nr. 3 dækker mere af kollisionsområdet. Hvis du kigger på billederne, kan valg nr. 3 ikke kun gøres, så sensorfelterne overlapper hinanden, men også de kan dække midten og ud over robotens udvendige bredde.

Med valg nr. 1, jo mere adskilte sensorerne er fra hinanden, jo mere er en blind plet i midten.

Vi kunne gøre #2, (jeg tilføjede nogle billeder med servo som en mulighed) og få dem til at feje, og det kan naturligvis dække det meste område. Jeg vil dog forsinke brugen af en servo så længe som muligt af mindst to grunde:

• Vi bruger en af PWM -kommunikationskanalerne på Raspberry Pi. (Det er muligt at forbedre dette, men stadig …)
• Den nuværende trækning med servoen kan være betydelig
• Det tilføjer mere til hardware og software

Jeg vil gerne forlade servomuligheden til senere, når jeg tilføjer vigtigere sensorer, f.eks. Time-of-Flight (ToF) eller måske et kamera.

Der er en anden mulig fordel med valg nr. 2, der ikke er tilgængelig med de to andre valg. Disse IR -sensorer kan blive forvirrede, afhængigt af belysningen. Det kan være, at robotten får en aflæsning af et objekt, der umiddelbart er tæt på, når der faktisk ikke er et objekt i nærheden. Med valg nr. 3, da deres felter kan overlappe hinanden, kan begge sensorer registrere det samme objekt (fra forskellige vinkler).

Så vi går med placeringsvalg #3.

Trin 3: Tid til test

Efter at vi har lavet alle forbindelserne mellem Raspberry Pi, MCP3008 ADC og Sharp IR -sensorerne, er det tid til at teste. Bare en simpel test for at sikre, at systemet fungerer med de nye sensorer.

Som i tidligere instruktioner bruger jeg wiringPi C -biblioteket så meget som muligt. Gør tingene lettere. Noget, der ikke er særlig indlysende ved at gennemgå wiringPi -webstedet, er, at der er direkte support til MCP3004/3008.

Selv uden det kunne du bare bruge SPI -udvidelsen. Men det er ikke nødvendigt. Hvis du ser nærmere på Gordons git -lager til wiringPi, støder du på en liste over understøttede chips, hvoraf en af dem er til MCP3004/3008.

Jeg besluttede at vedhæfte koden som en fil, fordi jeg ikke kunne få den til at blive vist korrekt på denne side.

Trin 4: En virtuel sensor - AmpSensor

Jo flere forskellige måder du kan få robotten til at modtage information om omverdenen, jo bedre.

Robotten har i øjeblikket otte HCSR04 akustiske ekkolodssensorer (de er ikke i fokus for denne Instructable), og den har nu to Sharp IR -afstandssensorer. Som tidligere nævnt kan vi drage fordel af noget andet: Roboclaws motorstrømfølerfunktion.

Vi kan pakke dette forespørgselskald til motor-controlleren ind i en C ++-klasse og kalde det en AmpSensor.

Ved at tilføje nogle "smarts" til softwaren kan vi overvåge og justere typisk strømtrækning under lige bevægelse (fremad, baglæns) og også rotationsbevægelser (venstre, højre). Når vi kender disse forstærkningsområder, kan vi vælge en kritisk værdi, så hvis AmpSensor får en strømaflæsning fra motor-controlleren, der overstiger denne værdi, ved vi, at motorerne sandsynligvis er gået i stå, og det indikerer normalt, at robotten er stødt ind i noget.

Hvis vi tilføjer en vis fleksibilitet til softwaren (kommandolinjearg og / eller tastaturindgang under drift), kan vi øge / reducere tærsklen for "kritiske forstærkere", mens vi eksperimenterer ved blot at lade robotten bevæge sig og støde på objekter, både lige ind, eller mens du roterer.

Da vores navigationsdel af softwaren kender bevægelsesretningen, kan vi bruge al den information til måske at stoppe bevægelsen og prøve at vende bevægelsen i en kort periode, inden vi prøver noget andet.

Trin 5: Navigation

Robotten er i øjeblikket begrænset i feedback fra den virkelige verden. Det har et par nærdistandsfølere til forhindring af forhindringer, og det har en tilbagefaldsteknik til overvågning af strømtrækning, hvis afstandssensorerne savner en forhindring.

Den har ikke motorer med encodere, og den har ikke en IMU (inertial-måleenhed), så det gør det vanskeligere at vide, om den virkelig bevæger sig eller roterer, og hvor meget.

Selvom man kan få en slags indikation af afstand med de sensorer, der aktuelt er på robotten, er deres synsfelt bredt, og der er uforudsigelighed. Den akustiske ekkolod reflekterer muligvis ikke korrekt tilbage; infrarød kan forveksles med anden belysning eller endda flere reflekterende overflader. Jeg er ikke sikker på, at det er besværet værd at faktisk prøve at spore ændringen i afstand som en teknik til at vide, om robotten bevæger sig, og hvor meget og i hvilken retning.

Jeg valgte med vilje IKKE at bruge en mikro-controller som f.eks. En Arduino, fordi a) jeg ikke kan lide det psuedo-C ++ miljø, b) og at for meget udvikling vil slide læse-skrive hukommelsen (?), Og at jeg skulle bruge en værtscomputer til at udvikle (?). Eller måske sker jeg bare som Raspberry Pi.

Pi'en, der kører Raspbian, er imidlertid ikke et real-time operativsystem, så mellem disse sensorers ustabilitet og operativsystemet, der ikke læser nøjagtigt hver gang, følte jeg, at formålet med disse sensorer var bedre egnet til forhindring af forhindringer og ikke faktisk afstandsmåling.

Denne tilgang syntes kompliceret og med ikke så stor fordel, når vi kan bruge bedre ToF (time-of-flight) sensorer (senere) til det formål (SLAM).

En tilgang, som vi kan bruge, er at holde en form for spor af, hvilke bevægelseskommandoer der er blevet udsendt inden for de sidste X sekunder eller kommandoer.

Sig som et eksempel, at robotten sidder fast mod et hjørne diagonalt. Det ene sæt sensorer fortæller det, at det er for tæt på den ene væg, så det svinger, men så fortæller det andet sæt sensorer, at det er for tæt på den anden væg. Det ender med bare at gentage et mønster fra side til side.

Ovenstående eksempel er blot en meget enkel sag. Tilføjelse af nogle smarts kan bare hæve det gentagne mønster til et nyt niveau, men robotten forbliver fast i hjørnet.

Eksempel, i stedet for at rotere frem og tilbage på plads, roterer den en vej, gør kortvarig omvendt (som derefter sletter de kritiske afstandsindikationer), og selvom den roterer i den anden retning, går den stadig fremad i en eller anden vinkel tilbage i hjørnet, gentagelse af et mere kompliceret mønster af stort set det samme.

Det betyder, at vi virkelig kunne bruge en historik med kommandoer og se på, hvordan vi kan udnytte og bruge disse oplysninger.

Jeg kan tænke på to meget grundlæggende (rudimentære) måder at bruge bevægelseshistorien på.

• for det sidste X antal træk, matcher de Y -mønster. Et simpelt eksempel kunne være (og dette skete) "FREM, REVERSE, FORWARD, REVERSE, …..". Så der er denne matchende funktion, der returnerer enten SAND (mønster fundet) eller FALSKT (ikke fundet). Hvis SAND, i navigationsdelen af programmet, skal du prøve andre bevægelsessekvenser.
• for det sidste X antal træk, er der en generel eller netto fremadgående bevægelse. Hvordan kan man afgøre, hvad der er ægte bevægelse fremad? Nå.. en let sammenligning er, at for de sidste X -træk sker "FREM" mere end "BAGVEND". Men det behøver ikke at være det eneste. Hvad med dette: "HØJRE, HØJRE, VENSTRE, HØJRE". I så fald skal robotten dreje til højre for at komme ud af et hjørne, eller fordi den nærmede sig væggen i en vinkel, kan det betragtes som en reel fremadgående fremgang. På den anden side betragtes "VENSTRE, HØJRE, VENSTRE, HØJRE …" måske ikke som virkelig fremadrettet fremgang. Såfremt "HØJRE" forekommer mere end "LEFT", eller "LEFT forekommer mere end" RIGHT ", kan det være reel fremgang.

I begyndelsen af denne instruktør nævnte jeg, at et muligt 3. mål kunne være at firkantes eller justere til en væg. Til det har vi dog brug for mere end "er vi tæt på et objekt". For eksempel, hvis vi kan få to fremadvendte akustiske sensorer (ikke fokus i denne artikel) til at give rimeligt gode, stabile svar vedrørende afstand, er den åbenbart, hvis den ene rapporterer en meget anden værdi end den anden, robotten nærmet sig væggen i en vinkel og kunne forsøge at manøvrere for at se, om disse værdier nærmer sig hinanden (vendt mod væggen).

Trin 6: Endelige tanker, næste fase …

Håber denne instruktive gav nogle ideer.

Tilføjelse af flere sensorer introducerer nogle fordele og udfordringer.

I ovenstående tilfælde fungerede alle de akustiske sensorer godt sammen, og det var ret ligetil med softwaren.

Når først IR -sensorerne blev introduceret i blandingen, blev det lidt mere udfordrende. Årsagen er, at nogle af deres synsfelter overlapper dem med de akustiske sensorer. IR-sensorerne virkede lidt følsomme og uforudsigelige med skiftende omgivelseslysforhold, hvorimod de akustiske sensorer naturligvis ikke påvirkes af belysning.

Og så var udfordringen, hvad vi skulle gøre, hvis en akustisk sensor fortæller os, at der ikke er nogen hindring, men IR -sensoren er.

For nu, efter forsøg og fejl, endte tingene i denne prioritet:

1. forstærker-sensing
2. IR-sensing
3. akustisk sansning

Og hvad jeg gjorde var bare at sænke følsomheden af IR -sensorerne, så de kun ville registrere meget tætte genstande (f.eks. Forestående stoleben)

Indtil videre har der ikke været behov for at lave software med flere tråde eller afbrydelser, selvom jeg lejlighedsvis støder på tab af kontrol mellem Raspberry Pi og Roboclaw-motorstyringen (tab af seriel kommunikation).

Det er her, E-Stop kredsløbet (se tidligere instruktioner) normalt ville komme i brug. Men da jeg ikke (endnu) vil have at gøre med at skulle nulstille Roboclaw under udviklingen, og robotten ikke går så hurtigt, og jeg er til stede for at overvåge den og lukke den ned, har jeg ikke tilsluttet E-Stop.

Til sidst vil multitrådning sandsynligvis være nødvendig.

Næste skridt…

Tak fordi du nåede så langt.

Jeg fik nogle VL53L1X IR laser ToF (time-of-flight) sensorer, så det er højst sandsynligt emnet for den næste Instructable, sammen med en servo.