Traduction automatique, non relue par un locuteur natif. L'anglais fait foi.

Premiers pasModifier sur GitHubSource : docs/tutorials/01-first-orbit.md

Tutoriel 1 — Ma première orbite : où sont les satellites GPS

Kind: orbit · Scénario : scenarios/orbit-sgp4-gps.toml (copie pédagogique : scenarios/orbit.toml) · Difficulté : débutant · ~15 min

À la fin, vous aurez propagé la véritable constellation GPS opérationnelle, lu sa disponibilité et sa géométrie, et exporté un tableau de l'endroit où se trouve réellement chaque satellite dans l'espace — et vous saurez que ce tableau est validé par rapport à une référence externe, et non par rapport à lui-même.

Ce qu'est ce scénario#

Les satellites GPS (Global Positioning System) indiquent à un utilisateur où il se trouve et quelle heure il est. Avant tout cela, il faut savoir où sont les satellites et combien d'entre eux un utilisateur peut voir. C'est la géométrie, et la géométrie fixe le plancher de la précision avec laquelle vous pouvez être positionné (la dilution de la précision, ou DOP). Ce tutoriel :

  1. prend un véritable instantané Celestrak gps-ops de la constellation GPS (2021-07-28, 30 satellites, véritables éléments à deux lignes, TLE),
  2. propage chaque satellite avec le modèle validé SGP4/SDP4 (Simplified General Perturbations 4 / Simplified Deep-space Perturbations 4),
  3. détermine à chaque pas de temps quels satellites un utilisateur en orbite terrestre basse peut voir (ligne de visée, occultation par la Terre et masque d'élévation de 5°),
  4. transforme cette géométrie en PDOP (dilution de la précision en position) et en précision de position, et
  5. exporte les positions réelles des satellites dans le référentiel terrestre fixe centré sur la Terre (ECEF) vers un fichier SP3 (Standard Product 3, le format d'orbite précise de l'International GNSS Service, IGS ; GNSS désigne Global Navigation Satellite System).

Le fil conducteur est : TLE → propagation SGP4 → ECEF par époque → visibilité → nombre de satellites visibles → PDOP → sigma de position = PDOP · σ_UERE, où σ_UERE est l'erreur de distance équivalente de l'utilisateur (l'erreur de mesure de distance à 1 σ par satellite).

L'exécuter#

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"])

Ou ouvrez le Studio dans le navigateur et choisissez le scénario d'orbite.

Lire le résumé d'une ligne#

L'exécution déterministe (seed = 17) affiche :

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)

Champ par champ :

  • scenario 4c51512369a6 — l'empreinte de scénario de 12 caractères. Elle identifie de façon unique les entrées exactes (graine, seuils, paramètres du modèle, bloc TLE). Changez une entrée et elle change ; gardez-les identiques et vous reproduisez l'exécution bit pour bit. La même empreinte est inscrite dans le pied du graphique et dans le fichier JSON (JavaScript Object Notation) de résultat.
  • 345/361 samples GNSS-nominal — sur les 361 pas de temps, l'utilisateur dispose d'un point exploitable à 345 d'entre eux (95,6 %). L'exécution est un passage de 12 h (43 200 s) avec un pas de 120 s.
  • best PDOP 1.07 — la meilleure (la plus basse) dilution de la précision en position sur le passage. Un PDOP proche de 1 correspond à une excellente géométrie ; plus il est bas, mieux c'est.
  • pos 1.07m — la meilleure précision de position : sigma de position = PDOP · σ_UERE. Dans ce scénario, sigma_uere_m = 1.0, de sorte que les deux nombres sont numériquement égaux ici — mais la règle est PDOP × UERE, et non « position = PDOP ». Avec une UERE de 3 m, le sigma de position serait d'environ 3,2 m. (Voir le piège à la fin.)
  • Les figures d'horloge (holdover, p95, integrity, security) sont fournies parce que le paquet d'orbite porte aussi une horloge pendant le passage ; elles sont l'objet du Tutoriel 2, et non de celui-ci. (security affiche n/a (no attack) parce qu'aucune attaque n'est configurée.)

Le bloc de géométrie du JSON contient les nombres sous-jacents :

"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
}

Où sont les satellites ? (la récompense)#

La géométrie est bonne parce que les satellites sont réellement dans la couche GPS. Prouvez-le — exportez leurs positions dans le référentiel terrestre fixe :

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

Les trois premiers satellites au premier pas d'échantillonnage, ECEF en km (le fichier SP3 porte une quatrième colonne, d'horloge, écrite avec le marqueur « sans valeur » 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

Prenons le rayon géocentrique de PG01 :

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

La référence indépendante non circulaire : est-ce vraiment une orbite GPS ?#

Un tutoriel qui vérifie le moteur par rapport à lui-même ne prouve rien. Voici l'ancrage externe, non circulaire, de chaque affirmation ci-dessus.

1. Les satellites se situent sur la véritable couche d'orbite terrestre moyenne (MEO) du GPS. Le demi-grand axe nominal du GPS est a = 26 560 km, soit une altitude ≈ 20 180 km au-dessus du rayon terrestre moyen de 6 378 km (IS-GPS-200, la spécification d'interface du GPS ; la norme de performance du service de positionnement standard (SPS) du GPS, département de la Défense des États-Unis (DoD) ; Misra & Enge, Global Positioning System, 2e éd.). Le rayon instantané de PG01, de 26 480,9 km, se situe à quelques centaines de km de a — exactement ce que produit l'excentricité réelle du GPS (~0,005–0,02). Le test tests/tutorials.rs::tutorial1_satellites_are_in_the_gps_meo_shell vérifie 26000 km < |r(PG01)| < 27200 km par rapport à ce a publié, qui est externe à Kshana.

2. La durée du passage est une révolution GPS. La troisième loi de Kepler donne la période T = 2π√(a³/μ) avec a = 26,560 km et μ = 398,600.4418 km³/s² (World Geodetic System 1984, WGS-84 ; rapport technique de la National Imagery and Mapping Agency NIMA TR8350.2) : T = 43,078 s = 11.967 h, soit un demi-jour sidéral. La durée du scénario de 43 200 s (« environ une révolution GPS ») s'y accorde à moins de 0,3 % près, et la trace au sol du GPS se répète chaque jour sidéral (deux révolutions), selon l'IS-GPS-200.

3. Les positions propagées sont validées, et non auto-cohérentes. Le propagateur SGP4/SDP4 qui a produit ce tableau ECEF concorde avec l'ensemble des 666 vecteurs de vérification AIAA (American Institute of Aeronautics and Astronautics) 2006-6753 avec un pire cas de 4,12 mm (tests/sgp4_verification.rs, docs/SGP4-VALIDATION.md) et concorde avec la crate indépendante sgp4 à moins du micron. Le tableau que vous avez exporté est donc vérifié par rapport à une implémentation de référence externe, et non par rapport à l'arithmétique propre de Kshana.

Une remarque sur les dates SP3. L'en-tête d'époque SP3 affiche une date calendaire de substitution (2000-01-01) ; la propagation part en réalité de l'époque propre à chaque TLE (2021). Lisez le tableau comme « positions ECEF au premier pas d'échantillonnage », et non « au 1 janv. 2000 ».

Ce que le test fixe#

tests/tutorials.rs transforme chaque nombre ci-dessus en contrat d'intégration continue :

  • tutorial1_orbit_headline_holds — best_pdop ≈ 1.071, best_position_sigma_m == best_pdop (parce que sigma_uere_m = 1.0), samples_total == 361, et le résumé contient 345/361.
  • tutorial1_satellites_are_in_the_gps_meo_shell — le rayon de PG01 se situe dans la bande de la couche GPS, vérifié par rapport au a = 26,560 km publié.

Si le moteur cesse un jour de produire une véritable couche GPS, la construction passe au rouge.

Pièges et unités#

  • Le sigma de position est PDOP × UERE, et non PDOP. Les deux sont égaux uniquement parce que sigma_uere_m = 1.0 ici. Changez l'UERE et ils se séparent.
  • Les figures de synchronisation temporelle sont en nanosecondes, la figure de position en mètres. Ne les mélangez pas.
  • holdover_s est quantifié par la grille (une borne inférieure au pas de la grille temporelle). Dans ce passage, l'utilisateur est pratiquement toujours en position fixée, donc le holdover est de 0 s (aucune panne à traverser en roue libre) — c'est le bon cas.

Pour aller plus loin#

  • Resserrez ou élargissez le masque d'élévation (mask_deg) et observez la disponibilité changer — c'est un exercice de niveau 2.
  • Remplacez-le par un instantané TLE récent avec scripts/fetch_tles.sh (niveau 2 « utiliser des données récentes »).
  • Passez au Tutoriel 2 — Holdover d'horloge, où le signal GNSS est retiré et où l'horloge embarquée doit tenir en roue libre.