RAPPORT DE STAGEReprésentation 2D/3D de trajectoires d ’objets célestes et sate!ites artificiels

Avril - Juin 2011

Yoann Dufresne 1

Stage de fin de licence informatique effectué à l’observatoire d’astronomie de LilleEncadré par Florent Deleflie, Alain Vienne et Jean-Christophe Routier

Yoann Dufresne 2

Yoann Dufresne 3

R E M E R C I E M E N T S

Je tiens tout particulièrement à remercier Marc Fouchard pour m'avoir aidé à obtenir ce stage ainsi que Alain Vienne et Florent Deleflie, mes maîtres de stage, pour leur soutien tout au long de ces 3 mois. Merci également à Jean-Christophe Routier, mon tuteur universitaire pour m'avoir suivi et dirigé vers les bonnes personnes lorsque j'avais des problèmes. Merci à Fabrice Aubert pour avoir communiqué par mail avec moi et pour m'avoir reçu afin de résoudre des problèmes liés à la 3D. Enfin, merci à Stefan Renner pour m'avoir aidé dans l’orientation de mon travail ainsi qu'à Mme Ballenghien, concierge de l'observatoire, pour son accueil quotidien chaleureux.

TABLE DES MATIÈRES

I. Positionnement du problème" 71.1 Présentation du laboratoire" 7

Historique du laboratoire" 7

Le laboratoire aujourd’hui" 8

1.2 Projet global sur les débris spatiaux" 8

1.3 Mon travail au sein du projet" 9

1.4 Solutions techniques envisagées" 9

II. Contexte et rappels en mécanique spatiale" 102.1 Lois de la gravitation" 10

2.2 Première loi de Kepler" 11

2.3 Deuxième loi de Kepler" 11

2.4 Troisième loi de Kepler" 12

2.5 Les paramètres orbitaux" 12

2.6 Des paramètres orbitaux aux coordonnées cartésiennes" 13

III. Réalisation technique du logiciel" 15111.1 Principes généraux" 15

111.2 Blocs fonctionnels" 15

Le modèle des données" 15

Le solveur$ 15

Le diagramme de classe$ 17

Les outils de visualisation" 18

Yoann Dufresne 4

Visualisation 3D$ 18

Visualisation planisphère$ 20

L'interface graphique" 22

Sélection des systèmes$ 22

Sélection des vues$ 23

111.3. Fonctionnalités supplémentaires" 23

IV. Exemples de fonctionnement" 254.1. Visualisation 3D" 25

Principe général" 25

Les "vues"" 25

Vue globale et vue de profil$ 25

Vue du plan$ 26

Vue de surface$ 27

4.2. Visualisation planisphère" 27

Principe général" 27

Les modes de tracé" 27

Le mode horaire$ 27

Le mode périodes$ 28

Le mode "en direct"$ 28

V. Retour sur la gestion du projet" 305.1. Difficultés techniques rencontrées" 30

5.2. Gestion du temps" 31

Bibliographie" 33

Annexes" 34Annexe A : Améliorations logiciel" 34

Yoann Dufresne 5

INTRODUCTION

$ C’est dans le cadre de mon stage de fin de licence informatique au sein du laboratoire d’astronomie de Lille que je suis amené à rédiger ce rapport.

$ Bien que le laboratoire ne comprenne pas d’informaticien, je me suis vu confié la tâche de créer un logiciel en Java permettant la visualisation d’orbites célestes en 3D ainsi que la vi-sualisation des projetés de ces orbites sur des planisphères.

$ Ce qui m’a avant tout attiré vers ce stage, c’est la pluridisciplinarité qu’il nécessite. Sou-haitant devenir un informaticien au service d’autres domaines, ce stage m’a beaucoup apporté.

$ À l’image de la pluridisciplinarité de ce stage, le rapport ne relatera pas uniquement la conception du logiciel. L'aspect mathématique et astronomique du stage sera omniprésent dans le rapport.

Yoann Dufresne 6

I. POSITIONNEMENT DU PROBLÈME

1.1 Présentation du laboratoire

$ H I S T O R I Q U E D U L A B O R A T O I R E

$ C'est au début du siècle dernier que commence la "pré-his-toire" de l'observatoire d'astronomie de Lille. Robert Jonckheere, un riche industriel de la région lilloise, se décide à faire fabriquer une lu-nette astronomique de près de 7m de long afin d'assouvir sa passion pour l'astronomie. Il s'intéresse tout particulièrement aux étoiles doubles (deux étoiles liées gravitationnellement) et référencera envi-ron 3 000 de ces astres.

$ Suite à la première guerre mondiale, Robert Jonckheere se retrouve dans de grandes difficultés financières et se voit obligé de vendre une grande part de sa bibliothèque, de nombreux instru-ments scientifiques ainsi que sa lunette à l'université de Lille. L'université, ne souhaitant pas conserver l'observatoire privé de Hem, décide de construire un nouvel observatoire au coeur de Lille et d'y transporter tout le matériel récemment acquis.

Bien qu'en ayant les compétences, Robert Jonckheere ne deviendra jamais directeur du labora-toire d'astronomie de l'université faute de diplômes. Depuis lors, plusieurs directeurs se sont succédés, tels que Vladimir Kourganoff, qui publia en Europe de l'Ouest des traductions de travaux de recherche de ses homologues d'URSS, ou encore Pierre Bacchus qui en plus de son poste de directeur, deviendra un des pères fondateurs des cours d'informatiques au sein de l'université de Lille.

Yoann Dufresne 7

Vladimir Kourganoff Pierre Bacchus

$ L E L A B O R A T O I R E A U J O U R D ’ H U I

$ Depuis 2004, les chercheurs du laboratoire d'astronomie de Lille ne sont plus les seuls à occuper l'observatoire. En effet, en Juillet 2004, l'«association Jonckheere, les amis de l'obser-vatoire» a vu le jour dans le but de valoriser et promouvoir le patrimoine scientifique et astro-nomique de l'observatoire de Lille. Ses membres aident à l'en-tretien de la lunette et des locaux, fournissent un travail d'ar-chivage des nombreux livres et revues accumulés depuis l'épo-que de M. Jonckheere et oeuvrent à moderniser la lunette. Ils participent également à la réalisation de quelques expériences comme la manipulation «météores» qui à pour but de détecter le nombre d'entrées de météores dans l'atmosphère de la Terre.

$ Il y a désormais quatre permanents au sein de l'observatoire qui font partie de l'Institut de Mécanique Céleste et de Calcul d’Éphémérides (IMCCE) : Alain Vienne, professeur des universités et directeur de l'observatoire depuis 2007, Marc Fouchard et Stéfan Renner maîtres de conférences et Florent Deleflie, astronome. La thématique de recherche s'articule autour de trois axes qui sont : "La dynamique des satellites principaux de Jupiter et Saturne", "L'étude du nuage d'Oort et des comètes à longue période" et "L'étude des débris spatiaux". C'est dans le cadre de cette dernière thématique que mon travail s’inscrit.

1.2 Projet global sur les débris spatiaux$ Il existe actuellement au sein de l'IMCCE un projet nommé PODET (Pôle sur la Dy-namique de l’Environnement Terrestre). Le projet PODET vise à rendre accessible les données concernant certains objets en orbite autour de la Terre au travers d'une base de données conte-nant plusieurs centaines d'objets ainsi que des interfaces utilisateur permettant facilement d'exploiter ces données.

$ Le projet PODET est doté de trois parties distinctes, PODET-Astéroïdes, PODET-Comètes et PODET-Débris. Le travail de Florent Deleflie intervient au sein de PODET-Dé-bris. Il conçoit un nouveau modèle d'évaluation des trajectoires afin d'en tirer des coordonnées orbitales valables à court et long terme. Le nouveau modèle devrait être plus précis et permet-tre à court terme une meilleure détection des collisions potentielles, ainsi que sur le long terme d'estimer plus précisément les durées de vie des satellites et de prévoir une période pour leur rentrée dans l'atmosphère.

Yoann Dufresne 8

$ Le but à terme est de disposer d’une base de données comprenant plusieurs dizaines à centaines de milliers d’objets alimentant des services (voir webservices) et applications scienti-fiques en dynamique spatiale. La visualisation des trajectoires est l’un de ces services.

1.3 Mon travail au sein du projet$ Mon travail ne vient pas s'intégrer dans la partie calcul des éléments orbitaux mais dans la partie utilisation et interprétation de ces données au travers d'un logiciel de visualisation.

$ L'objectif initial de mon stage est de créer un outil de visualisation des orbites en 3D à partir de coordonnées orbitales. Dans un second temps, il m’est demandé de créer une mé-thode de visualisation par projeté sur planisphère. L’objectif est de proposer un logiciel sembla-ble au logiciel IXION déjà existant tout en apportant des nouveautés telles que la possibilité d’afficher les orbites en 3D ou le fait de pouvoir voir plusieurs satellites simultanément.

$ Tout au long de mon stage, le sujet s'est petit à petit densifié et l'on compte désormais deux ajouts majeurs qui sont le calcul et le tracé des zones depuis lesquelles les objets en orbite sont visibles à la surface du corps central, ainsi que la connexion du logiciel à la base de donnée ODIN du projet PODET afin de permettre le tracé de tous les corps enregistrés en son sein.

1.4 Solutions techniques envisagées$ Au début de mon projet, j’ai décidé de diviser mon travail en deux parties.

$ Une partie théorique qui doit contenir les modèles de données. Ces modèles doivent fournir un moyen simple de représenter les systèmes astraux et doivent permettre de calculer la position de chaque astre à n'importe quel moment. La taille de la zone depuis laquelle le satel-lite peut être visible sur Terre doit également pouvoir être calculée à tout moment.

$ La seconde partie de mon travail est la réalisation des représentations graphiques asso-ciées au modèle dynamique. En travaillant sur ce projet, je me suis rapidement rendu compte que cette seconde partie se découpait en trois sous-parties : la vue 3D, le projeté sur plani-sphère et l’interface graphique. L'aspect interface graphique doit être entièrement séparée de la conception des représentations graphiques du modèle.

Yoann Dufresne 9

II. CONTEXTE ET RAPPELS ENMÉCANIQUE SPATIALE

$ Pour pouvoir commencer à travailler, il faut comprendre comment les lois de la nature régissent la rotation des corps célestes. Pour cela, il est nécessaire de faire un peu de mécanique céleste. Ce chapitre est là pour en rappeler quelques bases.

2.1 Lois de la gravitation

$ Le principe fondamental de la dynamique appliqué sur un corps et la loi de la gravita-tion de Newton nous donnent les deux équations suivantes :

En combinant ces deux équations, on obtient ce système de 3 équations du second ordre à 3 inconnues :

On peut décomposer ces équations afin d'obtenir un système de 6 équations du premier ordre à 6 inconnues :

La résolution de ce système de 6 équations fait intervenir des "intégrales premières" (i.e. des quantités constantes du système) qui sont reliées aux trois lois de Kepler. Les lois de Kepler vont nous permettre de définir 6 constantes représentant les orbites elliptiques en 3 dimen-sions.

Yoann Dufresne 10

!"#$%#&'(

!"#$%$&$'$!"#$($$

!! ""!#

!"#$%#&'(

!"#$%$&$'$(()*+$)*,-$.!"/$/0,-$!"#$(1*(+2,--

!! ""#!#"

$"

!%!#"

!"#$%#&'(

!"#$%&'%()*+%",#$%-.!!/%&'%()*+%0&#$12#$13#$4#!5%6%$''

!!"

!#!!"

$ "

#"!$ %!$&!%"&!

!"#$%#&'(

!"#$%&'%()*+%",#$%-.!!/%&'%()*+%01#$2&#$23#$4#!5%6%$''

!!"

!#!!"

$ "

#%!$ "!$&!%"&!

!"#$%#&'(

!"#$%&'%()*+%",#$%-.!!/%&'%()*+%01#$23#$2&#$4#!5%6%$''

!!"

!#!!"

$ "

#%!$ &!$"!%"&!

!"#$%#&'(

!"#$%#&'()#!"#*%#+#"&*#$#

! "

! #! ""

!"#$%#&'(

!"#$%#&'()#!"#*%#+#"&*#$#

! "

! #! ""

!"#$%#&'(

!"#"$%#&'#$()*#!"#%'#+#,!!-#&'#$()*#.&/012/013/04/!560''

! !"

! #"#

$ "

$"!% %!%&!&"'!

!"#$%#&'(

!"#"$%#&'#$()*#!"#%'#+#,!!-#&'#$()*#./012&01230140!561''

! !"

! #"#

$ "

$%!% "!%&!&"'!

!"#$%#&'(

!"#"$%#&'#$()*#!"#%'#+#,!!-#.'#$()*#/.0123012&0140!561''

! !"

! #"#

$ %

$%!% &!%"!&"'!

!"#$%#&'(

!"#$%#&'()#!"#*%#+#"&*#$

! "

! #!""

u : vecteur unitaire

!"#$%#&'(

!"#"$"%&'(")"&'*+

!!" "#!##

"$

2.2 Première loi de Kepler$ La première loi de Kepler a été énoncé de cette manière : "Les planètes du système so-laire décrivent des trajectoires elliptiques dont le Soleil occupe un des deux foyers". Pour dé-crire la forme d'une ellipse, deux paramètres suffisent ; le demi-grand axe (a) ainsi que l'excen-tricité (e) définie par le rapport entre la distance séparant le centre de l'ellipse à un foyer et le demi-grand axe.

Ces deux paramètres suffisent pour décrire la forme de l'ellipse et donnent accès à la distance entre l'objet en orbite et le foyer par la relation :

2.3 Deuxième loi de Kepler

$ La seconde loi de Kepler dit que le mouvement en plan et que l'aire balayée par le vec-teur position en un temps t reste constant quel que soit le point de départ sur l'ellipse. La pre-mière partie de la loi permet de définir deux angles afin d'obtenir l'orientation du plan de l'or-bite dans l'espace. Le premier angle est l'inclinaison (i) de l'orbite par rapport au plan xOy. Le fait d'incliner l'orbite détermine une droite d'intersection entre le plan de l'orbite et l'horizon-tale. C'est l'angle fait entre cette droite et l'axe Ox qui permet de définir le second angle. Cet angle est appelé la longitude du noeud ascendant (☊).

Yoann Dufresne 11

!"#$%#&'(

!"#"$%"&'()*+,-"./)!"$'0)"1.2"/-

!!" "!##"$

!%# #$% $

!"#$%#&'(

!"#$#%#&#%'()

!!""#"!$

2.4 Troisième loi de Kepler$ La troisième loi de Kepler est appelée loi des périodes car elle permet de déterminer la période orbitale d'un astre en fonction d'autres constantes du système tel que le demi-grand axe.

La connaissance de la période permet de déterminer une nouvelle variable qui est linéaire avec le temps que l'on appellera l'anomalie moyenne (M). Physiquement cette variable représente un angle sans réel sens et c'est seulement lorsqu'on la relie à l'anomalie excentrique (E) puis l'ano-malie vraie (v) que le paramètre prend son sens. En effet, E et v ne sont pas linéaires avec le temps et ne sont donc pas calculables directement.

2.5 Les paramètres orbitaux$ Pour compléter notre représentation des orbites elliptique, il est nécessaire de détermi-ner un dernier paramètre gravitationnel. Ce paramètre est un angle décrit par l'intersection des plans xOy et du plan de l'orbite avec le vecteur allant de O au périastre (point de l'orbite le plus

Yoann Dufresne 12

!"#$%#&'(

!"#$%"&$'$(

!!""!#

!"#$%#&'(

!"#"$%"&'"()*+",

!!!"

#

!"#$%#&'(

!"#$%&'()&#

!!""# !"# "

!"#$%#&'(

!"#$%&$'&()$*+$,$-.)!//01(2$'&()$/03(22$!"#$%4$'&()$*+$

!"# !!

$

"#$ %%"%&"!"# !

#

$

"

!"#$%#&'(

!"#"!$%"&"'"()"*")$%+

!!!!""##$#

!%

proche de O). Cet angle appelé argument du périastre (périhélie pour le soleil) et noté ω per-met de donner la position d'un point particulier de l'ellipse.

$ Les paramètres orbitaux a, e, i, ☊, ω étant constants et M permettant de décrire un an-gle allant de 0 à 2π, il nous est désormais possible de représenter les orbites sous la forme sui-vante :

Ce schéma d’orbite représente une orbite Képlerienne. Dans la réalité, a, e, i, ☊, ω varient avec le temps mais sur des courtes périodes comme celles traitée dans le logiciel, l’approximation conviens.

2.6 Des paramètres orbitaux aux coordonnées cartésiennes$ Les coordonnées cartésiennes étant faciles à trouver dans le plan de l'orbite, on obtient ces équations :

Yoann Dufresne 13

!"#$%#&'(

!"#$%&&'()(*($+!(,-(.(&/()(*(!01(,-(.(2()(3-(

!!" !"# #

$!" #$% #

%!&

Pour trouver les coordonnées dans le repère 3D centré sur le point autour duquel orbite le corps, il ne reste plus qu'à appliquer une rotation suivant l'angle ☊ puis suivant l'angle ω et en-fin l'angle i. On obtient alors les 3 coordonnées selon les 6 paramètres gravitationnels (v per-mettant d’obtenir M) :

Yoann Dufresne 14

!"#$%&'()

!"#"$%&'()*+,-"./)0"$'1)"2.3"/-"456)3"357"5"357&81/,

!!" "!##"$

!%# #$% $&%&' % %&' "&%$$

!"#$%#&'(

!"#"$%&'()*+,-"./)0"$'1)"2.3"/-"456)3"&2.3"7"2.3"&81/,"("359"7

2.3"5"359"&81/,,

!!" "!##"$

!%# #$% $&"#$%% #$%"&%$$#%&'% #$% ' %&' "&%$$$

!"#$%#&'(

!"#"$%&'()*+,-"./)0"$'1)"2.3"/-"456)3"&357"8"2.3"&91/,"("2.3"8

2.3"5"357&91/,,

!!" "!##"$

!%# #$% $&"%&'% #$%"&%$$##$%% #$% ' %&' "&%$$$

(1)

(2)

(3)

III. RÉALISATION TECHNIQUE DU LOGICIEL

111.1 Principes généraux

$ Pour concevoir ce logiciel, je me suis basé sur le patron de conception Modèle-Vue-Contrôleur. Ici, le modèle est l’ensemble des classes représentant les systèmes astraux, la vue, la modélisation 3D et le projeté, et le contrôleur les divers menus de l'interface graphique.

$ Mon logiciel se décompose en conséquence de 4 «blocs fonctionnels» afin de bien res-pecter cette structure.

111.2 Blocs fonctionnels

$ L E M O D È L E D E S D O N N É E S

$ Il y a deux parties bien distinctes dans mon modèle de donnée. Je dois tout d’abord créer un solveur des équation de Kepler permettant d’obtenir les coordonnées en fonction des paramètres orbitaux. Je dois ensuite concevoir une architecture logiciel permettant d’ouvrir mon code à l’extension.

$ $ L E S O L V E U R

$ L'un des aspects principaux de ce stage est de transformer la théorie physique en un modèle informatique satisfaisant. Je dois pour cela créer un solveur permettant de passer des six coordonnées orbitales (cf II) aux coordonnées cartésiennes de points de la trajectoire. Les équations sont celles annotées (1), (2) et (3) et ont été données à la fin du II

Yoann Dufresne 15

$ Pour rappel, dans ces formules, v représente l'anomalie vraie. Cependant, le résultat re-cherché doit lui être fonction de l'anomalie moyenne M car elle est la seule à s’exprimer en fonction du temps.

Pour obtenir v en fonction de M, il faut procéder en deux étapes. D'abord obtenir l'anomalie excentrique E puis de l'anomalie excentrique obtenir l'anomalie vraie grâce à ces deux formu-les :

Pour résoudre l'équation de Kepler (La seconde équation), j'utilise le théorème d'inversion de Laplace pour obtenir :

Je peux désormais exprimer l’anomalie vraie en fonction de l’anomalie excentrique. Il ne reste plus qu’à faire varier M entre 0 et 2π pour obtenir tous les points de l’orbite.

$ Afin de compléter les coordonnées, il me faut également la coordonnée temporelle pour chaque point de l'espace. Sachant qu'il faut respecter la loi des aires (cf II), il est judicieux de ne pas prendre un point tous les n fractions de radiants mais plutôt de partir du temps et de chercher des points à intervalles temporels réguliers. On peut facilement trouver M en fonc-tion du temps grâce à la formule suivante :

Yoann Dufresne 16

Rapport entre l’anomalie vraie v, l’anomalie excentrique E et l’anomalie moyenne M

!"#$%#&'(

!"#$%&$'&()$*+$,$-.)!//01(2$'&()$/03(22$!"#$%4$'&()$*+$

!"# !!

$

"#$ %%"%&"!"# !

#

$

"

!"#$%#&'(

!"#"$%&'()"*+',"-"'./0123"$"%")"*+',"4"'.4"123"&4"$0%/"*+',"-

'./"123"&/"$0

!!""##$!

"##%$%&""

!

'#'$%& #'" %"

#

"##$%& ##" %

!"#$%#&'(

!"!#$%&'&()*'++,-&./0*&+123-&-&

!!!!"" #

#

$"

t : temps (en secondes)M0 : M à t=0µ : paramètre gravitationnel standard du système

!"#$%#&'(

!"#$%&'()&#

!!""# !"# "

$ Le problème avec la fonction qui permet d’avoir E en fonction de M est que pour le dé-veloppement au 3ème ordre ne suffit plus au delà d’une excentricité de 0.6. Or, je souhaite pou-voir tracer des orbites jusqu’à une excentricité de 1. Sur les conseils de Florent Deleflie, j’utilise donc la méthode de Nijenhuis qui consiste à prendre l’équation de Kepler, y soustraire E et chercher ensuite les 0 :

Avec cette seconde méthode, le solveur permet d’obtenir toutes les orbites elliptiques désirées.

$ $ L E D I A G R A M M E D E C L A S S E

$ Afin de rendre mon code le plus évolutif possible, j'ai créé un arbre de classes pour re-présenter les systèmes astraux. Dans l'optique d'avoir plus tard des systèmes contenant d'autres systèmes en mouvement (par exemple une planète avec satellites en rotation autour d’une étoile), j'ai entièrement désolidarisé la notion d'orbites et celle d'objet spatial.

$ Dans cet arbre de classes, j’essaye de respecter les «notions d’objets» que l’on retrouve dans la réalité. Un système astral, dans la réalité, peut être composé de divers objets (étoiles, planètes, comètes, satellites, etc). J’ai donc implémenté quelques classes abstraites et interfaces dans le but que tous ces objets puissent facilement être ajoutés dans le modèle actuel. De même j’ai créé une interface orbite permettant l’adaptation des orbites afin de pouvoir utiliser de meilleurs solveurs voire des solveurs permettant d’aller au delà d’une excentricité de 1 (une excentricité supérieure à 1 provoque des trajectoires hyperboliques et la méthode de calcul n’est plus la même).

Yoann Dufresne 17

Arbre de classe très simplifié

!"#$%#&'(

!"#$%"&'()*+,)&$)'#

! !" "#!#$$ !"# # "$"

$ L E S O U T I L S D E V I S U A L I S A T I O N

$ Comme précisé précédemment, les outils de visualisation sont au nombre de deux. Un premier en 3D permettant la visualisation directe des trajectoires et un second permettant de voir le tracé du projeté des trajectoires à la surface du corps central au système ainsi que les zo-nes depuis lesquelles le satellite est visible sur ce corps.

$ $ V I S U A L I S A T I O N 3 D

$ Pour la création de la scène 3D j'utilise la librairie Java 3D pour deux raisons. Première-ment c'est un outil recommandé par le CNES pour les études de mécanique spatial. Seconde-ment, car c'est une librairie qui a déjà été beaucoup utilisée et qui est assez bien documentée.

$ Pour la conception de la visualisation, j'ai décidé d'utiliser l'univers de base pré-confi-guré par la librairie et nommé SimpleUniverse. L'avantage évident est qu'il n’est pas nécessaire de tout configurer manuellement. J'ai considéré que cela me simplifierait grandement la tâche pour concevoir ma première application 3D.

$ Pour coller parfaitement au modèle, mon arbre 3D doit être construit de la même manière que l'arbre des classes de ce modèle. Ainsi, une orbite dans le modèle est représentée par une orbite graphique en 3D, un objet sphéri-que par un objet sphérique graphique, etc.

$ La difficulté dans la conception de la scène 3D réside en particulier dans la représen-tation des corps en mouvement. Elle peut être décomposée en deux parties.$ La première partie de cette représen-tation est l'affichage de la trajectoire sur laquelle l'objet 3D va se déplacer. Cette partie est très facile à représenter car il a suffit de créer autant

Yoann Dufresne 18

Arbre de la scène graphique

Racine de la scène

Système astral graphique

Objets astraux graphique

Mouvement orbital

Objet orbital

Orbite graphique

Dessin de l’orbite

Dessin de l’objet en orbite

de segments que nécessaire pour joindre tous les points connus de la courbe de révolution. Il est important de trouver un bon compris entre la vitesse de traçage de l'orbite et la qualité de son rendu. Pour obtenir un traçage rapide et clair à la fois, j'ai fixé la décomposition à 200 seg-ments.$ La seconde partie consiste à mettre un corps en mouvement le long de l'orbite précé-demment tracée. En théorie, il suffit de créer une série de points, une série de coordonnées temporelles et une fonction du temps pour déterminer la façon dont il doit s'écouler. Bien que toute cette théorie soit respectée, le parcours ne fonctionne pas encore parfaitement.

$ Afin de représenter une version simplifiée de la rotation des corps sur eux même, cha-que objet se voit doté de la possibilité de définir une inclinaison et une période de rotation sur elle même. Cette transformation vient s'ajouter dans l'arbre au niveau du "transform group" déjà existant qui permet déjà mouvement orbital.

$ Le dernier développement effectué pour ce "bloc fonctionnel" est une classe Camera permettant des transformations basiques de caméra. Cette classe permet de se déplacer dans la scène, de regarder ou l'on veut et d'augmenter ou diminuer les distances de visibilité quel que soit l'état précédent de la caméra. Elle n'est pas utilisée directement dans le logiciel et fournit des fonctions basiques qui sont utilisées pour créer différentes prises de vues (cf 4.1).

Yoann Dufresne 19

Vue 3D de côté de la Terre et quatre satellites

$ $ V I S U A L I S A T I O N P L A N I S P H È R E

$ Lorsque l'on repère un point à la surface d'une planète ou sur un planisphère, on utilise les coordonnées de latitude et de longitude. Il peut en être fait de même avec le projeté ortho-gonal d'un objet en orbite autour d'un corps central. En repérant ainsi tous les points d'une or-bite au cours du temps, on obtient le tracé du projeté de toute l'orbite sur la surface d'une pla-nète. On peut ainsi en déduire le projeté sur le planisphère.

$ Dans le logiciel, la méthode mise en place pour tra-cer le résultat sur planisphère est semblable. Bien entendu le planisphère n'est pas recalculé à chaque fois, seules les posi-tions des points d'orbites sont recherchées. L'origine des lon-gitudes est déterminée par la position de l'axe Ox en 3D. Pour simplifier les calculs, j'ai décidé de ne pas prendre la latitude comme seconde coordonnée mais d'utiliser une notion analo-

gue déterminée dans un repère sphérique, l'angle θ. Cela a pour avantage d'éviter d'avoir des angles entre -90° et 90°

mais de les avoir plutôt entre 0° et 180°. Pour trouver ces deux angles, j'utilise ces formules en partant des coordonnées cartésiennes spatiales :

$ Une fois ces coordonnées obtenues, il faut en déduire les coordonnées en (x, y) afin de représenter les points aux bons endroits du planisphère. Au lieu de calculer directement les coordonnées en fonction du nombre de pixels de la fenêtre et de devoir les recalculer à chaque redimension, je les enregistre comme proportion de la largeur et proportion de la hauteur de la fenêtre. Les coordonnées en nombre de pixel ne sont jamais enregistrées et sont directement calculées à chaque appel de la méthode repaint() de la fenêtre.

Yoann Dufresne 20

Coordonnées sphériques

Premier tracé pour le satellite QZS

$ Bien que l'on obtienne déjà un tracé, il ne correspond en rien à la réalité car il ne prend pas en compte la rotation du corps central. Il faut ajouter une notion de temps et corriger la longitude en fonction de la vitesse de rotation du corps central. Pour effectuer cette correction, il suffit de soustraire la longitude du point d'origine du corps central à la longitude du corps en orbite. Par exemple, sachant que la Terre fait une rotation en 23h56min04s soit 86164s, à la se-conde 21541, il faudra faire une correction de 90° sur la longitude.

$ La dernière partie de la création du mode plani-sphère a été la réalisation de "cercles de visibilité". Les cercles de visibilité représentent les zones du corps cen-tral depuis lesquelles l'objet est visible à un endroit don-né. Afin de simplifier au maximum les calculs, les cercles

tracés ne sont qu'une approximation des cercles réels. Ils sont ici approxi-més par un cercle tangent au corps central comme sur le schéma ci des-sus. En théorie, plus on s’éloigne de l’équateur et plus les cercles devraient être déformés. Aux pôles, ils devraient même recouvrir toute la largeur. De nouveau par soucis de simplification, la déformation n’est pas appliquée.

Yoann Dufresne 21

Tracé de QZS après correction de la rotation de la Terre

Tracé d’orbite et de cercles de visibilité d’un débris d’Ariane 5

Approximation des cercles de visibilité

$ Désormais, il ne reste plus qu'un seul problème, la lenteur extrême de l'affichage. Dès qu'il y a plusieurs satellites et qu'il faut tracer sur environ 24h, le logiciel peine à tracer. Afin d'optimiser cette étape, j'ai décidé de faire un calcul supplémentaire pour lui imposer de n'affi-cher que les points qui ont une distance d'au moins trois pixels avec le dernier point tracé. Cela permet de diminuer le temps d'exécution de la fonction d'un facteur 10 environ.

$ Remarque : Il reste encore un cas à traiter, le cas des systèmes sans corps centraux. Dans le cas où certains corps d'un système ont une taille semblable, il se peut que le point autour duquel les corps gravitent ne soit pas occupé par un corps physique. Dans la réalité ce cas se présente pour certains systèmes d'étoile double. Il existe même ce genre de cas au sein du système solaire avec par exemple Pluton et sa lune Charon. Pour de tels astres, j'ai opté pour la possibilité de tout de même tracer les projetés sur un corps central imaginaire avec un rayon nul. Les cercles de visibilité, n'ayant plus aucun sens dans ces cas, n’apparaissent pas.

$ L ' I N T E R F A C E G R A P H I Q U E

$ Comme de nombreux logiciels, j’ai décidé de doter le mien d’une barre de menus. Ces menus sont les menus classiques et basiques et permettent les actions standards. Ils permet-tent d'enregistrer, de quitter ou encore de voir les crédits. À plus long terme et si quelqu'un re-prend ma suite sur ce logiciel, il serait bon d'y incorporer une aide. Seule originalité de ce me-nu, il permet de changer le type de visualisation que l'on souhaite avoir. Cette option d'affi-chage permet de changer la structure de l'interface graphique en interchangeant les "panels" des visualisateurs.$

$ Pour ne pas surcharger le menu et avoir une interface conviviale et facile d'utilisation, la plupart des fonctionnalités se trouvent dans la barre latérale. Cette barre latérale est composée de deux parties bien distinctes. Une première permettant de choisir certaines branches du mo-dèle et ainsi sélectionner un système et au sein de ce système certaines orbites. La seconde permet de sélectionner une des "Vues" parmi celles proposées selon le mode de visualisation.

$ $ S É L E C T I O N D E S S Y S T È M E S

$ L'encadré de sélection des systèmes propose une liste déroulante permettant le choix du système et un panneau déroulant permettant l'affichage des différents objets composant ce sys-tème.

Yoann Dufresne 22

Etoile double sans corps central

$ Afin de bien respecter le rôle de contrôleur que j'ai attribué à l'interface graphique, l’en-cadré à pour rôle l’initialisation du modèle au lancement de l’application. Cela lui permet en-suite de créer la liste déroulante proposant les systèmes. De nouveau pour respecter le rôle de contrôleur, la sélection d’un item de la liste déroulante met à jour le cadre juste en dessous.

$ Remarque : Quel que soit le type de visualisation en cours, cet encadré reste inchangé.

$ $ S É L E C T I O N D E S V U E S

$ Cet encadré a toujours le même but quelque soit le type de visualisation en cours. Il est là pour proposer le choix entre différents modes d'affichage de la visualisation courante. Cet encadré ne modifie jamais le modèle mais simplement la façon dont on le perçoit. Par exemple, pour la visualisation 3D il permet de changer l'emplacement de la caméra et pour la vue plani-sphère, de choisir le mode de tracé. Nous allons voir plus de détails sur ce que contrôle cet en-cadré durant la partie 1v.

111.3. Fonctionnalités supplémentaires$ Au moment où j'écris ces lignes, les fonctionnalités qui vont être présentées ici ne sont pas encore existantes et devraient être mises en places dans les jours suivant le rendu de ce rapport.

Yoann Dufresne 23

Menu de sélection des systèmes

Menus de gestion des «vues»A gauche menu 3D et a droite menu planisphère

$ Rendez-vous est pris avec les personnes s'occupant de la base de donnée ODIN afin de pouvoir y relier mon application. Cette connexion va permettre d’ajouter un très grand intérêt au logiciel. Durant ce rendez-vous il sera également évoqué la possibilité de créer une seconde version de l’application afin de l’intégrer aux services web de PODET.

La solution technique que je vais leur proposer pour la base de données est la suivante :$ Tout d'abord je vais créer (ou faire créer) une vue au sein de leur base de donnée per-mettant d'avoir accès aux 6 coordonnées orbitales ainsi qu'aux caractéristiques (taille, masse, ...) des objets répertoriés dans cette base.$ Je pense ensuite créer un morceau de code sur leur serveur afin récupérer les informa-tions au sein de la base de donnée, les transformer en un ou plusieurs fichiers xml.$ Enfin, je créerai un accès par socket permettant de transférer les informations depuis le serveur jusqu'aux divers clients.

$ Cette solution technique a pour avantage de n'utiliser le mot de passe de la BDD que du côté serveur et de ne pas permettre la modification des données au sein de cette même BDD. Le seul inconvénient est de ne pouvoir accéder aux informations que depuis un poste ayant un accès à internet.

Yoann Dufresne 24

IV. EXEMPLES DEFONCTIONNEMENT

$ Dans cette partie, je vais montrer le fonctionnement des deux type de visualisation en m'aidant au maximum de captures d'écran du logiciel.

4.1. Visualisation 3D

$ P R I N C I P E G É N É R A L

$ Au premier lancement de la visualisation 3D, le logiciel calcule et met en place la scène 3D. Il génère dès le début tous les systèmes que le modèle contient. De cette manière, lors de la sélection d'un système dans la liste déroulante, le morceau d'arbre 3D correspondant est tout de suite raccroché à la scène 3D et apparait instantanément. Il n'y a aucun chargement. Lors d'un changement de système, le morceau d'arbre précédemment utilisé n'est pas détruit mais simplement décroché de la scène 3D.

$ Pour créer les différentes vues, je fais appel aux fonctions de base définies dans la classe Camera précédemment présentée.

$ L E S " V U E S "

$ $ V U E G L O B A L E E T V U E D E P R O F I L

$ Pour ces deux vues, la technique employée afin de trouver l’endroit où doit être placée la caméra est la même. Tout d'abord, je calcule la distance entre le point tracé le plus éloigné du centre et le point O. On appellera cette distance D. Ensuite, sachant que la caméra a un angle de vue de 45°, il est facile de trouver la distance de recul nécessaire pour voir le tracé sous un angle satisfaisant. Voici la figure explicative accompagnée de la formule :

Yoann Dufresne 25

!"#$%#&'(

!"#"$"%&'(")*+,")-"."%&'("/011

!!"

!"# "#

$

#

$ Pour plus de confort d'affichage, je remplace D par 1.5*D et ainsi ne pas avoir le tracé sur le bord. Maintenant que je connais la distance à laquelle je dois envoyer la caméra, il ne me reste plus qu'à effectuer un recul selon l'axe Oz pour la vue globale et selon l'axe Oy pour la vue de côté. Il ne reste plus qu’à effectuer une rotation de caméra pour fixer le centre du repère et voilà le résultat :

$ $ V U E D U P L A N

$ Le rendu 3D ne permet pas toujours de bien se rendre compte de la forme des orbites à cause des effets de projection. Pour palier à cela, j'ai créé une vue permettant de se positionner sur la droite perpendiculaire au plan d'une orbite choisie et passant par O. La distance à laquelle doit se trouver la caméra est calculée de la même manière que les deux vues précé-dentes.

$ Pour calculer les coordonnées exactes de la caméra, je procède en deux étapes. Premiè-rement, à l'aide de deux points de la courbe non alignés avec le centre, et le centre, je calcule le

Yoann Dufresne 26

Vue globale Vue profil

Vue du plan

vecteur unitaire passant par O et normal au plan de l'orbite choisie. Secondement, je multiplie ce vecteur par la distance à laquelle doit se trouver la caméra. En voici le résultat :

$ $ V U E D E S U R F A C E

$ Cette vue est prévue mais n'est pas encore implémentée. Contrairement aux trois vues précédentes, elle ne sera pas fixe mais accrochée à une orbite. Le travail s'axera sur deux con-traintes principales. Premièrement, la caméra devra pouvoir changer la direction de visé à l'aide de la souris et secondement on devra pouvoir changer la latitude et la longitude auxquelles la caméra se trouvera.

$ Cette vue permettra essentiellement de se rendre compte du mouvement relatif des ob-jets. Cette vue m’a initialement été demandée dans le but d’observer la course perpétuelle en-tre Janus et Épiméthée, deux lunes de Saturne.

4.2. Visualisation planisphère

$ P R I N C I P E G É N É R A L

$ Contrairement à la visualisation 3D, la visualisation par planisphère ne garde rien en mémoire. A chaque changement du modèle, de l’interface graphique ou de mode de traçage, le cadre contenant le planisphère est entièrement repeint. Je n'ai pas choisi la même technique que pour la 3D car java 2D ne fonctionne pas à la manière d'un arbre.

$ Quel que soit le type de tracé, l'affichage se passe toujours en 3 temps : Le tracé du pla-nisphère, le tracé des segments de l'orbite et enfin le tracé des cercles de visibilité.

$ L E S M O D E S D E T R A C É

$ $ L E M O D E H O R A I R E

$ Ce mode consiste simplement à tracer les projections pour un certain nombre d'heures. Le nombre de points utilisés pour tracer chaque orbite est égal au nombre d'heures demandées multipliées par 100. Voici un rendu pour 12h pour plusieurs satellites de la Terre :

Yoann Dufresne 27

$ L E M O D E P É R I O D E S

$ Ce tracé permet de représenter un nombre de périodes données. Attention, une période pour chaque satellite ne correspond pas à la même durée de révolution. Ainsi, si je demande le tracé d'une période pour l'ISS et pour le satellite QZS, l’image suivante représentera 1h30 pour l'ISS et 24h pour QZS :

$ $ L E M O D E " E N D I R E C T "

$ Ce mode est pour le moment conçu pour un tracé en temps réel. Il affiche un nouveau point toutes les cinq secondes pour les orbites sélectionnées. A terme, il va évoluer pour que le premier point tracé soit la position réelle au moment du lancement. Pour cela, il faudra néces-

Yoann Dufresne 28

Tracé de 3 satellites sur 12 heures

Une période pour l’ISS et QZS

sairement que la connexion avec la base de donnée soit opérationnelle. Voici un aperçu de la version actuelle :

Yoann Dufresne 29

Tracé en direct

V. RETOUR SUR LA GESTIONDU PROJET

5.1. Difficultés techniques rencontrées$ Bien qu'ayant été étudiant en licence de physique avant de m'orienter en informatique, la compréhension des équations à la base du logiciel n'a pas toujours été très simple. J’ai choisi ce stage pour sa pluridisciplinarité et c’est de là que vient cette difficulté.

$ Dans le logiciel, j’ai dû concevoir pour la première fois une interface graphique élaborée. La quantité de travail à fournir pour obtenir un résultat convenable ne me semblant pas hors de portée, j’ai pris la décision de coder l’interface manuellement. Cette décision m’a fait perdre beaucoup de temps et je pense qu’à ma prochaine création d’interface j’utiliserai un logiciel pour m’assister.

$ Le domaine qui m'a posé le plus de soucis durant le stage est sans conteste la 3D. J’ai démarré le stage sans même avoir une idée de comment se programmait une scène 3D.$ Pour moi, tout a été laborieux durant la conception de ce pan du logiciel. L'apprentis-sage en ligne a été un vrai cauchemar faute de tutoriels clairs à propos de Java3D. La création d'une scène statique a été une lutte du fait de ne pas pouvoir tracer d’ellipses grâce à des fonc-tions prédéfinies. Ensuite, il fallait que la scène puisse créer des objets sur des distances courtes comme des satellites et leur corps central (quelques centaines de km) mais également qu'elle puisse créer des objets très distants comme le Soleil et Sedna (distances de plus d'une centaine de milliard de km par moments) alors que les configurations devaient changer. Enfin, la plus grosse difficulté a été la mise en mouvement des objets de la scène. À chaque fois que j'ai es-sayé d'implanter un objet pour transformer la scène, je me suis instantanément retrouvé avec un bug prenant quelques temps à résoudre.$ Cependant, ces mésaventures m'ont permis d'apprendre beaucoup de nouveaux con-cepts et m'ont donné l'envie de poursuivre dans l'apprentissage de la conception 3D. L'aspect optimisation y est omniprésent et m'intéresse tout particulièrement.

$ La dernière difficulté rencontrée vient du fait que l’affichage du planisphère provoquait des lenteurs excessives. J'ai très rapidement vu que le logiciel devenait très lent lorsque je tra-çais les projetés de plusieurs satellites simultanément. Le travail d'optimisation que j'ai fourni

Yoann Dufresne 30

n'avait pas été prévu et c'est en ce sens que je classe ce ralentissement dans les difficultés ren-contrées. Bien que cela soit classé dans les difficultés, résoudre ce problème m'a beaucoup plu.

5.2. Gestion du temps $ La gestion du temps au cours du stage a été un des aspects pour lesquels je me suis fait le plus de critiques. Pour tous les travaux que l'on effectue dans le cadre des cours, j'arrive assez bien à savoir à l'avance comment organiser mon temps pour parvenir à mes fins. Durant mon travail à l'observatoire, j'ai remarqué être passé par trois "phases" du stage. Le point commun de ces trois phases est de toujours avoir sous-évalué la durée pour effectuer une tâche.$$ Durant les passages par la phase de compréhension (du sujet ou d'une technique nou-velle), j'ai chaque fois eu besoin de plus de temps que ce que j'avais estimé et ce, soit à cause de nuances que je n'avais pas saisies soit à cause de phases de tests plus longues que prévues.$ Durant les phases de "création de code", ce sont les divers et nombreux "bugs" qui sont venus me retarder. De plus, le fait de passer plusieurs heures voire plusieurs jours sur un pro-blème a accentué le retard occasionné en me décourageant.$ Enfin, durant les phases de finalisation, j'ai toujours sous estimé le temps à consacrer aux derniers détails. Je pense que cela est dû au fait que lors des TPs dans le cadre de mes cours, je ne me suis jamais soucié de rendre une application entièrement finalisée.

$ Cela dit, bien que le temps mit pour effectuer mon travail ait dépassé mes prévisions, le programme rendu en fin de stage est quasiment complet et entièrement fonctionnel. Le travail initialement demandé est entièrement terminé (à l'exception de la vue de surface) et j'ai même intégré quelques améliorations non prévues à l'origine. Lors de mes travaux futurs, l'expérience de ce stage me permettra d'évaluer plus précisément le temps nécessaire pour la réalisation d'une tâche.

Yoann Dufresne 31

CONCLUSION

$ Ce stage était d'une nature informatique dans un contexte de mécanique céleste et spa-

tiale. Pour intégrer pleinement chacun des points du cahier des charges, il a fallu commencer par comprendre l'ensemble du contexte scientifique : objectif de l'ensemble du projet PODET, fonctionnalisées non encore opérationnelles, importance du travail qui m'a été proposé dans l'ensemble du schéma d'analyse.$ Les objectifs de départ étaient donc clair. La grande majorité des points a été prise en compte (Création de vues 3D d'orbites, création d'un planisphère de visualisation), d'autres sont même venus enrichir le cahier des charges en cours de réalisation (Création de cercles de visibilité pour le planisphère, connexion à la base de donnée ODIN, création d'un tracé en temps réel).

$ Ce stage a dépassé mes attentes sur tous les points.$ Sur le plan humain, l’accueil qui m’a été fait me correspondait parfaitement. Travailler sans horaires fixes, a permis d’adapter mon travail aux périodes durant lesquelles j’étais le plus productif.$ Sur le plan des connaissances mathématiques et astronomiques, j’ai pu enrichir mes fa-cultés dans ces domaines et ainsi accroître ma culture générale.$ Cependant, c’est sur le plan informatique que ce stage m’a le plus apporté. Plutôt que de m’aider à devenir un expert dans un domaine de l’informatique, ce stage m’a permis de dé-couvrir plusieurs de ces domaines. Le projet m’a permis de créer un solveur et ainsi faire de l’analyse numérique, de créer deux visualisateurs qui m’ont permis de découvrir les mondes de la 2D et de la 3D et de concevoir une interface graphique.

$ L'intégration de l'outil que j'ai développé est déjà effective au sein des webservices de PODET existants. Ceci assure une belle visibilité et une valorisation de mon travail. Pour aider au développement de la suite du logiciel, je propose en annexe A des améliorations possible ainsi qu’une piste de travail pour chacune d’entre elles. Une extension de l'outil est d'ailleurs d'ores et déjà prévue et s'appuiera sur les modules que j'ai développé.

Yoann Dufresne 32

BIBLIOGRAPHIE

Toshio Fukushima «A method solving kepler’s equation without transcendental function evaluations»The astronomic journal, Volume 112, Number 6 : Décembre 1996

PODET «PÔle sur la Dynamique de l’Environnement Terrestre» (accès restreint pour le moment)https://podet.imcce.fr/

IXION, outil de visualisation de projetés d’orbites.http://climserv.ipsl.polytechnique.fr/ixion.html

Alain Vienne «Le problème des deux corps»http://lal.univ-lille1.fr/cours_astr201.pdf

Tutoriel Java 3Dhttp://rvirtual.free.fr/programmation/java3d/intro.html

Florent Deleflie «“PODET-débris” : Vers un nouveau catalogue de débris spatiaux»Rapport, 7 Décembre 2009, Toulouse, CCT PMI du CNES

Yoann Dufresne 33

ANNEXES

Annexe A : Améliorations logicielJe vais présenter ici les améliorations qui, selon moi, seraient bénéfiques au logiciel.

Variations des coordonnées orbitales : Pour le moment, le logiciel fonctionne avec 5 coor-données orbitales constantes. Dans le cas de mouvements non Képleriens, ces coordonnées varient avec le temps.

Implémenter ces coordonnées risque d’être un travail ardu car il ne suffira pas de changer de solveur pour les équations de Képler. Il faudra faire en sorte que les coordonnées de la scène 3D varient au cours du temps. Pour le moment l’orbite 3D est pré-calculée avant le lancement. Il sera sans doute possible d’apporter les corrections depuis un module externe.

Vue de suivi : Cette vue qui était prévue initialement n’est pas implémentée. Il faudrait faire en sorte que la caméra soit accrochée à un corps en rotation.

La tâche n’est pas simple car il ne suffit pas d’attacher la caméra à un repère tournant. Il faut également que la direction de la vue puisse être changée (idéalement à la souris). Enfin, il fau-drait faire en sorte que l’emplacement à la surface de la planète ou du satellite soit réglable (le mieux me semble être un système de latitudes et longitudes sur l’interface graphique comme dans IXION).

Systèmes de systèmes : Il est pour le moment possible de créer des systèmes orbitaux avec des objets en orbite autour du point central. Ce que j’appelle ici système de système serait par exemple la Lune tournant autour de la Terre tournant elle même autour du Soleil.

Le modèle prévoit déjà qu’un système puisse avoir une orbite. Il suffit de créer un solveur per-mettant de transformer les coordonnées d’un repère fixe en coordonnées dans un repère tour-nant.

Planisphère non central : Actuellement, l’utilisation du planisphère n’est possible que sur le corps central. Il n’y a pas de raison pour que dans le système Terre-Lune on ne puisse pas proje-té la trajectoire relative de la Terre sur la Lune.

Yoann Dufresne 34

Une nouvelle fois, il faut créer un solveur permettant d’obtenir des coordonnées dans un repère tournant.

Trajectoires non elliptiques : Le solveur ne permet actuellement de résoudre que l’équation de Kepler pour des objets avec une excentricité inférieure à 1.

Pour cela il faut créer un solveur de l’équation relative aux trajectoires avec e>1.

Yoann Dufresne 35