RB2 rinnande rutor. (1 / 4 steg)

Steg 1: Den styrande delen

För att bygga skriptet 3 huvuddelar måste anses: "Styrning" del, som kan härledas från maskinvaruegenskaper, "Kontrollerade" del, de algoritmer som behandlar skillnaderna (fel) mellan anseenden och verklighet och den "Faktiska" delen, som består av data från sensorer (givare) används, som ger information om den faktiska situationen mest troliga (!).

Skriptet kontrollsystemets tungt riktigheten av manöverdonen används. Till exempel: om de gamla sjömännen hade ett GPS-system, de skulle ha haft mer exakta uppgifter på deras faktiska position.

Med fler, annorlunda, manöverdon som kodare, digital kompass, en GPS retriever (för extern användning) eller ens ett gyroskop, skulle producera mer noggrannhet på den faktiska situationen. Tyvärr gör den kontrollerade delen lite mer komplex, för det ska hantera vägda påverkan av den separata sensoren att bestämma den mest exakta uppgifter om den verkliga positionen ('sensor fusion").

Varje ställdon används, åtminstone kommer att ge vissa särskilda "brus" i ekvationer. Om en GPS-mottagare skulle hämtar data på en stadig position för, låt oss säga, 24 timmar, skulle plottning av dessa data vara spridda runt den verkliga positionen. Detta uttrycks riktigheten av ett GPS-system med 95% av de avläsningar som faller inom ett visst intervall (t.ex. < 5 meter). För att ta itu med filtrering sensor buller och balansera vikten mellan de separata manöverdon bör man använda en mer sofistikerad kontrollerar kretsar. Kalman-filter används ofta för detta.

Dagu Arduino som mini föraren av RB2 kan en feedback intervall för sensorer på 0,01 sek. Men det fanns några saker att tänka på. På första där är flera källor till dröjsmål (t.ex. körningstiden för den kontrollerar kretsar sig). Andra är för att ta hänsyn till resolutionen som encoder. Med andra ord: den minsta tid som krävs för att generera minst 1 Markera start (dvs. den stall hastighet). För RB2 används 0.1 SEK som intervall. En 10-gånger lägre feedback frekvens har dess konsekvenser på det kontrollerar kretsar: det begränsar graden av tuning för fel och justeringar. En bana på 2 meter tar en bra 6 sekunder till slut (0.31 m/s). Under denna period blir bara mindre än 60 stunder att läsa manöverdonet data och genomföra de beräknade justeringarna.

För god stämning (jag kommer till det när du beskriver den kontrollerar kretsar) bör man minst ha ett par hundra utvärdering loopar. Du kan titta på effekten i videon i början av bloggen: korrigeringar på riktningen är ibland lite abrupt. Att ha en högre frekvens feedback kan till slät-en korrigeringarna mer. (En annan orsak är resolutionen som encoder: den minsta fel som kan läsas är 1 Markera. Så vad du ser på video, är det bästa jag kunde klämma ur situationen.)

Det är viktigt att utvärderingarna som görs på en konstant frekvens. Variationer i pauserna är katastrofala för det kontrollerar kretsar! Det är där jag konfronterades med annan hindret. Jag började använda Python time.time() funktionen, men fick reda på det skapade några konstiga toppar. Även när bara kör ett skript med endast en intervall slinga sig själv. Så jag bytte till funktionen time.clock() som är bunden till processortiden sig och sprang skriptet på en Windows, Unix och ett Linux-system. Halas utan bättre resultat. Försökte även threading. Timer() att generera en timing loop som en separat tråd. Det fungerade bra, men gjorde skriptet alldeles för komplicerat (för mig). Du kan läsa i manus, jag slutade med tak timern på maximalt och hoppa över reglerkretsarna när timern överskrider gränsen. En bit grov och det har dess konsekvenser på noggrannhet, men det fungerar bättre än att ha för mycket avvikelser i reglerkretsarna. Förmodligen kunde man producera en bättre timing/händelsehantering i C/C++, men för mig som skulle ta mig för mycket tid att ta reda på med tanke på vad skriptet gör.

Så varje 0.1 SEK läses kodare, skillnaderna (fel) på vår bedömning beräknas och en ny bedömning görs. I skriptet är bot önskad hastighet beräknas och anges som mål. Mål är oftare kallas "Setpunkter". I skriptet är en Setpoint önskad hastighet multiplicerat med tidsintervall, ger mängden fästingar att göra i intervallet. Detta är egentligen inte korrekt. Önskad hastighet är hastigheten i slutet av intervallet. Om man vill arbeta mer exakt, en bör använda ekvationen: Vt = Vo + Asson eller åtminstone genomsnittlig hastighet: (Vt-Vo) / t för att beräkna den exakta mängden fästingar som bör göras i intervall. (V står för hastighet i m/s, en = acceleration och t = tiden intervall).

Ta i beaktande alla begränsningar jag beskrev redan, höll jag det enkla. Som video visar, kan man nå rimliga resultat i alla fall. Att ha en setpoint etablerade, körs bot vid en viss hastighet och i början av ett nytt intervall, normvärdet kan utvärderas mot encoder data. Det är där den kontrollerade delen börjar.