Mám dvě konfigurace propeleru, které testuji. Jeden je téměř symetrický kolem svého těžiště (je trochu těžký zdola, ale samotné trysky jsou stejné vpředu i vzadu). Druhý má na zádi další čtyři trysky pro další translační delta-v.
Tento obrázek ukazuje asymetrickou konfiguraci. Symetrická je velmi podobná, ale bez 15cm odstupu mezi druhou sadou translačních trysek. Poloměr je asi 2 a čtvrt metru a délka je asi 9 metrů; CG je 4 metry od zadní části.
Ale s asymetrickou konfigurací mám opravdu podivné výsledky.
Optimální skupiny kandidátů
Bohužel jsem nebyl schopen najít originální papír pro COG. Samotný algoritmus je ale popsán na dvou místech, která jsem našel:
- Shoemaker, D. 2013. Přehled logických algoritmů pro výběr tryskové sondy. Na konferenci AAS Guidance & Control Conference, Breckenridge, CO.
- Wie Bong. 2008. Kapitola 7: Rotační manévry a řízení postojů. Dynamika a řízení vesmírných vozidel . (Zdá se, že tento je ve formátu PDF na Googlu. V mé kopii je algoritmus uveden v části 7.6.2, počínaje s. 474.)
Pozemky níže jsou mým pokusem reprodukovat ty, které jsou uvedeny v recenzi Shoemaker. Základní myšlenka je, že máte příkazový vektor $ \ mathbf {b} $ o velikosti $ d $ (jeden vstup na stupeň volnosti), normalizovaný na délku 1 a thruster na -time pole $ \ mathbf {x} $ délky $ N $ (jedno pro každý propeler). Snažíte se vyřešit
$$ \ mathbf {A} \ mathbf {x} = \ mathbf {b} $$$$ \ textrm {s výhradou omezení}} \ mathbf {x} \ geq \ mathbf {0} $$
Nemůžete to přímo vyřešit, protože je to omezené. Takže místo toho předpokládáme, že pro $ d $ stupňů volnosti potřebujeme zapnout trysky $ d $ a rozdělit $ \ mathbf {x} $ na $ \ mathbf {\ hat {x}} $ (pro vybrané trysky) a $ \ mathbf {\ tilde {x}} $ (u trysek se rozhodně držíme stranou).
Můžeme tedy rozdělit $ \ mathbf {A} $ na odpovídající $ \ mathbf {\ hat { A}} $ (čtverec) a $ \ mathbf {\ tilde {A}} $ pro každý oddíl $ \ mathbf {x} $. Pomocí toho můžeme vyřešit
$$ \ mathbf {\ hat {A}} \ mathbf {\ hat {x}} = \ mathbf {b} \, \ textrm {.} $$
To dává všem kandidátským skupinám trysek, z nichž jen některé jsou optimální. Celý algoritmus popisuje, jak zmenšujete prostor pro vyhledávání a eliminujete skupiny, které jsou zjevně neoptimální - ty, kde $ \ mathbf {\ hat {A}} $ je singulární, kde zapnutí nějakého propouštěče ne v $ \ mathbf {\ hat {x}} $ vytváří lepší skóre, nebo kde je jakákoli hodnota v $ \ mathbf {\ hat {x}} $ menší než $ - \ epsilon $.
Poslední optimální skupiny kandidátů jsou ty, které maximalizují skóre $ \ mathbf {b} \ cdot (\ mathbf {\ hat {c}} \ mathbf {\ hat {A}} ^ {- 1}) ^ \ mathrm {T} $, kde $ \ mathbf {c} $ je vektor nákladů (v zásadě průtok pro každý propeler, když je zapnutý) a vhodně rozděleny jako u $ \ mathbf {A} $ a $ \ mathbf {x} $. (Všimněte si, že většina lidí předpokládá, že všechny náklady jsou pro jednoduchost 1.)
Takže! To nás přivádí k grafům.
Zobrazuji zde pouze 3 DOF, takže jsem provedl výpočty pouze pro rotaci nebo pouze pro překlad. Příkazy $ \ mathbf {b} $ mají tedy velikost 3. Takže pro čistý překlad $ \ hat {x} $ bude $ \ mathbf {b} _ \ textrm {translation} = \ left [1 \, 0 \, 0 \ right] $; pro čistý $ \ hat {y} $ překlad, $ \ mathbf {b} _ \ textrm {překlad} = \ left [0 \, 1 \, 0 \ right] $; atd. Totéž dělám pro rotaci.
Takže generuji síťovou jednotku příkazů. Pro každý COG najdu optimální sadu (nebo sady) trysek, které se mají použít, a spočítám skóre a celkovou dobu zapnutí (součet $ \ mathbf {\ hat {x}} $). Obrázek on-times pak ukazuje jednotkovou sféru zmenšenou součtem vypočítaných on-times. Údajem o autoritě má být, podle mého čtení, body jednotkové koule zmenšené podle vzájemného skóre. Barevná mapa je vypočítána shodně.
Výsledky
výsledky překladu jsou podle očekávání identické:
Už několik dní s tím bojuji. Mám podezření , že problém souvisí s rozkladem LU, který používám k převrácení matic kandidátské autority. Proč jsem dospěl k tomuto závěru? V mé matici translační autority mají všechny mé buňky pouze dvě velikosti (0 a sto něco). Ale ve své matici rotační autority dostávám několik velikostí, které jsou malé (~ 8) a spoustu, které jsou větší (200 až 600).
Viděl někdo jiný něco podobného? Nyní jsem vyzkoušel dva různé dekompaktní algoritmy LU a produkují stejný výstup. (Oba používají částečné otočení a měly by být stabilní; jeden je z GSL. Také kontroluji číslo vzájemné podmínky výsledku a vyřazuji kandidátské skupiny, kde rcond < eps .)
Když jsem poprvé psal kód v Pythonu, místo rozkladu LU jsem použil SVD a nezdálo se, že by tím konkrétním problémem trpěl. Ale teď, když píšu v kompilovaném jazyce, vzbuzuje znepokojení relativní algoritmická složitost SVD, takže bych raději použil LU, pokud je to možné.