Projet de développement "suivi de cible"

phoenixA380 · 13/04/2011 20:04:28

Bonjour à tous,
Je suis étudiant en Math Sup, et dans le cadre d'un projet présenté aux concours des grandes écoles l'an prochain, je désire développer un programme de suivi de cible sur simulateur de vol.
Plus précisément : je voudrais qu'un avion soit asservi en orientation (lacet, roulis, tangage) et vitesse pour suivre un autre avion.
Je vais utiliser un filtrage de Kalman, permettant de prédire des paramètres en fonction d'une série d'observations.

J'ai besoin des éléments suivants :
- un logiciel de simulation souple et open source : j'ai trouvé, c'est FG ;-)
- récupérer les variables suivantes de FG, pour pouvoir les exploiter dans mon programme :
- coordonnées cartésiennes, orientation, vitesse de l'avion SUIVEUR
- coordonnées cartésiennes, orientation, vitesse de l'avion SUIVI
- modifier en temps réel (par itération, je pense) les variables suivantes : coordonnées cartésiennes, orientation, vitesse de l'avion SUIVEUR (en réalité, modifier les variables de la partie commande de l'avion, pour impliquer la modification de ces paramètres)

nota :
- l'avion SUIVI présente une trajectoire et une vitesse aléatoires, et peut être piloté à la main.
- Il est envisageable pour moi de travailler avec deux PC en réseau, si nécessaire.

J'ai commencé à regarder le Nasal, et je pense que c'est le langage qu'il faut pour réaliser mon projet. Qu'en pensez-vous ?
Mon problème est que je ne connais pas très bien la structure de FG, malgré tout ce que j'ai lu sur votre site.

Pouvez-vous m'indiquer comment je puis débuter pour atteindre les objectifs cités plus haut ? Je ne sais pas, de façon pratique, comment commencer.

Merci pour vos réponses !

Dernière modification par phoenixA380 (13/04/2011 20:10:32)

zakharov · 14/04/2011 8:31:18

salut phoenixA380 et bienvenue,

il y a déjà plusieurs suivis de types différents présents dans FG:
* le "wingman" (en nasal je crois) qui permet de créer un deuxième appareil aux côtés du tien et qui semble suivre tes mouvements comme en formation
* le "tracking" en C++ qui s'intègre dans un HUD et ajoute un cercle autour des appareils environnants
* le système de détection de proximité qui affiche sur une carte les appareils environnants, et des infos sur leur direction et vitesse pour éviter les collisions (en C++ et uniquement sur la version de développement, je ne sais pas si elle fait partie de la très prochaine version 2.2)
* le vol en double commande (en nasal), pour piloter à deux un appareil au travers du réseau
* peut-être d'autres encore

ce qui ne t'empêche nullement d'implémenter ta propre version de suivi bien sûr avec ta propre approche des choses . Y a plusieurs solutions: déplacer le modèle de l'appareil (pas besoin de fdm, facile et pas cher), jouer sur les commandes de ton appareil suiveur (plus rock'n'roll), ou jouer avec le pilote automatique (àmha le mieux), et certainement d'autres.

y a des exemples plein partout dans les différents appareils dispos, je ne les ai pas en tête mais pas mal de monde t'indiquera vers lesquels tu pourras zieuter pour t'inspirer)

toutes les infos concernant ton appareil (position, vecteurs de déplacement, tout tout tout) est disponible, au moins en lecture, dans l'arbre des propriétés, et Nasal version FG possède évidemment tout un tas de moyens mis à dispo pour manipuler ces propriétés.

pour les appareils extérieurs, c'est pareil, avec un peu moins d'infos mais celles qui t'intéressent sont bien sûr présentes.

FG intègre un navigateur de propriétés, elles portent souvent des noms parlants, découvre par toi-même celles qui peuvent être utiles, le nasal est très facile à appréhender et permet de très nombreuses choses, y a de quoi beaucoup s'amuser . Sur le wiki il y a une page dédiée à nasal

quand au temps réel (le vrai) ça faut pas y penser, FG ne le permet pas (autant que je sache et dans la version de base).

bon courage
@+
zakh

Dernière modification par zakharov (14/04/2011 10:06:56)

phoenixA380 · 14/04/2011 11:09:06

Merci zakharov pour ta réponse !

Je pense que je vais jouer sur le pilote auto, ça m'évitera sans doute des décrochages et mises en vrille involontaires.

- Peux-tu m'expliquer où je peux implanter un fichier .nas à moi pour pouvoir récupérer les données ? Dans le dossier Nasal de FG ou dans le dossier Nasal d'un avion en particulier ?

- Quelle est la syntaxe pour récupérer dans un programme nasal les variables de l'arbre des propriétés ?

zakharov · 14/04/2011 12:21:08

jouer avec le pilote automatique ne va pas empêcher les vrilles et autres décrochages, en fait c'est un simple régulateur PID intégré à FG donc il peut-être utile dans ton cas pour asservir la valeur de propriétés en fonction de certains paramètres comme la position, la vitesse, les vecteurs d'accélerations, etc. de l'appareil que tu suis. et ces propriétés peuvent être liées à des surfaces de contrôle (comme c'est courant pour un pilote automatique, mais aussi à tout autre chose qui pourrait t'être utile).

le pilote automatique se configure en XML, mais il est possible de la mâtiner de nasal pour calculer certains paramètres du régulateur qui pourraient varier en fonction de paramètres particuliers.

pour ce qui est de l'emplacement de tes fichiers nasal, dans $FGHOME/Nasal c'est un bon compromis ils seront chargés à chaque lancement de FG (d'ailleurs dans la version de dev, il est maintenant possible de créer une arborescence dans $FGROOT/Nasal), ensuite si tu les mets dans un appareil particulier, il faut que tu les "références" dans les fichiers de configuration des appareils qui vont les utiliser. Il n'y a pas de structure unique et figée, la seule chose qui est fixe est que le premier fichier lu d'un appareil est

$FGROOT/Aircraft/<niveau_de_répertoire_de_l_appareil>/<nom_de_l_appareil>-set.xml

Depuis ce fichier tous les autres fichiers, qu'ils soient à l'intérieur de la structure de fichiers de l'appareil ou à l'extérieur, sont chargés au fur et à mesure de leur déclaration, et l'arborescence de l'arbre des propriété est aussi créée.

Pour des raisons de sécurité tu ne peux pas par défaut intégrer du code depuis l'extérieur de $FGHOME ou $FGROOT, à moins d'ajouter le chemin autorisé dans le fichier $FGROOT/Nasal/IOrules.

pour ce qui est de la syntaxe et des moyens d'édition de code Nasal ou XML la page de wiki citée plus haut répond à ces questions

[edit: ajout de lien]
@+
zakh

Dernière modification par zakharov (14/04/2011 12:24:07)

phoenixA380 · 14/04/2011 23:31:43

Ok, merci beaucoup, je me suis amusé à récupérer des grandeurs comme l'altitude et la vitesse, et à les faire afficher par la ligne de commande toutes les secondes.

Maintenant il me faut les archiver dans des tableaux ou des hash pour les utiliser dans des calculs statistiques. Je vais regarder vos cours concernant ça, et je reviendrai certainement vous poser des questions.
Je reviendrai surement aussi pour le PA.
Merci et à bientôt !

jano · 14/04/2011 23:58:51

salut, pour te faire des fichiers de vol à des fin de stat, tu peux utiliser ça:

http://www.flightgear.org/Docs/getstart … -1070005.6

il te suffit de te faire un protocol perso adapté à tes besoins.

jano

Dernière modification par jano (15/04/2011 0:01:46)

phoenixA380 · 15/04/2011 11:30:40

Hello Commandant^^
La ligne de commande en question, c'est bien celle qu'on peut afficher avec la case "voir la ligne de commande" dans la dernière page avant le lancement du vol ? (où il y a Atlas, multijoueur...)
Je n'y ai aucun pouvoir d'écriture... Quelle est la procédure ?

Une fois que j'aurai réussi à lancer l'enregistrement du vol, comment puis-je récupérer les séries de valeurs dans un fichier ? C'est toujours en Nasal ?
Quel est le rôle d'un protocol XML ?

jano · 15/04/2011 13:41:19

avec fgrun, c'est dans le menu entrée / sorties:

http://fr.flightgear.tuxfamily.org/lib/ … sortie.jpg

pour le cas suivant: --generic=file,out,20,flight.out,playback

FG va écrire à 20Hz dans le fichier "flight.out" en utilisant le protocol "playback"

le fichier de protocol te permet de choisir quelles valeurs exporter dans le fichier, pour plus d'infos:

http://gitorious.org/fg/fgdata/blobs/ma … E.protocol

si tu exporte en ascii, il me semble que chaque ligne du fichier correspond à un temps donné, avec les valeurs séparées par des espaces.

cette façon de faire n'utilise pas de nasal.

jano

phoenixA380 · 16/04/2011 11:09:27

OK, je vous remercie.
En ce qui concerne le code nasal, je fais des tests par l'intermédiaire de la console nasal, en appelant un fichier .nas à moi.
Le problème, c'est que FG n'arrête pas l'ancienne exécution à chaque fois que je réexécute le programme. (et il y a des procédures récursives)
Et même, il rappelle le programme en question, sans que je le lui demande, à chaque ouverture du simulateur.
Je ne trouve pas de commande du genre "restart" pour tout remettre à zéro.
Et quand je lui dis "break;" (dans une condition), il répond runtime error...
Que me conseillez-vous ?

zakharov · 16/04/2011 13:41:55

j'imagine que ton erreur avec break c'est parce qu'il est fait pour arrêter une boucle, pour arrêter la récursivité il vaut mieux faire du return qui termine l'exécution de la fonction et retourne à l'instruction appelante + 1.

Il faut bien comprendre que ce que tu codes s'exécute immédiatement et durant toute la durée de la session FG, ou jusqu'à ce que tu arrêtes la première fonction appelée (cf § plus bas). il vaut mieux donc déclarer toutes tes actions à l'intérieur de fonctions, et lancer ta fonction "principale" (ton "main") via un listener (cf. setlistener(prop, objet, trigger)), il faut aussi que tu codes par toi-même les arrêts de tes fonctions.

aussi il n'y a pas de "restart" il y a un ensemble de propriétés dans /sim/signals qui permettent de savoir si FG subit un reset (via le menu "File > reset" par exemple), ou à quelle étape du démarrage il en est, tu peux t'en servir, ou faire ta propre propriété pour gérer le démarrage/pause/arrêt de tes actions. ça permet entre autre de gérer des dépendances entre fonctions, ou autres.

hope this helps
@+
zakh

Dernière modification par zakharov (16/04/2011 13:45:41)

phoenixA380 · 25/04/2011 16:16:37

Re-bonjour camarades volants^^,

Merci, le return; est parfait.

Quelqu'un peut-il m'indiquer quelles sont les propriétés du pilote automatique qui permettent de :

- activer PA
- activer maintiens du cap
- activer maintiens de l'altitude
- activer manette des gaz automatique
- activer maintiens de la vitesse verticale

- choisir la consigne de cap
- choisir la consigne d'altitude
- choisir la consigne de vitesse air (ou sol) d'ailleurs laquelle vaut-il mieux choisir pour mon projet ?
- choisir la consigne de vitesse verticale

Avec toutes les propriétés du /autopilot je m'y perds et je ne vois pas sur lesquelles agissent les boutons de la console PA du tableau de bord graphique.

Dernière modification par phoenixA380 (25/04/2011 16:17:36)

zakharov · 25/04/2011 20:47:43

le pilote auto n'a pas de propriétés spécialement affectées, ni de propriétés "en dur". historiquement toutes les propriétés liées au PA sont situées dans /autopilot

tu peux essayer de zieuter un que j'ai écrit pour un instrument toujours en cours de réalisation (l'arlésienne qu'il s'appelle ): https://gitorious.org/zakharov/zkv1000/ … opilot.xml

il n'a rien de particulier, je l'ai repompé from l'original par défaut dispo dans FG (j'arrive pas à remettre la main dessus). on y lit par exemple que le PID "Wing Leveler (Turn Coordinator based)" est actif quand la propriété "/autopilot/locks/roll" est égale à la chaîne "wing-leveler" et que la propriété "/autopilot/locks/passive-mode" est fausse (chaîne vide ou valeur nulle). il prend en entrée la valeur de la propriété "/instrumentation/turn-indicator/indicated-turn-rate" et sa sortie est la propriété "/controls/flight/aileron".

les valeurs inclues dans la balise <config> servent à paramétrer le contrôleur PID et dépendent de multiples paramètres, certaines se déterminent pas le calcul, d'autre par empirisme, mais mes cours sur le sujet sont vraiment trop lointains pour que je puisse être utile ici. Il y a aussi des balises références <reference> qui vont permettre au PID de connaître la valeur à atteindre ou approcher.

<edit>
ce pilote auto crée 3 branches dans /autopilot:
/autopilot/locks: pour savoir quel contrôleur est armé
/autopilot/setting: ce sont les valeurs d'altitude, de cap, etc. que le pilote a entrées dans le PA
/autopilot/internals: ce sont des propriétés intermédiaires (contrôleurs à plusieurs étages cf plus bas)
j'ai rien inventé juste c'était fait comme ça dans l'exemple que j'ai suivi et j'ai pas trouvé mieux
</edit>

surtout ce qu'on voir c'est qu'en entrée tu mets une propriété (celle qui t'arrange) et en sortie une autre propriété (ou la même mais là faut reconnaître que c'est moyennement utile ), mieux avec ce système tu peux imaginer plusieurs "étages": l'entrée d'un PID est la sortie d'un autre, ça permet de mettre plus de conditions, plus de finesse, ... le système est souple si t'as envie d'appeler tes propriétés "foo", "bar" ou "foobar" (pour ne pas dire "toto", "tata", "tutu"), ça marchera pareil. ce sera moins lisible, mais ça marchera.

<edit n="2">
la vitesse au sol ne sert à rien en vol, enfin c'est pas elle qui va t'éviter le dépassement de vitesse ou le décrochage
</edit>
bon courage
@+
zakh

Dernière modification par zakharov (25/04/2011 20:54:32)

phoenixA380 · 28/04/2011 21:56:12

Merci pour ces précision, j'ai compris comment élaborer le PID.

Maintenant, dans l'architecture de FG :

- comment créer une propriété dans l'arbre des prop internes ? (si j'ai bien compris, votre programme ne modifie pas l'arbre des prop, mais indique qu'on veut un PID utilisant telles variables)
Par exemple si je veux avoir des gains variables au lieu de constantes mises directement dans le xml...

- Vu que chaque avion a son système PA "perso" apparemment, y a-t-il selon vous un avion plus adapté à mon projet, en terme de PA et de model de vol ?

Forum Flightgear France

Annonce

#1 13/04/2011 20:04:28

Projet de développement "suivi de cible"

#2 14/04/2011 8:31:18

Re : Projet de développement "suivi de cible"

#3 14/04/2011 11:09:06

Re : Projet de développement "suivi de cible"

#4 14/04/2011 12:21:08

Re : Projet de développement "suivi de cible"

#5 14/04/2011 23:31:43

Re : Projet de développement "suivi de cible"

#6 14/04/2011 23:58:51

Re : Projet de développement "suivi de cible"

#7 15/04/2011 11:30:40

Re : Projet de développement "suivi de cible"

#8 15/04/2011 13:41:19

Re : Projet de développement "suivi de cible"

#9 16/04/2011 11:09:27

Re : Projet de développement "suivi de cible"

#10 16/04/2011 13:41:55

Re : Projet de développement "suivi de cible"

#11 25/04/2011 16:16:37

Re : Projet de développement "suivi de cible"

#12 25/04/2011 20:47:43

Re : Projet de développement "suivi de cible"

#13 28/04/2011 21:56:12

Re : Projet de développement "suivi de cible"

Pied de page des forums