LISA airplanes

F-GTUX · 2013-06-16 10:15:15

Me revoilà.
Pour le pb de lancement du JSBsim, je tâtonne puisque je ne l'ai pas chez moi (FG 1.9.1 sous Linux). Tentez d'insérer ça dans Akoya-base.xml, avant la partie <nasal>, de toute façon ça ne fera pas de mal :

<surface-positions>
<chute-pos-norm type="float">0</chute-pos-norm>
</surface-positions>

Pour les masses, j'en ai ajouté un peu par défaut, ça se joue dans Akoya-base.xml :

<weight n="0">
<name>Pilot</name>
<weight-lb>160</weight-lb>
<max-lb>210</max-lb>
<min-lb>130</min-lb>
</weight>

<weight n="1">
<name>Passenger</name>
<weight-lb>0</weight-lb>
<max-lb>210</max-lb>
<min-lb>0</min-lb>
</weight>

<weight n="2">
<name>Payload</name>
<weight-lb>0</weight-lb>
<max-lb>210</max-lb>
<min-lb>0</min-lb>
</weight>

</sim>

<weight n="0">
<name>Pilot</name>
<weight-lb alias="/fdm/jsbsim/inertia/pointmass-weight-lbs[0]"/>
<max-lb>210</max-lb>
<min-lb>130</min-lb>
</weight>

<weight n="1">
<name>Passenger</name>
<weight-lb alias="/fdm/jsbsim/inertia/pointmass-weight-lbs[1]"/>
<max-lb>210</max-lb>
<min-lb>0</min-lb>
</weight>

<weight n="2">
<name>Payload</name>
<weight-lb alias="/fdm/jsbsim/inertia/pointmass-weight-lbs[2]"/>
<max-lb>210</max-lb>
<min-lb>0</min-lb>
</weight>

</payload>

Pour le FDM JSBSim, merci pour la piste. J'aurais eu tendance à plutôt jouer sur les réglages des moments de rappel en tangage. Ca devrait avoir un effet comparable sur le tangage, mais déplacer AERORP doit jouer aussi sur le roulis et le lacet. Maintenant, c'est toi le pilote : si ça te va en décalant AERORP comme tu as fait, surtout on laisse comme ça ! Je l'ai fait chez moi, c'est effectivement sympa.

Quant au yasim, j'ai fait du ménage, et je vous envoie le résultat, en attendant bien sûr les critiques. Le comportement a beaucoup changé, j'espère que ce sera dans le bon sens ! Les conseils de Buckaroo ont été très utiles, je n'avais pas vu les sections les plus récentes.

A bientôt !

dany93 · 2013-06-16 21:52:39

Bonjour Lionel,

Je viens de prendre connaissance de tes envois, je n'ai fait que des essais très rapides et partiels mais je préfère te répondre même un peu à chaud pour ne pas trop te faire attendre (quitte à compléter ou rectifier après).
- Pour le plantage JSBSim, tu as fait ce qu'il fallait.
Je l'avais débloqué en commentant les lignes (dans Akoya-jsbsim.xml)

          <table>
            <independentVar lookup="row">/instrumentation/doors/wings/position-norm</independentVar>
            <tableData>
	    0 1
	    1 0
            </tableData>
          </table>

Je pense qu'il y avait un problème de non-initialisation, que tu as résolu par ton additif dans Akoya-base.xml.

- Pour YASim, le comportement est infiniment meilleur, ou au moins plus prometteur. Peut-être trop d'inertie (par moments on se croirait dans un Boeing !) mais c'est une bonne voie. On a aussi une réelle sensation de mouvements amortis (je ne sais pas pourquoi mais avec cette inertie le ressenti est différent). Je suis sidéré qu'il faille ajouter des ballasts à + ou - 15 m pour obtenir une inertie qui ressemble à quelque chose (même si c'est un peu trop, mais + ou - 5 m ne suffisaient pas). YASim semble avoir un problème avec cette grandeur (ce n'est pas le premier avion avec lequel je ressens ces brutalités de comportement).
Si on adopte cette méthode, le compromis est entre les deux (à évaluer pifométriquement !!)

Par contre, j'ai l'impression qu'il n'y a pas du tout d'effet du souffle d'hélice sur les gouvernes de profondeur et de direction (essaie pour voir arrêté aux freins, au besoin en observant les compressions du train). Quand l'avion arrêté commence à lever la queue sous la traction de l'hélice, tirer le manche est sans effet. Est-ce l'objectif des lignes control="FLAP0EFFECTIVENESS" que tu as ajoutées ?

- Pour l'AERORP de JSBSim, j'ai fait ça un peu vite et c'est sans doute améliorable. Il est connu que des raisons de stabilité, le CG doit toujours être devant le centre des forces aérodynamiques (sauf pour des motifs de manœuvrabilité, par exemple pour des avions de chasse, ou d'économie d'énergie, pour les avions de ligne, qui sont pilotés via un calculateur). Je ne sais pas si c'est la seule solution, mais il est certain que les instabilités du modèle initial ne seraient pas tolérables dans la réalité. Le recul de l'AERORP par rapport au CG est donc une possibilité qui rend le comportement acceptable. Il faudra si possible voir si ces emplacements ne sont pas (ou pas trop) en désaccord avec la géométrie réelle. Je n'ai pas osé avancer le CG pour les raisons bien connues de tendance à se mettre en pylône au freinage. Le mieux serait d'avoir un centrogramme de l'avion (limites de positions du CG).
Je pense aussi que, sur cet avion, la propulsion par l'hélice à l'arrière pourrait aggraver les instabilités.

On pourra essayer ton idée de jouer sur les moments de rappel en tangage et voir ce que ça donne.
[EDIT] j'ai essayé. Donne effectivement un effet un peu similaire en améliorant la stabilité en tangage. Je dirais que le coefficient du couple de rappel en tangage dans le FDM était plutôt faible, ce n'est peut-être pas mal de l'augmenter. Mais je crois qu'il va alors falloir remettre un peu d'efficacité à l'elevator, ce qui pourrait redonner une sensation de contrôle difficile (?). Tout ceci interagit. Peut-être un panachage des deux méthodes ? (AERORP et rappel par le plan fixe horizontal)

Attention, ce n'est pas parce que j'ai une (modeste) expérience du pilotage que je suis une référence, d'autant plus que ces réglages reposent sur des critères non quantitatifs. Ma contribution peut peser, mais d'autres avis sont à prendre en compte.

Ton fichier mixture.nas agit aussi dans le JSBSim (au moins dans la version 1.0.7 que Didier m'a envoyée). Solution probable : l'appeler depuis Akoya-yasim-cnf.xml. De toutes façons, il faudra revoir les réglages de ralenti du moteur JSBSim (il cale au ralenti, c'est en principe facile à arranger).
Il faudra peut-être aussi s'interroger sur l'hélice. Tu sembles avoir utilisé Aeromatic, que j'ai souvent vu dans les choux. J'utilise les courbes NACA.

Dernière modification par dany93 (2013-06-17 14:55:35)

Didier1963 · 2013-06-17 10:20:51

Bonjour à tous,

je suis off pour l'instant, cause GROS TRAVAUX !!!!!

Nouvel ordi, bon, c'est tout comme :
- partitionnement (je mavé tronpé, tou mi sur la 1ere, et rien dan lote), donc maintenant 20Go pour le manchot, 4Go pour le swap, 100 Go pour les programmes installés manuellement (/media/programs), 280Go pour mon home sweet home (/home/didier1963), et 280 pour les fichiers développement (/media/devlopment).
- compilation de la dernière version stable de FG;
- install de la dernière stable Blender et Gimp;
- apt-get chromium, wine &co;
- Notepad++ (pour le Xml);
- etc............

Bravo pour le super boulot sur les FDM's !!

Lionel, si tu as des liveries, essaie d'attendre un peu. Je doit modifier le coté gauche pour faire de la place pour les deux faces de la gouv de direction.
Je me suis permis de refaire tes liveries avec la nouvelle dispo car je tiens à ce qu'elles soient dans la dernière version.

Désolé de vous laisser tomber pendant le week-end, réunion de famille où c'était le seul moment où je pouvait voir tout le monde.
Hein? Bien sur que j'ai parlé de l'Akoya !!! Ça occupe plus de la moitié de mon temps libre et ça me passionne !!!

A+
ou à ce soir si tout va bien................

Dernière modification par Didier1963 (2013-06-17 11:09:31)

F-GTUX · 2013-06-17 18:26:24

Un mot vite fait : oui, le mixture.nas de la 1.0.7 n'est pas le bon pour le FDM jsbsim. Dany93, je t'envoie le bon, il détecte le type de FDM et s'adapte en conséquence.
Oui, l'hélice est faite par aeromatic, avec un peu de réglage sur le diamètre (pas représentatif) pour avoir le bon régime de rotation. Je n'ai pas d'expérience dans l'utilisation des courbes NACA, mais je veux bien apprendre.
A bientôt !

dany93 · 2013-06-17 23:01:39

Merci, bien reçu ton mixture.nas modifié. Cependant, il est plus efficace et plus économique de l'appeler depuis Akoya-yasim-cnf.xml. Je trouve cette subdivision existant dans tous les avions d'Emmanuel très astucieuse. Ainsi, tu évites l'instruction

if (getprop("/sim/flight-model") == "yasim")

pour YASim, et ainsi JSBSim n'a même pas à lire ce fichier avec condition jamais satisfaite.

Pour les courbes hélices NACA, il faut lire (le début de...) ce REPORT No. 640. Il donne les coefficients permettant à FG de calculer la traction, la puissance absorbée (et le rendement, non demandé par FG mais pouvant servir de vérification ou inversement de donnée primaire quand on a bien tout compris). Ceci en fonction d'une variable réduite sans dimensions J = V/nD (vitesse, nombre de tours, diamètre hélice). Ce sont les tables que tu trouves dans le fichier propeller.xml. Le tout pour des hélices à 2 , 3 ou 4 pales, paramétré avec l'angle de calage. C'est essentiellement pour un (ou deux) profil(s) courant(s) mais je trouve que ça marche bien (voir DR400 JSBSim, Cap10B et C JSBSim, DC3 JSBSim hangar PAF). Je n'aurais jamais pu (re) faire l'hélice à pas variable et mise en drapeau du DC3 si je n’étais pas entré dans cette compréhension.
J'en suis venu là à l'occasion du DR400 (Guillaume les utilisait), et j'en suis très content. Pour prendre le pire, le Skyranger ne décollait même pas avec les tables Aeromatic. J'ai l'impression qu'Aeromatic peut être particulièrement faux pour les petites motorisations. De plus, comme tu le mets en commentaire dans le fichier, il ne fait même pas la différence en fonction du nombre de pales. Cette démarche évite d'être pieds et poings liés devant des tables qu'on ne maîtrise pas.

Dernière modification par dany93 (2013-06-18 09:50:58)

Helijah · 2013-06-18 08:07:00

Salut à tous

Alors en fait vous aurez peut être remarqué que dans mes fichiers -set il y a (pour le c460 dans l'exemple) :

<!-- <PropertyList include="c460-jsbsim-cnf.xml"> -->
<PropertyList include="c460-yasim-cnf.xml">

Mon idée au tout début était de ne faire de tord à personne et de bien séparer les JSBsim et les YASim mais en ne gardant qu'un seul -set puisque de toute façon on ne vole JAMAIS avec les deux en même temps. Soit on vole en YASim, soit on vole en JSBSim (ou autre d'ailleurs )

Ainsi il est possible d'avoir un ....-yasim-cnf pour YASim et un ....-jsbsim-cnf pour JSBSim en ayant un seul -set pour les deux. Mais j'ai l'impression que personne n'a compris le principe

Il suffisait de simplement changer la ligne e remarque dans le -set pour passer de l'un à l'autre.

Bien sur depuis j'ai totalement abandonné l'idée de faire du JSBSim. Voir le DR400, par exemple, se poser sur l'eau est tellement ridicule

Je ne reviendrais pas sur les explication de l'abandon de JSBSim quoique...... Mais une chose est sure, JSBSim est une TRES mauvaise idée de toute façon. Certe YASim a des lacunes, mais il reste ce qu'il y a de mieux pour FG.

Amicalement Emmanuel

dany93 · 2013-06-18 09:40:37

Tout en profitant de ton organisation (que je trouve très bien), je préfère la séparation en deux yasim-set et jsbsim-set car elle propose un accès direct, au moins du lanceur FGRun, pour les utilisateurs (sûrement nombreux) qui n'ont pas l'envie ou la connaissance (bien qu'ici ce soit très simple) pour entrer dans les fichiers. Et je ne vois pas d'inconvénient.

Dernière modification par dany93 (2013-06-18 10:24:49)

Didier1963 · 2013-06-18 10:36:26

Dany, Lionel,

je me posait justement la question, point de vue développement, ne serait-ce pas plus facile de faire deux versions dans chacune leurs dossiers?
Ça éviterais les complication de conflit entre les deux, non?
Par contre, comme je n'y connaît encore pas grand chose (j'ai pas mis "rien car j'ai commencé à y mettre le nez aussi bien Yas que Jib), vous faut-il des autre versions pour les fichiers instrument?

dany93 · 2013-06-18 13:12:06

Aucune solution n'est parfaite.

Versions séparées :

- pas de conflits, simplicité, clarté (évidemment).
- MAIS (gros mais) obligation de répercuter (recopier) une amélioration d'une version sur l'autre. A la longue, c'est fastidieux.

Version unique :

Parfois, difficultés , exemples :
- animation bille : pas le même facteur (facile à régler avec <condition>)
- compression trains : idem, plus qq fois dysfonctionnement s'il y a offset ou interpolation car le décalage de zéro se répercute d'une condition à l'autre au lieu d'être non pris en compte (j'ai eu le problème avec compression trains et orientation pales hélices DC3) .
- gestion carburant différente (tout le système) .

Remèdes :
- animations avec <condition> (mais dysfonctionnement si des offsets sont nécessaires),
Ces problèmes d'offset peuvent être largement amoindris voire évités si l'avion est bien conçu lors du dessin 3D (bonnes origines pour les positions).
- une couche de nasal se terminant par une propriété commune créée exprès,
- fichiers séparés, seulement ceux nécessaires, appelés sélectivement par yasim-set ou jsbsim-set (c'est là que cette organisation est très appréciable).
Je crois qu'il y a toujours une solution, mais c'est assez galère quand on ne domine pas bien.

Les instruments courants (anémomètre, altimètre, vario, turn, jauges huile essence,...) peuvent être communs sans problème. S'il y a exception, elle est rare et ne me vient pas.

Le choix de base est le développement ou non de deux FDM. Celui-ci fait, j'ai l'impression que la tendance est à la version unique (bien que j'aie parfois piqué des crises avec ça).

J'en oublie sûrement, mais il y aura bien qq'un pour me compléter ou me corriger. Que cette réponse serve de démarreur...

Dernière modification par dany93 (2013-06-18 13:48:38)

Didier1963 · 2013-06-18 13:38:17

T'as pas mis le fichier Nasal pour le démarreur?

Bon, elle est pas drôle?

Donc, je vote pour garder la situation actuelle, deux FDM dans le même dossier.
En même temps, c'est facile à dire pour moi, c'est vous qui vous tapez le plus gros du boulot.

Si j'ai bien compris pour la partie 3D,
- point de référence (origine blender) des ailes, au centre de l'axe de rotation (au milieu de sa longueur et au centre de son diamètre);
- -- // -- des volets et ailerons, au centre de sa longueur et centre du diamètre de l'arrondi du bord d'attaque;
- -- // -- du fuselage, au CG (là, comme je connaissait pas je l'ai mis au pif, en vue de haut au 1er tiers de la corde en partant du bord d'attaque, et en vue de côté, arbitrairement au centre du fuselage, mais en y réfléchissant, ce serait plus probablement un peu plus près des ailes, donc au 1er tiers du fuselage en partant du haut.
- -- // -- des instrument à aiguille, là ou l'aiguille principale est censé pivoter (légèrement décalé de 0.001x, pour un instrument modéliser pour être incorporé en standalone).
- -- // -- des autres instruments, au centre en hauteur et largeur, à l'endroit qui correspond à la surface du tableau de bord qui va le recevoir pour la profondeur.

J'ai bon M'sieur! ou j'ai encore dit une c...........ie?

[EDIT]

pour la "chandelle du freinage", il faudrai que je vérifie (une foi que j'aurai re-compilé FG), mais il se peux que je n'ai pas mis les trains principaux assez vers l'avant, ni assez incliné en négatif vers l'avant. Donc, du coup, points de contact trop près du CG, et cela à enduit Lionel d'erreur! (haaa, non, INDUIT en erreur!!).

Dernière modification par Didier1963 (2013-06-18 13:42:54)

Helijah · 2013-06-18 13:40:37

Salut Dany

L'autre gros inconvénient des doublons c'est l'alourdissement du dossier Aircraft à un moment ou tout le monde cherche à le simplifier. Et que dire de GIT si tout les avions se retrouvent en double dossiers ou plus (il ne faut pas oublier les autres FDM ).

Pour le reste ce n'est que l'une des raisons qui m'ont fait abandonner JSBSim. Le non respect des normes du logiciel hôte. En effet JSBSim est un programme externe qui n'a aucun rapport avec FG au départ. Il n'a été ajouté que plus tard. Mais ce faisant il a imposér SES conditions pour certaines choses (bille, compression etc...) en ne respectant absolument pas l'existant du logiciel hôte. Que cela arrive au départ, je l'accepte sans soucis, mais quand on arrive en version 2 JSBSim et que tout est encore comme avant c'est tout simplement un manque de respect évident des auteurs de JSBSim pour FG. Je l'ai déjà écrit à mainte reprises. JSBSim est un excellent produit, un travail de fou, mais qui ne fait que reprendre tout ce qui a été fait ces 30 dernières années. Et pire que tout, JSBSim utilise FG pour être amélioré mais se fout totalement des conséquences pour FG et ses utilisateurs (voir le passage de JSBSim 1 à JSBSim 2 qui a rendu tout les avions JSBSim obsolètes et inutilisables... heureusement qu'ils ne sont pas nombreux. Mais nombreux ici n'ont pas connus ce passage Nous verrons bien au passage à JSBSim 3 lol )

Amicalement Emmanuel

dany93 · 2013-06-18 14:33:39

Helijah a écrit :

L'autre gros inconvénient des doublons c'est l'alourdissement du dossier Aircraft à un moment ou tout le monde cherche à le simplifier. Et que dire de GIT si tout les avions se retrouvent en double dossiers ou plus (il ne faut pas oublier les autres FDM ).

Même si j'ai mon opinion quant au choix du FDM (et je me suis aperçu que les pilotes réels de FG que je connais comme tels ont fait ce même choix), je respecte le choix de Didier d'avoir voulu inclure les deux. Et je ne cherche pas à attiser chez toi ce sujet maintes fois développé, ce n'est pas l'endroit pour se bagarrer. Ceux qui veulent se faire une opinion peuvent rechercher dans les forums FR et US. Je n'ai pas connu ces péripéties historiques que tu rapportes, mais c'est effectivement regrettable.

Je suis d'accord, je vois avec déplaisir la taille des dossiers avions augmenter. D'ailleurs plutôt à cause d'une inflation 3D.

Le question est celle de Didier, préalable : deux FDM ==> préconises-tu un ou deux dossiers ? (plutôt deux si on suit ton argument taille de dossier ?)

Dernière modification par dany93 (2013-06-18 14:49:52)

Helijah · 2013-06-18 17:00:11

Dany93 a écrit :

plutôt deux si on suit ton argument taille de dossier ?

Et bien non justement. Un seul dossier avec les deux versions dedans. Quand je parle d'alourdissement, comme je l'ai écrit d'ailleurs, je parle du dossier Aircraft, pas des dossiers des avions.

Deux versions c'est 85% des fichiers en doublons dans deux dossiers séparés pour seulement 15% de fichiers spécifiques. (je simplifie sans vraiment compter, mais je ne dois pas être loin du compte). Imaginons un dossier de 100 Mo c'est donc 85 Mo en plus pour seulement 15 Mo de spécifique. Autant ajouter ces 15 Mo dans le dossier d'un seul avion et gagner ainsi 85 Mo

J'ai rapidement associé 15% au fichiers ...-set.xml (puisque tu préfères l'avoir aucun problème pour moi ), le ...-jsbsim-cnf.xml, le ...--jsbsim.xml et tous les xml d'animations spécifiques à JSBSim (voir les fichiers Nasal permettant de mélanger les deux facilement).

Quand au choix de JSBSim ou YASim tu n'a pas l'argument qui tue car j'ai le même dans l'autre sens Des pilotes des vrais qui préfèrent YASim à JSBSim. D'ailleurs, même si certains ne veulent pas le comprendre et déforment mes propos sans retenue, je le répète JSBSim est excellent. Simplement YASim et JSBSim font la même chose avec un avantage pour YASim car il crée lui même les tables nécessaires via un pseudo tunnel virtuel là ou JSBSim utilise des tables pré définies (et comme chacun sait, une mesure quel qu’elle soit est fausse à partir du moment ou elle est prise). JSBSim reste l'idéal et le must pour un jeu..... Mais FG n'est pas un jeu. Du moins ce n'est pas l'optique choisie au départ par ses créateurs. Que d'autre veuillent changer cela est une autre histoire. YASim comporte bien des défaut aussi, mais il reste LA seule réelle solution d'avenir que nous ayons sous la main en attendant mieux.

Amicalement Emmanuel

dany93 · 2013-06-18 17:57:25

Même si ma réponse était moins nette, ceci conforte Didier dans son choix : "Un seul dossier avec les deux versions dedans". Pas de torture.

Didier,

Pour la mise en chandelle au freinage, c'est un problème que j'ai rencontré sur tous les avions à train classique de FlightGear. C'est un danger dans le monde réel, mais je ne sais pas si FG exagère. En attendant, il faut limiter le freinage dans les FDM car avec "B" c'est 0 ou 1. Maintenant, si tu arrives à améliorer en ajustant les positions des roues (pas facile en l'absence de plans)...
Ce comportement rend encore plus important la prise ne compte du souffle d'hélice sur les gouvernes.

Didier1963 · 2013-06-18 18:08:29

OK,
je regarderai ça plus tard, à l'occasion.
Je pense que si mes trains sont trop hauts et pas assez en avant et/ou incliné, forcément la force du poids des masses passe trop près du CG.
Donc, dès que j'aurai amélioré le reste, je reviendrai dessus en espérant avoir eu un peu plus de détails du côté de là ou tu sait (qui se font d'ailleurs tirer l'oreille pour la réponse, en même temps, pas de nouvelles bonnes nouvelles).
Pour l'instant je n'ai que les vidéos et quelques rares vues. Quoi que sur les vidéos, à pare l'effet de lentille, c'est filmé du dessous pendant la sortie et la rentrée des trains.

Helijah · 2013-06-18 20:19:06

dany93 a écrit :

Pour la mise en chandelle au freinage, c'est un problème que j'ai rencontré sur tous les avions à train classique de FlightGear. C'est un danger dans le monde réel, mais je ne sais pas si FG exagère. En attendant, il faut limiter le freinage dans les FDM car avec "B" c'est 0 ou 1. Maintenant, si tu arrives à améliorer en ajustant les positions des roues (pas facile en l'absence de plans)...
Ce comportement rend encore plus important la prise ne compte du souffle d'hélice sur les gouvernes.

Hum Dany,

Voici un sujet intéressant Ne pourrait on pas assigner une propriété différente au freinage et obtenir quelque chose ressemblant aux "flaps" mais pour activer les freins. Ainsi avec un appui sur "b" on obtiendrais 0.25 de freinage, puis 0.50, puis 0.75 et enfin 1.0..... enfin si on le fait en 4 divisions. Histoire de mieux gérer le freinage. Après tout, le freinage au pédal (enfin si ma mémoire est bonne) est fonction de l'appui sur les pédales non ?

Amicalement Emmanuel

F-GTUX · 2013-06-18 20:48:23

C'est vrai que j'aurais pu faire deux mixture.nas différents et appeler l'un ou l'autre. Pour autant, celui-ci fait quand même des choses en jsbsim, et le test n'est appelé qu'une fois au lancement. Un fichier de moins dans le dossier, puisqu'on en parle !
Quant au débat yasim vs jsbsim, ce sera sans moi : il y a de bons arguments des deux cotés, c'est bien pour ne pas rentrer là-dedans que je bricole avec les deux. Sur les jets, yasim réclame justement un peu plus de bricolage pour modéliser des différences de comportement en transsonique, mais on peut quand même faire des choses. Pour l'Akoya, il n'y a pas de raison qu'on n'arrive pas à un truc sympa en yasim comme jsbsim.
Amicalement, Lionel.

Didier1963 · 2013-06-18 21:08:36

haaaaa, merci Lionel, on va pouvoir passer le mur du son acec l'Akoya!!!

Hein? C'est pas ça que tu as dit?

Ha bon, tantpis!

Dernière modification par Didier1963 (2015-03-19 21:04:04)

dany93 · 2013-06-18 23:03:50

Helijah a écrit :

Ne pourrait on pas assigner une propriété différente au freinage et obtenir quelque chose ressemblant aux "flaps" mais pour activer les freins. Ainsi avec un appui sur "b" on obtiendrais 0.25 de freinage, puis 0.50, puis 0.75 et enfin 1.0..... enfin si on le fait en 4 divisions. Histoire de mieux gérer le freinage. Après tout, le freinage au pédal (enfin si ma mémoire est bonne) est fonction de l'appui sur les pédales non ?

Bien sûr (exactement comme sur une voiture).
Ce serait effectivement pas mal. Comme ça, de but en blanc, je ne vois pas comment faire. Pourtant, les freins peuvent être progressifs avec un palonnier à freins (property-scale). La puissance de freinage est donc réglable dans FG.
Avec le système actuel, on se débrouille (parfois dangereusement) en appuyant sur b par touches brèves.
L'appui sur b seule ne suffirait pas, car il faut aussi pouvoir décrémenter et relâcher. Et ton fonctionnement laisse entendre un freinage maintenu, et non par appui-relâchement. On pourrait aussi imaginer deux touches non affectées, une pour incrémenter, une pour décrémenter, et l'appui sur b comme d'hab. Pas simple... et pas forcément pratique pour ceux qui n'ont que deux mains. Ou un freinage dont la puissance ne monterait que progressivement (en 0.5 à 1 sec), la touche b seule suffirait et la gestion serait plus facile.
A réfléchir. Les idées sont bienvenues...

Lionel,

Dans jsbsim, mon opinion est que tu peux économiser le mixture.nas. Je ne sais pas pour l'Akoya, mais je n'ai pas encore vu d'ULM avec réglage de richesse. Quoique l'Akoya se classe dans les LSA, ce qui est un cran au-dessus. Cependant, à ma connaissance (pas beaucoup plus loin que FG...), dans les avions avec réglage de richesse, celui-ci n'est pas automatique comme ton mixture.nas, mais manuel (c'est un réglage du genre "au mieux de..."). Je dis bien : à ma connaissance. A voir pour l'Akoya.
Ces appareils en VFR peuvent réglementairement aller jusqu'à 19500 ft, mais on ressent le manque d'oxygène autour de 12500 ft et en pratique on dépasse rarement les 5000 ft.

Pour les FDM, c'est déjà assez bien parti pour arriver à un truc sympa dans les deux. Ça fait deux fois plus de travail c'est tout.

Dernière modification par dany93 (2013-06-18 23:09:09)

F-GTUX · 2013-06-19 19:36:04

Pour ce que j'ai pu lire du Rotax 912 ULS, il n'est pas à injection électronique, ce que je croyais au départ : ça, c'est le Rotax 912iS, sorti l'an dernier. Ca me fait drôle, moi qui suis dans l'électronique automobile, pour laquelle les moteurs à essence sont massivement électronisés depuis plus de 20 ans (dépollution oblige). Mais ses carburateurs sont quand même compensés en altitude, ce qui a l'air confirmé par l'absence de commande de richesse dans le cockpit, sauf erreur de ma part.

Pour autant, je pourrais effectivement économiser le mixture.nas en jsbsim, en intégrant le calcul de la commande de richesse dans le FDM, c'est vrai : FG a pas mal d'avions jsbsim faits comme ça. Pour yasim, je ne saurais le faire que si la variation était linéaire (ou peut-être quadratique) avec l'altitude, ce qui n'est évidemment pas le cas. Edit : et si j'avais réfléchi, je n'aurais pas écrit ça : en raisonnant avec la pression, ça devient beaucoup plus facile !

Dernière modification par F-GTUX (2013-06-20 05:36:31)

Didier1963 · 2013-06-19 22:10:36

Je viens de comprendre l'expression "planer à 2000".
Heureusement que je ne me suis pas attaqué tout seul au FDM!!
Car quand je vous lis, il y a bien des choses que je comprend sans pour autant savoir les appliquer, mais pour le reste................ je plane (et pas besoin de FDM là !)

Lionel,
J'ai enfin un début de commencement de config pour bosser. Mis à part que je ne suis pas encore arrivé à compiler FG 2.11. J'ai donc installé la version de la logithèque de Bouboune 13.04. (tu as du voir dans quel état était mon PC il y a deux jours, forcement cela ne m'a pas avancé).
Je suis entrain de finir le 1er essais d'amélioration de l'aile (des ailes, puisque je vais utiliser la fonction miroir pour obtenir l'autre).
je te passe ce que j'ai vendredi soir, où que j'en soit.
Il y aura du changement sur les points de référence des ailes, puisque, sauf erreur, je les ai retrouvés en y=0 (je vérifie après avoir modifié le fichier qui va bien pour voir si elles pivotent correctement). Et comme j'ai mis 1° de dièdre, je m'attend a des surprises au 1er essais.

Je veux bien que tu me dise comment animer la petite trappe d’accès à la commande de verrière extérieur (pas d'ouverture brusque 0-1, mais quelque chose de progressif comme le mouvement des ailes.
Je pensais à utiliser la même chose que les ailes, mais je n'ai pas eu le temps de regarder de près comment tu avait fait avec le fichier Nasal, et si on pouvait le réutiliser ou alors en faire un autre spécifique.

Donc devoirs de fin de semaine:
- Ailes;
- Commande extérieur de verrière (avec logement, trappe et bouton, ou clef);
- Commande intérieur de verrière sur accoudoir pilote;
- Commande de mouvement ailes derrière le pilote
- Trappe et logement
- et si j'ai le temps, commande pour la surprise et animation de celle-ci

dany93 · 2013-06-19 22:31:05

Lionel,

Dans ce cas, fais ce qui te semble le mieux adapté (compensation en nasal si ça te semble le bon fonctionnement et que c'est le plus simple). Ton activité professionnelle fait que tu en connais plus que moi là-dessus. La question que je me pose est de savoir à quel point c'est important pour les altitudes normalement pratiquées avec ce genre d’appareil (ce qui expliquerait peut-être que je n'ai jamais vu ce réglage sur les ULM classiques).
Je proposais de supprimer le mixture.nas pour de simples raisons de propreté s'il était inutile, mais on n'est quand même pas à 15 lignes de nasal près...

Didier1963 · 2013-06-20 08:40:08

D'autant plus que si j'ai bien lu, le Rotax 912 ULS-fr est équipé d'un boîtier de régulation. Peut-être que au lieu de jouer sur la richesse du mélange, on joue seulement sur l'allumage (avance ou retard allumage suivant les besoins).
Pour le mouvement de la trappe (et celui de la surprise), pourrait-tu être un peu plus précis et me donner les grandes lignes (ou un lien de doc) qui me permette d'essayer de le faire sans aide?

Merki

dany93 · 2013-06-20 09:36:31

Le Rotax 912 ULS est équipé d'un réducteur. Je ne sais pas ce que tu entends pas "boîtier de régulation".
L'ajusteur de pas hydraulique ne nous concerne pas puisque l'hélice est à pas fixe.
On joue sur l'avance à l'allumage en fonction du régime (comme tous les moteurs) mais à ma connaissance ce n'est pas un remède à l'altitude.
En revanche, il est équipé de deux carburateurs à dépression constante ce qui, si je comprends bien, va dans le sens de Lionel (mais je ne sais pas comment).

Dernière modification par dany93 (2013-06-20 09:46:01)

Didier1963 · 2013-06-20 11:47:57

Sur le 912 ULS-fr, il y a un boîtier électronique pour gérer la vitesse moteur dans diverses condition.
L'Akoya est équipé de l'option CSC-1P, qui est un régulateur de vitesse constante (Constant Speed Controler) de chez Smart Avionics.
Mes connaissances en aéro sont très limitées, mais je pense que le CSC doit probablement jouer un rôle dans ce cas de figure.
Mes connaissances en mécanique un peu, aussi, je n'ai qu'un CAP méca-auto et n'ai pratiqué que 5 ans en poids lourd et engins.
Pour ce qui est d'un éventuel réglage de richesse, je poserai la question à un de ceux qui à dompté la bête. Ça fera l’occasion de demander des nouvelles.

Daniel, toi qui a la licence qui va bien, a combien la limite maxi en altitude pour les ULM et LSA?

FlightGear - Création d'avions et autres / Creation of aircraft and other

#151 2013-06-16 10:15:15

Re : LISA airplanes

#152 2013-06-16 21:52:39

Re : LISA airplanes

#153 2013-06-17 10:20:51

Re : LISA airplanes

#154 2013-06-17 18:26:24

Re : LISA airplanes

#155 2013-06-17 23:01:39

Re : LISA airplanes

#156 2013-06-18 08:07:00

Re : LISA airplanes

#157 2013-06-18 09:40:37

Re : LISA airplanes

#158 2013-06-18 10:36:26

Re : LISA airplanes

#159 2013-06-18 13:12:06

Re : LISA airplanes

#160 2013-06-18 13:38:17

Re : LISA airplanes

#161 2013-06-18 13:40:37

Re : LISA airplanes

#162 2013-06-18 14:33:39

Re : LISA airplanes

#163 2013-06-18 17:00:11

Re : LISA airplanes

#164 2013-06-18 17:57:25

Re : LISA airplanes

#165 2013-06-18 18:08:29

Re : LISA airplanes

#166 2013-06-18 20:19:06

Re : LISA airplanes

#167 2013-06-18 20:48:23

Re : LISA airplanes

#168 2013-06-18 21:08:36

Re : LISA airplanes

#169 2013-06-18 23:03:50

Re : LISA airplanes

#170 2013-06-19 19:36:04

Re : LISA airplanes

#171 2013-06-19 22:10:36

Re : LISA airplanes

#172 2013-06-19 22:31:05

Re : LISA airplanes

#173 2013-06-20 08:40:08

Re : LISA airplanes

#174 2013-06-20 09:36:31

Re : LISA airplanes

#175 2013-06-20 11:47:57

Re : LISA airplanes

Pied de page des forums