Hirdetés
-
Rossz üzlet az EV-kölcsönzés
it Küszködik az EV-kölcsönzés miatt a Hertz Global, még több EV-t adnak el.
-
VR játék lesz az Alien: Rogue Incursion
gp Az év végén érkező program PC-re, Meta Quest 3-ra és PlayStation VR2-re érkezik a tervek szerint.
-
Olcsó 5G-s ajánlatot nyújt a Realme Indiának
ma Megérkezett a Realme C65 5G, az első készülék a MediaTek Dimensity 6300-zal.
Új hozzászólás Aktív témák
-
Jackal2
senior tag
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 valamitMivel 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 veleNa 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áshozJó 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
Egyéb, hasonló témájú topikok:
● Fimi drónok
● Drón topik
● DJI topic