Új hozzászólás Aktív témák

• #13 Jackal2 senior tag fape #4

  Új Válasz 2016-04-11 20:55:08 #13

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Jackal2

  senior tag

  válasz fape #4 üzenetére

  Lehet rosszul fogalmazom meg a gondolataimat, mert csak bele-bele kaptam a témába, de amit észrevettem mostanában és elég nagy téma, az a PID tuningolás. NEM BIZTOS HOGY JÓL ÍROM, MERT MÉG NEM VAGYOK NAGYON KÉPBEN, szóval valaki javítsa.

  Kicsit úgy írnám le, mint a forma1-es autók finomhangolása. Van Zsoleszfpv-nek egy jó cikke róla, azt olvassátok el, de a lényeg, hogy:
  - a kameraplatform vezérlők és a racer vezérlők totál eltérnek egymástól
  - kameraplatform vezérlők, mint APM, NAZA, Pixhawk stb. rohadt sok szenzor adatait dolgozzák fel, lassan, stabil de lassú
  - racer vezérlők kevés adatot iszonyat gyorsan dolgoznak fel, hogy a reakció sokkal gyorsabb legyen, mert a fordulatszám egy mp. alatt akár 30.000-0-30.000 is lehet, fékezni kell, meg a beömlő adatokkal kell kezdeni valamit

  Mivel ezek számításigényes lebegőpontos számítások, ezért elkezdtem átnézni az architektúrát, hogy hogyan is épül fel. A legtöbb vezérlő az STM32 processzor valamelyik verziójára épül. Jó alap az, ha azt nézzük, milyen verziói vannak az STM32-nek, pl.:
  - STM32 F1 a Naze 32 acro és full
  - STM32 F3 az összes újabb vezérlő, Dodo, Sparky, Motolab Tornado, Seriously Pro Racing F3 stb. itt van matematikai co-processzor az ilyen számításokra
  - STM32 F4 brutál drága, vadonat új vezérlőkön lehet elvétve találkozni vele

  Na most a PID feldolgozása akkor egyszerű, ha kevés szenzor kevés adatot ad, gyorsan. Mivel a PID-et - én, jelenleg - egy olyan függvénydoboznak képzelem el, ahol a szenzorok képviselik a változókat, minél kevesebb szenzor adatait kell egymással összehasonlítgatni és visszacsatolást adni a múlt, a jelenlegi és a jövőbeni állapot miatt, annál gyorsabb a művelet. Ugye milyen paraméterek jöhetnek be:
  - accelerométer, ez mindig bejön
  - gyro stabilizált módban bejön
  - magnetométer az iránymeghatározáshoz
  - barométer a magasságtartáshoz
  - GPS a pozíciómeghatározáshoz

  Jó sok paraméter. Mivel ez az egész egy visszacsatolásos alapon működő matematikai kör, ezért ez hurokként ismétlődik, vagyis nem mindegy, hogy a hurok "mikor ér körbe" és adja le a vezérlő az ESC-k felé a loopot. Ezt úgy szokták jelölni, hogy a gyorsabb a kisebb, vagyis az 1200 Loop jobb mint a 2400. Gondolom kevesebb processzoridőt emészt fel vagy ilyesmi.

  Ezért nagyon nem mindegy, hogy milyen módban repülünk és milyen szenzorok működnek közben. Nyilván az Acro a leggyorsabb, a második leggyorsabb a Horizon jellegű dolgok. Ezért sincs értelme GPS-el bohóckodni a racereken meg barométerrel.

  A másik, ahogy Fape is írja, hogy milyen protokollal valósul meg a vezérlés, I2C, SPI vagy akármi, ezeknek a mintavételezési sebessége is más. Valami olyasmi rémlik, hogy az I2C-nél 1 kiloherz volt a mintavételezési freki míg az SPI-nél 8KH, szóval elvileg az SPI 8x gyorsabb,

  Ha emlékeztek még a PWM-re, ott a mintavételezés 1KHZ-volt, ezt vették alapnak. Volt a Oneshot125 is, ami szerintem azért 125 mert az 1KHZ 1/8-ada. Ez gyorsabb reagálást tesz lehetővé, de terheli a processzort (volt erről cikk a blogomon, csak nem akarom bevágni, mert egy korlátolt 3 betűs admin többször kitiltott miatta) .

  Na most az új menőség a Multishot, ez 10x gyorabb a Oneshotnél, ami kb. 5-25 microsecundumos válaszidőt ad, ha tudja az ESC. Ugye ezt viszont fel is kéne dolgozni, ehhez viszont még durvább processzor kell, ezek az F4-ek, viszont elvileg a gépek is sokkal gyorsabban reagálnak.

  Ez így értelmes amit írtam?

  Az alábbi blog szerkesztője: quadkopter.blog.hu

Új hozzászólás Aktív témák