RobinDR-400 jsbSim 120cv

Bonsoir à tous,

J'aimerai énormément modifier le calage altimétrique de l'altimètre pour le mettre "à l'européenne" c'est à dire en millibars.
Actuellement il est en inch de mercure hors en France je ne vois que des altimètres en millibars et le traffic aérien ce fait en millibars.

Ma question est : quelle est la formule pour convertir le calage inHg en milliBars ? car dans FG il n'y a que la valeur en inHg...

Amicalement,
Clément

http://www.google.fr/#hl=fr&sclient=psy-ab&q=in+hg+en+bar&oq=in+HG&aq=2&aqi=g3g-v1&aql=&gs_sm=1&gs_upl=0l0l1l1784l0l0l0l0l0l0l0l0ll0l0&gs_l=hp.1.2.0l3j0i15.0l0l1l1784l0l0l0l0l0l0l0l0ll0l0&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb&fp=c02d96e86c63b9ce&biw=1428&bih=922

Amicalement.

arff... pourtant j'avais cherché... mais j'avais orienté ma recherche en anglais.
Pour ceux qui veulent le savoir : inHg x 33.85 = millibars

Bon ben y'a plus qu'à
Merci Ernest !

Ah et tout de même : personne n'y voit d'objection d'utiliser des mesures européen pour cette avion (Français) ?

Amicalement,
Clément

Je suis tout à fait pour utiliser des hPa aussi. C'est la mesure utilisée en France en aéronautique et les altimètres que j'ai croisés sont tous en hPa.

Et voilà, j'ai deux fiches de pesée: l'une d'un avion neuf, léger (qui a pris 19 kg entre la pesée que j'ai prise et la dernière en date!); l'autre sur un avion un peu plus ancien et plus lourd. Je vais me base sur le lourd, il a l'air plus représentatif de la majorité des appareils.

PS: ça ne dérange personne si je mets toutes les unités que je croise dans le système international? JSBSim calcule en unités impériales malheureusement, mais on peut entrer les données dans une autre unité avec unit="unité" dans les balises.

Oui, je pense a priori que les unités internationales seront beaucoup plus faciles à comprendre et moins sources d'erreurs. Surtout si on peut faire tous les raisonnements et observations des grandeurs dans ces unités, en ignorant les unités sous-jacentes. Elles sont d'ailleurs déjà utilisées dans d'autres fichiers (interior.xml, panel.xml) pour le positionnement des instruments et autres objets.

Aïe, l'origine du modèle de vol est décalée de 180 pouces (4,572 m). Du coup tout est décalé par rapport à Blender et on ne s'y retrouve plus… Est-ce qu'il y a un but à ce décalage? Sinon, je préfère encore reprendre toutes les longueurs, ce sera plus simple à comprendre ensuite.

180 pouces, rien que ça...
C'est historique et j'ignore pourquoi. N'ayant pas de logiciel de dessin, je n'ai pas touché aux origines de coordonnées (Emmanuel ? Guillaume CHAUVAT ?).
C'est peut-être aussi pour ça que j'avais du mal à comprendre, et que les yeux du pilote étaient "placés" dans dr400-jsbsim.xml, puis "offsettés" dans interior.xml ?
En fait, je me suis contenté de reprendre petit à petit des points du FDM qui ne me convenaient pas à cause du comportement, et quelques animations.

J'ai fini de remettre tout au bon endroit, sans offset, et d'adapter les valeurs à celles du manuel de vol en unités métriques. J'ai presque fini d'ajouter les masses pour les quatre occupants et les bagages, je teste et ensuite j'envoie sur le dépôt git. Il ne restera «plus que» l'aérodynamique ensuite .

C'est déjà un travail important de clarification et de mise en place qui permettra d'être sur une bonne base .
Merci, Guillaume.

F-JJTH a écrit:Des petites nouvelles de mon côté :

- Le DR400 ne peux plus se poser sur l'eau ! Niark ! Comme ça plus personne ne pourra dire "tiens pose toi sur l'eau pour voir"

Amicalement,
Clément

exellentissime nouvelle !!!!!
comment as-tu résolu ce pb ???
peut-on l'étendre sur tous les modèles ???
amicalement
georges

J'ai testé, c'est une bonne idée.
En revanche, Clément, je ne sait pas si c'est lié mais le souci est que le moindre petit trou fait "valser" l'avion comme s'il se crashait.

Exemple à LFHU où il y a une petite faille entre les batiments



Ensuite ça donne ça



Sinon, quel bonheur de voler avec cet avion !!!

Amicalement,

Voilà, c'est pushé. Les masses sont modifiables dans equipment -> fuel and payload. Par contre, la modification des données géométriques erronées (notamment les bras de levier des empennages et la position du centre de gravité) ont cassé le bon comportement en vol de l'avion. Je vais donc corriger l'aérodynamique pour que ça redevienne correct. Il faudra aussi vérifier le moteur et l'hélice une fois que l'aérodynamique sera bonne pour obtenir les bonnes vitesses.

Avec un peu de chance il redeviendra volable dès ce soir, et désolé pour le cassage provisoire de modèle de vol … J'aurais peut-être dû attendre d'avoir tout corrigé en fait.

pour ton probleme jm c'est normal la roulette avant doit prendre 5cm de hauteur en un temps tres tres tres petit, donc on compression du train avec un variation tres grande en un petit temps ce qui fgait avec les formules de jsbsim que le train rebondit d'une façon gargantuesque et te propulse en l'air, c'est de la physique dans un ordinateur lol..

Guillaume, peux-tu nous en dire plus sur les fonctions de cet inter en rouge?.

C'est une balise de détresse. L'interrupteur sert à l'éteindre, à la tester (attention, ça appelle les secours…) et sinon elle est en position auto, je crois qu'elle s'allume en cas de crash.

OK, merci.

algajojo a écrit:
comment as-tu résolu ce pb ???
peut-on l'étendre sur tous les modèles ???
amicalement
georges

Pour palier à ce problème j'ai ajouté ça dans le dr400.nas :

Code:


terrain_survol = func {
  var lat = getprop("/position/latitude-deg");
  var lon = getprop("/position/longitude-deg");
  var aircrat_elev = getprop("/position/gear-agl-m");
  var info = geodinfo(lat, lon);
  if (info != nil) {
    if (info[1] != nil){
      if (info[1].solid !=nil)
        setprop("/environment/terrain-type",info[1].solid);
      if (info[1].load_resistance !=nil)
        setprop("/environment/terrain-load-resistance",info[1].load_resistance);
      if (info[1].friction_factor !=nil)
        setprop("/environment/terrain-friction-factor",info[1].friction_factor);
      if (info[1].bumpiness !=nil)
        setprop("/environment/terrain-bumpiness",info[1].bumpiness);
      if (info[1].rolling_friction !=nil)
        setprop("/environment/terrain-rolling-friction",info[1].rolling_friction);
      if (info[1].names !=nil)
        setprop("/environment/terrain-names",info[1].names[0]);
    }       
  }else{
    setprop("/environment/terrain",1);
    setprop("/environment/terrain-load-resistance",1e+30);
    setprop("/environment/terrain-friction-factor",1.05);
    setprop("/environment/terrain-bumpiness",0);
    setprop("/environment/terrain-rolling-friction",0.02);
  }

  if(!getprop("/environment/terrain-type") and getprop("/position/gear-agl-m") < 0.2){
    setprop("sim/messages/copilot", "You are on water !");
    setprop("sim/freeze/clock", 1);
    setprop("sim/freeze/master", 1);
  }
  settimer(terrain_survol, 0);
}

terrain_survol();


On peut utiliser ce code sur tous les appareils sans aucun problème

@Jean-Michel : le comportement que tu décris ne provient pas de la fonction que j'ai mise en place. Comme bibi l'a expliqué : il n'a pas aimé la marche :/ (d'ailleurs avant on avait un trou, maintenant on a une marche ?)

Aujourd'hui j'ai trouvé un truc bizarre sur le DR400-jsbSim : À l'arrêt, avec un vent soutenu, le DR400 bascule sur l'arrière ! Le FDM a dû prendre un coup ? lol

Sinon à part ça :
- Nouveau système électrique
- Lights pris en compte dans le système électrique (sauf pour les cones : impossible car ils utilises un effet)
- Les lights visible en MP
- Nouveau circuit de carburant (relié au circuit électrique)
- Ajout d'une option dans le menu du DR400 pour cacher les lights cone et ne garder que les lights 2D
Il reste encore des choses à faire sur le système électrique... je continuerai plus tard.

Par contre une chose importante : pour la procédure réaliste, il faudrait modifier le FDM pour lui dire que le démarreur n'est pas relié à la propriété "contols/engines/engine/starter" mais à la propriété "systems/electrical/outputs/starter"

Amicalement,
Clément

F-JJTH a écrit:Aujourd'hui j'ai trouvé un truc bizarre sur le DR400-jsbSim : À l'arrêt, avec un vent soutenu, le DR400 bascule sur l'arrière ! Le FDM a dû prendre un coup ? lol

Avant la modification du centrage (vers 18h je crois)? Parce que maintenant, le CG est au bon endroit, plus en avant, et d'ailleurs j'ai eu besoin de beaucoup renforcer la roue avant parce qu'elle supporte beaucoup plus de poids.

Oui c'était avant ta modif, donc c'est normal ?

Oui, le CG n'était pas au bon endroit. Mais du coup j'ai tout cassé et il ne vole plus très bien. Je travaille sur une correction de l'aérodynamique qui devrait rétablir un comportement normal.

F-JJTH a écrit: Par contre une chose importante : pour la procédure réaliste, il faudrait modifier le FDM pour lui dire que le démarreur n'est pas relié à la propriété "contols/engines/engine/starter" mais à la propriété "systems/electrical/outputs/starter"

Je ne comprends pas. Cela n'a rien à voir avec le modèle de vol ? J'ai utilisé cette propriété pour allumer le voyant "Démarreur" (facile à arranger si c'est ça, mais où est la différence ?).

Bravo pour ton script acquatique !

Ça permettrait de couper le démarreur quand la batterie est éteinte, par exemple.

Je pense que la solution serait de redéfinir le raccourci clavier pour 's' et le bouton du démarreur pour qu'ils activent "systems/electrical/outputs/starter". Ensuite, on peut activer "contols/engines/engine/starter" avec du code nasal par exemple.

dany93 a écrit:Je ne comprends pas. Cela n'a rien à voir avec le modèle de vol ?

En Yasim (je prend ça comme exemple parce que je n'y connais rien à jsbsim) on a ça :

Code:


<control-input axis="/engines/engine[0]/cranking" control="STARTER"/>


Cette ligne permet de dire que le démarreur qui lance le moteur sera lancer lorsque la propriété "engines/engine[0]/cranking" est à 1 (true)
Comment dire la même chose à jsbsim ?

@Guillaume: je voudrais éviter d'utiliser une telle solution car si j'ai introduit un système électrique complet c'est pour s'en servir^^ J'espère au moins que l'on peut personnalisé les propriétés de jsbSim ?

On peut presque tout personnaliser, mais peut-être pas ça, je crois que c'est codé en dur. Je trouve que c'est ce qui manque à la gestion du moteur d'ailleurs: les moteurs utilisent beaucoup moins de propriétés configurables que le reste.

En gros, FG envoie directement la propriété du démarreur à JSBSim, qui l'envoie directement au moteur.

J'ai envoyé une nouvelle gestion des immatriculations à Christian, pour remédier aux superpositions qui arrivaient avec certaines livrées intégrant leur propre immatriculation pour des raisons esthétiques.

Deux modes d'immatriculation cohabitaient, dont l'utilisation simultanée créait un superposition :
- une possibilité d'immatriculation "texte" (anciennement modifiable par le menu Robin DR 400 > Immatriculation), normalement utilisée pour les livrées Default, Martin, Reinette uniquement,
- des immatriculations "intégrées" à certaines livrées (F-GXGL, F-HBIZ, G-BALF, G-CEKE, HB-KFW), non modifiables.

De plus, en mode multijoueur, cette intervention m'a fait réaliser qu'on pouvait faire figurer l'indicatif multijoueur personnel (callsign) à la place de l'immatriculation "texte". N'ayant pas pratiqué le multijoueur auparavant, je ne sais pas si d'autres avions exploitent cette possibilité. Elle peut être pratique si on se donne rendez-vous pour voler en formation.

Le fonctionnement est maintenant le suivant :
Les immatriculations ou votre indicatif multijoueur sont désormais gérés automatiquement.

- En mode "normal" (non multijoueur) :
L'immatriculation "texte" s'affiche à l'extérieur de l'avion et à l'intérieur (au tableau de bord) pour les livrées Default, Martin, Reinette. Cette immatriculation peut être individualisée par livrée, mais de manière non directement accessible (il faut aller dans les fichiers Liveries .xml). Elle est actuellement à F-GHYQ.
Pour les autres livrées (F-GXGL, F-HBIZ, G-BALF, G-CEKE, HB-KFW), l'immatriculation intégrée à la livrée s'affiche à l'extérieur et rien ne s'affiche au tableau de bord.

- En mode "multijoueur" :
Vous activez le mode multijoueur et vous entrez votre indicatif multijoueur avant de lancer le simulateur; cet indicatif figure ensuite automatiquement à la place de l'immatriculation "texte" à l'extérieur et au tableau de bord pour toutes les livrées à immatriculation "texte" (Default, Martin, Reinette).
Les immatriculations intégrées aux livrées ne sont pas impactées (voir mode "normal").

(Une explication un peu longue pour quelque chose qui, en fait, fonctionne tout seul)

[EDIT 13 mars 2012] Avec la version FG 2.6.0 ce système ne fonctionne plus. Il y a eu un changement dans la gestion des propriétés multijoueur à la connexion MP (/sim/multiplay/callsign changeait précédemment avec FG 200, et vraisemblablement avec FG 240, contre /sim/multiplay/online avec FG 2.6.0). Résultat : l'indicatif multijoueur s'affiche en permanence pour moi avec FG 260, MP ou pas. Cependant, la Prop ".../online" existant dans FG 240, on peut espérer une solution compatible FG 240 - 260 [/EDIT]

Dany