1. Contexte

Le projet Mercury est un de centre de contrôle sol composé de deux parties :

• Station sol —> Ordinateur pour récupérer les données de la télémétrie analogique et afficher ces données de manière clair et structurée. Celui ci peux également transmettre des valeurs à la fusée (avant vol).
• Télémétrie —> Système de télémétrie analogique et LoRa avec tracker automatique pour pouvoir capter les paramètres de vol (accélération, position, vitesse, pression,…) et les flux vidéos. Celle ci n’est pas embarqué sur la fusée, elle est à l’extérieur de l’ordinateur (c’est sa propre structure).

Cela a pour mission de fonctionner avec des fusées voulant effectuer un Space shot (100km) et assurer le fonctionnement de tout les systèmes durant la durée complète de la mission (de la mise en rampe jusqu’à la récupération). Le flux vidéo fonctionnant pendant une plage « courte » du vol (entre 0 et 10 km grâce à un télémesure analogique) puis bascule sur un flux SSDV (Slow Scan Digital Video)sur le reste du vol (grâce aux LoRa).

2. Spécifications

2.1 Station sol

2.2 Station télémesures

2.3 Bilan de liaison RF

2.3.1. Objectif de l'Étude

L'objectif de ce document est de valider mathématiquement la capacité de la Station de Télémesures au sol à recevoir un flux de données (LoRa / SSDV) provenant d'une fusée expérimentale atteignant un apogée de 100 kilomètres (Space Shot).

Le calcul du bilan de liaison permet de déterminer la Marge de Liaison (Link Margin). En ingénierie aérospatiale, une marge supérieure à 10 dB est requise pour garantir une réception sans perte de paquets, malgré les aléas atmosphériques et la rotation de la fusée.

2.3.2. Paramètres et Hypothèses du Système

L'étude est réalisée sur la bande de fréquence ISM européenne standard, avec des paramètres d'émission typiques pour l'aérospatial étudiant.

• Fréquence de transmission (f) : 868 MHz
• Distance maximale (d) : 100 km
• Modulation : LoRa (Spreading Factor: SF9, Bandwidth: 250kHz)
• Sensibilité du récepteur (LoRa SF9) : -124 dBm
• Vitesse maximale de la fusée : Mach 3 (1020 m/s)

2.3.3. Calcul de l'Affaiblissement en Espace Libre (FSPL)

L'affaiblissement en espace libre (Free Space Path Loss) représente la perte de puissance du signal électromagnétique au fur et à mesure qu'il se propage dans l'espace.

La formule de Friis s'exprime ainsi :

(Avec d en kilomètres et f vuen MHz)

Application numérique pour l'apogée :

À 100 km, le signal subit donc une atténuation naturelle de -131.2 dB.

2.3.4. Tableau du Bilan de Liaison (Link Budget)

Le bilan de liaison additionne la puissance d'émission, les gains des antennes et les amplificateurs, et soustrait l'ensemble des pertes du système.

2.3.5. Analyse de la Marge de Sécurité

La Marge de Liaison se calcule en soustrayant la sensibilité matérielle du récepteur à la puissance réellement reçue par l'antenne sol.

Conclusion sur la portée : Une marge de sécurité de +44.8 dB est exceptionnelle. Le seuil de viabilité en aérospatial étant de +10 dB, ce résultat démontre qu'avec l'architecture RF choisie (Antenne Yagi + LNA + LoRa), la Station Mercury captera sans aucune difficulté le signal à 100 km d'altitude. La liaison survivra même si la fusée effectue des rotations violentes (pertes de polarisation extrêmes).

2.3.6. Validation de l'Exigence Doppler (SOL-SW-01)

L'exigence SOL-SW-01 stipule une bande passante LoRa BW 250kHz pour absorber l'effet Doppler généré par la vitesse balistique (Mach 3).

Calcul du décalage de fréquence Doppler (\Delta f) :

• f_0 = 868 MHz (868 * 10^6 Hz)
• v = 1020 m/s (Mach 3)
• c = 3 * 10^8 m/s (Vitesse de la lumière)

Conclusion Doppler : À Mach 3, la fréquence de la fusée se décalera d'environ 3 kHz. Une bande passante classique (ex: 62.5 kHz) risquerait de désynchroniser le récepteur. En utilisant une bande passante élargie (BW 250 kHz) couplée au balayage multi-SF des puces LoRa, l'effet Doppler de la fusée est parfaitement absorbé sans aucun risque de perte de verrouillage matériel (Lock Loss).

3. Hardware design

3.1 Diagramme de blocs

3.2 Bilan de puissance station sol

Sous-système : Station Sol (Mercury Ground Station)

Révision : 1.0

Objectif : Dimensionnement de l'alimentation embarquée pour répondre à une exigence d'autonomie cible de 3 heures en conditions opérationnelles nominales.

3.2.1. Contexte et Hypothèses

Le présent document détaille l'estimation de la consommation électrique de la Station Sol du projet Mercury. L'objectif est de dimensionner la batterie interne afin de garantir une autonomie de 3 heures (couvrant la phase de préparation, le tir "Space Shot", et la récupération), tout en respectant la contrainte mécanique stricte de portabilité (poids total 3 kg, réf: GS-MECA-02).

Hypothèses de calcul :

Utilisation continue de l'ensemble des sous-systèmes (réseau, écrans, traitement de données).

Luminosité de l'écran principal réglée à son maximum pour répondre à l'exigence de lisibilité en plein soleil (>800 nits, réf: GS-ENV-01).

Prise en compte d'une marge de sécurité pour contrer les pertes de conversion et les chutes de tension liées aux températures extrêmes (jusqu'à -10°C, réf: GS-ENV-02).

3.2.2. Bilan de Puissance

Le tableau ci-dessous répertorie la consommation électrique estimée en fonctionnement nominal pour chaque bloc fonctionnel de la Station Sol :

3.2.3. Calcul des Besoins Énergétiques

Sur la base de la consommation totale estimée, nous calculons l'énergie totale requise pour la durée de la mission.

• Énergie de base (Nominale) : 32W
• Application du coefficient de sécurité : 20%

Pour éviter une décharge profonde (nuisible aux cellules Lithium), compenser le vieillissement de la batterie et garantir le fonctionnement par temps froid (-10°C), une marge de sécurité de 20% est appliquée.

3.2.4. Dimensionnement de la Batterie et Poids Estimé

Pour atteindre la capacité cible de 115.2 Wh, nous envisagions cette architectures d'alimentation principales pour la Station Sol :

L'utilisation d'un pack batterie Lithium-Ion (Li-Ion) en configuration 3S (Nominal: 11.1V, Max: 12.6V) est standard pour ce type d'équipement.

• Capacité requise :

• Poids estimé de la batterie :

3.2.5. Conclusion

Une capacité énergétique embarquée de 115 à 120 Wh est requise pour assurer les 3 heures d'autonomie avec l'écran haute luminosité au maximum.

Une batterie Li-Ion standard de 12V / 10.4Ah répondra parfaitement à ce besoin. Son poids contenu (environ 500g) permet de rester en parfaite conformité avec la spécification matérielle GS-MECA-02 (Poids total de la station \le 3 kg), laissant environ 2.5 kg pour le châssis, le RPi CM5, les écrans et l'électronique périphérique.

Pour gagner de l’espace, nous pouvons mettre deux batteries de 12V / 5.2 Ah en parallèle.

3.3 Bilan de puissance station télémesures

Sous-système : Station de Télémesures Extérieure (Antenna Tracker) Révision : 1.0 Objectif : Dimensionnement de l'alimentation embarquée pour garantir une autonomie de 3 heures en condition de suivi intensif (tracking de fusée jusqu'à Mach 3).

3.3.1. Contexte et Hypothèses

Ce document évalue la consommation électrique de l'unité de télémesure extérieure. Contrairement à la station sol, ce système intègre des actionneurs mécaniques (moteurs pas-à-pas) fonctionnant en continu pour le suivi de la cible, ainsi qu'un ordinateur Edge (Raspberry Pi 5) exécutant une pile logicielle lourde (ROS 2, calculs cinématiques TF2, décodage LoRa multi-SF).

Hypothèses de calcul :

• Autonomie cible : 3 heures de fonctionnement ininterrompu.
• Moteurs pas-à-pas alimentés en continu (maintien du couple de maintien "Holding Torque" et mouvements dynamiques rapides pour compenser l'effet Doppler et suivre la trajectoire balistique).
• Respect de l'exigence SOL-ELEC-03 : Séparation physique des lignes d'alimentation via des UBEC/Régulateurs isolés pour le RPi et les moteurs, afin d'éviter les chutes de tension (brownouts) lors des pics d'appels de courant des moteurs.

3.3.2. Bilan de Puissance

Le tableau ci-dessous détaille la consommation électrique moyenne estimée en phase de vol actif (suivi dynamique continu) :

3.3.3. Calcul des Besoins Énergétiques

Sur la base de cette consommation continue estimée à ~32.5 W :

1. Énergie de base (Nominale) :

• 32.5W

1. Application du coefficient de sécurité (20%) : Les moteurs peuvent générer des pics de consommation imprévisibles (rafales de vent sur l'antenne Yagi-Uda obligeant le système à forcer pour maintenir la position). De plus, l'équipement doit fonctionner en extérieur (potentiellement jusqu'à -10 degrees Celsius ce qui réduit l'efficacité des batteries.

3.3.4. Dimensionnement de la Batterie

Pour la station de télémesures, le choix de la tension (Voltage) est critique. Les moteurs pas-à-pas nécessitent une tension d'alimentation élevée pour conserver leur couple à haute vitesse (ce qui est crucial pour suivre une fusée à Mach 3). Une alimentation 5V ou même 12V classique peut s'avérer insuffisante pour des mouvements balistiques brusques.

Architecture 24V

L'utilisation d'une batterie Lithium-Polymère (LiPo) 6S (Nominal: 22.2V) ou Li-Ion 6S offre une dynamique optimale pour les drivers TMC2209 et les moteurs pas-à-pas.

• Capacité requise :

• Recommandation Composant : Batterie LiPo/Li-Ion 6S de 5500 mAh à 6000 mAh.
• Avantage : Mouvements très fluides et couple élevé à haute vitesse. Les UBEC s'occuperont d'abaisser le 24V en 5V propre pour le Raspberry Pi 5.

3.3.5. Conclusion

Pour garantir le suivi d'un vol de la rampe à la récupération (3 heures), la Station de Télémesures nécessite une batterie d'une capacité d'environ 120 Wh. Afin d'optimiser les performances mécaniques du Pan-Tilt et de tirer pleinement parti du microstepping des drivers TMC2209 (Exigence SOL-ELEC-01), il est recommandé d'opter pour une architecture de batterie en 24V (6S) d'une capacité de 5500 mAh minimum. Cela couvrira la consommation lourde du Raspberry Pi 5 tout en garantissant un suivi fluide et réactif de l'antenne.

4. Architecture logiciel

4.1 Station sol

4.1.1. Choix Technologiques

Pour garantir une fluidité d'affichage (latence < 100ms) et une intégration native avec le matériel (GPIO, I2C, UART) du Raspberry Pi CM5, la pile logicielle suivante est sélectionnée :

• Système d'Exploitation : Raspberry Pi OS (Debian 12 - Bookworm) en version 64-bit avec environnement de bureau allégé (Wayland/X11) pour maximiser les ressources CPU.
• Langage Principal : Python 3.11+ (Choisi pour sa rapidité de développement, sa gestion des mathématiques et ses bibliothèques d'interface de pointe).
• Framework Graphique (GUI) : PyQt6 (ou PySide6). Standard industriel pour les interfaces complexes, permettant de gérer les deux écrans (Principal et Secondaire) nativement.
• Visualisation de Données : PyQtGraph. Accélération matérielle pour dessiner les courbes de télémétrie à plus de 60 FPS sans surcharger le processeur (contrairement à Matplotlib).
• Middleware Réseau (Local) : Intégration de rclpy (ROS 2 Python) ou utilisation de WebSockets/TCP pour recevoir les données du Tracker d'antenne distant.

4.1.2. Architecture Multi-Processus (Threading & Multiprocessing)

Afin d'éviter que l'interface graphique ne se fige lors de la réception d'un paquet de données ou du décodage d'une image vidéo, le logiciel est divisé en 5 "Threads" (fils d'exécution) asynchrones :

• Thread 1 : Interface Graphique Principale (Main GUI Loop)
  • Rôle : Gère l'affichage (boutons, rendu des courbes, mise à jour des textes). Priorité haute pour garantir la sensation de fluidité.
• Thread 2 : Listener Réseau (Télémétrie entrante)
  • Rôle : Écoute le port Ethernet en continu. Désérialise les paquets bruts (Altitude, Accélération, Vitesse, GPS, État Batterie) et les place dans une file d'attente (Queue).
• Thread 3 : Pipeline Vidéo (Analogique & SSDV)
  • Phase 0-10 km : Capture le flux analogique numérisé via USB (/dev/video0) avec OpenCV/GStreamer.
  • Phase > 10 km : Écoute les trames radio SSDV (Slow Scan Digital Video), réassemble l'image (JPEG) et l'envoie à l'interface.
• Thread 4 : Gestion I/O Matériel (Boutons & Encodeurs)
  • Rôle : Surveille les GPIO/I2C. Lit les encodeurs (Volume/Luminosité) et détecte l'appui sur le Bouton Macro pour déclencher les commandes d'Uplink.
• Thread 5 : Cloud Sync Manager (Export Serveur)
  • Rôle : Gère la communication asynchrone avec le serveur de l'association Apollos Science Innovator (voir Section 5).

4.1.3. Agencement de l'Interface

L'interface est conçue pour éviter la surcharge cognitive (Dark Mode, polices monospace).

Fenêtre Principale (Écran Tactile 1)

Divisée en 4 zones critiques :

1. Zone Vidéo (Centre-Gauche) : Flux vidéo actif avec incrustation OSD (On-Screen Display) des données vitales.
2. Zone Graphiques (Droite) : Courbes déroulantes en temps réel (Altitude vs Temps, Vitesse Mach vs Temps).
3. Zone Attitude (Bas-Gauche) : Modèle 3D schématique ou horizon artificiel orienté via les quaternions de l'IMU.
4. Console de Commandes (Bas) : Interface "Uplink" et console de logs défilants (événements système).

Fenêtre Secondaire (Écran Statut 2)

Application indépendante affichant les constantes vitales : Jauge de Batterie de la Station (%), Tension Batterie du Tracker, Heure UTC, Temps T-Minus, et Température CPU.

4.1.4. Enregistrement Local des Données

Pour respecter l'exigence GS-DATA-01 (redondance), chaque paquet reçu est traité localement :

• Format : Sauvegarde brute en fichier .CSV et base de données légère (SQLite ou InfluxDB).
• Redondance : Un processus en tâche de fond écrit simultanément sur le SSD M.2 NVMe et sur la carte SD. Ce fonctionnement garantit la sécurité des données même en cas de perte totale de connectivité internet sur le pas de tir.

4.1.5. Synchronisation et Export vers le Serveur d’ASI

Afin de centraliser l'historique des lancements et permettre l'analyse post-vol par l'équipe, la base de données est exportée vers le serveur de l'association selon un principe de résilience (Store & Forward).

Logique de fonctionnement (Store & Forward)

1. Store : Écriture prioritaire sur le SSD M.2 local.
2. Surveillance : Le Thread 5 (Cloud Sync Manager) vérifie la disponibilité d'une connexion internet (ex: point d'accès 4G partagé).
3. Forward : Dès qu'une connexion stable est détectée, les données en attente sont expédiées. Si le réseau est indisponible, l'export s'effectuera automatiquement au retour de la mission.

Modes d'Exportation

• Mode "Live Telemetry" (Direct) : Utilisation de protocoles légers (MQTT ou REST API via requêtes POST) pour envoyer des trames de base (Altitude, Vitesse, GPS) à fréquence réduite. Permet d'alimenter un tableau de bord public sur le site web de l'association.
• Mode "Full Database Dump" (Post-Vol) : Transfert sécurisé (SFTP) d'une archive compressée (.zip) contenant la base SQLite, les logs textuels et les vidéos SSDV à la fin de la mission.

Sécurité et Authentification

• Chiffrement : Toutes les communications avec le serveur s'effectuent via TLS/SSL (HTTPS).
• Authentification : Le système embarque une Clé API cryptée ; le serveur rejette toute donnée non signée par l'association.
• Intégrité : Génération d'un hash cryptographique (SHA-256) du fichier de base de données avant l'envoi pour détecter toute corruption durant le transfert.

4.2 Station télémesures

4.2.1. Objectif et Philosophie ROS 2

L'ordinateur "Edge" (Raspberry Pi 5) embarqué sur l'unité de télémesure a pour rôle de pointer mécaniquement une antenne directionnelle vers une fusée évoluant jusqu'à Mach 3 et 100 km d'altitude. Pour garantir un haut niveau de résilience, l'architecture logicielle repose sur le framework ROS 2 (Humble ou Iron). Cette approche par micro-services (Nœuds) garantit que la défaillance d'un composant matériel (ex: perte du GPS) n'entraîne pas le crash complet du système de suivi.

4.2.2. Topologie des Nœuds (Node Graph)

Le système est divisé en quatre catégories de nœuds fonctionnant de manière asynchrone, communiquant via le protocole DDS intégré à ROS 2.

Nœuds d'Acquisition (Sensors)

• lora_receiver_node : Pilote la puce RF via bus SPI. Gère la réception multi-SF (Spreading Factors) sur une large bande passante (BW \ge 250\text{ kHz}) pour absorber le décalage de fréquence dû à l'effet Doppler (Exigence SOL-SW-01). Il publie les paquets décodés sur le topic /rocket/telemetry_raw.
• tracker_gps_node : Lit les coordonnées absolues de la station au sol sur le site de lancement.
• tracker_imu_node : Lit l'attitude de la base (assiette, inclinaison) pour compenser un positionnement sur un terrain non plat.

Nœuds de Traitement Mathématique (Processing)

• ballistic_predictor_node (Filtre EKF) : Nœud critique (Exigence SOL-SW-05). Il écoute les positions GPS reçues de la fusée. En cas de perte de signal radio (ex: passage du mur du son ou masquage par les tuyères), ce nœud prend le relais en utilisant un Filtre de Kalman Étendu (EKF) basé sur le profil aérodynamique de la fusée pour prédire sa position future et continuer à orienter l'antenne "à l'aveugle".
• kinematics_tf2_node : Utilise la bibliothèque standard de transformations spatiales de ROS 2 (TF2). Il calcule le vecteur pointant de l'antenne vers les coordonnées 3D de la fusée, et le convertit en consignes d'angles absolus.

Nœuds d'Actionnement (Control)

• motor_controller_node : Écoute les topics de consignes d'angles (Azimut/Élévation). Pilote les drivers de moteurs pas-à-pas (TMC2209) en générant des signaux matériels (STEP/DIR) ou via UART pour exploiter le microstepping, garantissant une rotation fluide sans vibrations perturbant la réception RF.
• homing_sequence_node : Activé uniquement au démarrage, il utilise les capteurs de fin de course (Endstops) pour étalonner le Pan-Tilt et définir le point Zéro (Nord vrai / Horizon géographique).

Nœuds de Sécurité et Données (Safety & Data)

• safety_watchdog_node : Surveille les "Heartbeats" (battements de cœur) de tous les autres nœuds. Si le nœud kinematics ne répond plus pendant 500ms, le Watchdog envoie une commande d'arrêt d'urgence au motor_controller_node pour figer instantanément l'antenne et éviter un enroulement destructeur des câbles (Exigence SOL-SW-07).
• rosbag_logger_node : Enregistre en continu l'intégralité du trafic ROS 2 sur la clé USB/SD locale pour permettre un "Replay" exact du vol à des fins de débogage post-mission (Exigence SOL-SW-06).

4.2.3. Arbre de Transformations Spatiales (TF2 Tree)

Pour simplifier les calculs trigonométriques complexes, le Tracker utilise l'arbre de transformation spatiale suivant maintenu par le nœud kinematics_tf2_node :

1. world (Référentiel géodésique absolu, WGS84)
2. —> tracker_base_link (Position GPS statique de la valise sur le pas de tir)
3. —> pan_link (Rotation en Azimut, 0 à 360°)
4. —> tilt_link (Rotation en Élévation, 0 à 90°)
5. —> antenna_yagi_link (Axe du lobe principal de l'antenne RF)
6. Cible : rocket_link (Coordonnées mobiles reçues par télémétrie)

Le calcul d'asservissement consiste simplement à minimiser en temps réel l'erreur angulaire entre le vecteur d'antenna_yagi_link et les coordonnées de rocket_link.

4.2.4. Communication avec la Station Sol (Ethernet DDS)

Afin de ne pas surcharger la boucle radio LoRa, la Station de Télémesure (extérieure) et la Station Sol (la mallette de l'opérateur) sont physiquement reliées par un câble Ethernet longue portée (Exigence SOL-COM-01).

• Routage DDS : ROS 2 utilisant le protocole natif DDS (Data Distribution Service) sur IP, l'ordinateur de la Station Sol s'abonne directement au topic /rocket/telemetry_clean publié par le Raspberry Pi 5 du Tracker.
• Standardisation : Les données complexes sont sérialisées via JSON ou Protobuf avant d'être expédiées sur le réseau TCP/IP, garantissant une interopérabilité totale avec l'interface graphique en Python (PyQt6) de la Station Sol.

5.Analyse de risques