Stap 2: Het besturingselement lus
De stuurgroep deel biedt de feiten voor onze berekeningen. De volgende stap is de schatting van waar de robot als een begin van de gecontroleerde deel van het script worden moet.
We moeten allereerst Kies een interval voor de lus van de controle met inbegrip van de metingen van de sensor. Hoe kleiner het interval, hoe beter: een snelle feedback op onze schattingen maken door de gegevens van de encoders. Bij voorkeur moet de interval ongeveer 0.01 seconde.
De Dagu Arduino zoals mini bestuurder van RB2 kunt een interval van de feedback voor de sensoren van 0.01 sec. Maar er waren sommige dingen om te overwegen. In het eerste er zijn verschillende bronnen van uitstel (bv. de uitvoeringstermijn voor de controle-lus zelf). Ten tweede is om rekening te houden de resolutie van de encoder. Met andere woorden: de minimale tijd die nodig is voor het genereren van ten minste 1 teek op snelheid (dat wil zeggen de overtreksnelheid) beginnen. Voor RB2 wordt 0.1 sec gebruikt als interval. Een 10 keer lagere feedback frequentie heeft de gevolgen ervan op de controle-lus: het beperkt de mate van afstemming van de fouten en aanpassingen. Een baan van 2 meter duurt een goede 6 seconden te voltooien (0.31 m/s). In deze periode zal alleen er minder dan 60 momenten de actuator-gegevens lezen en uitvoeren van de berekende aanpassingen.
Voor goede tuning (ik kom daar bij het beschrijven van de controle-lus) moet men ten minste een paar honderd evaluatie lussen. U kunt kijken naar het effect in de video aan het begin van de blog: de correcties over de richting zijn soms een beetje abrupt. Met een hogere frequentie van de feedback zal toelaten om gladde-nl de correcties meer. (Een andere oorzaak is de resolutie encoder: de minimale fout die kan worden gelezen is 1 teek. Dus wat je ziet op de video, is de beste die ik uit de situatie kon drukken.)
Het is essentieel dat de evaluaties worden gedaan met een constante frequentie. Variaties in de intervallen zijn rampzalig voor de controle-lus! Dat is waar ik werd geconfronteerd met een andere hindernis. Ik begon met behulp van de functie van de time.time() Python, maar ontdekte het gemaakt van sommige rare pieken. Zelfs wanneer alleen het draaien van een script met alleen de interval lus zelf. Dus ik overgestapt naar de functie van de time.clock() die is gebonden aan de processortijd zelf en rende het script op een Windows, een Unix en een linuxsysteem. Halas met geen betere resultaten. Zelfs geprobeerd threading. Timer () voor het genereren van een lus van de timing als een aparte thread. Dit werkte goed, maar maakte het script veel te ingewikkeld (voor mij). Zoals je in het script lezen kunt, ik eindigde met de aftopping van de timer op een maximaal en de controlelussen overslaan wanneer de timer de limiet overschrijdt. Een beetje ruw en het heeft de gevolgen ervan op de nauwkeurigheid, maar het werkt beter dan het hebben van teveel varianties in de controlelussen. Waarschijnlijk kan één produceren een betere timing/gebeurtenisafhandeling in C/C++, maar voor mij dat zou me teveel tijd om erachter te komen in het licht van wat het script moet doen.
Dus op elke 0.1 sec de encoders worden gelezen, de verschillen (fouten) op onze schatting worden berekend en er is een nieuwe schatting gemaakt. In het script is de gewenste snelheid van de bot berekend en ingesteld als doel. Doelstellingen zijn vaker 'Basiswaarden' genoemd. In het script is een Setpoint de gewenste snelheid vermenigvuldigd met de intervaltijd, de hoeveelheid teken te maken in het interval op te geven. Dit is eigenlijk niet correct. De gewenste snelheid is de snelheid aan het einde van het interval. Als men wil werken nauwkeuriger, moet men gebruik maken van de vergelijking: Vt = Vo + a.t of op zijn minst de gemiddelde snelheid: (Vt-Vo) / t om de exacte hoeveelheid teken dat moet worden gemaakt in het interval te berekenen. (V staat voor snelheid in m/s, een = de acceleratie en t = de intervaltijd).
Gezien alle beperkingen die ik al heb beschreven, hield ik het eenvoudig. Als de video toont, kan men toch redelijke resultaten bereiken. Met een setpoint opgericht, wordt het bot uitgevoerd bij een bepaalde snelheid en aan het begin van een nieuw interval, het setpoint kan worden afgewogen tegen de gegevens van de encoder. Dat is waar het gecontroleerde deel begint.
