Naprosto souhlasím s tím, že 8bit desky už jsou dávno za zenitem...Sám už bych do žádný coptery něco jako MWii, KK, nebo jiný čínský paskvily nedal...Osobně doporučuji, když už ne rovnou A2, nebo DJI NAZA, tak alespoň cenově dostupnější ArduPilot( Arduflyer je čínská kopie, ale svou práci také odvede)..
Tady je seznam desek, které jsem dělal zhruba před rokem:
http://www.quadcopter.8u.cz/rozdeleni-ridicich-desek-od-elkory-prubezne-aktualizovano/
V seznamu i komentari mas par nepresnosti (APM s 2560 neni 32bit, ArduPilot je software a nikoliv deska atd...) ,nektere jednotky tam vubec nejsou (Naze32 a PixHawk)
Zrovna Pixhawk v posledni dobe Nazu dost valcuje - napr. v US jsou povolene drony pro rozvoz leku nebo se pouzivaji drony pro lokalizaci ruseni v okoli letist. Oba stroje pouzivaji ramy od DJI ale nepouzivaji jejich jednotky ale PixHawk.
BTW : Pixhawk ma zdvojene IMU - pouziva MPU6000 (takze na rozdil od zde resene MPU6050 muze pouzivat SPI ktere je rychlejsi nez I2C) a k tomu jeste LSM303D (accel/kompas) a L3GD20 gyro. Data umi prumerovat z obou IMU a dosahuje tak vyrazne vyssi stability.
Mno Takový jednotky tam jsou dvě co obsahují jak cop. 2560, pro samotné řízení výkonu...Ale pro výpočty a ostatní je tam druhej procesor, kterej už 32 bit je (ATMEGA32U) a jestliže ho výrobce presentuje jako 32bit IMU, tak to nebudu dávat do 8bitů.
Ten Pixhawk tam určitě doplním...Bylo to v plánu, ale byl jsem půl roku mimo tak na to nedošlo...Desek tam určitě chybí víc...Stačí napsat dolů do komentářů a připojit odkaz a já už to doplním...To se týká i nepřesností, které se tam mohou vyskytnout i když jsem se snažil ze stránek prodejců i výrobců vycucnout co šlo, ale ne vždy jsou informace relevantní..
APM ardupilot deska je...nebo ji alespoň pod tímto názvem prodává x výrobců...Navíc je to originál( vedle toho existuje čínská kopie Arduflyer). Obě mám doma takže vím o čem mluvím...;)..
Toho pixe plánuju koupit až budu dělat octo s rámem ala Amazon...Dost se mi na něm líbí i to, že už má všechny výstupy připravené...Chceš zapojit ledky? stačí zasunout konektor tam kde je napsáno LED....;)
Zajímalo by mě, jak vypadal software na Raspberry Pi, který dělal regulaci. To byl obyčejný unixový/linux proces nebo měl alespoň nastavený realtime scheduler?
Jednoduchý cyklický plánovač, běžící na Arduinu nebo obecně na 8 bitovém Atmelu by byl v tomto případě samozřejmě daleko lepší.
Arduino je velmi pěkný framework pro snazší programování mikrokontrolérů Atmel Atmega, ale nehodí se pro stabilizaci letu. Aby regulátory svoji práci odváděly s úspěchem, musí frekvence aktualiace stabilizace letu byt vyšší jako frekvence vlivů (vítr, kmitání pi regulátoru, nepřesnost měření, 8bit čísla).
Na 8bit procesorech s frekvenci kolem 16MHz lze problem regulace úspěšně řešit absolutni kontrolou nad kódem a velmi optimalizovaným navrhem - použít assembler a použít jen ty periferie, které svým přesným a stabilním měřením přispějí k přesnostem vypočtu, barometr je zbytečné řešit na tak nízké úrovni, kde je třeba řešit hlavně, aby se kvadrokoptéra udržela ve vzduchu a stabilizace fungovala tolik přesně, aby byla možná správa letu počítačem. Človek s RC ovladačem je taky stabilizátorem letu a proto není třeba tak dokonalé řídící desky! Proto dostupná řešení stačí jen pro poletovaní, ale ne počítačem spravovaný let.
Pokud zde jde o vyuzití hotových řešení a manuální správu letu pilotem, šáhl bych alespoň po řídící desce KK2.1.5 s firmwarem od Steveis, následně bych upravil část věnující se vstupům z přijímače a upravil bych ji pro vstup z Raspberry Pi (jediné HW PWM jako PPM signal nebo přímo seriovou sběrnici, kde je ale problém s nároky na výkon a obsluhu přerušení). Ideální pro tuto úpravu, ale dražší, je např. řídící deska AfroFlight Naze32. Komerční profi řešení jsou tvořena příliš na pevno, jsou extrémně drahá a platí se za jejich nápad a značku.
Použít na stabilizaci pouze Raspberry Pi je úplné selhání při analýze. Chápu to nadšení pro Raspberry Pi, ale RPi se standardním OS není určeno pro realtime řízení a pokud je na to upraveno, nelze při této aplikaci (řízení stabilizace a letu) využít jeho potenciál, i v tomto případě je nějaká pravdepodobnost, že se RPi dostane do stavu, kdy znemožní stabilizaci na dost dlouho, aby došlo k pádu. Navíc by byl u RPi veškerý výkon vypotřebován na jednoduché stabilizaci letu. Hlavním problémem je, že OS neprovede to co po něm spuštěný program chce v ten moment, kdy to program chce. Nelze s přesností říct, kdy bude příkaz vykonán a je to dáno obsluhou přerušení, které musí systém vykonat jen pro svuj stabilni provoz.
Nicméně je zde Arduino nováček, který by tuhle práci zvládl nějakým způsobem řešit i s použitím Arduino frameworku. Jmenuje se Teensy 3.
Osobně se kloním k použití procesorů ST STM32 4.řady a vlastniho designu PCB. STM32 je tolik výkonné, že je výhodnější programovat v c/c++ a vyuzit std. knihoven. V praxi jsem STM32 použil pro realizaci stabilizace pohonu a jízdy, velmi přesnou odometrii a správu jízdy u pozemního robota. Nejjednoduššími úkoly při realizaci robota byla stavba a navigace. Míra úspěšnosti řešení závisí na tom, jak perfektně a jak předvídatelně dokážete součásti ovládat (mam na mysli regulaci motorů/pohonu jednotlivě i jako celek, jak směrodatná jsou data z senzorů, apod.), pak je správa jizdy/letu a navigace naprosto jednoduchá.
Dobrý den,
myslím, že přeceňujete nutnost RT řízení quadrocoptéry, nejspíš proto, že nevíte, jak vlastně její stabilizace funguje. Jak je napsáno v článku, těžko budete upravovat výkon motorů s frekvencí vyšší, než je 200 Hz, neboť víc neumožňuje MPU6050. To je celá myšlenková úvaha co se RT potřeb týče, všechno ostatní je nadbytečné.
Pokud upravím výkon, tak se náklon začne měnit. Aproximaxe posledních dvou čtení mi neřekne, jak moc moje změna výkonu upravila náklon. Dokud řízení spočívá ve změně výkonu, tak nedává smysl ho měnit, dokud nemám nové měření.
Pro výpočet výkonu samozřejmě má smysl použít několik posledních měření, spočítat diferenciály změn apod. Ale jakmile mi z té rovnice vyjde výkon, jaký mám nastavit, tak ho prostě nastavím. Dokud nepřijde nový údaj, tak mi ta rovnice lepší výsledek nedá.
Výstup z IMU na hobby řídící desce je jen jeden zdroj informací a stačí pro hobby použití, ale ne pro řízení počítačem. 200Hz je frekvence novych DMP dat v IMU, ale neznamená to, že jsou tyto data přesná. Ne vždy více cool informace (DMP) znamenají více přínosu, DMP neni bůhví jaká výhra. MPU6050 není zrovna přesné IMU a není dobré čist informace jen z DMP, data z jednotlivých senzorů lze přijimat rychleji a ne u všech pid regulatoru je třeba znát data z DMP, důležitá data jsou data z gyroskopu. Vůbec neuvažujete frekvenci aktualizace regulátorů motorů, normálně není rychlost otáčení motorů a další veličiny známé, protože je komunikace s regulátory jednosměrná. Některé regulátory motorů umožňují úpravu pro komunikaci např. po I2C. Programování řídící desky je jen jedna část soustavy regulátorů multikoptéry. Pro úplnou kontrolu nad letem musí být odezva na změny co nejrychlejší a hlavne správná, aby byla reakce včasná. Reagovat na stará data je kontraproduktivní. Pokud by se braly v úvahu jen DMP data, která jsou aktualizována pomalu, pak je naprosto důležité, aby odezva na vstup DMP dat byla okamžitá. Vzhledem k "rychlosti" aktualizace DMP dat je rozumné je použít jen pro absolutní orientaci letounu a pro stabilizaci letu použít přímá data z gyroskopu a akcelerometru (ideálně více jednotek na těle multikoptéry, např. páry IMU na protilehlých ramenech) a použit SPI misto I2C, moderní ARM procesory mají mnoho SPI rozhraní, takže není třeba sběrnice sdílet. Regulátory motorů pro multikoptéry aktualizují s frekvencí i 8kHz, tak je žádoucí minimalizovat bottleneck v řídící jednotce a využít plný potenciál soustavy.
Aktualizovat ESC co nejdříve po získání dat z DMP je rozhodně dobrá připomínka, ale nesouhlasím s tím co píšete ohledně DMP samotném. DMP provádí matematickou fůzi údajů z gyroskopu a akcelerometru a to z několika vzorků.
Nebudu moc bláhový, když se domnívám, že DMP není žádný bastl, ale provádí nejoptimálnější možnou matematickou operaci nad těmito daty.
Data z gyroskopu a akcelerometru můžete číst s mnohem vyšší frekvencí než z DMP, ale k čemu vám to bude? Jednotlivé vzorky jsou velice zašuměné, stějně je budete muset filtrovat = tak jako tak zkreslení výstupu. Tak proč se s tím štvát a nepoužít rovnou DMP?
Mám takový pocit, že mluvíte o IMU jako o něčem, z čeho se dá jasně určit pohyb kvadrokoptéry, ale to není možné kvůli načítající se chybě a troufnu si říct že je úplně jedno, jak sofistikované řešení použijete. Co je podle vás nutné k tomu, řídit kvadrokoptéru z počítače? K tomu se tak jako tak bude používat především zpracování obrazu.
Ano, filtrovat a kalibrovat je třeba každý výstup z IMU, to je naprosto základní. Nefiltrovaná a nekalibrovaná data jsou především u Invensense IMU téměř nepoužitelná (hlavně magnetometr, ale o ten tu momentálně nejde). Ideálním filtrem je optimalizovaný kalmanův filtr. DMP už určité filtrování obsahuje, takže není nutné filtrovat data z DMP jakoby trpěla nahodilostí, ale určitý filtr se hodí i zde. DMP v MPU6050 není stejně jako samotné IMU designováno pro použití v multikoptérách (spousty rušení elektromagnetického i mechanického), ale je tvořena pro nenáročné aplikace např. pro spotřební elektroniku, chytré telefony, atd. U psaní firmware pro řídící desky se programátoři potýkají s problémem, že se multikoptéra otáčí nebo pohybuje rychleji než dokáže IMU snímat, tím se naprosto zmate určování polohy. Řešením je zrychlit snímkovací frekvenci. Tato situace nastává např. při flipech a akrobacii. Ale pak není multikoptéra schopna se dobře vyrovnat s větrem nebo šumem systému bez náročného filtrování.
Možná si myslíte, že při běžném letu není možné se do takové situace dostat (jako jsou rychlé změny při flipech, ..). Ale např. při kontaktu s neznámou překážkou v dostatečné výšce s rychlým snímkováním IMU je multikoptéra schopná se stabilizovat. Kdyby bylo IMU nastavené na pomalé snímkování s vysokou přesností, pak je multikoptéra ztracena (pokud není užito nějaké samoopravné nebo pravděpodobnostní metody). Pokud záleží na rychlosti reakce, pak je rozumné umístit na multikoptéru alespoň dvě 6-osé IMU. Jedno pro rychlé reakce, druhé pro stanovení chyby při jemné stabilizaci. Jemná stabilizace je velmi důležitá pro zachování pozice při poryvech větru.
Pro počítačem navigované letouny je životně důležité, aby ony samy o sobě měli co nejvíce informací. Potřebují vědět o tom, kde se přibližně mohou nacházet (zde přichází v úvahu pravděpodobnostní odometrie, apod.), stejně tak potřebují vědět co nejlépe to, jak moc se jejich stav změnil oproti poslednímu zjišťování stavu, nebo alespoň vědět co nejpřesněji možnou chyby měření. Předpokládat, že multikoptéry dokáží létat maximálně 20 minut a průměrná multikoptéra léta maximálně 30km/h, a proto nedokáží nastřádat dost chyby, aby to mělo vliv na celkový let, je jako za dob procesorů 386 předpokládat, že počítače nebudou mít paměti větší než několik desítek mega a pak proč tedy designovat systém, který by uměl spravovat více ;) Multikoptéra se může dostat do velké množiny různých podmínek a přes vliv podmínek by její řídící systém měl dokázat ji stabilizovat na místě nebo při velmi rychlém letu a nebo alespoň by její systém měl vést záznam o tom jak moc změnila svoji polohu.
V detailech se skrývá ďábel a není radno je ignorovat. Pokud na multikoptéry budeme cpát počítač, pak jistě ponese i drahé zařízení a jistě nechceme, aby kvůli nedomyšlenosti spadla z 100 metrů přímo na beton ;) a nebo na nic netušící osobu nebo živočicha.
Nebudu Vám říkat, jak máte tvořit své pokusy :) Jen mám v tomto okruhu dosti praktických zkušeností a netvořím hračky. Čím robustnější a čím obecněji navržený systém, tím snáze přežije programátora, chyby i náhody.
... provádí nejoptimálnější možnou matematickou operaci nad těmito daty.
Eště optimálnější!
:-))))))
(Nápověda pro méně jazykově orientované: optimální vyjadřuje již samo o sobě třetí stupeň a nemá smysl ho dále stupňovat.)
Kdyby autor projevil nejminimálnější cit pro smysl slov, nemusel se projevit jako nejmaximálnější ucho.
Alebo este je moznost pouzit vyspelejsi ArduCopter APM2.x zalozeny na Atmel ATMEGA2560 a ATMEGA32U-2 pripadne jeho nastupcu PixHawk ktory uz ma 32bit ARM Cortex M4. Tieto riadiace jednotky alebo ich lacnejsie klony maju uz v prislusenstve casto aj 433MHz radio jednotku pomocnou ktoreho sa daju prenasat telemetricke udaje a aj riadiace prikazy na ovladanie koptery z PC, a su dostatocne schopne na to ze kopteru udrzia vo vzduchu bez zasahov pilota.
Na podobné pokusy zajímavá, i když trošku velká deska je STM32F3Discovery.
Je to 32bit ARM Cortex M4F (hardwarová podpora pro float výpočty) s 256KiB ROM, 48KiB RAM a obsahuje to co modeláři nazývají 9 DoF (3-osý akcelerometr, gyro a kompas).
Nepočítaně PWM výstupů, ADC s podporou DMA a tak...
+ si připočtěte optimalizované implementace matematiky a filtrů přímo od ARMu (CMSIS DSP lib) a podporu v některých existujících projektech pro UAV.
Cena asi $10 (dost často včetně poštovného).
Pokud pominu prinos toho ze misto aby clovek vylepsil existujici softy tak pise uz napsane od znova tak bych doporucil podivat se na jednotky znacena jako Naze32 clone.
Napr. jednotka Flip32+ 10Dof ma na sobe STM32F103CB, MPU6050, kompas a baro.
Oproti jednotkam ala Pixhawk ma slabsi procesor (F1 vs F4) ale je vyrazne levnejsi takze pro prvotni pokusy kdy hrozi nejaky problem je to lepsi.
A jako inspirace se da pouzit CleanFlight firmware ktery je open source
Doporučte někdo nějakou lepší řídící jednotku v podobné cenové kategorii (okolo 30€ ale klidně i o něco dražší), aby to mělo vyšší výkon a splňovalo potřebné parametry (jako v článku) bez bastlení. (co nejvíce integrované) A s podporou již nějakého hotového SW.
Aby se k tomu pak dalo připojit R-Pi s GPS/WiFi/BT/GSM/kamerou/...
Splňuje parametry třeba toto, nebo tomu ještě něco chybí?
http://hobbyking.com/hobbyking/store/__68630__AfroFlight_Naze32_Acro_AbuseMark_FunFly_Controller_Soldered_version_Vertical_Pin_.html
Děkuji
Pokud chce clovek hotove reseni tak ma vcelku 3 zakladni moznosti :
DJI NAZA Lite - leti prakticky sama ale nic moc clovek neudela, neni open source
APM 2.6 - Desky zalozene na Mega2560 se software ArduCopter - nejlevnejsi jednotka ktera rozumne stabilizuje pozici (tzv. loiter mode), je open source
Naze32/Flip32 - Desky pro CleanFlight/BaseFlight - jsou urcene primarne pro FPV zavody a jsou dost nevhodne pro cokoliv jineho. Drzeni pozice se uplne neladi takze to neni zadnej slagr, je open source
PixHawk (a klony ala HKPilot32/RTFHawk atd...) je aktualne rols mezi stabilizacema - je tam STM32M4F , jsou k disposici dva softy (Arducopter a Pixhawk), POSIX RTOS, complet open source, nekolik seriovych portu, moznost pripojit optical flow modul (drzi pak pozici podle obrazu z kamery smerujici pod copter), telemetrii atd....
Pokud chce nekdo stabilizaci kterou bude ridit externi jednotkou tak jednoznacne Pixhawk class. Cokoliv slabsiho je nesmysl a budete bojovat s tim aby to vubec letelo spis nez s tim aby to RPi nejak ovladalo.
BTW : Chystam se na montovat na Pixhawk enabled copteru Intel Edison a pomoci OpenCV hledat misto pro pristavani :-D
Jak jsem napsal - z meho pohledu je nejrozumnejsi reseni poridit desku a rozsirovat soft co uz zije.
Ano, mám podobné důvody pro pořízení něčeho výkonějšího, aby se to dalo nějak rozumně rozšířit a nemuset bojovat o každý bajt kódu.
HKPilot32 je bohužel cenově docela jinde. Jako první lítátko bych do toho nešel. V tom mi přijde lepší Naze32, který jsem odkazoval výše, ale jestli zase není odladěný software...
Nakonec přecijen vezmu odkazovanou desku z článku s Mega2560. Za tu cenu je to asi dobrý poměr výkonu a na první pokusy to stačí.
Když vše pude dobře, věřím že nebude problém udělat druhou koptéru nebo upgrade té první, když přežije. Tolik peněz to zase není.
Na desce ktera je uvedena v clanku jede pouze Multiwii (a historicka verze MegaPirate) a to je 8bitova verze toho softu co jede na Naze32 co jsi poslal ty.
Rozhodne necekej ze to bude letat lepe :-D
Jinak deska Naze32 lita v pohode ale kod pro drzeni pozice proste neni tak dobry jako u ArduCopteru.
Necham to na tobe ale mozna bude stacit kdyz napisu co mam za desky :
Multiwii deska s Mega328 - lezi doma, vykon nestaci
Multiwii deska s 2560 (ta co je ve clanku) - pro normalni letani v pohode, GPS pozice se me nepovedla rozject ani po pul rocnim snazeni - taky odlozeno (naposled jsem ji pouzil pro demonstraci balancujiciho robutka na ArduinoDay v Plzni) - pokud ji koupis tak tady jsem publikoval pcb atd.. pro malou flashku pro logovani dat (http://www.devfor8.com/datalog/)
Flip32 - na FPV super (mam ji na zavodni 250tce) ale pozici to proste drzi blbe (a to pouzivam NEO 8 GPS ktera je nastavena tak ze bere GPS i Glonass)
HKPilot32 (Pixhawk clone) - na velke Y6 coptere (3D tisklej ram), lita super jako nosic kamery, pozici udrzi i v dost silnem vetru prakticky na fleku
Pixhawk Lite (Pixhawk clon z GoodLuckBuy, je levnejsi a mensi) - budu testovat na letadle, 6ti kolovem robotu a obouchavaci coptere pro dalsi rozisreni - optical flow, pitotka atd.....
Takze nejakou zkusenost uz mam :-)
Hmmm, používat soft, co už žije...
Záleží na tom, co od toho čekáte. Pokud se chcete něco naučit, určitě je užitečnější se pokusit něco realizovat na zelené louce. I ty slepé cesty, které nutně přijdou, jsou užitečné.
Ze stejného důvodu jsem si třeba napsal vlastní jednoduchý RTOS, když jsem chtěl poznat Cortex M4. Samozřejmě, mohl jsem použít zralý Free RTOS, ale troufám si tvrdit, že by mně teď chybělo dost zkušeností...
Pravdu máte :-) proto já obhajuji použití Arduina, ten kód by se dal rozhodně napsat mnohem optimálněji a pak by s tím neměl být problém. jenže napsat kód optimálně a nejlíp v assembleru zadarmo není, stojí to čas.. dneska už bych použil něo silnějšího.
Nezapomínejte, že ve starých dobách se používaly hojně analogové počítače, veškeré základní výpočty mohly být provedeny analogově a tedy s výstupem k dispozici ihned.
ten kód by se dal rozhodně napsat mnohem optimálněji ...
Eště optimálněji, vždyť jsem to říkal! :-))))
Samozřejmě, že lze multikoptéru ovladat bez stabilizace a po tvrdém výcviku by to dokazal nejspíš každý. Ale člověk je velmi dobrý výpočetní organický stroj :) a takovéto ovládání není ani trochu komfortní. Stabilizace a ovládání letu je tu proto, aby bylo možné ovládat letadlo stejně jako v DOSu simulátory F-15ky ;) šipkama nebo joystikem :D
Hlavně se změnil poměr ceny počítače a ceny práce programátora
Dneska stojí procesor s několika jádry a frekvencí kolem 1Ghz jenom několik hodin práce programátora
Takže vyjde levnějš použít "monstrum" na úrovni tehdejších superpočítačů do kalkulačky, protože nepotřebujete programátora ale jenom někoho kdo poslepuje knihovny a bude to mít za půl hodiny, ale tehdy to dělalo několik programátorů v assembleru, to by dneska nikdo nezaplatil
Dneska stojí 2 jádrový x86 na 3GHz s 1 MB cache 500 korun včetně DPH, kolik bude stát optimalizace kódu na 8bit když je k dispozici tak obrovskej výkon ?
Jenže on ten výkon neni všechno. Ono tomu 8mi bitu aby fungoval stačí napájení a pak natahat drátky z GPIO aby to něco dělalo. Je to malý, lehký, žere to pár mA a nemusí se to ověsit pomocnými systémy. Nebo existuje nějaký x86 šváb, který jednoduše vrazim do nepájivého pole nebo připájim na tišťák a nějak to bude fungovat?
Kdo potřebuje x86?
Co tohle, když ž se všude cpe Atmel: http://www.atmel.com/images/6175s.pdf ?
ARM7TDMI na 55MHz (32b data bus), RAM 4-64kB, FLASH 16-512kB, 3x UART (včetně DBGU), 1x SPI s podporou až 15 zařízení, 1x I2C, 4x HW PWM, systémový časovač, watchdog, 10b ADC s 8b muxem a 5V tolerantní...
Sice stará plečka, ale na tohle by bohatě stačila.
Bavíme se tady o nějakým dronu, kde můžou nastat vibrace a rázy (třeba při nárazu, dosednití, poryvu větru,...) V téhle disusi je ten argument tak nějak mimo.
Naopak, proti AVR a PIC mluví jejich spolehlivost a odolnost.
PIC je háklivý na rušení v napájení. Co bude dělat, když bude skoro prázdná baterka, zvedne se její vnitřní odpor a budou do toho mlátit výkonový špičky ze čtyř motorů?
AVR má zase problémy se stabilitou hodin, s brownoutem a s watchdogem, takže jak se program zacyklí, tak se někdy rozcyklí až po vyndání baterek. Do lítacího předměu bych si ho nelajzl, pokud s tím nebudu lítat tchýni nad hlavou a rodina nebude v bezpečí.
Narazal som skor na ten koment, ze vsade sa cpe Atmel. Ja osobne ho pouzivam pre jeho jednoduchost a dostupnost. Tie "lepsie" svaby proste amater nema sancu spravne osadit (uz len navrhnut dosku je tazke). A teda potom aky je rozdiel, ked si kupim hotovu kontrolnu dosku, hotovy ram, motory a zlozim to a kupim to hotove? Srobovanie nie je prilis zaujimava a poucna cinnost...
To platí tak možná v běžném IT, kde se to dnes často opravdu matlá jak to jen jde.
Počítače v Apollu a Saturnu - to byly, dnešními slovy, embedded záležitosti. Ani dnes nemůžete do vývoje klíčových částí řídících jednotek letadel nebo i aut atd... nasadit polovzdělané laciné blby. Znalost C, C++ a dokonce i assembleru daného MCU se pořád cení. Bez assembleru se na určité úrovni pořád neobejdete i když se v něm dělá jen malá část. Často se díváte, jaký kód vygeneroval překladač atd...
Potřebujete taky lidi, kteří se vyznají v teorii regulace, spolehlivosti, bezpečnosti... Prostě máte sice daleko lepší procesory(i když zdrojů v MCU stále není nazbyt), ale nároky na vás jsou obdobné jako na inženýry, kteří dělali tenkrát pro NASA a jeho dodavatele.
Nejako sa mi nezda ta disparita, ze pri 200Hz vycitavani vam nestaci 16MHz cpu. Ja mam taky maly vrtulnicek kde je noname cip ktory urcite nema fp a navyse musi robit ADC pri dost zarusenom signali (meral som) a funguje to vynikajuco. Podla mna tam robite nieco strasne neoptimalne alebo zle.
Vrtulníky stačí stabilizovat gyroskopem nebo flybar systémem a akcelerometrem. Vrtulník jsem nikdy neměl, takže chyby prosim omluvte. Na hračky vrtulníků jsou možná i nějaké hotové jednoduché mikroprocesory a nejake jednoduche gyro pro jednoúčelové hračky, není to zdaleka tak výkonově náročné jako multikoptéry a jejich stabilizace. Kdyby byly multikoptery tak jednoduché na ovládání, určitě by jako hračky prorazily na trh mnohem dříve :)
No co som nasiel, tak hoverfly prisiel na trh 1997. Skor to mozno nikoho nenapadlo, alebo MEMS ani piezogyro sensory neboli take lacne. Dnes sa davaju do "spotrebnej" elektroniky, takze podstatne zlacneli. Ked som bol maly, pouzivali sa piezogyra a tie boli velke a drahe. Este je tu rozdiel, a to ze dnes je doba youtubova, teda ze kazdy toci vsetko a zabery z dronov su na dost vysokej urovni, takze to kazdy chce a to umoznuje zvysit produkciu a znizit cenu.
K tej elektronike, MCU - neviem, lebo je obrusene, ale je to mozne aj ked malo pravdepodobne. Vyroba cipu na mieru nie je lacny spas. Gyro je miniaturne piezo murata co sa pouziva na stabilizaciu v kamerach. Na vystupe gyra je napatie podla rotacie.
BTW ked uz su tie realne cisla take nutne, tak existuje aj iny svet ako AVR. Napr PIC ma radu DSP ale uznavam, ze pozhanat nastroje a kompilatory atd, kto by sa s tym babral...ARM je asi schodnejsia cesta.
rekl bych ze stabilizace vrtulniku je uplne nekde jinde nez stabilizace copter. Kdyz jsem videl kod multiwii tak sem si rikal ze to nemuze letet. A litalo to. Dat to na vrtulnik tak nevim co by se stalo :D.
Jinak coptery se zacaly rozsirovat zhruba ve stejne dobe jak se zacaly pouzivat bezpadla. Dokonce se u copter ani nepouzivala zadna ridici jednotka :), z HK se koupily 4 gyra, neco na zpusob HK401 a vesele se litalo :).
BTW: tusim ze akcelerometry se u vrtulniku pouzivaji minimalne, vse se pocita pres gyroskopy.
zalezi o jakem rizeni se bavime, je jedno jestli u vrtulniku nebo koptery. Mame bud standartni ovladani (tak litaji treba zavodni FPV koptery nebo vsechny sportovni vrtulniky), nebo horizont mod ktery se chova jako koaxialni vrtulnik (hracka).
V prvnim pridape se akccelerometr nepouziva vubec. Ve druhem pripade se pouziva akccelerometr jen pro kalibraci pri startu vrtulniku/koptery. Pozice se potom dopocitava z gyr.
Jak to dela captron nebo cleanflight to nevim. Ale u captronu se to mozna da ziskat z patentu a cleanflight ma otevreny kod.
Problem akccelerometru je ze kvuli vibracim z neho lezou docela nepouzitelna data.
BTW: gyro neukazuje zrychleni pri rotacich, pokud by merilo zrychleni, tak pri konstatnich otackach by nenamerilo nic :).
Neviem ci sa to prejavuje ale istu formu stabilizacie mozu robit vrtule. Posobia ako zotrvacniky a na vychylenie ich osi treba urcitu energiu. Potom cim tazsia vrtulka a vescia rychlost otacania tym bude tazsia zmena smeru pre riadiacu jednotku ale aj pre vietor. V riadiacej jednotke by sa to dalo kompenzovat a stabilita je dobra vec.
Pokud mohu doporucit tak je dobre si projit historii na foru RCMania.cz . Copteru je velka skala a od toho se odrazi nejen volba jednotky tak jak to resime zde ale i volna motoru, vrtuli, regulatoru, baterii nebo treba ramu.
Hlavne je dobre si ujasnit co clovek chce. Zda na copter dat kameru a tocit prirodu a nabo cumet do monitoru/brejli a litat v lese mezi stromamam a nebo zavody. A nebo mit copteru jako nosic dalsi elektroniky.
Pak projit forum, udelat si nejaky zakladni obrazek (napr. o tom kde se pohybuji ceny protoze rozumny stroj se proste za par slupek poridit neda) a pak si to nechat treba schvalit (coz vyvola diskusi o tom ze prakticky vsechno je spatne a mnohem lepsi je neco uplne jineho - viz diskuse tady, je to vsude stejne :-D )