Roboti Autonom Wallace - Pjesa 4 - Shtoni distancë IR dhe sensorë "Amp": 6 hapa

2024 Autor: John Day | [email protected]. E modifikuara e fundit: 2024-01-30 12:24

Përshëndetje, sot ne fillojmë fazën tjetër të përmirësimit të aftësive të Wallace. Në mënyrë të veçantë, ne po përpiqemi të përmirësojmë aftësinë e tij për të zbuluar dhe shmangur pengesat duke përdorur sensorë të distancës infra të kuqe, dhe gjithashtu të përfitojmë nga aftësia e kontrolluesit të motorit Roboclaw për të monitoruar rrymën dhe për ta kthyer atë në një "sensor" virtual (softuer). Së fundi, ne do të hedhim një vështrim se si të lundroni pa SLAM (vendndodhja dhe hartografimi i njëkohshëm) (tani për tani), pasi roboti nuk ka ende sensorë IMU (njësi matëse inercie) ose ToF (koha e fluturimit).

Me navigim, fillimisht do të jenë vetëm dy qëllime kryesore:

1. shmangur pengesat
2. njohin kur është mbërthyer diku dhe nuk bën ndonjë përparim. ("përparim" do të thotë a ka ecur përpara ndonjë distancë kuptimplotë)
3. një objektiv i mundshëm i tretë mund të jetë që ai të përpiqet të rreshtohet në mënyrë katrore me një mur.

Ky projekt filloi me një çantë robotësh dhe funksionimin e lëvizjeve themelore duke përdorur një tastierë dhe lidhje ssh.

Faza e dytë ishte shtimi i qarkut mbështetës të mjaftueshëm për t'u përgatitur për shtimin e shumë sensorëve.

Në udhëzuesin e mëparshëm, ne shtuam disa sensorë akustikë HCSR04 dhe roboti tani mund të shmangë pengesat ndërsa lëviz nëpër apartament.

Ndërsa funksionon mirë në kuzhinë dhe korridor me sipërfaqe të mira dhe të ngurta të sheshta, është plotësisht i verbër kur i afrohet dhomës së ngrënies. Nuk mund të "shohë" këmbët e tryezës dhe karriges.

Një përmirësim mund të jetë mbajtja e gjurmëve të rrymave tipike motorike, dhe nëse vlerat kërcejnë, atëherë roboti duhet të ketë goditur diçka. Ashtë një "plan B" i mirë apo edhe C. Por kjo nuk e ndihmon atë të lundrojë nëpër zonën e ngrënies.

(Përditëso: në fakt, tani për tani, monitorimi aktual është plani A kur kthehet mbrapsht pasi kam hequr përkohësisht dhe sensorë nga pjesa e pasme).

Videoja për këtë seksion përbën fazën përfundimtare të sensorëve të shmangies së pengesave.

Ajo që shihni në video është gjashtë sensorë akustikë para HCSR04 dhe dy sensorë IR të mprehtë. Sensorët IR nuk u shfaqën shumë në video. Fortësia e tyre është kryesisht kur roboti gjendet në zonën e ngrënies përballë këmbëve të tryezës dhe karriges.

Përveç sensorëve, monitori aktual hyri në lojë veçanërisht gjatë kthimit mbrapsht, në rast se përplaset me diçka.

Së fundi, ai përdor historinë e 100 lëvizjeve të fundit dhe disa analiza bazë për t'iu përgjigjur një pyetjeje:

"A ka pasur kohët e fundit përparim të vërtetë përpara (apo ka ngecur në ndonjë vallëzim të përsëritur)?"

Pra, në video kur shihni të përsëritet një drejtim përpara-anasjelltas, atëherë kthehet, do të thotë që ka njohur modelin e kundërt, pra provon diçka tjetër.

Qëllimi i vetëm i programuar i këtij versioni të softuerit ishte që të përpiqej të bëja përparim të vazhdueshëm përpara dhe të shmangja pengesat.

Hapi 1: Shtoni Qarqet Mbështetëse (MCP3008)

Para se të shtojmë sensorët IR, do të na duhet qarku i ndërfaqes midis tyre dhe Raspberry Pi.

Ne do të shtojmë një konvertues analog-dixhital MCP3008. Ka shumë burime në internet se si ta lidhni këtë çip me Raspberry Pi, kështu që unë nuk do të hyj shumë në këtë këtu.

Në thelb, ne kemi një zgjedhje. Nëse versioni i sensorëve IR funksionon në 3V, kështu mund të veprojë edhe MCP3008, dhe ne pastaj mund të lidhemi drejtpërdrejt me Raspberry.

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

Në rastin tim, megjithatë, unë jam duke punuar kryesisht 5V, kështu që do të thotë një zhvendosës i nivelit dy-drejtues.

[Sensori IR 5V]-[MCP3008]-[Autobusi dy-drejtues 5V-në-3V]-[Raspberry Pi]

Shënim: Ekziston vetëm një dalje sinjali nga sensori IR. Shkon drejtpërdrejt në një nga linjat e sinjalit analog të hyrjes të MCP3008. Nga MCP3008, ka 4 linja të dhënash që na duhen lidhur (përmes autobusit dy-drejtues) me Raspberry Pi.

Për momentin, roboti ynë do të funksionojë duke përdorur vetëm dy sensorë IR, por ne lehtë mund të shtojmë më shumë. MCP3008 tetë kanale analoge të hyrjes.

Hapi 2: Montoni sensorët IR

Sharp prodhon disa sensorë të ndryshëm IR, dhe ata kanë diapazone të ndryshme dhe zonë mbulimi. Ndodhi që kam porositur modelin GP2Y0A60SZLF. Modeli që zgjidhni do të ndikojë në vendosjen dhe orientimin e sensorit. Fatkeqësisht për mua, nuk kam bërë kërkime të sakta se cilët sensorë të marr. Ishte më shumë një vendim "cilat mund t'i marr në një kohë dhe çmim të arsyeshëm nga një burim me reputacion, nga ato që ofrojnë".

(Përditëso: Sidoqoftë, kjo mund të mos ketë rëndësi, pasi këta sensorë duket se ngatërrohen nga ndriçimi i ambientit të brendshëm. Unë jam ende duke e eksploruar atë çështje)

Ekzistojnë të paktën tre mënyra për t'i montuar këta sensorë në robot.

1. Vendosini ato në një pozicion fiks, në pjesën e përparme, duke u kthyer pak larg njëri -tjetrit.
2. Vendosini ato në një servo, në pjesën e përparme, duke u kthyer pak larg njëri -tjetrit.
3. Vendosini ato në një pozicion fiks, në pjesën e përparme, por në cepat më të majtë dhe më të djathtë, të kënduar drejt njëri -tjetrit.

Në krahasimin e zgjedhjes #1 me zgjedhjen #3, unë mendoj se #3 do të mbulojë më shumë zonën e përplasjes. Nëse i hidhni një sy imazheve, zgjedhja #3 mund të bëhet jo vetëm në mënyrë që fushat e sensorit të mbivendosen, por gjithashtu ato mund të mbulojnë qendrën dhe përtej gjerësisë së jashtme të robotit.

Me zgjedhjen #1, sa më shumë që sensorët të jenë të vendosur nga njëri -tjetri, aq më shumë një pikë e verbër në qendër.

Ne mund të bëjmë numrin 2, (shtova disa imazhe me servo si mundësi) dhe t'i lëmë të bëjnë një spastrim, dhe padyshim që kjo mund të mbulojë zonën më të madhe. Sidoqoftë, unë dua të vonoj përdorimin e një servo sa më gjatë që të jetë e mundur, për të paktën dy arsye:

• Ne do të përdorim një nga kanalet e komunikimit PWM në Raspberry Pi. (Possibleshtë e mundur të përmirësohet kjo, por akoma …)
• Barazimi aktual me servo mund të jetë i rëndësishëm
• Shton më shumë në harduer dhe softuer

Do të doja të lija opsionin servo për më vonë kur shtoja sensorë më të rëndësishëm, të tillë si Time-of-Flight (ToF), ose ndoshta një aparat fotografik.

Ekziston një avantazh tjetër i mundshëm me zgjedhjen #2 që nuk është i disponueshëm me dy zgjedhjet e tjera. Këta sensorë IR mund të ngatërrohen, në varësi të ndriçimit. Mund të ndodhë që roboti të lexojë një objekt që është pafundësisht afër kur në fakt nuk ka asnjë objekt afër. Me zgjedhjen #3, meqenëse fushat e tyre mund të mbivendosen, të dy sensorët mund të regjistrojnë të njëjtin objekt (nga kënde të ndryshme).

Pra, ne po shkojmë me zgjedhjen e vendosjes #3.

Hapi 3: Koha për të testuar

Pasi të kemi bërë të gjitha lidhjet midis Raspberry Pi, MCP3008 ADC dhe sensorëve IR Sharp, është koha për të provuar. Vetëm një test i thjeshtë për të siguruar që sistemi po punon me sensorët e rinj.

Ashtu si në udhëzimet e mëparshme, unë përdor bibliotekën e instalimeve elektrike Pi sa më shumë që të jetë e mundur. I bën gjërat më të lehta. Diçka që nuk është shumë e qartë nga rishikimi i faqes në internet të wiringPi, është se ka mbështetje të drejtpërdrejtë për MCP3004/3008.

Edhe pa atë, ju thjesht mund të përdorni shtrirjen SPI. Por nuk ka nevojë. Nëse i hidhni një vështrim të afërt depozitës Giton për wiringPi, do të hasni në një listë të çipave të mbështetur, nga të cilët njëri prej tyre është për MCP3004/3008.

Vendosa ta bashkangjitja kodin si skedar sepse nuk arrita që ai të shfaqet saktë në këtë faqe.

Hapi 4: Një Sensor Virtual - AmpSensor

Sa më shumë mënyra të ndryshme që mund të bëni që roboti të marrë informacione për botën e jashtme, aq më mirë.

Roboti aktualisht ka tetë sensorë sonar akustikë HCSR04 (ata nuk janë fokusi i këtij Instructable), dhe tani ka dy sensorë të distancës IR Sharp. Siç u tha më herët, ne mund të përfitojmë nga diçka tjetër: veçoria e ndjeshmërisë së rrymave motorike të Roboclaw.

Ne mund ta mbyllim atë thirrje pyetëse te kontrolluesi motorik në një klasë C ++ dhe ta quajmë një AmpSensor.

Duke shtuar disa "zgjuarsi" në softuer, ne mund të monitorojmë dhe rregullojmë tërheqjen tipike të rrymës gjatë lëvizjes së drejtë (përpara, prapa), si dhe lëvizjet rrotulluese (majtas, djathtas). Pasi të dimë ato diapazone të amperit, ne mund të zgjedhim një vlerë kritike, kështu që nëse AmpSensori merr një lexim aktual nga kontrolluesi i motorit që tejkalon këtë vlerë, ne e dimë që motorët ndoshta kanë ngecur, dhe kjo zakonisht tregon se roboti është përplasur në diçka.

Nëse i shtojmë njëfarë fleksibiliteti softuerit (argjet e linjës së komandës, dhe / ose hyrjen e tastierës gjatë operimit), atëherë mund të rrisim / ulim pragun "kritik-amps" ndërsa eksperimentojmë duke e lënë robotin të lëvizë dhe përplaset me objektet, të dyja drejt, ose gjatë rrotullimit.

Meqenëse pjesa jonë e lundrimit e softuerit e di drejtimin e lëvizjes, ne mund ta përdorim të gjithë atë informacion për të ndaluar lëvizjen dhe për të provuar ta ndryshojmë lëvizjen për një periudhë të shkurtër para se të provojmë diçka tjetër.

Hapi 5: Lundrimi

Roboti aktualisht është i kufizuar në reagimet e botës reale. Ajo ka disa sensorë në distancë të afërt për shmangien e pengesave, dhe ka një teknikë prapambetjeje të monitorimit të tërheqjes së rrymës nëse sensorët e distancës humbin një pengesë.

Ai nuk ka motorë me kodues dhe nuk ka një IMU (njësi inerciale-matëse), kështu që e bën më të vështirë të dihet nëse është vërtet duke lëvizur ose rrotulluar, dhe sa.

Ndërsa dikush mund të marrë një lloj tregimi të distancës me sensorët aktualisht në robot, fusha e tyre e shikimit është e gjerë dhe ka paparashikueshmëri. Sonari akustik mund të mos reflektohet prapa siç duhet; infra të kuqe mund të ngatërrohet nga ndriçimi tjetër, apo edhe nga sipërfaqet e shumta reflektuese. Unë nuk jam i sigurt se ia vlen mundimi për të provuar në fakt ndryshimin në distancë si një teknikë për të ditur nëse roboti po lëviz dhe sa dhe në cilin drejtim.

Unë me qëllim zgjodha të NUK përdor një mikrokontrollues të tillë si një Arduino sepse a) nuk më pëlqen mjedisi psuedo-C ++, b) dhe se zhvillimi i tepërt do të lodhë kujtesën e leximit-shkrimit (?), Dhe se unë do të kishte nevojë për një kompjuter pritës për t’u zhvilluar (?). Ose ndoshta unë thjesht ndodhë si Raspberry Pi.

Pi që funksionon Raspbian, megjithatë, nuk është një sistem operativ në kohë reale, kështu që midis paqëndrueshmërive të këtyre sensorëve dhe OS që nuk lexojnë saktësisht çdo herë, ndjeva se qëllimi i këtyre sensorëve ishte më i përshtatshmi për shmangien e pengesave dhe jo matja aktuale e distancës.

Kjo qasje dukej e ndërlikuar dhe me jo aq përfitim, kur mund të përdorim sensorë më të mirë ToF (koha e fluturimit) (më vonë) për atë qëllim (SLAM).

Një qasje që ne mund të përdorim është të mbajmë një lloj gjurme të asaj që komandat e lëvizjes janë lëshuar brenda X sekondave ose komandave të fundit.

Si shembull, thoni që roboti është mbërthyer përballë një cepi diagonalisht. Një grup sensorësh i thonë atij se është shumë afër një muri, kështu që rrotullohet, por pastaj grupi tjetër i sensorëve i thotë se është shumë afër murit tjetër. Përfundon thjesht duke përsëritur një model krah për krah.

Shembulli i mësipërm është vetëm një rast shumë i thjeshtë. Shtimi i disa mençurive mund të ngrejë modelin e përsëritur në një nivel të ri, por roboti mbetet i mbërthyer në qoshe.

Shembull, në vend që të rrotullohet mbrapa dhe me radhë në vend, ai rrotullohet në një drejtim, bën mbrapsht momental (i cili më pas pastron indikacionet e distancës kritike), dhe edhe nëse rrotullohet në drejtimin tjetër, ai prapë shkon përpara në një kënd prapa në qoshe, duke përsëritur një sugjerim më të komplikuar të së njëjtës gjë në thelb.

Kjo do të thotë që ne me të vërtetë mund të përdorim një histori komandash dhe të hedhim një vështrim se si ta shfrytëzojmë dhe përdorim atë informacion.

Mund të mendoj për dy mënyra shumë themelore (rudimentare) të përdorimit të historisë së lëvizjes.

• për numrin e fundit të lëvizjeve X, a përputhen ato me modelin Y. Një shembull i thjeshtë mund të jetë (dhe kjo ndodhi) "PARA, KTHIM, PARA, KTHIM,…..". Pra, ekziston ky funksion i përputhjes që kthen ose TRUE (modeli u gjet) ose FALSE (nuk u gjet). Nëse është TRUE, në pjesën e lundrimit të programit, provoni sekuenca të tjera lëvizjesh.
• për numrin e fundit të lëvizjeve, a ka një lëvizje të përgjithshme ose neto përpara. Si mund të përcaktohet se çfarë është lëvizja e vërtetë përpara? Epo.. një krahasim i lehtë është se për lëvizjet e fundit X, "FORWARD" ndodh më shumë sesa "KTHIM". Por kjo nuk duhet të jetë e vetmja. Po në lidhje me këtë: "E DREJTA, E DREJTA, E majta, E DREJTA". Në atë rast, robotit i duhet të bëjë kthesat e duhura për të dalë nga një cep ose për shkak se iu afrua murit në një kënd, që mund të konsiderohet përparim i vërtetë përpara. Nga ana tjetër, "E majta, e djathta, e majta, e djathta …" nuk mund të konsiderohet përparim i vërtetë përpara. Kështu, nëse "E DREJTA" shfaqet më shumë se "E majta", ose "E majta ndodh më shumë se" E DREJTA ", atëherë ky mund të jetë përparim i vërtetë.

Në fillim të këtij Udhëzuesi, unë përmenda se një gol i mundshëm i 3 -të mund të ishte në katror ose rreshtim në një mur. Për këtë, megjithatë, ne kemi nevojë për më shumë sesa "a jemi pranë ndonjë objekti". Për shembull, nëse mund të marrim dy sensorë akustikë përpara (jo fokusi i këtij artikulli) për të dhënë përgjigje mjaft të mira dhe të qëndrueshme në lidhje me distancën, natyrisht nëse njëri raporton një vlerë shumë më të ndryshme se tjetra, roboti i është afruar murit në një kënd, dhe mund të bëjë disa manovra për të parë nëse ato vlera i afrohen njëra -tjetrës (përballë murit në mënyrë katrore).

Hapi 6: Mendimet përfundimtare, faza tjetër…

Shpresoj se ky Instructable dha disa ide.

Shtimi i më shumë sensorëve paraqet disa avantazhe dhe sfida.

Në rastin e mësipërm, të gjithë sensorët akustikë punuan mirë së bashku dhe ishte mjaft i drejtpërdrejtë me softuerin.

Pasi sensorët IR u futën në përzierje, u bë pak më sfiduese. Arsyeja është se disa nga fushat e tyre të shikimit mbivendosen me ato të sensorëve akustikë. Sensorët IR dukeshin pak të ndjeshëm dhe të paparashikueshëm me ndryshimin e kushteve të dritës së ambientit, ndërsa sigurisht sensorët akustikë nuk ndikohen nga ndriçimi.

Dhe kështu sfida ishte se çfarë të bëjmë nëse një sensor akustik po na thotë se nuk ka asnjë pengesë, por sensori IR është.

Tani për tani, pas provës dhe gabimit, gjërat përfunduan në këtë përparësi:

1. ndjerë amp
2. IR-sensing
3. akustike-shqisore

Dhe ajo që bëra ishte vetëm për të ulur ndjeshmërinë e sensorëve IR, në mënyrë që ata të zbulonin vetëm objekte shumë të afërta (siç janë këmbët e afërta të karriges)

Deri më tani, nuk ka qenë e nevojshme të bëhet ndonjë softuer me shumë fije ose me ndërprerje, megjithëse herë pas here has në humbje të kontrollit midis Raspberry Pi dhe kontrolluesit motorik Roboclaw (humbja e komunikimeve serike).

Këtu normalisht do të hynte në përdorim qarku E-Stop (shiko udhëzimet e mëparshme). Sidoqoftë, meqenëse nuk dua (akoma) të merrem me nevojën për të rivendosur Roboclaw gjatë zhvillimit, dhe roboti nuk po ecën aq shpejt, dhe unë jam i pranishëm për ta monitoruar dhe mbyllur, nuk e kam bërë lidhur E-Stop.

Përfundimisht, shumë filetime ka shumë të ngjarë të jenë të nevojshme.

Hapat e ardhshëm…

Faleminderit që e arritët deri këtu.

Kam marrë disa sensorë VL53L1X IR lazer ToF (koha e fluturimit), kështu që kjo ka shumë të ngjarë të jetë tema e Instructable tjetër, së bashku me një servo.