Wallace autonóm robot - 4. rész - IR távolság és erősítő érzékelők hozzáadása: 6 lépés

2024 Szerző: John Day | [email protected]. Utoljára módosítva: 2024-01-30 09:42

Helló, ma megkezdjük a Wallace képességeinek fejlesztésének következő szakaszát. Konkrétan az infravörös távolságérzékelők segítségével próbáljuk javítani az akadályok észlelésének és elkerülésének képességét, valamint kihasználjuk a Roboclaw motorvezérlő azon képességét, hogy felügyelje az áramot, és virtuális (szoftver) "érzékelővé" alakítsa. Végül megnézzük, hogyan lehet navigálni SLAM nélkül (egyidejű helymeghatározás és leképezés) (egyelőre), mivel a robot még nem rendelkezik IMU (tehetetlenségi mérőegység) vagy ToF (repülési idő) érzékelőkkel.

A navigációval kezdetben csak két fő cél lesz:

1. kerülje az akadályokat
2. felismerni, ha valahol elakadt, és nem halad előre. ("haladás" azt jelenti, hogy értelmes távolságot lépett előre)
3. lehetséges 3. cél lehet, hogy megpróbálja egyenesen a falhoz igazítani magát.

Ez a projekt egy robotkészlettel kezdődött, és az alapvető mozgások működtetéséhez billentyűzet és ssh kapcsolat segítségével.

A második fázis az volt, hogy elegendő támogató áramkört kellett hozzáadni ahhoz, hogy előkészítse számos érzékelő hozzáadását.

Az előző Instructable -ben több HCSR04 akusztikus érzékelőt is hozzáadtunk, és a robot most elkerülheti az akadályokat, miközben a lakásban jár.

Bár jól működik a konyhában és a folyosón, jó, szilárd sík felületekkel, teljesen vak, amikor közeledik az étkezőhöz. Nem látja az asztalt és a szék lábát.

Az egyik javulás lehet a tipikus motoráramok nyomon követése, és ha az értékek ugrálnak, akkor a robotnak biztosan elütött valamit. Ez egy jó "terv B" vagy akár C. De ez nem igazán segíti eligazodni az étkezőben.

(Frissítés: valójában egyenlőre az áramfelügyelet az A terv, amikor tolat, mivel ideiglenesen eltávolítottam és az érzékelőket hátulról).

Ennek a résznek a videója az akadálykerülő érzékelők utolsó fázisa.

A videóban hat elülső HCSR04 akusztikus érzékelő és két Sharp IR érzékelő látható. Az infravörös érzékelők nem sokat játszottak a videóban. Erősségük leginkább az, amikor a robot az étkezőben találja magát az asztal és a szék lábaival szemben.

Az érzékelőkön kívül az áramfigyelő is főleg tolatás közben lépett játékba, hátha beleütközik valamibe.

Végül az utolsó 100 lépés történetét és néhány alapvető elemzést használja fel egy kérdés megválaszolásához:

"Történt -e mostanában valódi előrehaladás (vagy elakadt valami ismétlődő táncban)?"

Tehát a videóban, amikor az előre-hátra ismétlődést látja, majd megfordul, ez azt jelenti, hogy felismerte az előre-hátra irányú mintát, és így valami mással próbálkozik.

A szoftver ezen verziójának egyetlen programozott célja az volt, hogy folyamatosan előre kell lépni, és el kell kerülni az akadályokat.

1. lépés: Támogató áramkör hozzáadása (MCP3008)

Mielőtt hozzáadnánk az infravörös érzékelőket, szükségünk lesz az interfész áramkörre a köztük és a Raspberry Pi között.

Adunk hozzá egy MCP3008 analóg-digitális átalakítót. Sok online erőforrás létezik, hogyan lehet ezt a chipet a Raspberry Pi -hez csatlakoztatni, ezért itt nem foglalkozom sokat ezzel.

Lényegében van választási lehetőségünk. Ha az infravörös érzékelők verziója 3 V -on működik, akkor az MCP3008 is, és akkor közvetlenül csatlakozhatunk a Raspberry -hez.

[3V IR érzékelő] - [MCP3008] - [Raspberrry Pi]

Az én esetemben azonban többnyire 5 V-ot futok, tehát ez kétirányú szintváltót jelent.

[5V IR érzékelő]-[MCP3008]-[5V-3V kétirányú busz]-[Raspberry Pi]

Megjegyzés: Az infravörös érzékelőből csak egy jel jön ki. Közvetlenül az MCP3008 egyik bemeneti analóg jelvonalához megy. Az MCP3008-ból 4 adatvonalat kell csatlakoztatnunk (a kétirányú buszon keresztül) a Raspberry Pi-hez.

Pillanatnyilag a robotunk csak két infravörös érzékelővel fog működni, de könnyen hozzáadhatunk többet. Az MCP3008 nyolc analóg bemeneti csatorna.

2. lépés: Rögzítse az IR érzékelőket

A Sharp több különböző infravörös érzékelőt gyárt, és ezek hatótávolsága és lefedettségi területe eltérő. Véletlenül megrendeltem a GP2Y0A60SZLF modellt. A választott modell befolyásolja az érzékelő elhelyezését és tájolását. Sajnos nekem nem igazán kutattam, hogy pontosan mely szenzorokat vegyem. Inkább az volt, hogy "melyiket kaphatom elfogadható időben és áron jó hírű forrásból, az általuk kínált termékek közül".

(Frissítés: Ez azonban nem számít, mivel úgy tűnik, hogy ezeket az érzékelőket összezavarja a belső világítás. Még mindig vizsgálom ezt a problémát)

Legalább háromféle módon lehet ezeket az érzékelőket a robotra szerelni.

1. Helyezze őket rögzített helyzetbe, elöl, kissé távol egymástól.
2. Helyezze őket egy szervóra, elöl, kissé távol egymástól.
3. Helyezze őket rögzített helyzetbe, elöl, de a bal és a jobb szélső legtávolabbi sarokban, egymáshoz képest szögben.

Összehasonlítva az 1. választást a 3. választással, úgy gondolom, hogy a 3. az ütközési terület nagyobb részét lefedi. Ha megnézi a képeket, a #3 -as választás nemcsak úgy történhet meg, hogy az érzékelőmezők átfedésben legyenek, hanem lefedhetik a robot közepét és külső szélességét is.

Az 1. választásnál, minél távolabb vannak egymástól az érzékelők, annál nagyobb a vakfolt a közepén.

Megtehetnénk a 2. számot (néhány képet szervóval adtam hozzá), és megkérhetnénk őket a söprésre, és ez nyilvánvalóan a legtöbb területet lefedi. Szeretném azonban a szervo használatát a lehető legtovább késleltetni, legalább két okból:

• Kihasználjuk a Raspberry Pi egyik PWM kommunikációs csatornáját. (Lehet ezt fokozni, de akkor is …)
• A szervó áramfelvétele jelentős lehet
• Többet ad a hardverhez és a szoftverhez

Szeretném későbbre hagyni a szervo opciót, amikor fontosabb érzékelőket, például repülési időt (ToF) vagy esetleg kamerát ad hozzá.

Van még egy lehetséges előny a 2. választással, amely nem áll rendelkezésre a másik két választással. Ezek az infravörös érzékelők a világítástól függően zavarosak lehetnek. Elképzelhető, hogy a robot leolvas egy olyan objektumot, amely közel van, bár valójában nincs közeli objektum. A 3. választással, mivel a mezőik átfedhetik egymást, mindkét érzékelő ugyanazt az objektumot regisztrálhatja (különböző szögből).

Tehát a 3. helyezéssel választunk.

3. lépés: A tesztelés ideje

Miután létrehoztunk minden kapcsolatot a Raspberry Pi, az MCP3008 ADC és a Sharp IR érzékelők között, ideje tesztelni. Csak egy egyszerű teszt annak ellenőrzésére, hogy a rendszer működik -e az új érzékelőkkel.

A korábbi Instructables -hez hasonlóan a lehető legnagyobb mértékben a wiringPi C könyvtárat használom. Megkönnyíti a dolgokat. A wiringPi webhely áttekintése során valami nem annyira nyilvánvaló, hogy az MCP3004/3008 közvetlenül támogatott.

E nélkül is használhatja az SPI kiterjesztést. De nem kell. Ha alaposan szemügyre veszi Gordon witPi git adattárát, a támogatott chipek listájára bukkan, amelyek közül az egyik az MCP3004/3008.

Úgy döntöttem, hogy fájlként csatolom a kódot, mert nem tudtam megfelelően megjeleníteni ezen az oldalon.

4. lépés: Virtuális érzékelő - AmpSensor

Minél többféle módon kaphat információt a robot a külvilágról, annál jobb.

A robotnak jelenleg nyolc HCSR04 akusztikus szonárérzékelője van (ezek nem az útmutató középpontjában állnak), és most két Sharp IR távolságérzékelővel rendelkezik. Amint azt korábban említettük, valami mást is kihasználhatunk: a Roboclaw motoráram-érzékelő funkcióját.

Ezt a motorvezérlőhöz intézett lekérdezési hívást C ++ osztályba csomagolhatjuk, és AmpSensornak nevezhetjük.

Ha hozzáadunk néhány "okosságot" a szoftverhez, nyomon követhetjük és beállíthatjuk a tipikus áramfelvételt az egyenes mozgás során (előre, hátra), valamint a forgó mozgásokat (balra, jobbra). Ha ismerjük ezeket az erősítő tartományokat, kiválaszthatunk egy kritikus értéket, így ha az AmpSensor a motorvezérlőtől ezt az értéket meghaladó áramértéket kap, akkor tudjuk, hogy a motorok valószínűleg leálltak, és ez általában azt jelzi, hogy a robot ütközik valamibe.

Ha némi rugalmasságot adunk a szoftverhez (parancssori argok és / vagy billentyűzetbemenet működés közben), akkor növelhetjük / csökkenthetjük a "kritikus erősítők" küszöbét kísérletezés közben azzal, hogy hagyjuk a robotot mozogni és tárgyakba ütközni, egyenesen befelé vagy forgatás közben.

Mivel a szoftver navigációs része ismeri a mozgás irányát, felhasználhatjuk ezeket az információkat, hogy esetleg megállítsuk a mozgást, és megpróbáljuk megfordítani a mozgást egy rövid ideig, mielőtt valami mással próbálkozunk.

5. lépés: Navigáció

A robot jelenleg korlátozott a valós visszajelzésekben. Néhány közeli távolságérzékelővel rendelkezik az akadályok elkerülése érdekében, és tartalék technikával rendelkezik az áramfelvétel figyelésére, ha a távolságérzékelők nem vesznek el egy akadályt.

Nem rendelkezik kódoló motorokkal, és nincs IMU (inerciális mérőegysége), így megnehezíti annak megállapítását, hogy valóban mozog vagy forog-e, és mennyivel.

Míg a roboton lévő érzékelőkkel valamiféle távolságjelzést kaphatunk, a látómezőjük széles és kiszámíthatatlan. Előfordulhat, hogy az akusztikus szonár nem tükröződik vissza megfelelően; az infravörös összekeverhető más világítással, vagy akár több fényvisszaverő felülettel. Nem vagyok benne biztos, hogy megéri a fáradságot, hogy valóban megpróbáljam technikaként nyomon követni a távolság változását, hogy megtudjam, mozog -e a robot, és mennyit és milyen irányba.

Szándékosan úgy döntöttem, hogy NEM használok olyan mikrovezérlőt, mint az Arduino, mert a) nem szeretem a psuedo-C ++ környezetet, b) és hogy a túl sok fejlesztés elhasználja az olvasási-írási memóriát (?), És hogy gazdagépre lenne szüksége a fejlesztéshez (?). Vagy talán csak úgy történik, mint a Raspberry Pi.

A Raspbian-t futtató Pi azonban nem valós idejű operációs rendszer, így ezen érzékelők instabilitása és az operációs rendszer nem minden alkalommal történő olvasása között úgy éreztem, hogy ezeknek az érzékelőknek a célja jobban megfelel az akadályok elkerülésére, és nem tényleges távolságmérés.

Ez a megközelítés bonyolultnak tűnt, és nem sok előnnyel járt, amikor jobb ToF (repülési idő) érzékelőket (később) használhatunk erre a célra (SLAM).

Az egyik módszer, amelyet használhatunk, hogy nyomon követhetjük, hogy milyen mozgásparancsokat adtak ki az utolsó X másodpercben.

Példaként tegyük fel, hogy a robot átlósan egy sarokkal szemben ragadt. Az egyik érzékelőcsoport azt jelzi, hogy túl közel van az egyik falhoz, ezért elfordul, de a másik érzékelőcsoport azt jelzi, hogy túl közel van a másik falhoz. A végén csak megismétli az egyik oldalról a másikra.

A fenti példa csak egy nagyon egyszerű eset. Néhány okosság hozzáadása csak új szintre emelheti az ismételt mintát, de a robot elakad a sarokban.

Példa: ahelyett, hogy előre -hátra forogna a helyén, az egyik irányba forog, pillanatnyi hátramenetet hajt végre (ez törli a kritikus távolság jelzéseit), és még ha a másik irányba is forog, akkor is bizonyos szögben előre megy a sarokba, lényegében ugyanazon dolog bonyolultabb pörgését ismételve.

Ez azt jelenti, hogy valóban használhatnánk a parancsok előzményeit, és megvizsgálhatnánk, hogyan lehet ezeket az információkat kiaknázni és felhasználni.

A mozgástörténet két nagyon alapvető (kezdetleges) módjára gondolok.

• az utolsó X számú mozdulathoz illeszkednek az Y mintához. Egyszerű példa lehet (és ez meg is történt) "ELŐRE, HÁTSÓ, ELŐRE, HÁTSÓ,…..". Tehát van ez a megfelelő függvény, amely vagy IGAZ (minta talált) vagy HAMIS (nem található) értéket ad vissza. Ha IGAZ, akkor a program navigációs részében próbáljon meg más mozgássorozatokat.
• az utolsó X számú lépésnél van -e általános vagy nettó előremozdulás. Hogyan határozható meg, hogy mi az igazi előrehaladás? Nos.. az egyik egyszerű összehasonlítás az, hogy az utolsó X lépésnél a "FORWARD" többet fordul elő, mint a "REVERSE". De nem kell, hogy ez legyen az egyetlen. Mit szólna ehhez: "JOBB, JOBB, BAL, JOBB". Ebben az esetben a robotnak jobb kanyarokat kell tennie, hogy kijusson egy sarokból, vagy mert szögben közelítette meg a falat, ez valódi előrehaladásnak tekinthető. Másrészt a "BAL, JOBB, BAL, JOBB …" nem tekinthető valódi előrehaladásnak. Így ha a "JOBB" többet fordul elő, mint a "LEFT", vagy a "BAL jobb fordul elő, mint a" JOBB ", akkor ez valódi előrelépés lehet.

Ennek az utasításnak az elején megemlítettem, hogy egy lehetséges 3. cél lehet a négyzet felállítása vagy a falhoz való igazítás. Ehhez azonban többre van szükségünk, mint "közel vagyunk valamilyen tárgyhoz". Például, ha két előre néző akusztikus érzékelőt szerezhetünk be (nem ez a cikk áll a középpontban), hogy ésszerűen jó, stabil válaszokat adjunk a távolságra vonatkozóan, nyilvánvalóan, ha az egyik sokkal más értéket jelent, mint a másik, a robot megközelítette a falat szögben, és megpróbálhat némi manővert, hogy lássa, ezek az értékek közelednek -e egymáshoz (egyenesen a fal felé nézve).

6. lépés: Utolsó gondolatok, következő fázis…

Remélem, ez az Instructable adott néhány ötletet.

További érzékelők hozzáadása néhány előnnyel és kihívással jár.

A fenti esetben az összes akusztikus érzékelő jól működött együtt, és meglehetősen egyszerű volt a szoftverrel.

Miután az infravörös érzékelőket bevezették a keverékbe, ez egy kicsit nagyobb kihívást jelentett. Ennek az az oka, hogy némelyik látómezőjük átfedésben van az akusztikus szenzorokéval. Az IR érzékelők kissé érzékenynek és kiszámíthatatlannak tűntek a változó környezeti fényviszonyok mellett, míg természetesen az akusztikus érzékelőket nem befolyásolja a világítás.

Tehát a kihívás az volt, hogy mit kell tenni, ha egy akusztikus érzékelő azt mondja nekünk, hogy nincs akadály, de az IR érzékelő igen.

Egyelőre a próba és hiba után a dolgok ebben a prioritásban kötöttek ki:

1. erősítő érzékelés
2. IR-érzékelő
3. akusztikus érzékelés

És én csak csökkentettem az infravörös érzékelők érzékenységét, hogy csak nagyon közeli tárgyakat észleljenek (például a közelgő széklábakat)

Eddig nem volt szükség többszálú vagy megszakítás-vezérelt szoftverre, bár időnként találkozom az irányítás elvesztésével a Raspberry Pi és a Roboclaw motorvezérlő között (soros kommunikáció elvesztése).

Ez az a hely, ahol az E-Stop áramkör (lásd a korábbi utasításokat) rendszerint használatba kerül. Mivel azonban nem akarok (még) foglalkozni azzal, hogy a fejlesztés során vissza kell állítanom a Roboclaw -t, és a robot nem megy olyan gyorsan, és jelen vagyok, hogy figyelemmel kísérjem és leállítsam. csatlakoztatta az E-Stop-ot.

Végül valószínűleg több szálra lesz szükség.

Következő lépések…

Köszönöm, hogy idáig eljutott.

Beszereztem néhány VL53L1X IR lézeres ToF (repülési idő) érzékelőt, így valószínűleg ez lesz a következő Instructable témája, egy szervóval együtt.