OpenPlane

Hello !

Je suis Wizix, ado de 17 ans en Terminale S à Rennes. Depuis tout petit j'ai trois passion, l'aéronautique, la programmation et le piano (qui ne nous intéressera pas pour ce sujet ). Je suis vraiment touche-à-tout, j'ai fais du C++, Ruby, HTML/CSS, PHP, JavaScript, C#, Perl, Ada, C… Mais le langage qui me branche beaucoup en ce moment c'est le Python. Et je pense qu'il est bien parti pour le rester. Bref, laissez-moi vous raconter ce qu'est OpenPlane.

Genèse

Depuis la quatrième je suis des cours d'aéronautique. Je possède mon BIA et je suis entrain de passer mon PPL. En aéronautique on utilise un logiciel très complet et totalement génial, Navigation. Le principal problème de celui-ci est qu'il ne tourne que sous Windows (et pour cause, il est codé en Visual Basic).
Étant un Linuxien, je dois l'émuler avec Wine. Et c'est lent, trop lent. Voici donc quelque temps que je me dis qu'il serait bien d'avoir un logiciel semblable sous Linux. Et ne trouvant pas de solution satisfaisante, j'ai pris la décision la plus débile que j'aurais pu prendre : faire cet équivalent moi-même.

Technologies

OpenPlane est entièrement codé en Python 3, il utilise (pour le moment) deux librairies externe :

• PyGObject pour l'interface graphique en GTK+
• matplotlib pour faire des beaux graphiques

Ce logiciel est et restera open source. Il est publié sur mon Github, à cette adresse : https://github.com/boopr/OpenPlane

C'est mon premier vrai projet, donc forcément l'organisation des fichiers n'est pas la meilleure qui soit mais je m'y retrouve. Mon code est sûrement dégoûtant notamment les fichiers openplane/gui/gui_plane_manager.py et openplane/gui/gui_weight.py qui sont affreusement répétitifs, mais j'avoue ne pas trop savoir comment faire autrement. Si quelqu'un se sent d'attaque pour me donner des conseils, je suis preneurs ! Toute aide est la bienvenue !

Screenshots

Je précise que j'apprends PyGobject à travers ce projet et le peu de ressource disponible sur Internet. Donc l'interface est voué à des changements (notamment le gestionnaire d'avion qui est actuellement une fenêtre qui va sûrement devenir une fenêtre modale).

En haut à gauche : la fenêtre principale, dessous : le convertisseur, dessous : le hangar et à droite : le gestionnaire d'avion, qui est sur l'onglet centrage de l'avion F-BTBB.

La fenêtre de masse et de centrage. Le graphique se met à jour automatiquement quand des valeurs sont entrées et il peut-être exporté grâce au bouton Enregistrer.

Ce qu'il reste à faire

Beaucoup de choses. Petite liste de ce que j'ai en tête :

• Un logo Merci à Blackline !
• La licence, GPLv2 ou GPLv3 ? GPLv3 me semble correspondre.
• Gestion des METARS et TAF, partie qui semble compromise car je ne sais absolument pas où me les procurer. C'est soit payant, soit pas à jour.
• Les NOTAMS
• Si, par le plus grand des miracles, je trouverais comment faire, une carte aéronautique interactive comme dans Navigation. Mais je ne pense pas que ce sera implémenté.
• Et autres

Voilà le projet sur lequel je bosse en ce moment. C'est vraiment un projet qui me tient à cœur, et j'en suis vraiment très fier.
Si vous avez toutes remarques, conseils, suggestions ou voir même un retour d'utilisation (si il y a des pilotes dans la salle, pourriez-vous me dire ce qu'il faut absolument que j'ajoute ?) n'hésitez pas.

Lien Github : https://github.com/boopr/OpenPlane

Je vous remercie de votre lecture, de vos retours et je vous souhaite une bonne journée !

Salut ! Ton projet m'intéresse, j'ai beau ne pas pouvoir voler, je fais de l'aéromodélisme, spécifiquement du planeur RC (d'où le SB-10 de l'avatar :D). Si j'ai bien compris, l'utilité actuelle est de gérer les calculs de CG ? Si oui, ça me rappelle PredimRC qui sert à ça mais c'est sans doute pas le même objectif (ni la même échelle :D)

En tout cas, ça a l'air vachement chiadé, continue comme ça !

P.S: J'ai jeté un oeil au code. Tu mets un membre "turbulance" dans Plane.py alors que c'est "turbulence" la bonne orthographe. Dernière petite chose, c'est juste un peu dommage que le code et l'UI soient en français (EDIT: je suis pas foutu de réfléchir à ce que j'écris).

Hey !
Mon quadcopter ne fait pas trop le poids face à ton planeur !
Grosso-modo, oui le logiciel ce limite pour le moment au calcul de CG. PredimRC à l'air vraiment bien plus poussé ! Je ne connaissait pas et il est vraiment impressionnant !

J'essaye de faire de mon mieux pour mettre tout le code en anglais, mais je manque un peu d'imagination sur les noms de variables. Par contre l'UI est intégralement en français !

Merci de ton commentaire (et de ta correction pour turbulence)

EDIT : J'ai renommé les variables, elles sont désormais toutes en anglais (enfin… sauf dans le fichier openplane/gui/weight.py)

Je me suis un peu plus documenté sur le centrage des avions grandeur, et apparemment vous c'est plus un truc où on compte la masse des bagages, pilote, carburant etc et on multiplie par des bras de levier pour obtenir des moments puis une valeur de centrage pour vérifier qu'on est dans une zone acceptable, c'est ça ? Si oui, c'est différent de PredimRC: PredimRC te permet de calculer un centrage optimal selon la géométrie du modèle, qu'on modifie ensuite après des essais en vol (sans parler du reste des fonctionnalités, les polaires tout ça). Mon commentaire dessus était un peu HS du coup vu que toi c'est pas un outil de conception.

Pour l'anglais, je me suis gouré, je me disais que c'était mieux de mettre tout en anglais parce que comme ça d'une part tu as plus d'exposition mais tu peux aussi aller demander des conseils sur les fonctionnalités sur des forums d'aviation anglophones. Si tu arrives à localiser ton soft, je veux bien bosser un peu sur la traduction.

C'est exactement ça. OpenPlane n'est pas un outil de conception mais de préparation de vol. Je ne construit pas d'avions mais par contre je vole, donc il me fallait un outil pour préparer ces vols tranquillement !

Pour l'anglais dans l'UI tu as raison, j'aurais dû y penser. Mais bon, maintenant qu'il est bien entamé en français, je vais faire toute l'UI dans cette langue. Mais je compte bien proposer les traductions, bien que ce ne soit absolument pas ma priorité (surtout que je ne sais pas encore comment faire ). De plus, je te note en traduction, merci de te proposer !

Merci pour tes explications.
Je vais essayer de mettre ça en place pour mercredi. Il faut d'abord que refasse certaines fenêtres avec Glade et que je nettoie un peu le code.

Je n'utilise pas PyGTK (dont on m'a dit que le projet était mort) mais PyGObject et la documentation n'est malheureusement pas aussi complète, car elle se limite à ça. Je vais me débrouiller pour que la traduction soit fonctionnelle prochainement.

Ah ouais, pas terrible, y'a rien sur l'i18n/l10n. Pour les chaînes de caractère qui traînent dans ton code, tupeux faire ça avec gettext et ça a pas l'air trop chiant. Par contre je sais pas comment faire pour traduire les fichiers glade.

Autre détail, tu mets l'unité du moment du poids des objets en $kg.m$ alors que c'est des $N.m$. C'est parce que tu fais tous les calculs en ignorant $g$, c'est ça ? Mon prof de physique aurait passé un long moment à couiner après les unités

Le texte que j'écris dans Glade est indiqué comme traduisible, regarde cette image :

Donc j'imagine qu'il doit y avoir quelque chose pour traduire un fichier Glade.

C'est vrai que maintenant que tu le dis, ça me semble logique. Mais dans les deux-trois manuels de vol que j'ai pu feuilleter, le moment est bien en $kg.m$ !

Je remercie énormément Blackline pour sa proposition de logo. Personnellement elle me plaît. Qu'en pensez-vous ?

Le logo envoie du lourd ! Et puis même si tu le trouves bof, OpenPlane c'est un chouette nom. Pour le moment, mon explication pour le moment c'est que, avec $d$ le bras de levier, $m$ la masse, $g$ la constante g, on a $\mathcal{M} = Pd = mgd$, et qu'en aviation on se fout de $g$. C'est probablement à cause de la division plus loin par la masse totale, peut-être qu'en physique on diviserait par le poids total et que donc ça simplifie le $g$.

Dans le code, fais un petit s/Rechager/Recharger aussi.

Le logo sera ajouté demain au projet. Je vais rajouter une nouvelle fenêtre pour les remerciments, afin que vos noms apparaissent.

Ton explication tiens la route, c'est probablement ça. Je demanderais à mon prof d'aéro.

Excuse-moi, mais je n'ai pas compris ce que tu voulais que je fasse à mon code.

Je n'y connais rien en avion, mais je voyant que le logiciel de référence est en visual basique je me dis que tu pourrais à terme faire mieux qu'en proposer une simple version pour linux : en proposer une version moderne pour tous les OS, windows compris !

Est-ce que ceci serait possible en python ?

+1 pour le multiplateforme, mais en Python c'est un peu chiant à faire d'après mes souvenirs. Wizix, c'était pour te dire que dans le code du hangar y'a "rechager" au lieu de recharger et ça apparait dans l'UI.

Salut Demandred,
Théoriquement, oui c'est possible. Les deux bibliothèques que j'utilise sont toutes dispo sur Linux/Windows et Mac OS X. Mais d'après ce que ce que j'ai vu, l'installation de PyGObject sous Mac OS X est assez ardue par contre, windows possède un installeur donc pas de soucis pour lui. Donc en théorie, il faut "juste" que je passe tous les chemins en universel et non pas en format UNIX. Après en pratique je ne saurais pas vous dire si ça fonctionne sous Windows, je n'en possède pas un.

Aha d'accord, merci Grimur ! Mais justement ce bouton passe à la trappe, j'ai réussi à faire en sorte que la liste se recharge automatiquement !

EDIT : Je viens d'ajouter le logo au projet, y'a pas à dire, ça a de la gueule. J'ai aussi ajouté un fichier config.py qui contient tous les chemins générés en fonction de l'OS. Un pas de plus vers le multi-plateforme !

Petite question, pour le moment le format des avions est .json, devrais-je créer ma propre extension, genre quelque chose comme :

• .opp pour OPen Plane ou Open Plane Planefile
• .opd pour Open Plane Document
• .opf pour Open Plane File
• .opl pour Open Plane pLane

Si vous avez des propositions, indiquez-les !

Il existe pas un format ouvert et interopérable à la base ? Si non, c’est bien. Mais si ça existe, autant prendre l’existant !

Il y a bien le format de Navigation mais il y a deux raisons pourquoi je ne l'utiliserais pas :

• Il vient d'un programme propriétaire
• Son implémentation en Python n'est pas aisée (contrairement au JSON)
• Difficilement éditable hors du logiciel (ce que je ne veux pas)

Donc pour moi, le JSON c'est tout naturellement imposé comme étant la seule solution. Mais je compte bien développer un petit convertisseur pour passer du formats de Navigation au format .opX.
Et à part Navigation, je ne connais pas d'autres logiciels gratuit qui permettent de faire ça.

C'est vraiment nécessaire l'extension perso ? C'est pour que Windows lance le bon soft quand on clique dessus ?

L'avantage c'est qu'imaginons en cas de partage du fichier, on sait exactement à quel logiciel se rapporte le fichier et comment nous devons l'éditer, car si c'est comme je l'ai compris du format JSON, ça peut être bien des autres choses.

Ps: Je t'encourage vivement pour ton projet, je le suis depuis le début et je trouve ceci très intéressant (Plus pour la parti programmation que le programme en lui-même car je ne connais pas grand chose en aviation).

Si tu fais un convertisseur Navigation/ton format et ton format/Navigation, ça passe.

Sinon j’ai pas compris les fonctionnalités de ton programme, étant pas un pilote. Possibilité de mettre une sorte de « tutoriel » expliquant ceci ou cela (un readme avec des screenshots, pour parler de l’utilité de tel ou tel chose) pour les profanes qui veulent s’amuser avec l’application en testant des valeurs au pif ?

qwerty: en gros l'idée c'est que le centre de gravité d'un avion doit être dans une certaine zone, sinon ça vole comme une merde. Par exemple, quand c'est trop arrière c'est super instable, j'en ai fait les frais sur un de mes planeurs RC, départ en vrille à gogo et après faut sortir la colle. Du coup, son soft permet de calculer la position du centre de gravité selon le poids des passagers et de tout le bordel pour savoir si t'es dans une bonne plage de centrage pour voler. Il y a aussi un convertisseur pied/m parce que les pilotes utilisent souvent des valeurs d'altitude en pieds.