Wallace Autonomous Robot - Deel 4 - IR-afstands- en "Amp"-sensoren toevoegen - Ajarnpa

2024 Auteur: John Day | [email protected]. Laatst gewijzigd: 2024-01-30 11:18

Hallo, vandaag beginnen we met de volgende fase van het verbeteren van de mogelijkheden van Wallace. We proberen met name het vermogen om obstakels te detecteren en te vermijden met behulp van infrarood-afstandssensoren te verbeteren, en ook profiteren van het vermogen van de Roboclaw-motorcontroller om de stroom te bewaken en dat om te zetten in een virtuele (software) "sensor". Ten slotte zullen we kijken hoe navigeren zonder SLAM (simultane locatie en mapping) (voorlopig), aangezien de robot nog geen IMU (traagheidsmeeteenheid) of ToF (time of flight) sensoren heeft.

Door navigatie zullen het in eerste instantie slechts twee hoofddoelen zijn:

1. obstakels vermijden
2. herkennen wanneer het ergens vastzit en geen vooruitgang boekt. ("vooruitgang" betekent dat het enige betekenisvolle afstand heeft afgelegd)
3. een mogelijk derde doel zou kunnen zijn om te proberen zichzelf recht op een muur uit te lijnen.

Dit project begon met een robotkit en om basisbewegingen te laten werken met behulp van een toetsenbord en ssh-verbinding.

De tweede fase was om voldoende ondersteunende schakelingen toe te voegen om de toevoeging van veel sensoren voor te bereiden.

In de vorige Instructable hebben we verschillende HCSR04 akoestische sensoren toegevoegd en de robot kan nu obstakels vermijden terwijl hij door het appartement beweegt.

Hoewel hij het goed doet in de keuken en hal met goede, stevige vlakke oppervlakken, is hij volledig blind wanneer hij de eetkamer nadert. Het kan de tafel- en stoelpoten niet "zien".

Een verbetering kan zijn om typische motorstromen bij te houden, en als de waarden springen, moet de robot iets hebben geraakt. Het is een goed "plan B" of zelfs C. Maar dat helpt niet echt om door de eetzaal te navigeren.

(Update: eigenlijk is stroombewaking voorlopig plan A bij het achteruitrijden aangezien ik tijdelijk sensoren heb verwijderd en sensoren van achteren).

De video voor deze sectie vormt de laatste fase van sensoren voor het vermijden van obstakels.

Wat je in de video ziet, zijn zes HCSR04-akoestische sensoren aan de voorkant en twee Sharp IR-sensoren. De IR-sensoren speelden niet veel in de video. Hun sterkste punt is meestal wanneer de robot zich in het eetgedeelte bevindt tegenover de tafel- en stoelpoten.

Naast de sensoren kwam vooral de stroommonitor in het spel tijdens het achteruitrijden, voor het geval hij ergens tegenaan stoot.

Ten slotte gebruikt het de geschiedenis van de laatste 100 zetten en een aantal basisanalyses om één vraag te beantwoorden:

"Is er onlangs echte vooruitgang geboekt (of zit het vast in een herhalende dans)?"

Dus als je in de video een voorwaarts-achteruit herhaald ziet, dan draait het, het betekent dat het het voorwaarts-achterwaartse patroon herkende en dus iets anders probeert.

Het enige geprogrammeerde doel van deze versie van de software was om te proberen voortdurend vooruitgang te boeken en obstakels te vermijden.

Stap 1: Ondersteunende schakelingen toevoegen (MCP3008)

Voordat we de IR-sensoren kunnen toevoegen, hebben we de interface-schakelingen tussen hen en de Raspberry Pi nodig.

We zullen een MCP3008 analoog-naar-digitaal converter toevoegen. Er zijn veel online bronnen om deze chip op de Raspberry Pi aan te sluiten, dus daar zal ik hier niet veel op ingaan.

In wezen hebben we een keuze. Als de versie van IR-sensoren op 3V werkt, kan de MCP3008 dat ook, en kunnen we dan rechtstreeks verbinding maken met de Raspberry.

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

In mijn geval gebruik ik echter voornamelijk 5V, dus dat betekent een bidirectionele niveauverschuiver.

[5V IR-sensor] -- [MCP3008] -- [5V-naar-3V bidirectionele bus] -- [Raspberry Pi]

Opmerking: Er is slechts één signaaluitvoer van de IR-sensor. Het gaat rechtstreeks naar een van de analoge ingangssignaallijnen van de MCP3008. Vanaf de MCP3008 zijn er 4 datalijnen die we (via de bidirectionele bus) moeten verbinden met de Raspberry Pi.

Op dit moment gaat onze robot draaien met slechts twee IR-sensoren, maar we kunnen er gemakkelijk meer toevoegen. De MCP3008 acht analoge ingangskanalen.

Stap 2: IR-sensoren monteren

Sharp maakt verschillende IR-sensoren en ze hebben verschillende bereiken en dekkingsgebied. Ik heb toevallig het GP2Y0A60SZLF-model besteld. Het model dat u kiest, is van invloed op de plaatsing en oriëntatie van de sensor. Helaas voor mij heb ik niet echt onderzocht welke sensoren ik precies moest krijgen. Het was meer een "welke kan ik tegen een redelijke tijd en prijs krijgen van een gerenommeerde bron, uit degenen die ze aanbieden" beslissing.

(Update: dat maakt misschien niet uit, omdat deze sensoren in de war lijken te raken door omgevingsverlichting in het interieur. Ik ben dat probleem nog aan het onderzoeken)

Er zijn minstens drie manieren om deze sensoren op de robot te monteren.

1. Zet ze op een vaste plek, vooraan, iets van elkaar af gericht.
2. Plaats ze op een servo, aan de voorkant, iets van elkaar af gericht.
3. Plaats ze in een vaste positie, aan de voorkant, maar op de meest linkse en meest rechtse verste hoeken, schuin naar elkaar toe.

Bij het vergelijken van keuze #1 met keuze #3, denk ik dat #3 meer van het aanvaringsgebied zal beslaan. Als je de afbeeldingen bekijkt, kan keuze #3 niet alleen worden gedaan zodat de sensorvelden elkaar overlappen, maar ze kunnen ook het midden en buiten de buitenbreedte van de robot bedekken.

Bij keuze #1 geldt dat hoe verder de sensoren uit elkaar staan, hoe meer een dode hoek in het midden.

We zouden nr. 2 kunnen doen (ik heb enkele afbeeldingen met servo als mogelijkheid toegevoegd) en ze een sweep laten doen, en dit kan natuurlijk het meeste gebied bestrijken. Ik wil het gebruik van een servo echter zo lang mogelijk uitstellen, om minstens twee redenen:

• We gebruiken een van de PWM-communicatiekanalen op de Raspberry Pi. (Het is mogelijk om dit te verbeteren, maar toch…)
• De huidige trekking met de servo kan aanzienlijk zijn
• Het voegt meer toe aan hardware en software

Ik zou de servo-optie voor later willen laten bij het toevoegen van belangrijkere sensoren, zoals Time-of-Flight (ToF), of misschien een camera.

Er is nog een ander mogelijk voordeel bij keuze #2 dat niet beschikbaar is bij de andere twee keuzes. Deze IR-sensoren kunnen, afhankelijk van de verlichting, in de war raken. Het kan zijn dat de robot een object leest dat op handen is, terwijl er in feite geen object in de buurt is. Met keuze #3, aangezien hun velden elkaar kunnen overlappen, kunnen beide sensoren hetzelfde object registreren (vanuit verschillende hoeken).

Dus we gaan voor plaatsingskeuze #3.

Stap 3: Tijd om te testen

Nadat we alle verbindingen tussen de Raspberry Pi, de MCP3008 ADC en de Sharp IR-sensoren hebben gemaakt, is het tijd om te testen. Gewoon een simpele test om te controleren of het systeem werkt met de nieuwe sensoren.

Net als in eerdere Instructables, gebruik ik de bedradingPi C-bibliotheek zoveel mogelijk. Maakt dingen makkelijker. Iets dat niet erg duidelijk wordt bij het bekijken van de bedradingPi-website, is dat er directe ondersteuning is voor de MCP3004/3008.

Zelfs zonder dat zou je gewoon de SPI-extensie kunnen gebruiken. Maar het hoeft niet. Als je Gordon's git-repository voor bedradingPi goed bekijkt, zul je een lijst met ondersteunde chips tegenkomen, waarvan er één voor MCP3004/3008 is.

Ik besloot de code als bestand bij te voegen omdat ik het niet correct kon weergeven op deze pagina.

Stap 4: Een virtuele sensor - AmpSensor

Hoe meer verschillende manieren u de robot informatie over de buitenwereld kunt laten ontvangen, hoe beter.

De robot heeft momenteel acht HCSR04 akoestische sonarsensoren (ze zijn niet de focus van deze Instructable), en hij heeft nu twee Sharp IR-afstandssensoren. Zoals eerder vermeld, kunnen we profiteren van iets anders: de motorstroomdetectiefunctie van Roboclaw.

We kunnen die vraagoproep naar de motorcontroller in een C++-klasse inpakken en het een AmpSensor noemen.

Door wat "smarts" aan de software toe te voegen, kunnen we de typische stroomafname volgen en aanpassen tijdens rechte bewegingen (vooruit, achteruit), en ook rotatiebewegingen (links, rechts). Zodra we dat bereik van versterkers kennen, kunnen we een kritieke waarde selecteren, zodat als de AmpSensor een stroomwaarde van de motorcontroller krijgt die deze waarde overschrijdt, we weten dat de motoren waarschijnlijk zijn afgeslagen, en dat geeft meestal aan dat de robot is gestoten in iets.

Als we wat flexibiliteit toevoegen aan de software (commando-args en/of toetsenbordinvoer tijdens het gebruik), dan kunnen we de "critical-amps"-drempel verhogen / verlagen terwijl we experimenteren door de robot gewoon te laten bewegen en tegen objecten aan te botsen, zowel recht naar binnen als draaiend.

Omdat ons navigatiegedeelte van de software de bewegingsrichting kent, kunnen we al die informatie gebruiken om de beweging misschien te stoppen en te proberen de beweging voor een korte periode om te keren voordat we iets anders proberen.

Stap 5: Navigatie

De robot is momenteel beperkt in real-world feedback. Het heeft een paar sensoren op korte afstand om obstakels te vermijden, en het heeft een terugvaltechniek om de stroomafname te bewaken als de afstandssensoren een obstakel missen.

Het heeft geen motoren met encoders, en het heeft geen IMU (inertial-measurement-unit), dus dat maakt het moeilijker om te weten of het echt beweegt of roteert, en met hoeveel.

Hoewel je een soort indicatie van afstand kunt krijgen met de sensoren die momenteel op de robot zitten, is hun gezichtsveld breed en is er onvoorspelbaarheid. De akoestische sonar reflecteert mogelijk niet correct; het infrarood kan worden verward door andere verlichting, of zelfs meerdere reflecterende oppervlakken. Ik weet niet zeker of het de moeite waard is om de verandering in afstand te volgen als een techniek om te weten of de robot beweegt en hoeveel en in welke richting.

Ik heb er bewust voor gekozen om GEEN microcontroller zoals een Arduino te gebruiken omdat a) ik niet van de psuedo-C++-omgeving hou, b) en dat te veel ontwikkeling het lees-schrijfgeheugen verslijt (?), en dat ik zou een hostcomputer nodig hebben om (?). Of misschien ben ik gewoon zoals de Raspberry Pi.

De Pi met Raspbian is echter geen realtime besturingssysteem, dus tussen de instabiliteiten van deze sensoren en het besturingssysteem dat niet elke keer precies leest, voelde ik dat het doel van deze sensoren beter geschikt was voor het vermijden van obstakels en niet werkelijke afstandsmeting.

Die aanpak leek ingewikkeld en met niet zo veel voordeel, wanneer we daarvoor (later) betere ToF (time-of-flight) sensoren (SLAM) kunnen gebruiken.

Een benadering die we kunnen gebruiken is om bij te houden welke bewegingscommando's in de laatste X seconden of commando's zijn gegeven.

Stel bijvoorbeeld dat de robot diagonaal in een hoek vastzit. De ene set sensoren vertelt hem dat hij te dicht bij de ene muur is, dus hij draait, maar de andere set sensoren vertelt hem dat hij te dicht bij de andere muur is. Uiteindelijk herhaalt het gewoon een patroon van links naar rechts.

Het bovenstaande voorbeeld is slechts een heel eenvoudig geval. Het toevoegen van wat slimmigheden kan het herhaalde patroon misschien naar een nieuw niveau tillen, maar de robot blijft vastzitten in de hoek.

Voorbeeld, in plaats van op zijn plaats heen en weer te draaien, draait hij in één richting, keert hij tijdelijk terug (waardoor dan de kritieke afstandsindicaties worden gewist), en zelfs als hij in de andere richting draait, gaat hij nog steeds onder een bepaalde hoek vooruit in de hoek, herhalend een ingewikkelder patroon van in wezen hetzelfde.

Dat betekent dat we echt een geschiedenis van commando's kunnen gebruiken en een kijkje kunnen nemen hoe we die informatie kunnen exploiteren en gebruiken.

Ik kan twee zeer basale (rudimentaire) manieren bedenken om de bewegingsgeschiedenis te gebruiken.

• voor het laatste X aantal zetten, komen ze overeen met het Y patroon. Een eenvoudig voorbeeld zou kunnen zijn (en dit gebeurde) "VOORUIT, ACHTERUIT, VOORUIT, ACHTERUIT, …". Er is dus een overeenkomende functie die TRUE (patroon gevonden) of FALSE (niet gevonden) retourneert. Indien WAAR, probeer in het navigatiegedeelte van het programma andere bewegingsreeksen.
• voor de laatste X aantal zetten, is er een algemene of netto voorwaartse beweging. Hoe kan men bepalen wat echte voorwaartse beweging is? Nou.. een gemakkelijke vergelijking is dat voor de laatste X zetten, "FORWARD" meer voorkomt dan "REVERSE". Maar dat hoeft niet de enige te zijn. Wat dacht je van: "RIGHT, RIGHT, LEFT, RIGHT". In dat geval moet de robot naar rechts draaien om uit een hoek te komen of omdat hij de muur onder een hoek naderde, dat zou als echte voorwaartse vooruitgang kunnen worden beschouwd. Aan de andere kant kan "LINKS, RECHTS, LINKS, RECHTS…" misschien niet als echte vooruitgang worden beschouwd. Dus als "RIGHT" meer voorkomt dan "LEFT" of "LEFT meer dan "RIGHT", dan zou dat een echte vooruitgang kunnen zijn.

Aan het begin van deze Instructable zei ik dat een mogelijk derde doel zou kunnen zijn om een muur uit te lijnen of uit te lijnen. Daarvoor hebben we echter meer nodig dan "zijn we dicht bij een object". Als we bijvoorbeeld twee naar voren gerichte akoestische sensoren kunnen krijgen (niet de focus van dit artikel) om redelijk goede, stabiele reacties met betrekking tot afstand te geven, is het duidelijk dat als de ene een veel andere waarde rapporteert dan de andere, de robot de muur heeft benaderd onder een hoek, en zou kunnen proberen te manoeuvreren om te zien of die waarden elkaar naderen (recht tegenover de muur).

Stap 6: Laatste gedachten, volgende fase…

Ik hoop dat dit Instructable enkele ideeën heeft gegeven.

Het toevoegen van meer sensoren introduceert enkele voordelen en uitdagingen.

In het bovenstaande geval werkten alle akoestische sensoren goed samen en was het vrij eenvoudig met de software.

Toen de IR-sensoren eenmaal in de mix waren geïntroduceerd, werd het een beetje uitdagender. De reden is dat sommige van hun gezichtsvelden overlapten met die van de akoestische sensoren. De IR-sensoren leken een beetje gevoelig en onvoorspelbaar met veranderende omgevingslichtomstandigheden, terwijl de akoestische sensoren natuurlijk niet worden beïnvloed door verlichting.

De uitdaging was dus wat te doen als een akoestische sensor ons vertelt dat er geen obstakel is, maar de IR-sensor wel.

Voor nu, na trial-and-error, eindigde het in deze prioriteit:

1. amp-sensing
2. IR-detectie
3. akoestische detectie

En wat ik deed was gewoon om de gevoeligheid van de IR-sensoren te verlagen, zodat ze alleen objecten van heel dichtbij zouden detecteren (zoals dreigende stoelpoten)

Tot nu toe was het niet nodig om multi-threading of interrupt-gestuurde software te gebruiken, hoewel ik af en toe verlies van controle tegenkom tussen de Raspberry Pi en de Roboclaw-motorcontroller (verlies van seriële communicatie).

Dit is waar het E-Stop-circuit (zie vorige Instructables) normaal gesproken in gebruik zou komen. Aangezien ik echter (nog) niet te maken wil hebben met het resetten van de Roboclaw tijdens de ontwikkeling, en de robot niet zo snel gaat, en ik aanwezig ben om hem in de gaten te houden en uit te schakelen, heb ik dat niet gedaan. de noodstop aangesloten.

Uiteindelijk zal multi-threading hoogstwaarschijnlijk nodig zijn.

Volgende stappen…

Bedankt dat je zo ver bent gekomen.

Ik heb een aantal VL53L1X IR-laser ToF-sensoren (time-of-flight) verkregen, dus dat is waarschijnlijk het onderwerp van de volgende Instructable, samen met een servo.