Wallace outonome robot - Deel 4 - Voeg IR -afstand en "versterkersensors" by: 6 stappe

2024 Outeur: John Day | [email protected]. Laas verander: 2024-01-30 07:26

Hallo, vandag begin ons met die volgende fase van die verbetering van Wallace se vermoëns. Ons probeer spesifiek sy vermoë om hindernisse op te spoor en te vermy met behulp van infrarooi afstandsensors, en gebruik ook die vermoë van die Roboclaw-motorbeheerder om die stroom te monitor en dit in 'n virtuele (sagteware) 'sensor' te verander. Ten slotte kyk ons na hoe om te navigeer sonder SLAM (gelyktydige ligging en kartering) (vir eers), aangesien die robot nog nie 'n IMU (traagheidseenheid) of ToF (tyd van vlug) sensors het nie.

Deur navigasie sal dit aanvanklik net twee hoofdoelwitte wees:

1. vermy hindernisse
2. herken wanneer dit iewers vas is en geen vordering maak nie. ("vordering" beteken dat dit op 'n betekenisvolle afstand vorentoe gegaan het)
3. 'n moontlike derde doelwit kan wees dat dit hom vierkantig teen 'n muur probeer belyn.

Hierdie projek het begin met 'n robotstel en om basiese bewegings aan die werk te kry met behulp van 'n sleutelbord en ssh -verbinding.

Die tweede fase was om voldoende ondersteunende stroombane by te voeg om voor te berei vir die toevoeging van baie sensors.

In die vorige Instructable het ons wel verskeie HCSR04 akoestiese sensors bygevoeg en die robot kan nou struikelblokke vermy terwyl hy deur die woonstel beweeg.

Alhoewel dit goed is in die kombuis en in die gang met goeie, soliede plat oppervlaktes, is dit heeltemal blind as dit na die eetkamer kom. Dit kan nie die tafel en stoelbene "sien" nie.

Een verbetering kan wees om tred te hou met tipiese motorstrome, en as die waardes spring, moet die robot iets getref het. Dit is 'n goeie "plan B" of selfs C. Maar dit help nie regtig om in die eetarea te gaan nie.

(Opdatering: tans is die huidige monitering plan A by die omkeer, aangesien ek tydelik verwyder het en sensors van agter af).

Die video vir hierdie afdeling vorm die laaste fase van hindernis-vermydingsensors.

Wat u in die video sien, is ses akoestiese sensors voor HCSR04 en twee skerp IR -sensors. Die IR -sensors het nie veel in die video ter sprake gekom nie. Hulle sterkte is meestal wanneer die robot hom in die eetarea bevind wat na die tafel en stoelpote kyk.

Benewens die sensors, het die stroommonitor veral tydens die omkering ter sprake gekom, as dit teen iets sou bots.

Uiteindelik maak dit gebruik van die geskiedenis van die afgelope 100 bewegings, en 'n paar basiese analise om een vraag te beantwoord:

"Was daar onlangs 'n ware vooruitgang (of is dit vasgevang in 'n herhalende dans)?"

Dus, in die video, as u 'n vorentoe-agteruit-herhaling sien herhaal, dan draai dit, dit beteken dat dit die patroon vorentoe-agteruit herken het en dus iets anders probeer.

Die enigste geprogrammeerde doel van hierdie weergawe van die sagteware was om voortdurend vorentoe te probeer vorder en hindernisse te vermy.

Stap 1: Voeg ondersteunende stroombane by (MCP3008)

Voordat ons die IR -sensors kan byvoeg, benodig ons die koppelvlakbane tussen hulle en die Raspberry Pi.

Ons sal 'n MCP3008 analoog-na-digitale omskakelaar byvoeg. Daar is baie aanlynhulpbronne om hierdie chip aan die Raspberry Pi te koppel, so ek sal hier nie veel ingaan nie.

In wese het ons 'n keuse. As die weergawe van IR -sensors op 3V werk, kan die MCP3008 ook, en kan ons dan direk met die Framboos aansluit.

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

In my geval werk ek egter meestal met 5V, so dit beteken 'n tweerigtingvlakverskuiwing.

[5V IR-sensor]-[MCP3008]-[5V-tot-3V tweerigtingbus]-[Framboos Pi]

Opmerking: daar is slegs een sein wat deur die IR -sensor uitgevoer word. Dit gaan direk na een van die ingang analoog seinlyne van die MCP3008. Vanaf die MCP3008 is daar 4 datalyne wat ons moet verbind (via die tweerigtingbus) na die Raspberry Pi.

Op die oomblik werk ons robot met slegs twee IR -sensors, maar ons kan maklik meer byvoeg. Die MCP3008 agt analoog -ingangskanale.

Stap 2: Monteer IR -sensors

Sharp maak verskillende IR -sensors, en hulle het verskillende reekse en dekkingsgebied. Ek het toevallig die GP2Y0A60SZLF -model bestel. Die model wat u kies, sal die plasing en oriëntasie van die sensor beïnvloed. Ongelukkig het ek nie regtig nagegaan presies watter sensors ek moet kry nie. Dit was meer 'n besluit "watter kan ek op 'n redelike tyd en prys kry by 'n betroubare bron, uit die wat hulle aanbied".

(Opdatering: dit maak egter nie saak nie, want dit lyk asof hierdie sensor verwar word deur die omringende beligting binne. Ek ondersoek die probleem nog)

Daar is ten minste drie maniere om hierdie sensors op die robot te monteer.

1. Plaas hulle in 'n vaste posisie, aan die voorkant, effens weg van mekaar.
2. Plaas dit op 'n servo, aan die voorkant, effens weg van mekaar.
3. Plaas hulle in 'n vaste posisie, aan die voorkant, maar aan die linker- en regterkantste hoek, teenoor mekaar.

As ek keuse #1 met keuse #3 vergelyk, dink ek dat #3 meer van die botsingsgebied sal dek. As u na die beelde kyk, kan keuse #3 gedoen word, nie net sodat die sensorvelde oorvleuel nie, maar dat dit ook die middel en buite die buitenste breedte van die robot kan bedek.

Met keuse #1, hoe meer uitmekaar die sensors van mekaar af is, hoe meer is 'n blindekol in die middel.

Ons kan nommer 2 doen (ek het 'n paar beelde bygevoeg met 'n servo as moontlik) en laat dit 'n sweep doen, en dit kan natuurlik die meeste gebied dek. Ek wil die gebruik van 'n servo egter om minstens twee redes so lank as moontlik vertraag:

• Ons gebruik een van die PWM -kommunikasiekanale op die Raspberry Pi. (Dit is moontlik om dit te verbeter, maar tog …)
• Die huidige trekking met die servo kan aansienlik wees
• Dit dra meer by tot hardeware en sagteware

Ek wil graag die servo-opsie laat vir later wanneer ek meer belangrike sensors byvoeg, soos Time-of-Flight (ToF), of miskien 'n kamera.

Daar is nog 'n moontlike voordeel met keuse #2 wat nie by die ander twee keuses beskikbaar is nie. Hierdie IR -sensors kan deurmekaar raak, afhangende van die beligting. Dit kan wees dat die robot 'n voorwerp lees wat onmiddellik naby is, terwyl daar eintlik geen nabygeleë voorwerp is nie. Met keuse #3, aangesien hul velde kan oorvleuel, kan beide sensors dieselfde voorwerp registreer (uit verskillende hoeke).

Ons gaan dus met plasingskeuse #3.

Stap 3: Tyd om te toets

Nadat ons al die verbindings tussen die Raspberry Pi, die MCP3008 ADC en die Sharp IR -sensors gemaak het, is dit tyd om te toets. Net 'n eenvoudige toets om seker te maak dat die stelsel met die nuwe sensors werk.

Soos in vorige instruksies, gebruik ek soveel as moontlik die wiringPi C -biblioteek. Maak dinge makliker. Iets wat nie baie duidelik is by die hersiening van die wiringPi -webwerf nie, is dat die MCP3004/3008 direkte ondersteuning bied.

Selfs sonder dit kan u net die SPI -uitbreiding gebruik. Maar nie nodig nie. As u die Gordon -git -bewaarplek vir wiringPi van nader bekyk, kom u op 'n lys van ondersteunde skyfies, waarvan een vir MCP3004/3008.

Ek het besluit om die kode as 'n lêer aan te heg, want ek kon dit nie reg kry op hierdie bladsy nie.

Stap 4: 'n Virtuele sensor - AmpSensor

Hoe meer verskillende maniere waarop u die robot inligting oor die buitewêreld kan ontvang, hoe beter.

Die robot het tans agt HCSR04 akoestiese sonarsensors (dit is nie die fokus van hierdie instruksies nie), en dit het nou twee Sharp IR -afstandsensors. Soos vroeër gesê, kan ons voordeel trek uit iets anders: die kenmerkende funksie van die motorstrome van Roboclaw.

Ons kan die navraagoproep na die motorbeheerder in 'n C ++-klas draai en dit 'n AmpSensor noem.

Deur 'n paar "smarts" by die sagteware te voeg, kan ons die tipiese stroomopname monitor en aanpas tydens reguit beweging (vorentoe, agteruit), en ook rotasiebewegings (links, regs). Sodra ons die reeks versterkers ken, kan ons 'n kritieke waarde kies, sodat as die AmpSensor 'n stroomlesing van die motorbeheerder kry wat hierdie waarde oorskry, weet ons dat die motors waarskynlik gestop het, en dit dui gewoonlik aan dat die robot gestamp het in iets.

As ons die sagteware 'n bietjie buigsaamheid gee (opdragreëls en / of sleutelbordinvoer tydens werking), kan ons die drempel van 'kritieke versterkers' verhoog / verlaag terwyl ons eksperimenteer deur die robot net te laat beweeg en in voorwerpe te stamp, beide reguit in, of terwyl dit draai.

Aangesien ons navigasiegedeelte van die sagteware die bewegingsrigting ken, kan ons al die inligting gebruik om die beweging te stop en die beweging vir 'n kort tydjie om te keer voordat ons iets anders probeer.

Stap 5: Navigasie

Die robot is tans beperk in die werklike terugvoer. Dit het 'n paar nabygeleë sensors om hindernisse te vermy, en dit het 'n terugval-tegniek om stroomtrekking te monitor as die afstandsensors 'n hindernis misloop.

Dit het nie motors met encoders nie, en dit het ook nie 'n IMU (traagheidseenheid) nie, so dit maak dit moeiliker om te weet of dit regtig beweeg of draai, en hoeveel.

Alhoewel 'n mens 'n aanduiding kan kry van afstand met die sensors wat tans op die robot is, is hul gesigsveld breed en is daar onvoorspelbaarheid. Die akoestiese sonar weerspieël moontlik nie korrek nie; die infrarooi kan verwar word deur ander beligting, of selfs verskeie weerkaatsende oppervlaktes. Ek is nie seker of dit die moeite werd is om die afstandsverandering eintlik te probeer opspoor as 'n tegniek om te weet of die robot beweeg en hoeveel en in watter rigting nie.

Ek het doelbewus gekies om NIE 'n mikrobeheerder soos 'n Arduino te gebruik nie, want a) ek hou nie van die psuedo-C ++ omgewing nie, b) en dat te veel ontwikkeling die lees-skryfgeheue (?) Sal verslind, en dat ek 'n gasheerrekenaar benodig om (?) te ontwikkel. Of miskien gebeur ek net soos die Raspberry Pi.

Die Pi wat Raspbian bestuur, is egter nie 'n intydse bedryfstelsel nie, so tussen die onstabiliteite van hierdie sensors en die bedryfstelsel lees nie elke keer presies nie, het ek gevoel dat die doel van hierdie sensors beter geskik was om hindernisse te vermy en nie werklike afstandmeting.

Die benadering lyk ingewikkeld en met nie soveel voordeel nie, as ons beter ToF (tyd-van-vlug) sensors (later) daarvoor kan gebruik (SLAM).

Een benadering wat ons kan gebruik, is om die spoor te hou van watter bewegingsopdragte binne die laaste X sekondes of opdragte gegee is.

Sê as 'n voorbeeld dat die robot skuins in 'n hoek vasgesit is. Een stel sensors vertel dat dit te naby aan die een muur is, sodat dit draai, maar dan sê die ander stel sensors dat dit te naby aan die ander muur is. Uiteindelik herhaal u slegs 'n sy-tot-sy-patroon.

Bogenoemde voorbeeld is slegs 'n baie eenvoudige geval. As u 'n paar slimhede byvoeg, kan die herhaalde patroon net na 'n nuwe vlak verhoog word, maar die robot bly vas in die hoek.

Byvoorbeeld, in plaas van om heen en weer op sy plek te draai, draai dit een kant toe, draai dit kortstondig om (wat dan die kritieke afstandsaanwysings uitvee), en selfs as dit in die ander rigting draai, gaan dit steeds in 'n hoek terug in die hoek, herhaal 'n meer ingewikkelde patroon van in wese dieselfde ding.

Dit beteken dat ons werklik 'n geskiedenis van opdragte kan gebruik en kan kyk hoe ons die inligting kan ontgin en gebruik.

Ek kan aan twee baie basiese (rudimentêre) maniere dink om die bewegingsgeskiedenis te gebruik.

• pas dit by die Y -patroon vir die laaste X aantal bewegings. 'N Eenvoudige voorbeeld kan wees (en dit het gebeur) "VOORUIT, OMKERWE, VOORUIT, BEKEER, …". So daar is hierdie bypassende funksie wat óf WAAR (patroon gevind) óf ONWAAR (nie gevind nie) teruggee. As dit WAAR is, probeer in die navigasiegedeelte van die program ander bewegingsreekse.
• Is daar 'n algemene of netto voorwaartse beweging vir die laaste X aantal bewegings? Hoe kan 'n mens bepaal wat werklike beweging vorentoe is? Wel, 'n maklike vergelyking is dat "VOORUIT" meer plaasvind as "OMKER" vir die laaste X -bewegings. Maar dit hoef nie die enigste een te wees nie. Hoe gaan dit hiermee: "REGS, REGS, LINKS, REGS". In daardie geval moet die robot regs draai om uit 'n hoek te kom of omdat dit teen 'n hoek teen die muur kom, wat as 'n werklike vooruitgang beskou kan word. Aan die ander kant word "LINKS, REGS, LINKS, REGS …" nie as 'n werklike vooruitgang beskou nie. As 'REGS' dus meer as 'LINKS' voorkom, of 'LINKER meer as' REGS ', kan dit werklike vordering wees.

Aan die begin van hierdie instruksies het ek genoem dat 'n moontlike derde doelwit kan wees om in 'n vierkant te kom of op 'n muur te pas. Hiervoor het ons egter meer nodig as 'is ons naby 'n voorwerp'. As ons byvoorbeeld twee voorwaartse akoestiese sensors (nie die fokus van hierdie artikel nie) kan kry om redelik goeie, stabiele antwoorde op afstand te gee, is dit duidelik dat as die een 'n baie ander waarde as die ander rapporteer, die robot die muur genader het skuins en kan probeer om te sien of hierdie waardes mekaar nader (vierkantig teen die muur).

Stap 6: Laaste gedagtes, volgende fase …

Hoop hierdie Instructable het 'n paar idees gegee.

Deur meer sensors by te voeg, bied dit 'n paar voordele en uitdagings.

In die bogenoemde geval het al die akoestiese sensors goed saamgewerk, en dit was redelik eenvoudig met die sagteware.

Nadat die IR -sensors in die mengsel ingebring is, het dit 'n bietjie meer uitdagend geword. Die rede is dat sommige van hul gesigsvelde oorvleuel met die van die akoestiese sensors. Die IR-sensors het effens sensitief en onvoorspelbaar gelyk met veranderende omstandighede, maar die akoestiese sensors word natuurlik nie deur beligting beïnvloed nie.

Die uitdaging was dus wat ons moet doen as 'n akoestiese sensor ons vertel dat daar geen hindernis is nie, maar die IR -sensor wel.

Vir nou, na proef-en-fout, beland dinge in hierdie prioriteit:

1. amp-sensing
2. IR-waarneming
3. akoesties waarneem

En wat ek gedoen het, was net om die sensitiwiteit van die IR -sensors te verlaag, sodat hulle slegs voorwerpe wat baie naby was (soos dreigende stoelbene) sou opspoor

Tot dusver was dit nie nodig om sagteware met veelvuldige of onderbrekingsgedrewe programme te doen nie, alhoewel ek af en toe 'n verlies aan beheer ondervind tussen die Raspberry Pi en die Roboclaw-motorbeheerder (verlies van seriële kommunikasie).

Dit is waar die E-Stop-kring (sien vorige instruksies) normaalweg in gebruik sou kom. Aangesien ek egter (nog) nie die probleem wil ondergaan om die Roboclaw te herstel tydens die ontwikkeling nie, en die robot nie so vinnig gaan nie, en ek is teenwoordig om dit te monitor en af te sluit, het ek nie verbind die E-Stop.

Uiteindelik sal multi-threading waarskynlik nodig wees.

Volgende stappe…

Dankie dat u so ver gekom het.

Ek het 'n paar VL53L1X IR laser ToF (time-of-flight) sensors gekry, so dit is waarskynlik die onderwerp van die volgende Instructable, saam met 'n servo.