Navrh ridici architektury bezpilotniho vrtulniku LinkQuad

Transkript

Fakulta Elektrotechnická
ČVUT v Praze
Bakalářská práce
Návrh řı́dı́cı́ architektury bezpilotnı́ho
vrtulnı́ku LinkQuad
Autor:
Michal Zajačı́k
Školitel:
Ing. Milan Rollo, Ph.D.
Prohlaseni autora prace
Prohlasuji, ze jsem pfedlozenou praci vypracoval samostatne a ze jsem uvedl veskere pouzite
informacni zdroje v souladu s Metodickym pokynem o dodrzovani etickych principu pfi pffprave
vysokoskolskych zaverecnych praci.
VPraze dne
..?9..:l:..Wl.
Podpis autora prace
Poděkovánı́
Na tomto mı́stě bych rád poděkoval mému vedoucı́mu, Ing. Milanu Rollovi, Ph.D., za přı́kladné vedenı́, podporu
a ochotu ke konzultacı́m během tvorby mé práce.
Dalšı́ dı́ky věnuji své rodině a všem přátelům za neustávajı́cı́ podporu nejen během psanı́ této práce, ale během
celého studia. Bez nich bych měl mnohem většı́ potı́že svou práci a studium dokončit.
Abstrakt
Cı́lem této práce je návrh řı́dı́cı́ architektury pro bezpilotnı́ čtyřrotorový vrtulnı́k LinkQuad s ohledem na
možnost jeho využitı́ při verifikaci vlastnostı́ algoritmů pro plánovánı́ taktických misı́ postavených nad systémem
AgentFly. Tento systém vyvı́jený v Centru Agentnı́ch Technologiı́, FEL, ČVUT v Praze umožňuje simulaci
a řı́zenı́ týmů bezpilotnı́ch prostředků a to jak virtuálnı́ch, tak i reálných. LinkQuad je uzavřená platforma
vybavená pokročilým autopilotem a přı́davnými palubnı́mi počı́tači vyvı́jená firmou UAS Technologies Švédsko.
Z uživatelského hlediska však poskytuje jen základnı́ letové funkce a pro jejı́ integraci do stávajı́cı́ho systému
bylo nutné navrhnout a implementovat architekturu, která by umožnila interakci s autoplilotem LinkBoard,
autonomnı́ plánovánı́ letových trajektoriı́, interakci s uživatelem a komunikaci s ostatnı́mi entitami v systému.
Navržené moduly byly implementovány v programovacı́m jazyku Java a běžı́ na přı́davném palubnı́m počı́tači
Gumstix a pozemnı́m řı́dı́cı́m pracovišti. Vlastnosti a funkcionalita navržené architektury byly ověřeny sadou
letových testů.
Abstract
Goal of this thesis is to design a control architecture for unmanned quadcopter LinkQuad considering its use
for verification of features of algorithms for tactical mission planning build on the AgentFly system. This
system, developed at Agent Technology Center, FEE, CTU in Prague, allows simulation and control of teams of
autonomous UAVs both virtual and real ones. LinkQuad is a closed platform equipped with advanced autopilot
and additional onboard computers, developed by UAS Technologies Sweden. From the user’s point of view
it offers only some basic flight functions and for its integration into an existing system it was necessary to
design and implement architecture which will allow interaction with LinkBoard autopliot, autonomous flight
trajectory planning, interaction with human user and communication with other entities. Designed modules
were implemented in Java programming language and run on Gumstix onboard computer and ground station.
Functionality and features of designed architecture were verified by a set of flight experiments.
Ceske vysoke uceni technicke v Praze
Fakulta elektrotechnicka
Katedra kybernetiky
ZADANI BAKALARSKE P R A C E
Student:
Michal
Zajacik
Studijni program:
Otevfena informatika (bakalafsky)
Obor:
Informatika a pocitacove vedy
Nazev tematu:
Navrh fidici architektury pro bezpilotni vrtulnik LinkQuad
Pokyny pro vypracovani:
1. Seznamte se s fidici architekturou bezpilotniho vrtulniku LinkQuad.
2. Implementujte v programovacim jazyku Java komunikacni protokol pro pfenos datovych
a fidicfch informaci mezi autopilotem LinkBoard a palubnim pocitacem Gumstix.
3. Navrhnete a implementujte model vrtulniku v simulacnim prostfedi AgentFly.
4. Navrhnete a implementujte architekturu zajist'ujicf autonomni planovani a vykonavani
letovych trajektorii.
5. Experimentalne overte vlastnosti navrzene planovaci a fidici architektury v simulacnim
prostfedi a na realnem bezpilotnim prostfedku.
Seznam odborne literatury: Doda vedouci prace.
Vedoucf bakalarske prace: Ing. Milan Rollo, Ph.D.
Platnost zadani: do konce zimniho semestru 2012/2013
V Praze dne 9. 1.2012
Obsah
1 Úvod
1
1.1
Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Cı́l práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Struktura práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2 Bezpilotnı́ letecké prostředky
3
2.1
Bezpilotnı́ letadla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Klasifikace bezpilotnı́ch prostředků . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.3
Čtyřrotorové vrtulnı́ky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3.1
6
Osy a úhly náklonu čtyřvrtulové helikoptéry . . . . . . . . . . . . . . . . . . . . . . . . . .
3 LinkQuad
3.1
3.2
3.3
7
Fyzické vlastnosti a hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.1.1
Fyzické vlastnosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.1.2
Hardwarová platforma a senzory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.1.3
Uživatelský počı́tač Gumstix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Řı́dı́cı́ mechanismy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1
Řı́dı́cı́ smyčky CMCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2
Letové módy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3
Komunikace se systémem LinkQuad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Softwarové vybavenı́ systému LinkQuad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.1
Angström linux a Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.2
LinkGS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.3
Konfigurace LinkBoardu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.4
Vnitřnı́ kontrolnı́ smyčky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.5
Vnějšı́ kontrolnı́ smyčky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.6
Mixer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.7
Systém vedenı́ záznamu o letu
3.3.8
Start systému LinkQuad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.9
Ukázky konfigurace autopilotu LinkBoard . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Návrh architektury vyššı́ řı́dı́cı́ vrstvy
19
5 Řı́dı́cı́ software AgentFly
20
I
5.1
5.2
AgentFly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1.1
Simulace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1.2
Plánovánı́ trajektorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1.3
Detekce koliznı́ch situacı́ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.4
Shrnutı́ vlastnostı́ systému AgentFly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Multi-agentnı́ platforma AGlobe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2.1
Architektura systému AGlobe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6 Architektura vyššı́ řı́dı́cı́ vrstvy
6.1
24
Realizace entity bezpilotnı́ho systému LinkQuad . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7 Implementace komunikace a letové řı́dı́cı́ funkce
27
7.1
Komunikačnı́ server LinkQuadGXsrvr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.2
Základnı́ struktura programu LinkQuadGXsrvr . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.3
serialComm3: C socket server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.4
Hlavnı́ řı́dı́cı́ funkce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.5
Přijı́mánı́ paketů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.6
Žádosti o proměnné a zápis uživatelských parametrů . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.7
Řı́dı́cı́ funkce letu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.7.1
Funkce letu po přı́mce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.7.2
Funkce rotace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8 Experimenty
33
8.1
V simulaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.2
Na reálném HW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.2.1
Vnitřnı́ prostředı́ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.2.2
Vnějšı́ prostředı́: manuálnı́ režim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.2.3
Vnějšı́ prostředı́: vznášenı́ a let po přı́mce . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9 Zhodnocenı́ výsledků a směry dalšı́ho vývoje
40
9.1
Zhodnocenı́ dosažených výsledků . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.2
Směry dalšı́ho vývoje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
10 Obsah přiloženého CD
41
II
Seznam obrázků
2.1
Ukázka UAV letounů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Schiebel S-100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.3
Bell XV-15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.4
Směr rotacı́ vrtulı́ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.5
Úhly a osy čtyřrotové helikoptéry, převzato z [Kivrak–06] . . . . . . . . . . . . . . . . . . . . . .
6
3.1
Helikoptéra LinkQuad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.2
Architektura bezpilotnı́ho systému LinkQuad . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.3
Architektura autopilotu LinkBoard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.4
Zasazenı́ LinkBoard do helikoptéry LinkQuad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5
Gumstix Overo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.6
Výpis souboru /proc/cpuinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.7
Výpis souboru /proc/meminfo
3.8
Hierarchie řı́dı́cı́ch smyček . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.9
Vzhled LinkGS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.10 Nastavenı́ vnitřnı́ch smyček . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.11 Nastavenı́ vnějšı́ch smyček . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.12 Ukázka nastavenı́ mixeru
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1
Schéma architektury vyššı́ řı́dı́cı́ vrstvy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2
Schéma vnitřnı́ architektury vyššı́ řı́dı́cı́ vrstvy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1
Grafická komponenta AgentFly - naplánovaná mise . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2
Grafická komponenta AgentFly - vizualizace trajektorie letounu . . . . . . . . . . . . . . . . . . . 22
5.3
Grafická komponenta AgentFly - vizualizace letounu . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.4
Architektura systému AGlobe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1
Schéma vyššı́ řı́dı́cı́ architektury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1
Základnı́ struktura programu LinkQuadGXsrvr . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.2
Optimálnı́ vývoj rychlosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.3
Trajektorie a referenčnı́ (kontrolnı́) bod. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.4
Zobrazenı́ načtených senzorových veličin pomocı́ LinkQuadGXsrvru . . . . . . . . . . . . . . . . 32
7.5
Ukázka výstupu LinkQuadGXsrvru při zadánı́ pokynu k letu . . . . . . . . . . . . . . . . . . . . 32
8.1
Fotografie bezpilotnı́ho systému LinkQuad za letu
III
. . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.2
Ukázka rozptylu pozice při automatickém udržovánı́ polohy . . . . . . . . . . . . . . . . . . . . . 35
8.3
Ukázka rozptylu výšky při automatickém udržovánı́ polohy ve větru. . . . . . . . . . . . . . . . . 36
8.4
Záznam průletu trajektorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.5
Záznam vývoje rychlosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.6
Záznam vývoje nadmořské výšky při průletu trajektorie. . . . . . . . . . . . . . . . . . . . . . . . 37
8.7
Záznam druhého průletu trajektorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.8
Záznam vývoje rychlosti při druhém průletu trajektorie. . . . . . . . . . . . . . . . . . . . . . . . 38
8.9
Záznam vývoje nadmořské výšky při druhém průletu trajektorie. . . . . . . . . . . . . . . . . . . 39
IV
Kapitola 1
Úvod
V poslednı́ch letech prudce stoupá počet bezpilotnı́ch leteckých prostředků (unmanned aerial vehicles - UAV)
nasazených jak v civilnı́ch, tak i ve vojenských oblastech. Bezpilotnı́ letouny jsou v současné době řı́zeny na
dálku pozemnı́ obsluhou a to bud’ pomocı́ satelitů (v přı́padě velkých letounů), nebo pomocı́ radiových vysı́lačů.
Oproti letounům s lidskou posádkou jsou jejich hlavnı́mi výhodami zejména nižšı́ provoznı́ náklady, pořizovacı́
cena a menšı́ nároky na výcvik jejich obsluhy.
Konečným cı́lem výzkumu bezpilotnı́ch prostředků je umožnit část úloh řı́zenı́ přesunout přı́mo na palubnı́
počı́tače bezpilotnı́ch prostředků a tı́m usnadnit práci operátorům odpovědným za řı́zenı́ mise. Prostředky by
měly být schopny samostatně naplánovat nejefektivnějšı́ trasu pro splněnı́ zadaných úkolů, přičemž berou v
potaz i přı́padné překážky, jako jsou budovy nebo hory a dále i vliv počası́, zejména větru.
Součástı́ výzkumu jsou také algoritmy zaměřené na spolupráci ve skupině takových letounů, kdy prostřednictvı́m
jednoho pozemnı́ho pracoviště bude možné ovládat vı́ce letounů současně. Letouny si budou moci vzájemně
zası́lat své letové plány, s předstihem detekovat koliznı́ situace a vyhýbat se bez zásahu operátorů.
Bezpilotnı́ letecké prostředky mohou mı́t řadu podob. Kromě letounů existujı́ prostředky spadajı́cı́ do kategorie VTOL (Vertical Take Off and Landing), tedy prostředků schopných vertikálnı́ho startu a přistánı́. Většinou
se jedná o helikoptéry a jejich různé typy, ale nacházı́ se zde i letouny speciálnı́ konstrukce, jako je napřı́klad
proudový letoun Harrier. Tato kategorie leteckých prostředků přinášı́ řadu nových problémů. Většina z nich se
týká předevšı́m stabilizace polohy, ale zároveň je nutné vyvinout nové způsoby plánovánı́ letu, které zohlednı́
specifické vlastnosti těchto prostředků, jako je schopnost zcela se zastavit a vznášet se na mı́stě či klesat a
stoupat v kolmém směru.
1
1.1
Motivace
Hlavnı́ motivacı́ pro tuto práci je nejnovějšı́ výzkum v Centru agentnı́ch technologiı́ (ATG) na FEL, ČVUT
v Praze, zaměřený na oblast bezpilotnı́ch prostředků a různých aplikačnı́ch scénářů, které tyto prostředky
využı́vajı́. V poslednı́ době roste důraz na praktické ověřenı́ vlastnostı́ algoritmů pro distribuované plánovánı́
týmových misı́. Ty byly dosud testovány pouze v simulačnı́m prostředı́ AgentFly, které však nepostihuje všechny
aspekty spojené s přechodem k reálnému nasazenı́. Z tohoto důvodu byly pořı́zeny reálné bezpilotnı́ prostředky
Procerus (letoun typu samokřı́dlo) a LinkQuad (čtyřrotorový vrtulnı́k). Tyto bezpilotnı́ prostředky jsou vybavené autopiloty s možnostı́ GPS navigace a komunikace s pozemnı́m pracovištěm. Tato úroveň řı́zenı́ ovšem
nepostačuje pro plánovánı́ komplexnı́ch misı́, proto je nezbytné vyvinout vyššı́ řı́dı́cı́ vrstvu, která by umožnila
jak autonomnı́ plánovánı́ letových trajektoriı́ v dynamickém prostředı́, tak i interakci s ostatnı́mi jednotkami v
rámci plněnı́ týmových misı́. Systém klade důraz i na interakci s uživatelem prostřednictvı́m grafického rozhranı́
pozemnı́ho pracoviště, které umožňuje ovládat jak jednotlivé bezpilotnı́ prostředky, tak i zadávat globálnı́ cı́le
celým týmům.
1.2
Cı́l práce
Platforma LinkQuad umožňuje kromě ručnı́ho ovládánı́ přes RC vysı́lač i základnı́ bezpilotnı́ operaci hovering, česky udrženı́ polohy dle senzorů. Cı́lem je usnadnit obsluhu vrtulnı́ku, automatizovat let a tı́m umožnit
prováděnı́ složitějšı́ch misı́ i ovládánı́ vı́ce strojů naráz. Proto nad základnı́ řı́dı́cı́ strukturou nı́zké úrovně budou vystavěny vyššı́ vrstvy, které ve finálnı́ podobě umožnı́ uživateli zadat letový plán, následně autonomně
naplánujı́ trajektorii vzhledem k fyzikálnı́m omezenı́m vrtulnı́ku a překážkám a celou trajektorii proletı́.
1.3
Struktura práce
Celá práce je strukturována následujı́cı́m způsobem. V druhé kapitole budou představeny bezpilotnı́ letecké
prostředky a v jejich rámci i bezpilotnı́ vrtulnı́ky. Třetı́ kapitola se bude věnovat popisu konkrétnı́ použité
platformy - bezpilotnı́mu systému LinkQuad - jak po hardwarové, tak softwarové stránce. Čtvrtá kapitola
představı́ návrh architektury vyššı́ řı́dı́cı́ vrstvy helikoptéry. V páté kapitole bude představen řı́dı́cı́ software
AgentFly. Následujı́cı́ šestá kapitola se bude věnovat konkrétnı́mu návrhu propojenı́ systému LinkQuad s řı́dı́cı́m
softwarem AgentFly. Sedmá kapitola se bude zabývat implementacı́ načı́tánı́ a zpracovánı́ dat ze senzorů a jejich
reálným uplatněnı́m při návrhu řı́dı́cı́ funkce letu helikoptéry po přı́mce. Osmá kapitola se věnuje experimentům
s bezpilotnı́m systémem LinkQuad a poslednı́ devátá kapitola shrne dosažené výsledky a vytyčı́ prostor pro
budoucı́ práci.
2
Kapitola 2
Bezpilotnı́ letecké prostředky
2.1
Bezpilotnı́ letadla
Jak již bylo řečeno v úvodu, UAV (někdy též dron), je bezpilotnı́ letecký prostředek, tj. letoun bez lidské posádky
na palubě. Je řı́zen většinou na dálku lidským operátorem ze země nebo dokonce z jiného dopravnı́ho prostředku,
a to pomocı́ rádiových vysı́lačů či satelitnı́ho spojenı́. V prvnı́m přı́padě je dosah omezen na několik kilometrů
od řı́dı́cı́ho centra, v tom druhém je možné ovládat letouny v rozsahu celé zeměkoule. Pozemnı́ obsluha plně
odpovı́dá za bezpečnost provozu letounů, řı́dı́ jejich letovou trajektorii a zároveň plnı́ předem stanovené úkoly. Z
paluby letounu vybaveného elektronickými senzory, kamerami, palubnı́mi počı́tači a komunikačnı́mi zařı́zenı́mi
dostává pozemnı́ obsluha úplné informace o děnı́ v okolı́ letounu a na jejich základě se rozhoduje, jak nejlépe
zadané úkoly plnit.
Výhodou použitı́ bezpilotnı́ch letounů je krom nı́zkých pořizovacı́ch a provoznı́ch nákladů snı́ženı́ nároků
na pozemnı́ obsluhu. Letouny je tak možné použı́t v mnohem širšı́m spektru aplikacı́, kde nasazenı́ klasických
letadel nenı́ možné z důvodů infrastruktury nutné k zajištěnı́ jejich provozu (např. letiště s dostatečně dlouhými
drahami). Velké bezpilotnı́ letouny určené pro průzkum terénu či monitorovánı́ meteorologických podmı́nek
mohou být ve vzduchu na rozdı́l od lidské posádky nepřetržitě i několik dnı́. Pozemnı́ obsluha se může v
ovládánı́ letounů v pravidelných intervalech střı́dat, snižuje se stres a únava a tı́m také klesá možnost pochybenı́
vlivem lidského faktoru.
Jeden letoun tak v současnosti typicky ovládá několik operátorů, kteřı́ odpovı́dajı́ za jeho pilotáž, zpracovánı́
informacı́ z paluby, přı́padně plánovánı́ a kontrolu plněnı́ misı́. Poslednı́ technologické trendy však ukazujı́ snahu
co nejvı́ce řı́dı́cı́ch úkonů provádět automaticky a v kooperaci s ostatnı́mi letouny, prostřednictvı́m počı́tačů
přı́tomných na palubě UAV.
Existuje řada typů bezpilotnı́ch letounů, mohou jimi být jak letadla, tak vrtulnı́ky různých velikostı́ a se
specifickou výbavou uzpůsobenou potřebám konkrétnı́ mise. Služeb UAVs v současnosti využı́vá hlavně armáda,
ale v menšı́ mı́ře se začı́ná nacházet i civilnı́ uplatněnı́, napřı́klad při monitorovánı́ požárů, průzkumu, lokalizaci
osob a při kontrolách vedenı́ elektřiny, ropy, či plynu. UAVs obecně se tedy nasazujı́ hlavně v situacı́ch, které jsou
pro letouny normálnı́ velikosti s posádkou přı́liš rizikové a nebezpečné, nebo pro které je provoz velkých letounů
přı́liš nákladný. Fotografie různých UAVs jsou na obrázcı́ch 2.1 a 2.2, fotografie přejaty z [Wikipedia–12].
Obrázek 2.1: Ukázky
námořnictva USA
UAV
letounů
Obrázek 2.2: Helikoptéra Schiebel S-100 s
vı́ceúčelovou raketou
3
2.2
Klasifikace bezpilotnı́ch prostředků
Existuje mnoho způsobů klasifikace bezpilotnı́ch prostředků. Jednı́m z hledisek je počet motorů. Dalšı́m hlediskem je konstrukce - jestli se jedná o tzv. fixed-wing, tedy letoun s pevnými křı́dly, nebo helikoptéru. UAV se
mohou klasifikovat i podle druhu pohonu na spalovacı́ a elektrická. Dalšı́m měřı́tkem může být velikost, dolet,
či dosah prostředku.
Bezpilotnı́ prostředky můžeme dělit i na CTOL (Convencional Take Off and Landing - tedy prostředky co
startujı́ a přistávajı́ konvenčnı́m způsobem), VTOL (zmı́něný v úvodu), STOL (Short Take Off and Landing prostředky které k přistanı́ potřebujı́ pouze krátkou přistávacı́ dráhu) a na kombinace předchozı́ch, napřı́klad
STOVL (Short Take Off and Vertical Landing).
Kategoriı́ existuje opravdu velké množstvı́ a proto bude jako poslednı́ uvedena klasifikace dle účelu prostředku:
• Falešné cı́le a návnady – UAV poskytujı́ podporu ostatnı́m jednotkám odlákánı́m nepřátelských zbraňových
systémů tı́m, že simulujı́ nepřátelský letoun či střelu
• Průzkumná UAVs – zjišt’ujı́ informace o stavu bojiště
• Bojová UAVs – poskytujı́ své ofenzivnı́ schopnosti v misı́ch přı́liš rizikových pro pilotované letouny
• Logistická UAVs – UAVs konstruovaná speciálně pro přepravu materiálu
• Výzkumná a vývojová UAVs – použı́vaná k dalšı́mu zdokonalenı́ bezpilotnı́ technologie.
• Civilnı́ a komerčnı́ UAVs – UAVs konstruovaná pro lokalizaci osob, monitoring požárů, kontrolu vedenı́,
ale existuje i ryze komerčnı́ využitı́ - např. fotografovánı́ a natáčenı́ akrobatických lyžařů a měst z výšky.
Systém LinkQuad se řadı́ k elektřinou poháněným čtyřmotorovým VTOL výzkumným bezpilotnı́m prostředkům.
Následujı́cı́ sekce proto bude věnována popisu čtyřrotorových vrtulnı́ků, které tvořı́ podkategorii VTOL bezpilotnı́ch prostředků.
4
2.3
Čtyřrotorové vrtulnı́ky
Čtyřrotorový vrtulnı́k, jak už název napovı́dá, je vybaven čtveřicı́ vrtulı́, které jsou umı́stěny v jedné rovině.
Čtyřrotory většinou užı́vajı́ vrtule s listy se stejným fixnı́m sklonem, na rozdı́l od helikoptér standardnı́ konstrukce, kde je sklon listů rotoru měnitelný.
U quadrotorů, jak jsou čtyřvrtulové helikoptéry občas nazývány, je řı́zenı́ stroje docı́leno pomocı́ regulace
rychlostı́ otáček jednotlivých rotorů za přı́padného naklápěnı́ celých motorů kolem horizontálnı́ osy. Hezkou
ukázkou technologie naklápěnı́ motorů je letoun Bell XV-15, který je vidět na obrázku 2.3, byt’ nepatřı́ mezi
UAV.
U malých dronů, jako je napřı́klad LinkQuad, se kvůli zjednodušenı́ konstrukce nejvı́ce použı́vá řı́zenı́ pouze
pomocı́ regulace otáček.
Dva motory, které jsou naproti sobě se otáčı́ stejným směrem, druhá dvojice motorů se točı́ směrem opačným
a kompenzuje vzniklou hybnost prvnı́ dvojice, grafické znázorněnı́ ukazuje obrázek 2.4, obrázek přejat z [Jiřinec–11],
motory jsou čı́slovány po směru pohybu hodinových ručiček.
Obrázek 2.3: Bell XV-15
Obrázek 2.4: Směr rotacı́ vrtulı́
5
2.3.1
Osy a úhly náklonu čtyřvrtulové helikoptéry
Když majı́ všechny rotory stejnou rychlost otáček, celková vytvářená hybnost je nulová, helikoptéra si udržuje
svou polohu (popřı́padě se pohybuje vertikálně), nikam se nenaklápı́ ani neotáčı́. Umı́stı́-li se kartézská soustava
souřadnic do středu vrtulnı́ku tak, že osa X procházı́ přednı́m (č. 1) a zadnı́m (č. 3) rotorem, osa Y levým (č.
2) a pravým (č. 4) rotorem a osa Z směřuje kolmo dolů, mohou se pojmenovat úhly rotacı́ kolem přı́slušných os
následovně (viz 2.5 s čı́slovánı́m motorů ve směru pohybu hodinových ručiček):
• orientovaný úhel kolem osy X: φ
• orientovaný úhel kolem osy Y: θ
• orientovaný úhel kolem osy Z: ψ
Obrázek 2.5: Úhly a osy čtyřrotové helikoptéry, převzato z [Kivrak–06]
Předozadnı́mu náklonu se řı́ká sklon (v angličtině pitch) a je docı́len změnou úhlu θ. Pravolevé otočenı́,
náklon (roll) je způsobeno změnou úhlu φ. Změna kurzu (yaw) je docı́lena změnou úhluψ. Kurz má hodnotu
0 pokud přednı́ část UAV mı́řı́ přesně na sever. Definované úhly budou využité později při popisu konfigurace
vnitřnı́ch kontrolnı́ch smyček helikoptéry LinkQuad. V přı́padě, že je požadován let helikoptéry určitým směrem,
je nutné celou platformu daným směrem naklonit pomocı́ regulace otáček rotorů. Pokud je vyžadován let šikmo,
měnı́ se samozřejmě těchto úhlů vı́ce najednou.
Nejčastějšı́ operace jsou náklony kolem os X a Y, tedy změny úhlů φ a θ, čili otočenı́ tělesa helikoptéry do
stran a dopředu/dozadu. Této změny polohy se docı́lı́ úpravou otáček motorů ležı́cı́ch na dané ose.
Při požadované změně kurzu (změna úhlu ψ) se výkon motorů měnı́ po dvojicı́ch. Při otáčenı́ doleva se zvedne
výkon motorů čı́slo 1 a 3 (přednı́ a zadnı́) a snı́žı́ výkon 2 a 4 (bočnı́) a pro samotnou rotaci se využije takto
vzniklá hybnost rotorů. Výkon druhé dvojice klesá proto, aby helikoptéra udržela výšku a nezačala stoupat ve
výkrutu. Při rotaci doprava se postupuje opačně, tedy zvedá se výkon motorů 2 a 4 (po stranách helikoptéry) a
ubı́rá výkon motorů 1 a 3. Protože je helikoptéra schopná pohybu do všech stran, nenı́ nutná změna kurzu za
účelem úpravy trajektorie.
6
Kapitola 3
Bezpilotnı́ systém LinkQuad
V této kapitole budou popsány fyzické vlastnosti a softwarové vybavenı́ čtyřrotorové helikoptéry LinkQuad,
fotografie se nacházı́ na obrázku 3.1. LinkQuad je uzavřenou platformou, produktem firmy UAS Technologies
Sweden. Z toho, že zařı́zenı́ nenı́ na bázi opensource, plynou jistá omezenı́, např. to, že část dokumentace a
software jsou uzavřené. ČVUT tedy nedisponuje plným přı́stupem k hardware a ke zdrojovým kódům a je
odkázané na zdroje informacı́ a pomoc poskytnuté dodavatelem zařı́zenı́.
Obrázek 3.1: Helikoptéra LinkQuad
3.1
3.1.1
Fyzické vlastnosti a hardware
Fyzické vlastnosti
LinkQuad je čtyřrotorová helikoptéra klasické konstrukce, vážı́cı́ dle [Jiřinec–11] 1.313 kg, z čehož 394 g připadá
baterii a 112 g kameře uchycené vespod helikoptéry. Letové zkoušky byly prováděny bez kamery, reálná letová
hmotnost byla tedy přibližně 1.2 kg. Na šı́řku měřı́ s vrtulemi 68 cm, bez nich 45 cm. Na výšku má s nasazenými
nohami a RC anténou 48 cm, 10 cm připadá na válcové tělo, ke kterému je RC anténa měřı́cı́ 33,5 cm připevněna
z boku.
Šesti-článková Li-Pol baterie, která se skládá ze dvou 3-článkových paralelně zapojených bloků, disponuje
celkovou kapacitou 5200 mAh při napětı́ 11.1 V. Reálná výdrž značně závisı́ na okolnı́ teplotě, při teplotě
7
vzduchu cca 25◦ C se pohybuje okolo 20 minut letu, v závislosti na sı́le větru a vytı́ženı́ stroje, obecně při teplotě
nižšı́ se výdrž citelně snižuje. Ve výbavě je i druhá baterie pro rychlou výměnu během leteckých experimentů.
Dalšı́m přı́slušenstvı́m je kamera, která se dá připevnit na spodnı́ část helikoptéry a která v reálném čase
přenášı́ obraz na pozemnı́ stanici. Kamera disponuje servo motorky a je plně ovládatelná pomocı́ vysı́lačky.
Kamera nebyla pro riziko jejı́ho poškozenı́ při pádu testována.
Použité motory Hacker A20-26M vážı́ 42g a disponujı́ výkonem 150 Wattů. Standardnı́ odběr motorů činı́
12 A, ve špičce až 15 A.
3.1.2
Hardwarová platforma a senzory
Nejprve bude představeno orientačnı́ schéma architektury bezpilotnı́ho systému LinkQuad, následně budou
popsány jeho jednotlivé komponenty.
Vrtulnı́k LinkQuad je řı́zen pomocı́ autopilotu LinkBoard, který na sobě kromě dvojice mikroprocesorů
nese řadu senzorů a vlastnı́ flash pamět’ pro uloženı́ konfigurace. Mikroprocesory majı́ za úkol zpracovávat
data a provádět kalkulace nezbytné k letu helikoptéry. Z autopilotu dále vedou výstupy do regulátorů motorů,
do ovládánı́ připojitelné kamery, linky k rádiovému přijı́mači a modemu pro komunikaci s pozemnı́ stanicı́.
K LinkBoardu se dajı́ připojit dva přı́davné uživatelsky přı́stupné počı́tače Gumstix. Poslednı́ komponentou je
výstup ke čtečce microSD karty, která se užı́vá k ukládánı́ záznamu o letu. Schéma na obrázku 3.2, bylo převzato
od [UASTech–12].
Obrázek 3.2: Architektura bezpilotnı́ho systému LinkQuad
Autopilot disponuje disponuje celou řadou senzorů pro zjištěnı́ přesné informace o poloze platformy:
• Gyroskopy - pro určenı́ úhlů φ, θ a ψ, tedy náklonů v jednotlivých osách
• 3D Akcelerometr - zjištěnı́ velikosti a směru zrychlenı́, tedy změnu rychlosti pohybu v čase
• Barometr - určenı́ atmosférického tlaku a následný výpočet nadmořské výšky
• Magnetometr - pro měřenı́ kurzu, tedy odchylky od severu
• Voltmetr - zjištěnı́ napětı́ napájecı́ baterie
• GPS - určenı́ polohy pomocı́ satelitnı́ho navigačnı́ho systému
Jak bylo zmı́něno výše, mikroprocesory řı́dı́cı́ let helikoptéry jsou dva. Oba jsou ARMové architektury a
majı́ pracovnı́ frekvenci 72 MHz. Prvnı́ z nich se nazývá Sensor Micro Controller Unit (dále jen SMCU), druhý
Control Micro Controller Unit (dále jen CMCU).
8
SMCU vyčı́tá a zpracovává data ze senzorů a RC přijı́mače a předává je ve zpracované formě do vnějšı́ch
a vnitřnı́ch řı́dı́cı́ch smyček běžı́cı́ch na CMCU. O smyčkách bude pojednáno v samostatné sekci této kapitoly.
Zpracovánı́ senzorových dat na SMCU spočı́vá v jejich filtraci, směšovánı́ a převáděnı́ do digitálnı́ podoby.
Zı́skané údaje využije CMCU a pomocı́ smyček vypočte a předá povely jednotlivým regulátorům motorů. Touto
neustálou kontrolou při správné funkci zajišt’uje stabilitu a ovladatelnost helikoptéry. CMCU zároveň odesı́lá
data na modem komunikujı́cı́ s pozemnı́ stanicı́, počı́tačem (např. notebookem). CMCU dále odesı́lá data na 10
PWM (Pulse Width Modulation, běžně užı́vaná technika kontroly napájenı́) výstupnı́ch kanálů.
SMCU i CMCU zároveň odesı́lajı́ svá data na sériové porty RS232, ke kterým je připojen přı́davný uživatelský
počı́tač Gumstix. Gumstixu bude věnován prostor také v samostatné sekci. Obrázek 3.3 znázorňujı́cı́ uspořádánı́
autopilotu, přejat z [UASTech–12].
Gumstix 1
Gumstix 2
RS232-1
RS232-1
RS232-3
RS232-2
RS232-2
USB-1
USB-1
Sensors:
1. 3D Accelerometer
2. 3 Gyroscopes
3. Barometer
4. Compass
Rc receiver
10 x PWM output
channels
Analog/Digital
Converter
Ch1: battery voltage
Ch2-Ch4: additional
sensors
Motor controllers
Sensor MCU
GPS
RS232-3
Control MCU
Additional sensors:
e.g sonar
Modem
Obrázek 3.3: Architektura autopilotu LinkBoard
Uživatel má následujı́cı́ možnosti komunikace s autopilotem:
• RC přijı́mač - přijetı́ a zpracovánı́ povelů z RC vysı́lačky
• Komunikačnı́ modem - užı́vaný ke spojenı́ a komunikaci s pozemnı́ stanicı́.
RC přijı́mač přijı́má uživatelské povely z rádiové vysı́lačky na frekvenci 35 MHz. Tyto povely vstupujı́ do
řı́dı́cı́ch smyček CMCU a tı́m ovládajı́ let bezpilotnı́ho prostředku.
Komunikačnı́ modem na straně helikoptéry se skládá ze dvou komponent. Z Wi-Fi vysı́lače na frekvenci 2.4
GHz pro bezdrátový přenos dat a převodnı́ku na sériový port RS232, pomocı́ kterého je modem připojen k
autopilotu. Pozemnı́ stanice má svůj vlastnı́ modem, ke kterému je připojena pomocı́ USB a sériový port se na
nı́ emuluje softwarově. Na straně pozemnı́ stanice má tudı́ž modem kromě Wi-Fi modulu převodnı́k na USB.
Připojená závěsná videokamera přenášı́ obraz v reálném čase na pozemnı́ stanici prostřednictvı́m vysı́lánı́
na frekvenci 1.3 GHz.
9
Obrázek 3.4: Zasazenı́ LinkBoard do helikoptéry LinkQuad. Počı́tač Gumstix je k LinkBoardu připojen zespodu,
nenı́ tedy na fotografii vidět. Zespodu odklopeného vrchnı́ho krytu je připevněná anténa GPS přijı́mače (vlevo)
a vpravo od nı́ kompas.
3.1.3
Uživatelský počı́tač Gumstix
LinkQuad může nést připojené současně až dva uživatelsky přı́stupné počı́tače Gumstix. V přı́padě zapojenı́
obou těchto jednotek funguje jedna jako řı́dı́cı́ a druhá jako podřı́zená jednotka. Oba počı́tače spolu mohou
navzájem komunikovat pomocı́ sériových portů RS232. Použitá platforma LinkQuadu nese na palubě připojený
jeden Gumstix. Gumstix disponuje vlastnı́m Wi-Fi modulem, který vytvářı́ 2.4 GHz Wi-Fi sı́t’ v ad-hoc režimu,
je tedy možné se k této sı́ti připojit jako ke kterékoli jiné Wi-Fi z libovolného zařı́zenı́. Modul s počı́tačem
Gumstix Overo Fire (na obrázku 3.5), konkrétně model GS3503F-R2766, je k autopilotu připojen zespodu a
komunikuje s nı́m pomocı́ sériových portů RS232. Podrobné informace o hardware poskytne použitý operačnı́
systém platformy - Angström linux.
Obrázek 3.5: Gumstix Overo. Zleva: modul Wi-Fi, vlastnı́ procesor Gumstix s heatspreadem, slot microSD karty
10
Procesor počı́tače Gumstix je jednojádrový čip s architekturou ARMv7, taktovaný na 500 MHz. K dispozici
je 256 MB RAM systémové paměti. Pro ukládánı́ dat a instalaci operačnı́ho systému je užita vlastnı́ 8GB
microSD karta. Podrobnějšı́ informace jsou zachyceny na obrázcı́ch 3.6 a 3.7.
Obrázek 3.6: Výpis souboru /proc/cpuinfo obsahujı́cı́ dostupné informace o procesoru
Obrázek 3.7: Výpis souboru /proc/meminfo obsahujı́cı́ dostupné informace o paměti RAM
3.2
Řı́dı́cı́ mechanismy
3.2.1
Řı́dı́cı́ smyčky CMCU
Na CMCU neustále běžı́ dvojice řı́dı́cı́ch smyček - vnějšı́ a vnitřnı́. Obě smyčky jsou plně konfigurovatelné.
V použitém nastavenı́ je rolı́ vnitřnı́ smyčky se zpětnou vazbou stabilizace kurzu, sklonu a náklonu a ovládánı́
polohy helikoptéry na základě senzorických dat, které dodává SMCU. Pokud je helikoptéra řı́zena kompletně
ručně pomocı́ RC vysı́lačky, jsou polohy joysticků využity jako vstupy do této smyčky. Tato vnitřnı́ velmi rychlá
stabilizace citelně usnadňuje řı́zenı́. Bez nı́ by platforma byla přı́liš nestabilnı́ a velmi obtı́žnou na pilotáž.
Výstupy z vnitřnı́ch smyček jsou dále předány do směšovače řı́dı́cı́ch signálů (Mixeru), kde se nastavı́ jaké
výstupy budou mı́t vliv na konkrétnı́ regulátor motoru.
Vnějšı́ smyčka je také zpětnovazebnou smyčkou, která na základě požadovaných hodnot uživatelských parametrů (vektor pozice a vektor rychlosti, přı́padně i akcelerace) poskytuje řı́dı́cı́ signály do vnitřnı́ smyčky. Jedná
se tady o strukturu vyššı́ úrovně, která řı́dı́ polohu helikoptéry v rámci zvoleného systému souřadnic. Řı́zenı́
externı́m programem je tedy možné prostřednictvı́m zápisu do uživatelských parametrů.
Hierarchie smyček se nacházı́ na obrázku 3.8.
Konfigurovatelnost hraje významnou roli. S nı́ je možné např. užı́vat uživatelských parametrů i ve vnitřnı́ch
smyčkách.
11
Obrázek 3.8: Hierarchie řı́dı́cı́ch smyček použité konfigurace.
3.2.2
Letové módy
Bezpilotnı́ systém LinkQuad umožňuje porovoz v těchto letových módech:
• Režim ručnı́ho ovládánı́ (Manual flight, Mode 1)
• Režim poloautomatického ovládánı́ (Semi-auto flight, Mode 2)
• Režim plně automatického letu (Automatic flight, Mode 3)
Módy se volı́ přepı́načem na RC vysı́lačce. Prvnı́m je plně ručnı́ režim, kdy je helikoptéra ovládána povely
řı́dı́cı́ch pák RC vysı́lačky, které určujı́ úhly náklonu, kurz a plyn. Samozřejmě je možné plně přizpůsobit
ovládánı́ a jeho citlivost konkrétnı́m potřebám. Druhým letovým módem je semi-automatický režim, který nenı́
v současné verzi prostředku zcela funkčnı́ a proto je v nastavenı́ deaktivován. Účelem tohoto režimu je poskytnout
automatický let ovlivnitelný uživatelským vstupem z RC vysı́lačky. Poslednı́m režimem je auto režim kdy se
LinkQuad řı́dı́ podle nastavených uživatelských proměných, při základnı́m nastavenı́ do nich při přepnutı́ módu
automaticky uložı́ aktuálnı́ pozici a tu nadále udržuje pomocı́ GPS navigace, kompasu a barometru. V tomto
režimu existuje i možnost augmentace bodu okolo kterého se vznášı́, tedy úpravu této polohy pomocı́ změny
cı́lových uživatelských parametrů podle pokynů z RC vysı́lačky. Tato funkčnost nebyla kvůli problémům se
stabilitou řı́dı́cı́ho firmwaru řádně otestována.
3.2.3
Komunikace se systémem LinkQuad
Komunikace mezi uživatelem a LinkQuadem probı́há pomocı́ 3 komunikačnı́ch kanálů. Prvnı́ kanál tvořı́ již
popsaný modem, sloužı́cı́ ke spojenı́ bezpilotnı́ho prostředku a řı́dı́cı́ho softwaru LinkGS. Komunikace může
bezpečně probı́hat až do vzdálenosti 1 km v otevřeném prostoru. V urbanizovaném prostředı́ se dosah může
zkrátit v závislosti na druhu a množstvı́ překážek. Druhý kanál ztělesňuje RC komunikace s vysı́lačkou pro
manuálnı́ řı́zenı́ a přepı́nánı́ letových módů. Třetı́m využı́vaným kanálem je ad-hoc 2.4 GHz Wi-Fi sı́t’ vytvářená
počı́tačem Gumstix, prostřednictvı́m které je umožněno shellové (SSH) spojenı́ s jeho operačnı́m systémem a
spouštěnı́ vlastnı́ch programů. Dosah sı́tě se bohužel pohybuje těsně nad hranicı́ 100 m. Obsluhovat operačnı́
systém a programy na něm běžı́cı́ je tedy možné pouze do této vzdálenosti od pozemnı́ stanice.
12
3.3
3.3.1
Softwarové vybavenı́ systému LinkQuad
Angström linux a Java
Jak již bylo několikrát zmı́něno, počı́tač Gumstix má na své připojené microSD kartě nainstalován operačnı́
systém Linux, konkrétně 32-bitovou distribuci Angström Linux z roku 2010 využı́vajı́cı́ headless jádro. Jedná
se o plnohodnotnou distribuci určenou primárně pro embedded zařı́zenı́, obsahujı́cı́ sadu základnı́ch linuxových
přı́kazů a několik doplňkových, které běžně nainstalované nebývajı́. Jako přı́klad takového přı́kazu může posloužit
screen. 1
Použitá verze Javy je nakonec Oracle Java(TM) SE Runtime Environment for Embedded (build 1.7.0 04ea-b20, headless). Prvnı́ verzı́, která byla testována byla Open verze Javy IcedTea Open Java SE, ale fungovala
pomaleji než uzavřená verze od Oraclu, navı́c obsahovala staršı́ verze knihoven a některé potřebné funkce tudı́ž
chyběly.
Angström linux má nainstalovaný a zkonfigurovaný C compiler gcc, nenı́ tedy problém překládat programy
psané v jazyku C přı́mo na počı́tači Gumstix.
3.3.2
LinkGS
LinkGS je hlavnı́ ovládacı́ program platformy psaný v jazyku C, použı́vajı́cı́ pro vizualizaci QT knihovny. Pro
správnou funkčnost zobrazovánı́ je nutné mı́t povolenou 3D akceleraci plochy ve Windows. S platformou LinkQuad komunikuje prostřednictvı́m komunikačnı́ho modemu připojitelného k počı́tači pomocı́ USB, parametry
připojenı́ (např. baudrate) jsou plně nastavitelné. Standardnı́ vzhled programu 3.9. V základnı́m nastavenı́
zobrazuje umělý horizont, až 8 modifikovatelných grafů vývoje senzorových proměnných, ovládacı́ prvky se
základnı́mi pokyny pro vypnutı́/zapnutı́ SMCU, CMCU, motorů a loggovánı́, indikátory stavu jednotlivých
komponent dle senzorů a konzoli se zprávami od systému.
Program sám o sobě je plně konfigurovatelný, jednotlivé komponenty (grafy, ovládacı́ prvky, umělý horizont
atd.) se dajı́ přesouvat a nastavovat jejich velikost, konfiguraci programu je možno uložit v XML formátu. Při
prvnı́m startu programu je také nutno načı́st XML konfiguračnı́ soubor dostupných senzorových dat platformy
LinkQuad (LinkQuadTelemetry.xml). Nastavenı́ řı́dı́cı́ architektury LinkBoardu je také možné exportovat do
XML, což se doporučuje, pokud existujı́ rozdı́lná nastavenı́, napřı́klad pro lety ve venkovnı́m prostředı́ a uvnitř
budov. Poslednı́m XML konfiguračnı́m souborem je soubor konfigurujı́cı́ mapu prostředı́. Zabudovaný systém
mapy prostředı́ však zatı́m nebyl otestován. To nicméně nenı́ na překážku, nebot’ jako grafické rozhranı́ plánovánı́
trajektorie bude použit grafický výstup systému AgentFly. Program LinkGS a všechny užité konfiguračnı́ soubory (včetně konfiguračnı́ch souborů LinkBoardu) se nacházı́ na přiloženém CD. Konfiguračnı́ soubory jsou jak
ve formě xml, tak v podobě screenshotů pro přı́padné užitı́ jako inspirace pro nastavenı́ novějšı́ verze platformy.
3.3.3
Konfigurace LinkBoardu
Následujı́cı́ řádky se budou věnovat konfiguraci autopilotu LinkQuadu - LinkBoardu - pomocı́ LinkGS. Otevřenı́
konfiguračnı́ho okna umožnı́ měnit veškeré nastavenı́ kontrolnı́ch mechanizmů vrtulnı́ku. Tato nastavenı́ je nutno
měnit s vypnutým CMCU i SMCU a pro uloženı́ je nutný zápis do konfiguračnı́ flash paměti LinkBoardu, až
poté je možné opět zapnout oba řı́dı́cı́ procesory. Všechna nastavenı́ je možné z paměti načı́st. Načı́tat lze bud’
všechno nastavenı́ naráz, nebo vybrané části z konfiguračnı́ho okna. Záložka Sensors (všechny záložky např.
obrázek 3.10) umožňuje měnit offsety a násobı́cı́ kontanty (gainy) u jednotlivých sensorů. Tyto hodnoty se
lišı́ pro každou verzi LinkBoardu a jsou určeny výrobcem. To samé platı́ pro hodnoty pod záložkou Filters,
kde se nastavujı́ komplementárnı́ filtry senzorických dat. Záložka Pan-Tilt Unit se použı́vá k nastavenı́ funkcı́
kamery. Nejdůležitějšı́mi záložkami jsou však záložky Mixer, RC sticks, Inner Loops a Flight Modes. RC Sticks
konfigurujı́ vstupy z RC vysı́lačky, Inner Loops nastavenı́ konstant a proměnných vnitřnı́ch řı́dı́cı́ch smyček a
záložka Flight Modes nastavuje proměnné a konstanty vnějšı́ kontrolnı́ smyčky pro automatické drženı́ polohy.
Mixer se stará o smı́senı́ řı́dı́cı́ch signálů a jejich distribuci regulátorům motorů a kamery.
1 Tohoto přı́kazu se dá využı́t pro odpojenı́ (a pro pozdějšı́ znovu připojenı́) programu terminálu, ve kterém byl spuštěn. To se
hodı́ při připojenı́ do systému přes SSH pomocı́ Wi-Fi. V přı́padě, že dojde ke ztrátě signálu, program spuštěný a běžı́cı́ v terminálu
se zastavı́. Při odpojenı́m pomocı́ screen může běžet dál, nebot’ se zbavil závislosti na SSH spojenı́.
13
Obrázek 3.9: Vzhled LinkGS s ukázkou zobrazenı́ grafů, umělého horizontu, indikátorů stavu komponent helikoptéry a ovládacı́ch tlačı́tek
3.3.4
Vnitřnı́ kontrolnı́ smyčky
U vnitřnı́ch smyček má každý letový mód svoje vlastnı́ konstanty (přı́klad nastavenı́ na obrázku 3.10). Konstanty
se nastavujı́ zvlášt’ pro Roll (náklon) a Roll Rate (mı́ra náklonu), Pitch (sklon dopředu/dozadu) a Pitch Rate
(mı́ra sklonu), Yaw (kurz) a výšku. U každé této operace je potřeba vybrat vstupnı́ proměnou (Input) a proměnou
jejı́ž hodnotě by se vstup měl rovnat (Target) pro proporčnı́, integračnı́ a derivačnı́ složku smyčky. Dále se
nastavujı́ offsety jednotlivých proměnných, jejich měřı́tka a limitnı́ hodnoty. Nakonec se nastavı́ váha té které
složky pomocı́ konstanty gain násobı́cı́ celou složku. Jestli je požadováno, aby výstup ovlivnila předchozı́ hodnota
dalšı́ proměnné či výstupu, je nutné nastavit ještě vstup Feed forward. Poslednı́m nezbytným nastavenı́m je na
jaký výstup odesı́lat vypočı́tané hodnoty. Při manuálnı́m módu (Mode 1) se jako požadované hodnoty volı́
hodnoty ovládacı́ch pák RC vysı́lačky, při automatickém režimu (Mode 3) se jako požadované hodnoty volı́
výstupy vnějšı́ch kontrolnı́ smyček. Vzhledem k nedostatku dokumentace musely být všechny konstanty řı́dı́cı́ch
smyček identifikovány experimentálně. Nastavovánı́ každé proměnné probı́halo iterativně, kdy se střı́daly fáze
nastavenı́ (vypnout CMCU a SMCU, nastavit, zapsat do flash paměti LinkBoardu, zapnout CMCU a SMCU),
a letové testy.
14
3.3.5
Vnějšı́ kontrolnı́ smyčky
Nastavenı́ vnějšı́ch smyček probı́há, stejně jako u vnitřnı́ch, volbou vstupnı́ch proměnných a požadovaných
hodnot jednotlivých složek ovládánı́ polohy. Na rozdı́l od vnitřnı́ch smyček, kde se reguluje přı́mo konkrétnı́
manévr (napřı́klad náklon), se zde reguluje přı́mo poloha platformy na vyššı́ úrovni v rámci zvolené soustavy
souřadnic. V použitém nastavenı́ je zvolena kartézská soustava souřadnic s počátkem v mı́stě, kde byl LinkQuad
zapnut, osou Y mı́řı́cı́ na východ, osou X směřujı́cı́ na sever a Z směřujı́cı́ kolmo od zemského povrchu. Pro
snazšı́ orientaci a výpočty v řı́dı́cı́m programu vyššı́ úrovně jsou však hodnoty vodorovných os transformovány
do souřadné soustavy tělesa helikoptéry, X je osou směřujı́cı́ dopředu, Y doprava. Osa Z představujı́cı́ vertikálnı́
vzdálenost od nadmořské výšky startu dále transformována nenı́. Výstupy těchto smyček se poté použijı́ jako
cı́le pro vnitřnı́ kontrolnı́ smyčky. Ukázka nastavenı́ je na obrázku 3.11.
3.3.6
Mixer
Zde se konfiguruje jaké vstupy budou mı́t vliv na daný regulátor motoru. Dalšı́m důležitým nastavenı́m je
přiřazenı́ minimálnı́ hodnoty výstupu do motorových regulátorů. Tato minimálnı́ hodnota bude motorům posı́lána
za každých okolnostı́, což se ukázalo jako potřebné při laděnı́ nastavenı́ platformy vzhledem k jejı́ nestabilitě při
přepı́nánı́ módů. Podrobnosti se nacházı́ v sekci 8.2.3.
3.3.7
Systém vedenı́ záznamu o letu
LinkQuad sám o sobě disponuje vlastnı́m systémem záznamu letu. Zaznamenává všechny údaje ze senzorů s
četnostı́ 500 záznamů za vteřinu. Toto ohromné množstvı́ dat k zápisu si vyžádalo vývoj speciálnı́ho filesystému
microSD karty určené jen a pouze k logovánı́. Operace čtenı́ logu z karty se kvůli tomu musı́ provádět pomocı́
programu LinkGS. Tento způsob tvorby logů se ukázal jako vhodný pro laděnı́ stability platformy a jistě i při
jejı́m vývoji. Zpracovávat takto veliká data však nenı́ pohodlné. Proto pro potřeby záznamů delšı́ch letů bude
využito vlastnı́ho systému z vyššı́ch řı́dı́cı́ch struktur zaznamenávajı́cı́ho vybrané proměnné.
3.3.8
Start systému LinkQuad
Pro nastartovánı́ systému je potřeba minimum úkonů. Vyžadováno je pouze zapnutı́ (+ počkánı́ 1 minutu
na inicializaci senzorů a boot operačnı́ho systému počı́tače Gumstix) a aktivace motorů (a přı́padné zapnutı́
vedenı́ logu) povelem z LinkGS. Poté je platforma plně připravena k letu. Při v současnosti užité konfiguraci
platformy se po aktivaci motorů vrtule ihned roztočı́ na nastavenou minimálnı́ úroveň otáček bez ohledu na
polohu plynové páky vysı́lačky. Pro vypnutı́ motorů a zastavenı́ vrtulı́ po skončenı́ letu je opět potřeba pokyn
z ovládacı́ho softwaru, je tedy třeba let ukončit v dosahu signálu komunikačnı́ho modemu pozemnı́ stanice. Při
vypı́nánı́ motorů je nutné počı́tat s prodlevou okolo 10 s než se motory skutečně deaktivujı́.
15
3.3.9
Ukázky konfigurace autopilotu LinkBoard
Obrázek 3.10: Ukázka nastavenı́ vnitřnı́ch smyček zodpovědných za stabilizaci a řı́zenı́ letu helikoptéry.
16
Obrázek 3.11: Ukázka nastavenı́ vnějšı́ch smyček
17
Obrázek 3.12: Ukázka nastavenı́ mixeru. Vstupy tvořı́ sloupce, regulátory motorů představujı́ jednotlivé řádky
18
Kapitola 4
Návrh architektury vyššı́ řı́dı́cı́ vrstvy
Na pozemnı́ stanici bude kromě řı́dı́cı́ho softwaru LinkGS spuštěna řı́dı́cı́ softwarová platforma. Řı́dı́cı́ platforma
bude přes Wi-Fi spojenı́ komunikovat s vyššı́ programovou řı́dı́cı́ vrstvou spuštěnou na uživatelském počı́tači
Gumstix na palubě helikoptéry. Od této vrstvy bude softwarová platforma dostávat v pravidelných intervalech
údaje o poloze a stavu bezpilotnı́ho systému. Simulačnı́ platforma umožnı́ krom vizualizace stavu helikoptéry
také zadat letovou trajektorii pomocı́ kontrolnı́ch bodů. Tyto body budou odeslány do vyššı́ programové vrstvy
helikoptéry, která je zpracuje a následně podle nich bude zadávat cı́le nižšı́ řı́dı́cı́ úrovni v podobě autopilotu
LinkBoard.
Obrázek 4.1: Schéma architektury vyššı́ řı́dı́cı́ vrstvy
Vyššı́ řı́dı́cı́ struktura se bude skládat ze dvou komponent. Z komponenty pro spojenı́ s pozemnı́ řı́dı́cı́
softwarovou platformou, která zároveň naplánuje trajektorii a z řı́dı́cı́ struktury, která vyčte data ze senzorů
a předá je komponentě. Řı́dı́cı́ struktura podle aktuálnı́ naplánované trajektorie bude řı́dit let poskytovánı́m
přı́kazů autopilotu.
Obrázek 4.2: Schéma vnitřnı́ architektury vyššı́ řı́dı́cı́ vrstvy
19
Kapitola 5
Řı́dı́cı́ software AgentFly
V této kapitole bude představen řı́dı́cı́ software AgentFly, vyvinutý v Centru Agentnı́ch Technologiı́ FEL ČVUT,
který bude použit pro řı́zenı́ z pozemnı́ stanice.
5.1
AgentFly
AgentFly ([AgentFly–12]) je multi-agentnı́ řı́dı́cı́ software a simulačnı́ prostředı́ civilnı́ letecké dopravy, schopné
velmi rozsáhlých simulacı́. Systém v sobě integruje pokročilé plánovánı́ letových trajektoriı́, decentralizovaný
systém detekce a zabráněnı́ kolizı́ (Collision Avoidance) a detailnı́ modely leteckých prostředků a prostředı́ s
možnostı́ 2D i 3D zobrazenı́. Mise jednotlivých letadel jsou specifikovány pomocı́ sady prostorových souřadnic,
kterými musı́ vést letová trajektorie. Celá operace může být bud’ naplánována na zemi před startem letadla bez
úvahy o možných kolizı́ch s ostatnı́mi účastnı́ky letového provozu, nebo dynamicky kdykoli během letu. Detekce
vzájemných konfliktů plánů probı́há až během letu peer-to-peer způsobem a ústı́ v dynamické přeplánovánı́
trajektorie, dokud nenı́ nalezena trajektorie bez kolizı́.
5.1.1
Simulace
Simulace se na konceptuálnı́ úrovni skládá ze synchronnı́ simulace virtuálnı́ho prostředı́ a asynchronnı́ch simulovaných leteckých prostředků. Každý prostředek je separátnı́ entita, která může být spuštěna na odděleném
počı́tači. I když je virtuálnı́ prostředı́ v principu samostatnou ucelenou jednotkou, může být také distribuováno
na vı́ce počı́tačů, což umožňuje redukovat zatı́ženı́ výpočetnı́ techniky.
5.1.2
Plánovánı́ trajektorie
Každé letadlo zastupované v simulaci svým softwarovým agentem může kdykoli během své mise zavolat plánovač
trajektorie. Trajektorie generovaná plánovačem je vždy spojitá a skládá se ze sekvence přı́mých elementů a
zatáček. Trajektorie musı́ být naplánována s ohledem na fyzikálnı́ omezenı́ dopravnı́ho prostředku, u letadel
napřı́klad minimálnı́ možný poloměr zatáčky, minimálnı́ rychlost apod. Plánovač trajektoriı́ helikoptér některá
omezenı́, jako je napřı́klad minimálnı́ poloměr zatáčky, nemusı́ brát v potaz a může počı́tat se schopnosti
helikoptér vznášet se na mı́stě a svisle stoupat/klesat. Použitým algoritmem plánovánı́ v současnosti může být
Hex-gridový plánovač ([HEX–11]), nebo Accelerated A* ([AAstar–09]), který během expanze stavového prostoru
určuje délku kroku expanze dynamicky, v závislosti na vzdálenosti expandovaného stavu od překážek.
20
5.1.3
Detekce koliznı́ch situacı́
V základu poskytuje AgentFly několik metod pro detekci a zabráněnı́ kolizı́. Každá z nich je implementována
jako oddělený plug-in, který může být kdykoli během letu dle potřeb aktivován a deaktivován. Podporován je
kooperativnı́ i nekooperativnı́ způsob. Nekooperativnı́ mód může být nasazen v přı́padě, že letadlo se kterým
nastane potenciálnı́ koliznı́ situace nechce, či nemůže komunikovat. Mezi kooperativnı́ způsoby patřı́ peer-to-peer,
kdy spolu letadla přı́mo komunikujı́ po dvojicı́ch, rule-based založený na leteckých pravidlech specifikovaných
Federal Aviation Administration USA a multi-party collision avoidance pro domluvu ve skupině.
5.1.4
Shrnutı́ vlastnostı́ systému AgentFly
• distribuovaný model letecké simulace
• pokročilé plánovánı́ trajektoriı́
• flexibilnı́ systém bráněnı́ kolizı́
• škálovatelnost
• pokročilá 2D/3D vizualizace
Všechna letadla jsou modelována pomocı́ autonomnı́ch softwarových agentů, kdy je každý agent zodpovědný
za své operace. Pro běh svých agentů systém AgenFly užı́vá multi-agentnı́ platformu AGlobe.
Obrázek 5.1: Grafická komponenta AgentFly - naplánovaná mise
21
Obrázek 5.2: Grafická komponenta AgentFly - vizualizace trajektorie letounu
Obrázek 5.3: Grafická komponenta AgentFly - vizualizace letounu
22
5.2
Multi-agentnı́ platforma AGlobe
AGlobe je multi-agentnı́ platforma pro běh softwarových agentů napsaná v jazyce Java. Jejı́mi největšı́mi
přednostmi jsou rychlost, systémová nenáročnost a možnost distribuce simulacı́ na vı́ce počı́tačů.
5.2.1
Architektura systému AGlobe
Schéma architektury se nacházı́ na obrázku 5.4.
Obrázek 5.4: Architektura systému AGlobe
Agent Platform je platforma, která poskytuje základnı́ prvky pro běh jednoho a vı́ce agentnı́ch kontejnerů.
Každá platforma běžı́ ve vlastnı́ instanci JVM. Hlavnı́ součásti agentnı́ platformy jsou Container Manager a
modul pro transport zpráv Message Transport.
Agentnı́ kontejner hostuje softwarové agenty a poskytuje jim základnı́ služby jako napřı́klad management agentů (startovánı́, migraci, ukončovánı́) nebo rozhranı́ pro přenos zpráv. Možnost běhu vı́ce agentnı́ch
kontejnerů na jedné platformě snižuje systémovou náročnost, protože je potřeba pouze jedné instance JVM.
Container Manager zajišt’uje startovánı́ a ukončovánı́ agentnı́ch kontejnerů.
Message Transport poskytuje efektivnı́ posı́lánı́ zpráv (ACL Messages) mezi dvěma a vı́ce agentnı́mi
kontejnery.
Agent je základnı́ autonomnı́ entita běžı́cı́ uvnitř agentnı́ho kontejneru. Každý agent běžı́ ve vlastnı́m
výpočetnı́m vlákně. Může komunikovat s ostatnı́mi agenty pomocı́ zpráv ACL Message a informace o simulovaném světě dostává pomocı́ systémových zpráv Topiců.
23
Kapitola 6
Architektura vyššı́ řı́dı́cı́ vrstvy
V předchozı́ch kapitolách bylo představeno schéma vyššı́ řı́dı́cı́ struktury bezpilotnı́ho systému (schéma se nacházı́
na obrázcı́ch čı́slo 4.1 a 4.2) a řı́dı́cı́ softwarová platforma AgentFly. V této kapitole se návrh architektury
prohloubı́ a konkretizuje.
AgentFly bude spouštěn na platformě AGlobe a vytvořı́ grafické rozhranı́ pro uživatelské zadávánı́ kontrolnı́ch bodů trajektorie. Dále vytvořı́ a spustı́ simulačnı́ prostředı́, umožňujı́cı́ připojenı́ vı́ce bezpilotnı́ch
prostředků najednou. Uživatel potom může specifikovat, kterému z nich si přeje zadat letové pokyny. Bezpilotnı́
prostředky nemusı́ být nutně skutečné, mohou existovat pouze v rámci simulačnı́ho prostředı́. V simulačnı́m
systému se však budou ostatnı́m prostředkům jevit jako reálné. Při zapojenı́ simulovaných i skutečných bezpilotnı́ch prostředků tak vznikne smı́šená simulace.
Každý bezpilotnı́ prostředek je v rámci systému reprezentován dvěma agenty, EntityPlaneAgentem a
EntityPilotAgentem. Agenti mezi sebou mohou komunikovat prostřednictvı́m posı́lánı́ a přijı́mánı́ zpráv, ACL
Message.
PilotAgent reprezentuje softwarovou část bezpilotnı́ho prostředku, kde se zpracovávajı́ přı́chozı́ kontrolnı́
body zadané uživatelem pozemnı́ stanice pomocı́ komponenty plánovače. Trajektorie se plánovačem zpracovávajı́
s ohledem na fyzická omezenı́ bezpilotnı́ho prostředku a bezletové zóny. Během letu může dojı́t k dynamickému
přeplánovánı́ vlivem zadánı́ nových bodů či řešenı́ koliznı́ situace. Každý PilotAgent má svůj vlastnı́ plánovač,
který je volán dle potřeby.
PlaneAgent reprezentuje hardwarovou část entity. Je spojen s modulem EntityBehavior zodpovědným za
vlastnı́ reprezentaci prostředku v simulaci. Komunikace mezi Behaviorem a PlaneAgentem probı́há prostřednictvı́m
systémových zpráv AGlobu, Topiců.
Ovládánı́ běhu simulace majı́ na starosti agenti SimulationAgent a ScenarioPlayer. ScenarioPlayer
je zodpovědný za vytvořenı́ a přı́padné odstraněnı́ bezpilotnı́ch prostředků (nebo také simulačnı́ch entit) ze
simulace. Dle konfigurace na začátku běhu simulace spustı́ všechny komponenty a agenty, kterými je entita
tvořena.
SimulationAgent ovládá simulaci jako takovou. Komunikuje synchronně se všemi Behaviory podle simulačnı́ho času, na základě kterého Behaviory spočı́tajı́ stavy jednotlivých entit v simulovaném prostředı́.
24
6.1
Realizace entity bezpilotnı́ho systému LinkQuad
Pro realizaci komunikace pozemnı́ stanice s bezpilotnı́m systémem LinkQuad bude na pozemnı́ stanici vytvořen
samostatný agent, LinkQuadGroundAgent, který bude prostřednictvı́m Wi-Fi sı́tě přijı́mat a odesı́lat zprávy ACL
Message. Přijı́mat bude zprávy s aktuálnı́m stavem (pozicı́ a náklony) helikoptéry, odesı́lat bude kontrolnı́ body
trajektorie, které uživatel vybral pomocı́ grafického rozhranı́ softwaru AgentFly. Data s aktuálnı́ informacı́ o
poloze a stavu helikoptéry předá pomocı́ asynchronnı́ systémové zprávy (Topicu) do modulu LinkQuadBehavior.
Modul LinkQuadBehavior bude zodpovědný za reprezentaci entity helikoptéry v simulačnı́m prostředı́ řı́dı́cı́ho
softwaru AgenFly a bude jako Behaviory všech entit synchronně připojen k SimulationAgentovi. Po obdrženı́
dat dojde k aktualizaci pozice a stavu reprezentace LinkQuadu v simulačnı́m prostředı́.
Struktura, která bude vybudována na uživatelském počı́tači Gumstix bude z hlediska nezbytných komponent AgenFly systému jednoduššı́, než struktura pozemnı́. V nezbytné platformě AGlobe budou spuštěni pouze
dva agenti. LinkQuadPlaneAgent a LinkQuadPilotAgent. Komunikace mezi nimi bude probı́hat pomocı́ zpráv
ACL Message. Oba agenti budou zastávat role popsané výše, tedy LinkQuadPlaneAgent bude ve spojenı́ s nižšı́
vrstvou pro komunikaci s HW. Dále bude pomocı́ zpráv ACL Message ve spojenı́ s LinkQuadGroundAgentem a bude mu předávat informace o stavu helikoptéry. Z pozemnı́ stanice LinkQuadPlaneAgent obdržı́ sadu
uživatelem zadaných souřadnic trajektorie a předá jı́ zprávou LinkQuadPilotAgentovi, který zavolá plánovač.
Po dokončenı́ plánovánı́ dojde k předánı́ naplánované trasy zpět LinkQuadPlaneAgentovi, který ji předá nižšı́
řı́dı́cı́ vrstvě pro komunikaci s HW helikoptéry.
Nižšı́ vrstvu pro komunikaci s HW a ovládánı́ helikoptéry bude reprezentovat LinkQuadGXsrvr. LinkQuadGXsrvr
bude načı́tat data ze senzorů a v pravidelných intervalech je bude předávat LinkQuadPlaneAgentovi. V přı́padě,
že obdržı́ sekvenci bodů tvořı́cı́ trajektorii, vypočı́tá pokyny pro autopilota LinkBoard bezpilotnı́ho systému LinkQuad a trajektorii proletı́.
Schéma výše popsané architektury se nacházı́ na obrázku 6.1. Bohužel pro nedostatek času, který vznikl
řešenı́m problémů se stabilitou bezpilotnı́ho systému LinkQuad zůstala výše popsaná struktura pouze konceptem
a nebyla naprogramována a otestována s výjimkou nižšı́ vrstvy pro komunikaci a ovládánı́ HW. LinkQuadGXsrvr
byl naprogramován a otestován. Detailněji bude rozebrán v přı́štı́ kapitole.
25
Obrázek 6.1: Schéma vyššı́ řı́dı́cı́ architektury, zobrazuje konfiguraci s helikoptérou LinkQuad, jednı́m reálným
a jednı́m simulovaným UAV
26
Kapitola 7
Implementace komunikace a letové
řı́dı́cı́ funkce
Cı́lem této kapitoly je navrhnout a implementovat strukturu pro čtenı́ senzorických dat a řı́zenı́ letu. Výsledkem
bude program, který se spustı́ na uživatelském počı́tači Gumstix, načte data ze senzorů, zpracuje je dle potřeby a
následně podle nich umožnı́ letět na uživatelem určený bod v prostoru. Program se bude pouštět bud’ samostatně,
nebo jako komponenta dřı́ve popsané řı́dı́cı́ struktury.
Komunikace s pozemnı́ stanicı́ bude probı́hat po 2.4 GHz Wi-Fi ad-hoc sı́ti bud’ pomocı́ navržené struktury,
nebo pomocı́ SSH spojenı́ bud’ prostřednictvı́m programu puTTY známého z platformy Windows, či přı́kazem
ssh z Linuxové přı́kazové řádky. Vzhledem k dosahu této sı́tě, který je do 100 m od pozemnı́ stanice, je potřeba
mı́t tuto skutečnost na vědomı́ a bud’ létat ve vymezeném okruhu, nebo program spouštět pomocı́ přı́kazu
screen. 1
7.1
Komunikačnı́ server LinkQuadGXsrvr
SMCU i CMCU posı́lajı́ data ze senzorů na sériové porty RS232, ke kterým je připojen počı́tač Gumstix.
Angström Linux běžı́cı́ na Gumstixu oba porty detekuje a připojı́ do adresáře /dev/ sloužı́cı́ho jako adresář
připojených zařı́zenı́. V současnosti je port CMCU mapován jako /dev/ttyS0 a port SMCU jako /dev/ttyS2.
Oba porty je před použitı́m nutné zkonfigurovat, nastavit baudrate, přı́stupový mód atd. Pro připojenı́ a konfiguraci sériových portů se v Javě může kromě placených modulů použı́t i opensource knihovna RXTX, ale během
vývoje se ukázalo, že nefunguje spolehlivě. Proto bude mezi hardwarovou platformu a komunikačnı́ server v Javě
vložena mezivrstva, server serialComm psaný v jazyku C, který zkonfiguruje porty a umožnı́ čtenı́/zápis dat.
Data načtená z obou MCU budou zpracována a využita ve funkci řı́zenı́ letu, která vypočte cı́le pro vnějšı́
kontrolnı́ smyčku a předá je pomocı́ zápisu uživatelských parametrů na port CMCU.
Ukázky výstupu tohoto programu jsou na obrázcı́ch 7.4 a 7.5 na konci této kapitoly.
7.2
Základnı́ struktura programu LinkQuadGXsrvr
Následujı́cı́ řádky budou popisovat obecnou strukturu programu, poté budou rozebrány vybrané třı́dy a jejich
činnosti.
Program nejprve vytvořı́ dvě instance třı́dy LinkGXConnector (controlPort a sensorPort), jednu pro
obsluhu komunikace s portem CMCU a druhou pro obsluhu SMCU. LinkGXConnector je tedy zodpovědný za
čtenı́ a zápis na jeden sériový port z této vyššı́ programové úrovně. Aby navázal spojenı́, LinkGXConnector
nejdřı́ve spustı́ serialComm3, C socket server, viz předchozı́ sekce.
Dále musı́ specifikovat, která data a jak často majı́ být posı́lána. Tomu se děje prostřednictvı́m sestavenı́ a
1 Pouštět programem screen a pak jej přı́kazem odpojit od terminálu, čı́mž se program zbavı́ závislosti na SSH spojenı́ a nebude
hrozit pozastavenı́ činnosti programu při výpadku spojenı́.
27
odeslánı́ požadavku na oba sériové porty. Požadavek stačı́ odeslat pouze jednou na začátku spojenı́. Vyžádaná
data jsou potom autopilotem LinkBoard posı́lána automaticky. Oba connectory poté spustı́ každý své vlákno
pro čtenı́ dat přı́chozı́ch ze serialCommu.
Komunikace probı́há pomocı́ paketů, je tedy nutné jednotlivé pakety rozkládat a sestavovat z nich data.
Sestavená data vlákna controlPortu i sensorPortu zapisujı́ do hs_received, instance třı́dy HeliState, odkud
je běžı́cı́ vlákno objektu LinkUpdater updater v pravidelných intervalech kopı́ruje do objektu heliState. Děje
se tomu tak proto, že do hs_received se zapisujı́ nová data jakmile přijdou a zpracujı́ se. Mezitı́m jsou však
načtená data potřeba ve zbytku programu, předevšı́m řı́dı́cı́ch funkcı́ch letu. Tento přı́stup zmı́rnı́ následky režie
synchronizace vı́cevláknového přı́stupu k jednomu objektu. Navı́c umožnı́ sledovat, jestli nedošlo k přepnutı́
letového módu (to když se lišı́ letové módy v hs_received a heliState) a ihned na to zareagovat v hlavnı́
programové smyčce.
Aktuálnı́ polohu a dalšı́ data zaznamenává do souboru flightlog.txt v nastavitelných intervalech objekt
LinkVarLogger. Ten kvůli své činnosti ve svém vlákně také musı́ přistupovat k objektu heliState.
Hlavnı́ programová smyčka je zodpovědná za obsluhu přı́kazů, bud’ zadaných uživatelem pomocı́ stisku
kláves, či módem letu po bodech v prostoru. Dále zodpovı́dá za pravidelné (vždy po 0.1 s) volánı́ řı́dı́cı́ funkce
letu flyTo() objektu FlightOperator. Ke správnému fungovánı́ této funkce je potřeba aktuálnı́ stav helikoptéry
uložený v objektu heliState. Metoda flyTo() vypočte výstupnı́ uživatelské parametry (cı́le pro vnějšı́ kontrolnı́
smyčku CMCU) a předá je controlPortu, který je rozložı́ do paketů a odešle serialCommu, aby je zapsal na
sériový port CMCU.
Obrázek 7.1: Základnı́ struktura programu LinkQuadGXsrvr
7.3
serialComm3: C socket server
Tento program vytvářı́ serverový socket, do kterého se připojı́ Javovský program. Javovský program tento
server také spouštı́. Sloužı́ pouze ke čtenı́/zápisu dat z/na jeden sériový port. Program přijı́má dva argumenty,
ID portu (textem zadaná cesta Linuxového zařı́zenı́) a čı́slo portu. Server je dvou-vláknový, po zkonfigurovánı́
portu spustı́ zapisovacı́ vlákno, které čte ze socketu a přijatá data ihned zapı́še na port. Druhé vlákno je čtecı́.
To čte přı́chozı́ data z portu a ihned je odesı́lá na socket. Tı́mto způsobem je umožněna plná komunikace přes
sériový port.
Na začátku je port otevřen pro čtenı́ i zápis, zápis neblokuje výstup, jedná se tedy o asynchronnı́ komunikaci. Pomocı́ struktury jazyka C termios, která tvořı́ terminálový interface pro konfiguraci asynchronnı́ch
komunikačnı́ch portů, jsou posléze nastaveny požadované atributy portu. Všechna možná nastavenı́ (a přı́slušné
konstanty) jsou k nalezenı́ bud’ v dokumentaci jazyka C, nebo v Linuxových manuálových stránkách (přı́kaz
man termios).
28
7.4
Hlavnı́ řı́dı́cı́ funkce
Hlavnı́ řı́dı́cı́ funkce startServer() je vstupem do celého programu LinkQuadGXsrvr. Je zodpovědná za inicializaci všech pomocných struktur a za řı́zenı́ letu. Vytvořı́ a připojı́ oba LinkGXConnectory, které prostřednictvı́m
spuštěnı́ a připojenı́ serialCommu obstarajı́ komunikaci se sériovými porty. Při inicializaci hlavnı́ funkce čeká,
dokud ze sériových portů nepřijdou prvnı́ validnı́ data (to zabránı́ nehodám při zapnutı́ LinkQuadGXsrvru za
letu) a poté spustı́ řı́dı́cı́ smyčku.
Na začátku řı́dı́cı́ smyčky se vždy zkontroluje standardnı́ vstup, jestli uživatel pomocı́ klávesnice nezadal
letové pokyny (v současnosti let o konstantnı́ vzdálenost dopředu, dozadu, do stran, nahoru, dolů, změnu kurzu
a spuštěnı́ letu po trajektorii zadané seznamem bodů). Dále dojde pomocı́ porovnánı́ letových módů v heliState
a hs_received k odchycenı́ a obslouženı́ přı́padné změny letových módů.
V přı́padě plně ručnı́ho režimu dojde pouze k předánı́ aktuálnı́ho stavu helikoptéry do uživatelských parametrů a letové pokyny z klávesnice jsou ignorovány.
Při plně automatickém letu se vyhodnotı́ přı́padné pokyny od uživatele, dle nich se adekvátně změnı́ letové
cı́le a dojde k inicializaci letu prvnı́m volánı́m funkce flyTo() objektu FlightOperator. Tato funkce vypočte
hodnoty uživatelských parametrů. V každé dalšı́ iteraci řı́dı́cı́ funkce se funkce flyTo() volá znovu a tı́m řı́dı́
let po celou dobu běhu programu v automatickém režimu. Funkce flyTo() se zároveň stará o kontrolu, jestli už
nebylo dosaženo cı́le. Přijatelná odchylka je nastavená na 1 m. V tom přı́padě dojde k uloženı́ aktuálnı́ pozice
helikoptéry a vznášenı́ stroje na mı́stě.
Pro proletěnı́ trajektorie (spuštěné přı́kazem CMD_WAYPOINT) se užı́vá seznam bodů, mezi kterými helikoptéra
přı́močaře létá. Od výše popsaného se prolétánı́ trajektorie lišı́ v tom, že když helikoptéra dorazı́ do cı́le (jednoho
ze zadaných bodů trasy), kontroluje přı́tomnost dalšı́ho zadaného bodu. Když seznam bodů obsahuje dalšı́ bod,
iniciuje se automaticky dalšı́ let. To ale pouze v přı́padě, že uživatel mezitı́m nezměnil přı́kaz z CMD_WAYPOINT
na jiný.
Na konci řı́dı́cı́ smyčky pokaždé dojde k zapsánı́ aktuálně vypočtených uživatelských parametrů na port
CMCU a pozastavenı́ běhu (na 0.1 s) před dalšı́ iteracı́.
7.5
Přijı́mánı́ paketů
Data jsou na sériové porty autopilotem LinkBoard posı́lána ve formě paketů. Také žádosti o proměnné musejı́
být odeslány v této podobě. Proto bude prvnı́ ukázána skladba paketu po jednotlivých bytech. Složenı́ paketu
bylo odpozorováno z ukázky kódu poskytnuté výrobcem zařı́zenı́. Index začı́ná čı́slem 1.
ID1
ID2
len
VER
flagy
SRC
DEST
TYPE
SEQ
data
...
poslednı́ data
CHKSUM
• ID1 a ID2 - identifikátory začátku paketu. Majı́ hodnoty 107, respektive 120, ve znacı́ch ’x’ a ’m’.
• len - délka paketu bez prvnı́ch 3 bytů, tedy bez ID1, ID2 a této len.
• VER - verze komunikačnı́ho protokolu, v současnosti konst. 0.
• flagy - jednotlivé bity nesou informaci o tom, jestli jsou byty SRC, DEST, TYPE a SEQ nastaveny.
• SRC - identifikátor zdroje, nenı́ v současné verzi využit
• DEST - id cı́le paketu, nenı́ v současné verzi využit
• TYPE - určuje typ paketu
• SEQ - sekvenčnı́ čı́slo, nenı́ v současné verzi využito
• data - prvnı́ byte obsahujı́cı́ skutečná data, má index v závislosti na délce hlavičky 3 + délka hlavičky.
• poslednı́ data - poslednı́ byte dat, má index len + 3 - 1
• CHKSUM - kontrolnı́ CRC součet, xorujı́ se všechny byty kromě tohoto. Má index 3 + len.
29
Hlavička paketu, to jest byty VER, flagy, SRC, DEST, TYPE a SEQ, má proměnlivou délku v závislosti na
tom, které byty jsou nastaveny (nastavenı́ se vyznačı́ pomocı́ jednotlivých bitů v bytu flagy). Minimálnı́ délka
hlavičky jsou 3 byty - VER, flagy a TYPE.
Data od serialCommu jsou v LinkGXConnectoru čtena pomocı́ Javovského InputStreamu a kopı́rována do
objektu RingBuffer, kruhového bufferu, který zaručuje, že kdyby byla načtena jen část paketu, zbytek se načte
při následujı́cı́m čtenı́ a bude zařazen hned za prvnı́ část. SMCU i CMCU majı́ tyto objekty separátnı́
Je vidět, že v přı́padě, kdy je úložná struktura RingBufferu zcela zaplněná a pokusı́me se o vloženı́ nového
prvku, dojde k přetečenı́ bufferu a přepsánı́ prvnı́ho uloženého prvku. Za normálnı́ch okolnostı́ je program dost
rychlý na to, aby načtené pakety z bufferu stı́hal zpracovat a uvolnit mı́sto pro nové, načtené. V přı́padě že by
došlo k zahlcenı́ a jeden (či vı́ce) byte by byl přepsán, takto poškozený paket by neprošel pozdějšı́ kontrolou a
byl z bufferu vymazán.
RingBuffer je dále procházen od začátku (tedy od pozice prvnı́ho prvku) a jsou hledány ID1 a ID2 byty.
V přı́padě nálezu se kromě vymazánı́ předcházejı́cı́ch (nepotřebných) bytů prověřı́ podle bytu len, jestli buffer
obsahuje dostatečné množstvı́ načtených bytů. Když ano, nakopı́ruje se úsek bytů patřičné délky do datové
struktury objektu Packet. V přı́padě opaku to znamená, že celý paket ještě nedorazil a zbytek teprve čeká na
načtenı́. Poté se operacı́ xor na všechny byty paketu kromě poslednı́ho spočte kontrolnı́ součet a porovná se
s poslednı́m bytem paketu. V každém přı́padě poté dojde k uvolněnı́ mı́sta vymazánı́m nakopı́rovaných bytů
z RingBufferu. Pokud hodnota kontrolnı́ho součtu souhlası́ s bytem CRC, paket je řádně načten a může se
přistoupit k jeho rozbalenı́.
Rozbalenı́ začne po kontrole bytu VER, tedy jestli se jedná o požadovanou verzi protokolu. Při úspěšné
kontrole dojde na přečtenı́ informacı́ z hlavičky paketu a vytvořenı́ objektu Metadata obsahujı́cı́ho informace
o uložených datech, ze kterých je v současnosti důležitá ta o typu paketu. Podle takto určeného typu paketu
posléze dojde ke složenı́ dat z paketu. Jak bylo řečeno v úvodu, před začátkem komunikace je potřeba na oba
porty poslat paket se žádostı́ obsahujı́cı́ informace která senzorová data (proměnné) jsou požadována a jak často
se majı́ posı́lat. Už na začátku je tedy známo, co za data od kterého portu budou přicházet a nynı́ podle této
informace stačı́ data extrahovat a správně složit z datové sekce paketu. Proměnné jsou různého typu, od float
přes int po byte a to včetně variant bez znaménka. Při skládánı́ proměnných se musı́ kromě jejich bytových
délek a pořadı́ v jakém jsou v paketu brát na zřetel tzv. endiannes, tzn. že Angström Linux a platforma
LinkBoard je little endian, zatı́mco Javovská Virtual Machine je Big Endian. Je tedy nutné správně
měnit pořadı́ bytů proměnných. Načtená data jsou uložena do pomocných struktur SCMCUData a SSMCUData, ze
kterých jsou po dokončenı́ skládánı́ synchronně zkopı́rována do objektu HeliState.
7.6
Žádosti o proměnné a zápis uživatelských parametrů
Jak odeslánı́ žádostı́, tak uživatelských parametrů je implementováno třı́dou Communication, kde se nacházı́
statické metody jak pro žádost údajů z SMCU, tak CMCU a také zápis uživatelských parametrů na port.
Proměnných v současné verzi LinkBoardu existuje 158 pro CMCU a 67 pro SMCU. Typ, měřı́tko, identifikátory a jednotky proměnných jsou určeny verzı́ LinkBoardu a jsou popsány pomocı́ PDF dokumentu dodaného
výrobcem zařı́zenı́.
Tvorba žádostı́ o proměnné je poměrně přı́močarou záležitostı́. Do pole jsou uloženy identifikátory proměnných.
Protože je toto pole vytvářeno spolu s inicializacı́ instance objektu SCMCUDataRequestPart s fixnı́ délkou rovnou maximálnı́mu počtu proměnných, je nutné uložit i jejich počet. Následně dojde k volbě četnosti odesı́lánı́.
Poté přijde na řadu tvorba Metadat, ale jediné, co je v současné verzi protokolu využito je typ paketu. Podle
zadaných metadat dojde k vytvořenı́ hlavičky, dále se zapı́še počet a identifikátory proměnných do datové části
paketu, paket se uzavře vypočı́tánı́m a zapsánı́m kontrolnı́ho součtu a poté se předá LinkGXConnectoru aby jej
zapsal na sériový port.
Následujı́cı́ řádky se budou věnovat odeslánı́ uživatelských parametrů na sériový port. Uživatelských parametrů je v současnosti vı́ce typů (float, int, uint8_t ...). Od každého typu existuje 10 proměnných. LinkQuadGXsrvr využı́vá všech 10 floatových uživatelských parametrů. Před odeslánı́m hodnot je nutné nastavit
pomocı́ flagů, o které parametry a proměnnou se jedná. Pro šetřenı́ výpočetnı́ho času se vzhledem k tomu, že v
průběhu běhu programu budou odesı́lány neustále ty stejné parametry, flagy vytvořı́ pouze jednou na začátku
při prvnı́m odeslánı́. Stejně jako je tomu tak při tvorbě žádosti o proměnné, dojde následně k uloženı́ dat do
pomocné struktury, k jejich rozloženı́ a uloženı́ do datové části paketu. Dále se vytvořı́ hlavička a kontrolnı́
30
součet a hotový paket se odešle na CMCU port.
7.7
7.7.1
Řı́dı́cı́ funkce letu
Funkce letu po přı́mce
Jak už napovı́dá název, funkce FlightOperator.flyTo() má na starosti řı́zenı́ letu helikoptéry. Kvůli problémům
se stabilitou platformy LinkQuad je v současné době implementována poměrně jednoduchým způsobem (o
problémech vı́ce viz sekce 8.2). Funkce vyjde ze současného stavu helikoptéry a kalkuluje výstupnı́ parametry
tak, aby helikoptéra letěla přı́mou čarou k cı́lovému bodu. Při letu se střı́dajı́ tři fáze. Fáze akcelerace, fáze letu
při dosaženı́ požadované cestovnı́ rychlosti a fáze brzděnı́ před cı́lem, viz obrázek 7.2, přejato z [Wzorek–11].
Helikoptéra tedy při dosáhnutı́ každého zadaného bodu zastavı́ a začne akcelerovat k dalšı́mu.
Obrázek 7.2: Optimálnı́ vývoj rychlosti
Cestovnı́ rychlost je v současnosti z bezpečnostnı́ch důvodů konstantnı́ a nastavena na maximum 4 m/s s
pomalou akceleracı́. Helikoptéra letı́cı́ mezi dvěma body se pohybuje po úsečce. Tato úsečka je parametrická,
závislá na parametru t. V čase t=0 je ve výchozı́m bodu, v čase t=1 je v cı́lovém bodu. Řı́dı́cı́ funkce tedy vypočte
aktuálnı́ čas, respektive hodnotu parametru relativnı́ho časového kroku (v programu proměnná tpar), dle něj
aktuálnı́ předpokládané hodnoty polohy helikoptéry na úsečce (tzv. referenčnı́, či kontrolnı́ bod, v programu
proměnné refPoint v objektu LineOut) a porovná jı́ s hodnotou polohy aktuálnı́. Ukázka na obrázku 7.3 přejata
z [Wzorek–11]. Při odchylkách nastavı́ uživatelské parametry tak, aby se helikoptéra vrátila na svou trasu. Dále
akceleruje do dosaženı́ cestovnı́ rychlosti a hlı́dá vzdálenost od cı́lového bodu. V závislosti na rychlosti začne v
určité vzdálenosti od cı́le brzdit. Všechny tyto letové operace jsou omezeny fyzikálnı́mi vlastnostmi helikoptéry
a zvolenou bezpečnostnı́ rezervou.
Nynı́ bude popsáno jak probı́há výše popsaný postup v programovém kódu. Při prvnı́m spuštěnı́ (inicializaci)
si funkce flyTo() uložı́ výchozı́ stav helikoptéry. tpar má na začátku hodnotu 0. Dále spustı́ pomocnou funkci
line() zodpovědnou za výpočet vzdálenosti cı́lového bodu a hlavně za polohu aktuálnı́ho referenčnı́ho bodu
trajektorie v závislosti na hodnotě tpar. Tyto hodnoty line() uložı́ do objektu LineOut lnOut. Při dalšı́
iteraci hlavnı́ kontrolnı́ funkce je funkce flyto() spuštěna znovu a aktualizuje informace o poloze helikoptéry.
Následně opět spustı́ line(), která vypočte nový referenčnı́ bod. flyto() poté porovná aktuálnı́ polohu s
polohou referenčnı́ho bodu a na základně poměru vzdálenosti těchto dvou poloh s celkovou délkou trasy vypočte
normalizované ∆ tpar, které poté přičte k současné hodnotě parametru a tı́m posune referenčnı́ bod přı́štı́
iterace. Sada podmı́nek zajistı́, aby tpar ∈ <0,1> a aby tpar >= tpar předchozı́. V této iteraci se nakonec
ještě nastavı́ výstupnı́ parametry jako objekt FlightToOut out, kam se jako cı́l polohy uložı́ iniciálnı́ poloha
+ referenčnı́ bod, jako rychlost rychlost spočtená s ohledem na limity, akceleraci a brzděnı́. Kurz v současné
verzi zůstane zachován iniciálnı́, ale kód je připraven na přı́padnou rotaci helikoptéry do směru letu. Objekt
FlightToOut out poté hlavnı́ řı́dı́cı́ funkce vezme a zapı́še pomocı́ složeného paketu na sériový port.
31
Obrázek 7.3: Trajektorie a referenčnı́ (kontrolnı́) bod.
7.7.2
Funkce rotace
Tato funkce zajišt’uje vzhledem k relativnı́ nestabilitě platformy při přı́liš rychlé změně kurzu pouze to, aby rotace
probı́hala o stanovený limit ve stupnı́ch a aby se na nový kurz helikoptéra otáčela kratšı́ trasou. Funkce tedy
spočte ∆ kurz, počet stupňů, o který se helikoptéra během iterace má otočit a předá tuto hodnotu uživatelským
parametrům. Funkce je spouštěna iterativně hlavnı́ funkcı́ přes funkci flyTo() do té doby, dokud helikoptéra
nenı́ natočena požadovaným směrem.
Obrázek 7.4: Zobrazenı́ načtených senzorových veličin pomocı́ LinkQuadGXsrvru
Obrázek 7.5: Ukázka výstupu LinkQuadGXsrvru při zadánı́ pokynu k letu. Tento ukázkový pokyn byl zadán
bez signálu GPS, což způsobilo takto veliké záporné hodnoty souřadnic.
32
Kapitola 8
Experimenty
8.1
V simulaci
Při komunikaci s dodavatelem helikoptéry LinkQuad byly představeny plány budoucı́ho rozvoje platformy.
Plány počı́taly s tı́m, že bude dodavatelem naprogramován Datový hub, program, který by obstaral komunikaci
pozemnı́ stanice s platformou. Do tohoto hubu by měly být připojeny všechny ostatnı́ programy a komponenty,
jako je např. řı́dı́cı́ software AgenFly.
Zapojitelnou součástı́ měla být i softwarová fyzikálnı́ simulace helikoptéry LinkQuad. Bohužel do této chvı́le
dodavatel zařı́zenı́ nedodal ani Datový hub, ani simulačnı́ program. Práce [Jiřinec–11], kde se Tomáš Jiřinec
zabýval stabilizacı́ této helikoptéry a která vedla k vytvořenı́ SimuLinkového modelu této helikoptéry, nemohla
být použita pro přechod na novou verzi autopilotu LinkBoard a s tı́m souvisejı́cı́ změnu charakteristik helikoptéry.
8.2
Na reálném HW
Zřejmě nejdéle trvajı́cı́ byly experimenty na reálném HW prováděné za účelem nalezenı́ vhodného nastavenı́ konstant řı́dı́cı́ch smyček autopilotu. Vzhledem k nedostatku dokumentace veškeré laděnı́ probı́halo experimentálně
iterativnı́m způsobem. Optimálnı́ naladěnı́ si kladlo za cı́l splnit tyto podmı́nky:
• snadná ovladatelnost z vysı́lačky ve venkovnı́m a vnitřnı́m prostředı́
• stabilita v bezvětřı́ a ve středně silném větru
• stabilita během přepı́nánı́ letových režimů
• dostatečně silná odezva vnějšı́ch kontrolnı́ch smyček na změnu uživatelských parametrů
Během reálných experimentů byly zjištěny následujı́cı́ problémy s řı́dı́cı́m firmwarem autopilotu LinkBoard:
• Nestabilita při změně kurzu - při přı́liš rychlé změně autopilot nenı́ schopen helikoptéru dostatečně
rychle stabilizovat a může dojı́t k pádu.
• Nestabilita při přepı́nánı́ letových režimů - Nestabilita se projevuje výpadkem jednoho (náhodně)
motoru a nezastavitelným pádem helikoptéry. Na odstraněnı́ této vady firmware spolupracoval výrobce
návrhem unifikovat zcela konstanty vnitřnı́ch smyček automatického i ručnı́ho režimu a nastavit mixer
tak, aby motory neustále bez ohledu na situaci dosahovaly minimálnı́ch otáček. Po aplikaci těchto návrhů
se situace nezlepšila. Výrobce zkontroloval užitý konfiguračnı́ soubor a slı́bil dodat referenčnı́ konfiguračnı́
soubor, popřı́padě novou verzi řı́dı́cı́ho firmware. Do současné chvı́le tak neučinil.
Podařilo se však nalézt metodu jak toto chovánı́ eliminovat. Nehody měly vždy spojitost s nastaveným
výkonem motorů. Standardnı́ přepnutı́ na automatický mód by mělo probı́hat ručnı́m letem na požadovanou
pozici, zastavenı́m helikoptéry na mı́stě a upravenı́m výkonu motorů tak, aby se stroj volně vznášel. Při
33
tomto postupu helikoptéra selhává. Avšak při aplikaci výkonu dostatečného pro stoupánı́ helikoptéry se
stabilita během přepı́nánı́ režimů citelně zlepšila.
• Nestabilita při větru - V bezvětřı́ je schopen bezproblémového vznášenı́ kolem bodu, od kterého se
přı́liš nevzdaluje (maximálně o poloměr cca 1 m). Ve větru rychlosti do cca 5 m/s se rozptyl pozice okolo
bodu podstatně zvýšı́. Při většı́ rychlosti větru nelze automatický let vzhledem k nestabilitě doporučit.
Během hledánı́ přijatelného nastavenı́ bylo přistoupeno k experimentům s dosahem komunikace a hlavně
k experimentům s automatickým udržovánı́m polohy systému LinkQuad. Po odladěnı́ nalezených chyb experimenty pokračovaly v podobě pokusných letů řı́zených pokyny uživatele z klávesnice za účelem nalezenı́ chyb
v kódu letové řı́dı́cı́ funkce. Poslednı́ testovánı́ se týkalo automatického průletu jednoduché trajektorie dané
fixnı́m seznamem souřadnic.
Následujı́cı́ sekce se budou zabývat jednotlivými experimenty v průběhu vývoje.
8.2.1
Vnitřnı́ prostředı́
Prvnı́m cı́lem bylo najı́t nastavenı́, které by dovolilo ovládat helikoptéru ve vnitřnı́ch prostorách. Ve vnitřnı́ch
prostorách má smysl uvažovat pouze o ovládánı́ z RC vysı́lačky, nebot’ automatický let je závislý na GPS. Létanı́
ve vnitřnı́ch prostorách je pro helikoptéru z hlediska stabilizace snazšı́, protože na let nemajı́ vliv faktory jako
vı́tr a jı́m produkované turbulence. Stı́sněné prostory však zvyšujı́ nároky na rychlost a citlivost reakce lidského
pilota. Vliv však majı́ relativně stı́sněné prostory, užitý bezpečnostnı́ polystyrenový kryt vrtulı́ platformy a při
letu v blı́zkosti země, či překážek i vzdušné vı́ry vrtulı́.
Kromě nalezenı́ hodnot pro kontrolnı́ smyčky byla potřebná úprava citlivosti pomocı́ škálovánı́ měřı́tka
ovládacı́ch pák RC vysı́lačky a tı́m omezenı́ maximálnı́ch hodnot náklonů (pitch a roll) na 20 stupňů. Velká
pozornost musela být věnována nastavenı́ kontrolnı́ smyčky kurzu, nebot’ LinkQuad vykazoval se změnou kurzu
nestabilitu, kterou se zatı́m nepodařilo plně odstranit, pouze redukovat. Jedná se o záležitost kontrolnı́ch mechanizmů jako takových, ne o záležitost nastavenı́. Změna kurzu i v současnosti vyžaduje pomalý postup. Výsledný
konfiguračnı́ soubor indoor.xml je umı́stěn na CD, viz popis obsahu CD v kapitole čı́slo 10.
8.2.2
Vnějšı́ prostředı́: manuálnı́ režim
Při prvnı́m pokusu o venkovnı́ let byla zjištěna nevhodnost nalezené konfigurace pro tyto účely. Polystyrenový
kryt tvořil moc velkou plochu, do které mohl vı́tr tlačit a tı́m velmi destabilizovat platformu. Kromě toho kryt
omezuje větrné kužely tvořené rotory, které, jak se ukázalo později, výrazně pomáhajı́ následky větru potı́rat.
Impulsy způsobené větrem byly však i po odejmutı́ krytu natolik veliké, že je nebylo možno plně kompenzovat
pokyny z RC vysı́lačky. Muselo tedy dojı́t k opětovnému přeškálovánı́ pák vysı́lačky a zároveň ke zvýšenı́ stability
platformy pomocı́ opětné rekonfigurace konstant vnitřnı́ch kontrolnı́ch smyček.
8.2.3
Vnějšı́ prostředı́: vznášenı́ a let po přı́mce
Po nalezenı́ vhodných konstant vnitřnı́ch kontrolnı́ch smyček ručnı́ho ovládánı́ byly tyto konstanty mı́rně upraveny a aplikovány i pro řı́dı́cı́ smyčky automatického letu. U automatického letu však bylo nutné nastavit i
konstanty vnějšı́ch smyček. Jejich optimálnı́ hodnoty byly identifikovány pomocı́ experimentů se vznášenı́m
a následně upraveny při pokusech s funkcı́ letu po přı́mce. Na CD je umı́stěn výsledný konfiguračnı́ soubor
outdoor.xml. Dalšı́m obsahem je několik videozáznamů letových pokusů s platformou, viz popis obsahu CD v
kapitole čı́slo 10.
V přı́padě letu po přı́mce má vı́tr vliv na cestovnı́ rychlost stroje. Vı́tr často odvane helikoptéru z naplánované
trajektorie a ta to musı́ kompenzovat návratem, který jı́ zpomalı́. Zvolené bezpečnostnı́ limity se ukazujı́ jako
moc přı́sné pro let ve větru. Jejich lepšı́ odhad si vyžádá dalšı́ experimenty.
Následujı́cı́ zobrazenı́ trajektoriı́ využı́vá měřenı́ vzdálenosti systému LinkQuad od mı́sta, kde byl zapnut a
to v souřadném systémy kdy osa X směřuje na východ a osa Y na sever.
Následujı́cı́ ukázky demonstrujı́ lety po trajektorii zadané fixnı́m seznamem souřadnic za větrného počası́.
Jak bylo řečeno v kapitole 7.7.1, helikoptéra zastavuje u každé souřadnice a poté se rozlétává k dalšı́mu. Na
přiloženém cd se nacházı́ videozáznam průletu trajektorie.
34
Obrázek 8.1: Fotografie bezpilotnı́ho systému LinkQuad za letu
Obrázek 8.2: Ukázka rozptylu polohy při automatickém udržovánı́ polohy ve větru. Zeleně vyznačen počátečnı́
bod, červeně koncový.
35
Obrázek 8.3: Ukázka rozptylu výšky při automatickém udržovánı́ polohy ve větru.
Obrázek 8.4: Záznam průletu trajektorie dané seznamem souřadnic. Zeleně počátečnı́ bod, červeně koncový.
Žluté body vyznačujı́ polohu souřadnic.
36
Obrázek 8.5: Záznam vývoje rychlosti. Je vidět, že zvolený limit akcelerace je přı́liš přı́sný. Zároveň je patrné,
že při letu na prvnı́ souřadnice vál podstatně slabšı́ vı́tr, než později.
Obrázek 8.6: Záznam vývoje nadmořské výšky při průletu trajektorie.
37
Obrázek 8.7: Záznam druhého průletu trajektorie dané seznamem souřadnic. Zeleně počátečnı́ a zároveň koncový
bod. Žluté body vyznačujı́ polohu souřadnic. Těsně před cı́lem došlo k poryvu větru, který vedl k zastavenı́
helikoptéry, která se následně stabilizovala a navrátila na trasu.
Obrázek 8.8: Záznam vývoje rychlosti při druhém průletu trajektorie.
38
Obrázek 8.9: Záznam vývoje nadmořské výšky při druhém průletu trajektorie.
39
Kapitola 9
Zhodnocenı́ výsledků a směry dalšı́ho
vývoje
9.1
Zhodnocenı́ dosažených výsledků
V souladu se zadánı́m práce proběhlo seznámenı́ s helikoptérou LinkQuad, jejı́m HW i SW a řı́dı́cı́mi principy.
Vývoj softwaru byl bohužel zdržen pomalou odezvou výrobce zařı́zenı́ a neúplnou dokumentacı́ a zpočátku
i neaktuálnı́ verzı́ seznamu dostupných proměnných. Dlouhý čas si vyžádalo experimentálnı́ laděnı́ systému
LinkQuad tak, aby byl schopen letu jak na ručnı́, tak automatické ovládánı́. Podařilo se však vyvinout řı́dı́cı́
server platformy (LinkQuadGXsrvr) umožňujı́cı́ jak načı́tánı́ dat ze senzorů a komunikaci s pozemnı́ stanicı́, tak
automatické lety po přı́mce zadané bud’ uživatelem z pozemnı́ stanice, či celou trajektoriı́ bodů. Byly podniknuty
experimenty na reálném bezpilotnı́m prostředku LinkQuad, které nastavenı́ a naprogramované části otestovaly.
Nepodařilo se však plně vyvinout a otestovat celou vyššı́ řı́dı́cı́ strukturu s řı́dı́cı́m softwarem AgentFly. Struktura
byla navrhnuta pouze na konceptuálnı́ úrovni a nebyla naprogramována a otestována.
9.2
Směry dalšı́ho vývoje
Pro snadnějšı́ pilotáž a kontrolu platformy při misı́ch na delšı́ vzdálenost bude vhodné zapojenı́ a otestovánı́
kamerového systému platformy LinkQuad.
Důležitým směrem dalšı́ho vývoje bude nalezenı́ volnějšı́ch bezpečnostnı́ch limitů a vývoj algoritmu pro plynulý průlet trajektorie dané složitějšı́ křivkou. Takové křivky se skládajı́ z vı́ce segmentů ohraničených zadanými
krajnı́mi body, mezi kterými se křivka matematicky interpoluje napřı́klad pomocı́ hermitovské (Fergussonovy)
kubiky. Takováto interpolace zajistı́ i C2 spojitost (spojitost i prvnı́ a druhé derivace) těchto segmentů.
Dále bude nezbytné realizovat vyššı́ řı́dı́cı́ strukturu, což zahrnuje implementaci architektury navržené v
kapitole 7 a připravenı́ plánovače upraveného pro helikoptéry pro nasazenı́ dle standardu AgentFly.
Protože AgentFly disponuje systémem zabráněnı́ kolizı́m (viz. str. 21), dalšı́m směrem vývoje bude jeho
nasazenı́ a hlavně otestovánı́ v kooperaci s ostatnı́mi reálnými bezpilotnı́mi prostředky.
40
Kapitola 10
Obsah přiloženého CD
• Foto - adresář s fotografiemi platformy LinkQuad
• LinkGS - adresář s řı́dı́cı́m softwarem LinkGS
• LinkQuadGXsrvr - adresář s projektem Eclipse, kde je implementována řı́dı́cı́ struktura LinkQuadGXsrvr.
• Nastaveni LinkBoard - adresář s konfiguračnı́mi xml soubory a se screenshoty nastavenı́ řı́dı́cı́ch smyček
helikoptéry
• PDF - adresář obsahujı́cı́ tuto bakalářskou práci v PDF podobě + jejı́ zdrojové texové kódy
• Video - adresář s krátkými filmečky zachytávajı́cı́mi let helikoptéry
• obsah.txt- výpis obsahu celého cd ve stromové struktuře.
41
Literatura
[Jiřinec–11] Jiřinec, T., Stabilization and control of unmanned quadcopter, Praha ČVUT FEL, 2011
[Wzorek–11] Wzorek, M., Selected Aspects of Navigation and Path Planning in Unmanned Aircraft Systems,
Linköping Institute of Technology at Linköping University, 2011
[Wikipedia–12] Unmanned aerial vehicle,
http://en.wikipedia.org/wiki/Unmanned_aerial_vehicle, 2012
[Kivrak–06] Kıvrak, A., Ö., Design of control systems for quadrotor flight vehicles. Mechatronics, Engineering
Department: Atılım University, 2006
[UASTech–12] Dokumentace LinkBoard, UAS Technologies Sweden, Linköping, 2012
[AgentFly–12] Šišlák,D., Volf, P., Kopřiva, S., Pechouček,M.: AgentFly: Scalable, High-Fidelity Framework for
Simulation, Planning and Collision Avoidance of Multiple UAVs, Praha ČVUT FEL, 2012
[AAstar–09] Šišlák,D., Volf, P., Pechouček,M., Accelerated A* Trajectory Planning: Grid-based Path Planning
Comparison, Praha ČVUT FEL, 2009
[HEX–11] Chrpa, L., Komenda, A., Smoothed Hex-grid Trajectory Planning Using Helicopter Dynamics, Praha
ČVUT FEL, 2011
[MAN–12] Linux Manual Pages, http://www.kernel.org/doc/man-pages/, 2012
[JAVA–12] Oracle Corporation, Java SE 7 Documentation, http://docs.oracle.com/javase/7/docs/, 2012
42

Navrh ridici architektury bezpilotniho vrtulniku LinkQuad

Transkript

Podobné dokumenty

Astronomický kurz Hvězdárny Hradec Králové

ME 2016 soupisky

Simulace chování leteckého dispe£era p°i °azení letadel p°ed

TÉMA: ELEKTROTECHNIKA / UMĚLÁ INTELIGENCE

4IZ631 INTELIGENTNÍ SYSTE´ MY

Markovské rozhodovací procesy, zpětnovazebné učení

Systém pro robotickou tele-výuku

zde

KYBERNETIKA A UMEL´A INTELIGENCE 1.´Uvod do kybernetiky a