Stap 1: De sturende deel
Om het script 3 te bouwen delen moeten worden beschouwd: het 'Steering' deel, die kan worden afgeleid uit de hardwarekenmerken, het deel van de 'Controlled', de algoritmes die omgaan met de verschillen (fouten) tussen de ramingen en werkelijkheid en het 'Werkelijke' gedeelte, bestaande uit de gegevens van de sensoren (actuatoren) gebruikt, voorlichting over de meest waarschijnlijke werkelijkheid (!).
De effectiviteit van het script is sterk afhankelijk van de nauwkeurigheid van de actuatoren gebruikt. Bijvoorbeeld: als de oude zeilers zou hebben gehad een GPS-systeem, ze hadden meer nauwkeurige gegevens op hun huidige positie.
Met behulp van meer, anders, actuatoren zoals coderingsprogramma's, een digitaal kompas, een GPS-retriever (voor buiten gebruik) of zelfs een gyroscoop, zou produceren meer nauwkeurigheid over de werkelijke situatie. Helaas maakt het het gecontroleerde deel een beetje meer complex, want het moet omgaan met de gewogen invloed van de afzonderlijke sensoren om te bepalen van de meest nauwkeurige gegevens over de werkelijke positie ('sensor fusion').
Elke actuator gebruikt, ten minste enkele bijzondere 'ruis' in de vergelijkingen zal brengen. Als een GPS-ontvanger worden gegevens op een stabiele positie voor, laten we zeggen, 24 uur ophaalt zou, zou het plotten van die gegevens worden verspreid over de huidige positie. Daarvoor is de nauwkeurigheid van een GPS-systeem wordt uitgedrukt door 95% van de lezingen vallen binnen een bepaald bereik (bijvoorbeeld < 5 meter). Men moet een geavanceerdere controle-lus gebruiken om te gaan met het filteren van ruis van de sensor en balanceren het gewicht tussen de afzonderlijke actuators. De Kalman-filter wordt vaak gebruikt voor die.
Dus het om eenvoudig te houden in mijn eerste verkenningen, ik vast aan een enkele bedieningssleutel en alleen gebruikt encoders. Ze genereren 'teken' per rotatie van het wiel assen, dus met gegevens over de werkelijke draaien van de wielen (die eigenlijk geeft informatie over snelheid en/of afstand).
Er zijn vele verschillende encoders. Optische codeerapparaten vaak een gesegmenteerde schijf gebruiken voor het meten van de veranderingen (van solide aan niet-effen en omgekeerde) met een infrarood sensor. De resolutie (d.w.z. hoeveelheid teken per omwenteling van de as van het wiel) van optische codeerapparaten is vrij laag en dus beperkt de nauwkeurigheid die kan worden bereikt. Andere encoders gebruik maken van magnetische schijven en doen een veel hogere resolutie. Optische codeerapparaten zijn veel goedkoper en gemakkelijk melodie/gebruik. Tot slot kunnen de encoders single of quadrature zijn. Het laatste biedt ook gegevens over de richting van de rotaties van de wiel.
Rb2 heeft één optische codeerapparaten. Ze zich verzetten tegen beperkingen; vooral op de juistheid (> = centimeter) en de gemeten frequentie (we moeten ten minste 1 teek te geef het gecontroleerde deel).
Nu laten we een duik in het gedeelte 'Steering'. Het is het meest feitelijke deel en alle variabelen nodig kunnen worden vooraf berekend en gebruikt als constanten in het script. Als het script is bedoeld om te worden gebruikt op verschillende Bezoekende robots, moet het 'Steering' deel worden behandeld in de initialisatie routine van het script.
Enkele feiten over RB2:
- Het chassis is een DF Robot Baron (4 motoren, verbonden als 2 differentieel motoren) + extra montage vloer
- Optische codeerapparaten op de 2 voorste wielen, het genereren van 20 teken per omwenteling.
- De afstand tussen het midden van de wielen = 0.147 m.
- De wieldiameter = 0.065 m.
Deze feiten kunnen worden gebruikt voor het berekenen van enkele belangrijke gegevens:
- De omtrek van de wielen = 0,20 m (d.w.z. Pi * de wieldiameter)
- De hoeveelheid teken per meter = 97.9 t/m (dat wil zeggen ticks_per_revolution / wiel _perimeter)
- De full_turn_perimeter = 0,46 m (d.w.z. wheel_center_distance * Pi) bij gebruik van beide zijden in de teller revolutie! Ik zal aan dat recenter komen wanneer duiken in draaien door een bepaalde hoeveelheid graden
- De hoeveelheid ticks_per_full_turn = 45.2 t (d.w.z. full_turn_perimeter * ticks_per_meter)
- De hoeveelheid ticks_per_degree = 0.13 t (ticks_per_full_turn / 360)
Dus we al een heleboel nuttige gegevens hebben, maar we ook enkele cijfers afhankelijk van de snelheid moeten. We willen weten van de maximumsnelheid, die de robot kan bereiken. Soms de leverancier verstrekt de gegevens op de kit en/of de motoren, maar die bleek te zijn ver weg. Ik maakte sommige berekeningen op de maximale rotatie op de motoren, de verhouding van de aftrek van de gearing in aanmerking te nemen, maar dat bleek ook ver weg.
Voor een heleboel redenen voor de hand liggende (en minder voor de hand liggende): lichte productie verschillen (zelfs wanneer overgenomen uit de dezelfde serie), tandwieloverbrengingen weerstand (smering), kleine wiel verschillen (midden positie, diameter), de grip van de banden, het gewicht van de auto en hoe het wordt gedistribueerd en een heleboel milieu-invloeden zoals: het oppervlak (weerstand, oneffenheden, vlakheid) en zelfs de luchtweerstand. Alle factoren die niet kunnen worden behandeld in het model van controle en waarom sommige waarschijnlijk gegevens moet worden verworven door het testen van upfront (terwijl het houden van zoveel factoren zo constant mogelijk).
De maximumsnelheid van de robot kan best worden gevonden door het uit te voeren in de zelfde omgeving op maximale PWM voor een bepaalde tijd en meet de afstand gemaakt in het midden van deze run. Ik denk dat dit kan het best worden gemeten door het tellen van de encoder teken en herberekenen deze in meter (daarmee zal ten minste rekening het coderingsprogramma ruis).
Rb2 kwam met 0.31 m/s (de leverancier verstrekt 0.68 m/s). Met dit cijfer kunnen we berekenen een andere variabele nodig: de max_ticks_per_second = 30.4 t/s (dat wil zeggen ticks_per_meter * max_speed)
We moeten eindelijk de overtreksnelheid. Dit kan ook worden gevonden door te testen: beginnen met 0,0 PWM en verhogen van de PWM tot de robot echt begint te verplaatsen. Het is gebruikelijk om 5-30% van uw totale PWM-bereik. Voor RB2, ik kwam met: 0.124 m/s.
Nu hebben we alle gegevens voor het schatten van de snelheid en afstand gemaakt door de robot te steken van een bepaalde afstand met een bepaalde snelheid. De onderstaande figuur toont het typische diagram voor dergelijke een run.
