Tecnam-P92-Echo

J'ai une piste:
Dans le dossier de mes avions, j'ai mis le dossier Intruments-3d de la PAF, et çà fonctionne.
J'avais jusqu'à présent un lien vers

Code:


fgfs-3.7/install/flightgear/data/Aircrafts/Instruments-3d

qui me donnait toujours les dernières versions des instruments en cas de modifs de ceux-ci, puisque je suis toujours à jour.
Vos tests m'intéressent, car j'ai bien peur que dans l'avion de mon hangar les gens ne voient pas ce qui devrait être vu, à savoir la coque noire du Garmin 196.

Bonsoir à tous, bonsoir Christian,

Malheureusement, je te confirme qu'après rechargement depuis ton hangar, la coque du Garmin est grise.

Bonjour Christian,

Tu as mis deux fois la même image. mais on comprend quand même.

J'ai fait un git pull vers 17h, avant ce test.
Pour la texture du Garmin, je crains que tu aies raison.
- Si j'ouvre celui sous (git) fgdata_paf, il est noir.
- Le même Tecnam-P92-Echo, mais copié - collé sous mon dossier personnel, il est gris.

La nuance ne mérite pas de venir à bout de tes cheveux.
Mais je suis comme toi, je déteste ne pas comprendre. Ça laisse la porte ouverte aux pétards à retardement. En plus, c'est fait pour fonctionner, ça doit fonctionner.

dany93 a écrit:Bonjour Christian,

Tu as mis deux fois la même image. mais on comprend quand même.

J'ai fait un git pull vers 17h, avant ce test.
Pour la texture du Garmin, je crains que tu aies raison.
- Si j'ouvre celui sous (git) fgdata_paf, il est noir.
- Le même Tecnam-P92-Echo, mais copié - collé sous mon dossier personnel, il est gris.

La nuance ne mérite pas de venir à bout de tes cheveux.
Mais je suis comme toi, je déteste ne pas comprendre. Ça laisse la porte ouverte aux pétards à retardement. En plus, c'est fait pour fonctionner, ça doit fonctionner.

Non Daniel, l'image montre en haut le dépôt de la PAF (voir les chemins console) vs le chemin de mes avions.



Ce qui est fou dans cette histoire, c'est que si je crée un lien vers Instruments-3d de la PAF, çà ne marche plus, avec en plus des erreurs nasal    .
Je sèche.

Pour le dr400-dauphin, c'est la même limonade, au passage le GPS est beaucoup plus beau en noir (enfin je trouve).

Je crains que çà ne soit pas le bon objet qui est animé lorsque l'on trim:
C'est le -trimprof- qui devrait l'être à la place du -profondeur- non?.
@Christian, j'ai loupé ton post, merci pour ton retour.

Bonsoir à tous, bonsoir Christian,

Voili, voilà ... un Garmin tout noir !...  



Ici :  http://www.mediafire.com/download/2ym2vlbe0tdjd1e/Tecnam-P92-Echo.tar.gz

Attention : Si d'autres fichiers ont été modifiés depuis 18h (heure à laquelle je l'ai téléchargé de ton hangar), ils ne sont pas pris en compte.
Pour info, j'ai rapatrié le Garmin 196 de fg et corrigé les fichiers qui posaient problèmes.

patten a écrit:Je crains que çà ne soit pas le bon objet qui est animé lorsque l'on trim:
C'est le  -trimprof-  qui devrait l'être à la place du -profondeur- non?.

Si les deux objets sont séparés et animables, oui. Attention au sens. Dans la réalité l'élévation du (petit) volet de trim prof fait baisser la (grosse) gouverne de profondeur par action de l'air qui "appuie" sur le volet de trim en volant. Tendance à piquer. L'animation est donc l'inverse de ce qu'on pourrait peut-être penser à première réflexion.
Mais il faut choisir les bonnes propriétés. J'ai souvent rencontré l'animation de l'appendice qui était commandée par le total commande + trim.

Bonjour à tous,

clm76 a écrit:Bonsoir à tous, bonsoir Christian,

Voili, voilà ... un Garmin tout noir !...  

Ici :  http://www.mediafire.com/download/2ym2vlbe0tdjd1e/Tecnam-P92-Echo.tar.gz

Attention : Si d'autres fichiers ont été modifiés depuis 18h (heure à laquelle je l'ai téléchargé de ton hangar), ils ne sont pas pris en compte.
Pour info, j'ai rapatrié le Garmin 196 de fg et corrigé les fichiers qui posaient problèmes.

C'est une solution en effet, d'ailleurs, vu que le Garmin a été developé par Jeep à la même époque que le P92, il était dans l'avion au départ (le Garmin, pas Jeep    ).
Le hic, c'est presque 7Mo de plus, ce qui en soi ne me dérange pas plus que çà, mais il me semble bien que çà avait été discuté ici.
Qu'est ce qu'on fait, on garde?.
Çà vaudrait le coup de faire un Merge request, pour la correction du bug, mais là, je suis largué (barrage de la langue pour un dialogue technique).
Dans l'affirmative, si on garde, quels sont les fichiers impactés (panel.xml et p92-echo-base.xml)?.
Au fait tu peux pusher si on adopte        
Le pire, c'est que le Garmin du dépôt ne change pas de texture si il est rapatrié, par contre, si le dossier complet Instruments-3d est rapatrié, çà fonctionne.    
@Christian:En 2 (allez 3) mots, tu peux éclairer notre lanterne, comment se fait-il qu'un soucis de texture bla bla bla...
@Dany:Oui, l'objet existe.Pour les animations, çà ne me passionne pas plus que çà, les écritures xml, j'y passe du temps que contraint et forcé.
En tous cas, j'aurais au moins appris un truc, je pensais que le trim de profondeur était un mini aileron (ce qu'il est en effet), mais je n'ai jamais réfléchi à son action.
Est-ce que çà durcit les commandes?.
À venir, la même chose sur le gouvernail, pour l’esthétique, et surtout pour être conforme à la réalité.  

Bonjour à tous,

Dans la réalité l'élévation du (petit) volet de trim prof fait baisser la (grosse) gouverne de profondeur par action de l'air qui "appuie" sur le volet de trim en volant

Euh, non !... La gouverne de profondeur est liée par tringlerie au manche. Le trim, pour les petits avions et ULM ne fait que diminuer l'effort engendré par la poussée de l'air sur la gouverne en compensant cet effort par une poussée aérodynamique contraire, ce qui permet de diminuer, voire d'annuler l'effort sur le manche. Ce trim peut être automatique sur certains avions légers, par un système de biellettes liant la gouverne de profondeur et le tab.

Garmin : quelle importance ces 7mo ? Pour Fg, qu'il aille chercher ses fichiers au sein de Fg ou de l'avion ne change rien au fonctionnement. Mais ... si tu veux changer de texture, il y aura problème car le fichier .ac de fg fait appel à son fichier de texture lié. Il faudrait donc aller modifier le fichier .ac dans fg/.../instruments.3d/... et là, à mon avis ce n'est pas bon car tu modifies des fichiers centraux de FG. Donc ... Il vaut mieux rapatrier le Garmin dans l'avion et tu peux alors faire ce que tu veux !...  

C'est aussi ce que je pense, pas de soucis pour moi, çà impacte juste le temps de téléchargement.
J'ai çà en console:
 

Code:

Sorry, qdot doesn't appear to be trimmable
  Trim Results:
          Altitude AGL:    4.7  wdot:  3.22e+01 Tolerance: 1e-03  Failed
           Pitch Angle:  -0.51  qdot: -2.20e-09 Tolerance: 1e-04  Passed
            Roll Angle:    2.7  pdot: -4.02e-08 Tolerance: 1e-04  Passed

  Trim Statistics:
    Total Iterations: 3
    Sub-iterations:
    wdot: 44 average: 14.667  successful:  1  stability: 2
    qdot: 0 average: 0  successful:  0  stability: 2
    pdot: 10 average: 3.3333  successful:  3  stability: 2
    Run Count: 158
Electrical System ... OK

C'est grave ou bien?.

Bizarre, je n'ai aucune erreur ici ...

[EDIT] je vais recharger l'appareil car il y a peut-être des fichiers modifiés par rapport à la version que j'ai. Problème de trim ?

[RE-EDIT] Quelle version est à jour ? Dans ton hangar ou sur Git ?

patten a écrit:
@Dany:Oui, l'objet existe.Pour les animations, çà ne me passionne pas plus que çà, les écritures xml, j'y passe du temps que contraint et forcé.
En tous cas, j'aurais au moins appris un truc, je pensais que le trim de profondeur était un mini aileron (ce qu'il est en effet), mais je n'ai jamais réfléchi à son action.
Est-ce que çà durcit les commandes?.
À venir, la même chose sur le gouvernail, pour l’esthétique, et surtout pour être conforme à la réalité.  

Moi non plus je ne suis pas passionné par l'écriture xml des animations (ni très compétent), d'autant que ceci oblige à rechercher des objets et fichiers créés par d'autres, avec leur logique.
Ma priorité est quand même le FDM.
Ça ne fait rien, je tâcherai de voir ça dans un créneau plus calme (rappelle-moi éventuellement).

Comme expliqué par clm76, cela ne durcit pas les commandes, au contraire cela permet d'annuler l'effort aérodynamique de l'air sur celles-ci, donc de les lâcher sans subir une embardée. Dans des conditions fixées, bien sûr. Même philosophie que dans FG avec notre ressort.

clm76 a écrit:Bizarre, je n'ai aucune erreur ici ...

[EDIT] je vais recharger l'appareil car il y a peut-être des fichiers modifiés par rapport à la version que j'ai. Problème de trim ?

[RE-EDIT] Quelle version est à jour ? Dans ton hangar ou sur Git ?

Tous mes tests sont faits avec la copie conforme du dépôt de la PAF.
Fg est updaté tous le jours chez moi (sources et data), hier la mise à jour m'a parue importante, peut-être que çà provient de là.
Çà n'empêche pas de voler, mais j'aime bien avoir une console "propre", je trouve qu'il manque un peu de rigueur dans Fg-addons, trop d'avions génèrent des warning en console AMA.

Bonjour,

Nouvelle hélice (plus grand pas), ajustements du FDM

Ma référence : Tecnam P92 Echo Classic Deluxe - Flight Manual], cf. photo Clément
PDF page 45/60, moteur 100 ch (912 ULS)
4300 RPM : 165 km/h
5000 RPM : 196 km/h

Mes tests (pleine charge avec copilote, 992 lbs)
4300 RPM : 163 km/h
5000 RPM : 193 km/h

Aussi, j'ai essayé de trouver un compromis pour les pré-réglages des trims au démarrage du simulateur.
Sachant qu'un ULM ne propose en vol que le trim de profondeur (les trims de direction et ailerons : au sol seulement).
Pour nous ce n'est pas un problème, on sait qu'il faut régler le trim en vol, et on sait comment faire.
J'ai pensé à ceux qui font juste connaissance avec l'appareil, voire qui ne sont pas très connaisseurs de FG.
Dans cet esprit, j'ai adopté :
- pour le trim ailerons, une valeur de croisière (4300 RPM, 163 km/h, charge par défaut 852 lbs sans copilote),
- pour le trim profondeur, un intermédiaire entre montée et petite vitesse croisière.

Tout de passe dans le fichier p92-echo-jsbsim-cnf.xml

Code:

 <controls>
      <flight>
          <aileron-trim type="double">0.038</aileron-trim>
          <elevator-trim type="double">-0.15</elevator-trim>
      </flight>
  </controls>

Si vous pensez qu'il vaut mieux changer, c'est facile.

Aussi, Effet de Sol.

patten a écrit:Je crains que çà ne soit pas le bon objet qui est animé lorsque l'on trim:
C'est le  -trimprof-  qui devrait l'être à la place du -profondeur- non?.

Fait, pushé.
Rmq : trim elevator : -2° à +12°. Le -2° ne se voit pas beaucoup.
Aussi : animations ailerons dans le bons sens et aux bons angles, corrections angles pour rudder et flaps.

L'animation de l'ensemble elevator et elevator-trim me turlupine, aucune solution n'est parfaite.

Dans la réalité :
1 - au sol, la manœuvre de l'elevator trim se fait sans changement de position de l'elevator;
2 - en revanche, en vol, la position de l'elevator "relâché" est hors du neutre quand il y a du trim (par action aérodynamique).
La position du trim ne change pas l'amplitude de mouvement de la gouverne de profondeur. Simplement, il la rend plus dure si on cherche à l’écarter de sa position d'équilibre trimmée.

Dans FG :
A - soit on anime l'elevator par

Code:

controls/flight/elevator

et on rend bien le 1, mais le 2. Si le pilote descend de son appareil en vol pour regarder sa gouverne de profondeur (ce qui est totalement imprudent), il la verra au neutre même si elle est trimmée à 100%.
La course visible de la gouverne de profondeur (-1, 0, +1) n'est pas impactée par le trim.

B - soit on l'anime par

Code:

surface-positions/elevator-pos-norm

(ce que j'ai fait), et on rend bien le 2 mais pas le 1 (la position elevator change avec le trim, aussi au sol).
Et effectivement, dans FG, quand le trim est à 100% dans un sens, le manœuvre du manche n'ajoute plus rien. Ce qui est cohérent avec une position en butée de l'elevator. Mais en plus dans ce cas, la course de l'elevator est limitée à 0 pour l'autre extrémité. Ce qui est un peu gênant visuellement.
C'est fromage ou dessert.
Je me demande si je ne vais pas changer pour la solution A.

Avez-vous une préférence ?
J'ai laissé les deux possibilités dont une sous commentaire dans Models/p92-echo.xml si vous voulez essayer.
A moins que vous ne trouviez une meilleure idée...

patten a écrit:À venir, la même chose sur le gouvernail, pour l’esthétique, et surtout pour être conforme à la réalité.

Là, je ne vois pas. Pas vu d'objet trim de direction. Et sur un ULM, seul le trim de profondeur est réglable en vol. Trims ailerons et gouverne de direction se font par torsion au sol de petites plaques métalliques.

Aménagements FDM pour décollage et atterrissage par vent de travers 15 kt (15 kt : max manuel de vol).

J'ai eu quelques difficultés pour régler le FDM sans dégrader le comportement général. Un ULM, c'est très léger pour sa surface, donc très sensible au vent.

Je ne garantis pas la quantitativité mais le comportement est là, ainsi que les actions à effectuer. Je verrai éventuellement plus tard à l'usage s'il faut.

La meilleure manière que j'ai trouvée pour l'atterro : arriver en compensation de dérive (donc en crabe nez au vent) jusqu'à très près du sol puis (peu avant de toucher) décraber au palonnier, en mettant du manche à contre pour contrer la dérive. On touche alors sur la roue au vent, nez dans l'axe. Évidemment en tirant le manche pour adoucir le toucher, comme d'habitude.
On peut effectuer le décrabage de plus haut pour avoir le temps de se préparer, mais la position et l'alignement sont un peu difficiles à tenir et l'augmentation de traînée fait chuter rapidement. En revanche, c'est un bon exercice. Avec un peu de gaz, ça va mieux.

Pour le fun :

Correction animation de la clé qui pendouille au bout de son anneau.

- L'animation était basée sur l'angle de roulis, ce qui faisait que la clé pendait toujours vers le sol, quelle que soit l'action sur le palonnier et même en virage incliné coordonné (bille au centre).
La bonne propriété est slip-skid-ball/indicated-slip-skid (qui tient compte des effets dynamiques).

- De plus, l'axe de rotation en piqué - cabré était décalé de l'anneau, ce qui rendait celui-ci baladeur.

Salut à tous,

Mon hangar est à jour avec la dernière version:

http://pattenflightgear.wifeo.com/tecnam-p92-echo.php

dany93 a écrit:La meilleure manière que j'ai trouvée pour l'atterro : arriver en compensation de dérive (donc en crabe nez au vent) jusqu'à très près du sol puis (peu avant de toucher) décraber au palonnier, en mettant du manche à contre pour contrer la dérive. On touche alors sur la roue au vent, nez dans l'axe. Évidemment en tirant le manche pour adoucir le toucher, comme d'habitude.

Mais c'est exactement comme cela qu'on fait en ULM et même avec des avions légers (Cessna 152 ...) et que j'ai appris à LFOH où j'ai très rarement eu du vent dans l'axe.

Oui, mais j'ai lu que l'autre manière (décraber et incliner d'un peu plus haut) était pratiquée aussi. Parce qu'elle permet d'avoir le temps de se réguler et de se coordonner au lieu d'avoir à tout faire en même temps : décraber, incliner juste ce qu'il faut, tirer le manche pour amortir le toucher.

Christian (Patten),

La vue cockpit ne me convient pas du tout, je suis obligé de régler le zoom à chaque ouverture.
Est-ce volontaire, pour une disposition d'écran particulière,... ou est-ce que je peux changer et pusher un "Field of view" que je trouve mieux adapté pour voir le tableau de bord ? (sachant quand même que le résultat dépend du nombre de pixels)

Bonsoir à tous, bonsoir Dany,

dany93 a écrit:Christian (Patten),

La vue cockpit ne me convient pas du tout, je suis obligé de régler le zoom à chaque ouverture.
Est-ce volontaire, pour une disposition d'écran particulière,... ou est-ce que je peux changer et pusher un "Field of view" que je trouve mieux adapté pour voir le tableau de bord ? (sachant quand même que le résultat dépend du nombre de pixels)

De mémoire, les vues sont d'origine.
C'est la première fois qu'on évoque ce soucis avec le P92, je me souviens que sur le (les) DR400 on en avait aussi débattu, la vue originelle ne convenait pas à ta config, fais comme bon te semble.

Bonjour,

J'ai fait un gros travail, dont les effets ne seront peut-être pas flagrants à première vue, mais important sur le fond et peut-être pour des améliorations à venir.
J'ai remplacé les courbes de portance et traînée d'Aeromatic (sommaires bien que pas honteuses en première approximation pour du vol "sage") par des courbes complètes. Sur la base de calculs ou / et de la littérature. Ce qui ne veut pas dire que tout est parfait.
Par la même occasion et bien obligé, j'ai réajusté les paramètres pour accorder au mieux que j'ai pu aux performances de finesse, vitesses de croisières et vitesses de décrochage.

Ceci donne :
- Vitesse de croisière à 4300 RPM : 166 km/h (Manuel de vol 165 km/h à l'altitude 0),
- Vitesse de croisière à 5000 RPM : 195 - 196 km/h (Manuel de vol 196 km/h),
- Taux de montée pleine charge entre 0 et 3500 ft 1400 - 1450 ft/mn (Manuel de vol 1200 ft/mn*),
- Vitesses de décrochage (à pleine charge 450 kg = 992 lbs) : 74 km/h en lisse et 64 km/h pleins volets (en accord avec Manuel de vol),
- Meilleure finesse : vers 110 km/h (100, plutôt 110) (Manuel de vol 110 km/h),
- Finesse à 110 km/h pleine charge hélice arrêtée : 11.7 (Manuel de vol pour le LSA : 12, je n'ai rien trouvé pour l'ULM)),
*La vitesse de montée est un peu forte (200 - 250 ft/mn gratos et on se plaint !    ), je ne sais pas quoi faire sans dégrader le reste.

- Avec (déjà fait) atterrissage par vent travers 15 kt, glissades, effet de sol.

Compte tenu de tout ceci, je me suis permis de passer l'évaluation FDM (de 3) à 4 sur 5 (prétentieux !).

Bonjour à tous, bonjour Daniel,

dany93 a écrit:Bonjour,

J'ai fait un gros travail, ............
- Avec (déjà fait) atterrissage par vent travers 15 kt, glissades, effet de sol.

Compte tenu de tout ceci, je me suis permis de passer l'évaluation FDM (de 3) à 4 sur 5 (prétentieux !).

Gros travail en effet, merci.
On sent bien l'effet de sol.

Qu'est qu'il manque d'après toi au FDM pour arriver à 5/5? .

Mon hangar est à jour:

http://pattenflightgear.wifeo.com/avions.php