Tutoriál 1 — Moje první oběžná dráha: kde jsou družice GPS

Kind: orbit · Scénář: scenarios/orbit-sgp4-gps.toml (výuková kopie: scenarios/orbit.toml) · Obtížnost: začátečník · ~15 min

Na konci budete mít propagovanou skutečnou provozní konstelaci GPS, přečtete si její dostupnost a geometrii a exportujete tabulku, kde přesně každá družice ve vesmíru je — a budete vědět, že tato tabulka je ověřena proti vnější referenci, nikoli sama proti sobě.

Co tento scénář je#

Družice GPS (Global Positioning System) říkají uživateli, kde je a kolik je hodin. Předtím je ale třeba vědět, kde družice jsou a kolik z nich uživatel vidí. To je geometrie a geometrie určuje spodní mez toho, jak přesně lze určit polohu (faktor DOP, zhoršení přesnosti). Tento tutoriál:

vezme skutečný snímek konstelace GPS gps-ops z Celestraku (2021-07-28, 30 družic, skutečné dvouřádkové elementy, TLE),
propaguje každou družici ověřeným modelem SGP4/SDP4 (Simplified General Perturbations 4 / Simplified Deep-space Perturbations 4),
v každém časovém kroku vypočte, které družice vidí uživatel na nízké oběžné dráze Země (přímá viditelnost, zákryt Zemí a elevační maska 5°),
promění tuto geometrii v PDOP (faktor zhoršení přesnosti polohy) a přesnost polohy a
exportuje skutečné polohy družic v zemské pevné soustavě se středem v Zemi (ECEF) do souboru SP3 (Standard Product 3, formát přesných drah Mezinárodní služby GNSS, IGS; GNSS je globální družicový navigační systém).

Osnova je: TLE → propagace SGP4 → ECEF pro každou epochu → viditelnost → počet viditelných družic → PDOP → sigma polohy = PDOP · σ_UERE, kde σ_UERE je ekvivalentní chyba měření vzdálenosti uživatele (chyba měření vzdálenosti 1-σ na družici).

Spusťte jej#

cargo run -- scenarios/orbit-sgp4-gps.toml

Python:

import json, kshana
result = json.loads(kshana.run(open("scenarios/orbit-sgp4-gps.toml").read()))
print(result["geometry"]["best_pdop"], result["geometry"]["best_position_sigma_m"])

Nebo otevřete Studio v prohlížeči a vyberte scénář oběžné dráhy.

Přečtěte si jednořádkové shrnutí#

Deterministický běh (seed = 17) vypíše:

scenario 4c51512369a6 | 345/361 samples GNSS-nominal | best PDOP 1.07 pos 1.07m | quantum holdover 0s p95 2.59e-5ns integrity 1.000 security n/a (no attack) | classical holdover 0s p95 6.7ns integrity 1.000 security n/a (no attack)

Pole po poli:

scenario 4c51512369a6 — 12znakový hash scénáře. Je otiskem přesných vstupů (seed, prahy, parametry modelu, blok TLE). Změníte-li jakýkoli vstup, změní se; ponecháte-li je stejné, reprodukujete běh bit po bitu. Stejný hash je vyznačen v patičce grafu a v souboru výsledku JSON (JavaScript Object Notation).
345/361 samples GNSS-nominal — z 361 časových kroků má uživatel použitelné řešení polohy v 345 z nich (95,6 %). Běh je průlet 12 h (43 200 s) s krokem 120 s.
best PDOP 1.07 — nejlepší (nejnižší) faktor DOP polohy za celý průlet. PDOP blízko 1 je vynikající geometrie; čím nižší, tím lepší.
pos 1.07m — nejlepší přesnost polohy: sigma polohy = PDOP · σ_UERE. V tomto scénáři platí sigma_uere_m = 1.0, takže obě čísla jsou zde číselně shodná — ale pravidlem je PDOP × UERE, nikoli „poloha = PDOP“. Při UERE 3 m by sigma polohy bylo ~3,2 m. (Viz úskalí na konci.)
Údaje o hodinách (holdover, p95, integrity, security) se objevují, protože balíček oběžné dráhy nese i hodiny po celý průlet; jsou předmětem Tutoriálu 2, nikoli tohoto. (security ukazuje n/a (no attack), protože není nastaven žádný útok.)

Blok geometrie v JSON obsahuje podkladová čísla:

"geometry": {
  "samples_total": 361,
  "samples_with_fix": 345,
  "sigma_uere_m": 1.0,
  "best_pdop": 1.0713624151805556,
  "median_pdop": 2.318376881311817,
  "best_position_sigma_m": 1.0713624151805556,
  "median_position_sigma_m": 2.318376881311817
}

Kde jsou družice? (odměna)#

Geometrie je dobrá, protože družice skutečně jsou ve slupce GPS. Dokažte to — exportujte jejich polohy v zemské pevné soustavě:

cargo run -- scenarios/orbit-sgp4-gps.toml --export-sp3 gps.sp3

První tři družice v prvním vzorkovacím kroku, ECEF v km (soubor SP3 nese čtvrtý sloupec s hodinami, zapsaný jako značka „bez hodnoty“ 999999,999999):

PG01   9771.575585  24612.128830      0.003744 999999.999999
PG02  20449.643959 -11875.958365 -12379.457079 999999.999999
PG03  26467.367408     45.510223   4010.411755 999999.999999

Vezměte geocentrický poloměr PG01:

|r(PG01)| = sqrt(9771.575585^2 + 24612.128830^2 + 0.003744^2) = 26480.9 km

Nekruhové orákulum: je to opravdu dráha GPS?#

Tutoriál, který kontroluje engine sám proti sobě, nic nedokazuje. Zde je externí, nekruhová opora pro každé tvrzení výše.

1. Družice leží na skutečné slupce střední oběžné dráhy Země (MEO) systému GPS. Nominální hlavní poloosa GPS je a = 26 560 km, výška ≈ 20 180 km nad středním poloměrem Země 6 378 km (IS-GPS-200, rozhraní specifikace GPS; Standard výkonnosti standardní určovací služby GPS (SPS), Ministerstvo obrany USA (DoD); Misra & Enge, Global Positioning System, 2. vyd.). Okamžitý poloměr PG01 26 480,9 km leží několik set km od a — přesně to, co vytváří skutečná excentricita GPS (~0,005–0,02). Test tests/tutorials.rs::tutorial1_satellites_are_in_the_gps_meo_shell ověřuje 26000 km < |r(PG01)| < 27200 km proti této publikované hodnotě a, která je vnější vůči Kshana.

2. Délka průletu je jeden oběh GPS. Třetí Keplerův zákon dává periodu T = 2π√(a³/μ) s a = 26,560 km a μ = 398,600.4418 km³/s² (World Geodetic System 1984, WGS-84; technická zpráva Národní agentury pro zobrazování a mapování NIMA TR8350.2): T = 43,078 s = 11.967 h, půl hvězdného dne. Trvání scénáře 43 200 s („~jeden oběh GPS“) tomu odpovídá s odchylkou pod 0,3 % a pozemní stopa GPS se opakuje každý hvězdný den (dva oběhy), podle IS-GPS-200.

3. Propagované polohy jsou ověřené, nikoli jen vnitřně konzistentní. Propagátor SGP4/SDP4, který tuto tabulku ECEF vytvořil, souhlasí se všemi 666 ověřovacími vektory AIAA (Americký institut pro letectví a kosmonautiku) 2006-6753 v nejhorším případě na 4,12 mm (tests/sgp4_verification.rs, docs/SGP4-VALIDATION.md) a shoduje se s nezávislým crate sgp4 na úrovni pod mikrometr. Exportovaná tabulka je tedy kontrolována proti externí referenční implementaci, nikoli proti vlastní aritmetice Kshana.

Poznámka k datům v SP3. Hlavička epochy SP3 ukazuje zástupné kalendářní datum (2000-01-01); propagace ve skutečnosti běží od vlastní epochy každého TLE (2021). Čtěte tabulku jako „polohy ECEF v prvním vzorkovacím kroku“, nikoli „dne 1. ledna 2000“.

Co test zafixuje#

tests/tutorials.rs mění každé číslo výše ve smlouvu CI:

tutorial1_orbit_headline_holds — best_pdop ≈ 1.071, best_position_sigma_m == best_pdop (protože sigma_uere_m = 1.0), samples_total == 361 a shrnutí obsahuje 345/361.
tutorial1_satellites_are_in_the_gps_meo_shell — poloměr PG01 leží v pásmu slupky GPS, ověřeno proti publikované hodnotě a = 26,560 km.

Pokud engine někdy přestane vytvářet skutečnou slupku GPS, sestavení zčervená.

Úskalí a jednotky#

Sigma polohy je PDOP × UERE, nikoli PDOP. Obojí je stejné jen proto, že zde platí sigma_uere_m = 1.0. Změňte UERE a rozejdou se.
Údaje o časování jsou v nanosekundách, údaj o poloze v metrech. Nezaměňujte je.
holdover_s je kvantováno mřížkou (dolní mez v kroku časové mřížky). Během tohoto průletu je uživatel v podstatě stále v řešení, takže holdover je 0 s (není žádný výpadek, kterým by bylo třeba setrvat) — to je dobrý případ.

Kam dál#

Zpřísněte nebo rozšiřte elevační masku (mask_deg) a sledujte, jak se mění dostupnost — to je cvičení úrovně 2.
Vyměňte snímek TLE za čerstvý pomocí scripts/fetch_tles.sh (úroveň 2 „použijte čerstvá data“).
Pokračujte Tutoriálem 2 — Holdover hodin, kde je signál GNSS odebrán a palubní hodiny musejí setrvat samy.