chatGPT

HH64 · 14/01/2026 18:13:20

Bonjour à tous,

Mes meilleurs voeux pour 2026. Que cette année insuffle un nouveau souffle à ce forum qui le mérite bien.

A dany93 et clm76,

Nous avons développé ensemble l'Alouette II jsbsim et j'éprouve à présent l'envie d'en soumettre le code à chatGPT pour apprécier ses capacités à l'optimiser.
C'est avant tout un exercice de style. Y voyez vous un inconvénient, une raison de ne pas s'y frotter?

En espérant que ce lien fonctionne, vous aurez un aperçu de ce que chatGPT propose...
https://www.mediafire.com/file/xpzpns3u … n.pdf/file

Bonne soirée.

Clm76 · 15/01/2026 8:23:58

Meilleurs vœux à toi également ainsi qu'à dany93.

dany93 a écrit :

j'éprouve à présent l'envie d'en soumettre le code à chatGPT pour apprécier ses capacités à l'optimiser.

Pourquoi ne pas essayer !!!
Mais attention que le code de chatGPT reste lisible et permette de s'y retrouver pour des ajouts ou modifications éventuelles. Il y a dans Fg quelques avions dont le code est quasiment indéchiffrable.

f-toro · 16/01/2026 10:25:13

Bonne année également.

HH64 a écrit :

Que cette année insuffle un nouveau souffle à ce forum qui le mérite bien.

Ça va pas être facile...
L'activité s'essouffle inexorablement.
Les forums sont passés de mode avec les nouvelles technologies.
Le nôtre est le seul qui subsiste en activité francophone, après la disparition de plusieurs autres (ou disparus du net ou devenus totalement inactifs).
Et pour combine de temps encore (voire les difficultés récurrentes de l'hébergeur...).
Et quand de plus on connait l'âge d'un certain nombre de participants...
Bref, on n'est pas encore tout à fait sortis de l'auberge...

arradoy · 16/01/2026 13:15:39

Meilleurs vœux à tous, de la part de votre doyen, je pense…

f-toro a écrit :

L'activité s'essouffle inexorablement.

oui, mais pas son utilité, si on consulte le nombre d'invités en ligne, et tous les non-anglophones y trouvent leur compte

HH64 a écrit :

ce que chatGPT propose

pour mémoire, "le Chat" de Mistral est 100% français et répond pratiquement les mêmes choses

HH64 · 16/01/2026 17:54:27

Cela fait plaisir de constater qu'il y a encore du monde sur la ligne. Ne pas intervenir sur le forum ne signifie pas que l'on s'en désinteresse mais probablement que l'on a plusieurs centres d'intérêts et pas toujours le temps de les satisfaire tous. Pour ma part FG pour la simulation aéronautique, les ESP (32S3) pour le bricolage en électronique, naturellement l'intelligence artificielle que je trouve bluffante. Les bons "Manuels" n'ont aucun soucis à se faire, les autres ?.

@clm76: je partage ta remarque sur la nécessité de conserver la lisibilté du code. Le plaisir de partager est bien l'une des vertus premières de FG.

@ arradoy: le moment venu, je n'hésiterai certainement pas à mettre Mistral en concurrence.

@ f-toro: je ne pense pas la fin de ce forum pour tout de suite mais les soucis d'hébergement auront probablement contribué à l'éloignement de bien des membres... A ce propos, j'utilise de temps en temps FGmap sous plusieurs formes mais ce dernier me semble également rencontrer de nombreux problèmes de serveur(s). Auriez-vous fait le même constat?

Bonne fin de journée.

dany93 · 18/01/2026 18:32:47

Bonjour à tous, et meilleurs vœux.

@HH64,
Je n'ai aucune idée de ce que peut apporter ChatGPT à ce sujet. J'ai une grande méfiance vis-à-vis de ces soit-disant "intelligences" qui ne sont que des super moteurs de recherche, incapables d'extrapoler au-delà ce ce qui est déjà publié. Ce qui est malgré tout un gain par rapport aux capacités humaines dans les domaines à immenses bases de données, et à une certaine capacité à "apprendre". Mais quand la question est trop complexe ou / et trop ouverte, si le sujet n'a pas été traité ailleurs, on risque les réponses très générales destinées à faire semblant.

Ceci dit, je te fais confiance pour préserver la qualité comportementale de l'appareil et la lisibilité des fichiers. Et tu es quand même l'initiateur de ce projet / de cette collaboration.

Ma connaissance du nasal est très superficielle. Je crois savoir qu"il ne faut pas en exagérer dans FG, c'est un formidable pourvoyeur de bugs. Le XML est plus solide et plus rapide quand c'est possible, mais plus lourd.

Dany

Patten · 22/01/2026 11:16:02

Bonjour à tous, bonjour Daniel,

Démarche intéressante.

dany93 a écrit :

Bonjour à tous
Ma connaissance du nasal est très superficielle. Je crois savoir qu"il ne faut pas en exagérer dans FG, c'est un formidable pourvoyeur de bugs. Le XML est plus solide et plus rapide quand c'est possible, mais plus lourd.
Dany

Donc pour voir, j'ai donc soumis ton fdm jsbsim du Tecnam P92 à Perplexity (J'ai TOUT migré en Suisse (Infomaniak), mais Euria l'IA de Infomaniak na prends pas encore les fichiers xml), voici les suggestions proposées. Je n'ai plus de FG d'installé, je nai pas pû tester, de toute façon, je suis "largué" .

Pour le simulateur de vol Flightgear, quels seraient les points à modifier dans le modèle de vol du Technam p2 Echo en PJ pour coller au plus près à la réalité?.
Les principaux points à ajuster pour rapprocher le P92 Echo JSBSim de la réalité sont : la polaire de portance/traînée (CL/CD) pour retrouver les bonnes vitesses (décrochage, croisière), la poussée/hélice pour coller aux taux de montée et vitesses plein gaz, et les moments de stabilité (tangage/lacet) pour obtenir des réactions cohérentes en pilotage et en décrochage. [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws … jsbsim.xml)
## 1. Vérifier les performances de base
Avant de toucher aux coefficients, il faut viser les chiffres POH (P92 Echo « classique » ou MkII selon ce que vous voulez reproduire). Les valeurs typiques sont :
- Vs avec volets : ~34–39 kt selon version et masse. [tecnamair](https://www.tecnamair.com/wp-content/up … e-Luxe.pdf)
- Vitesse de croisière max ~110–115 kt, Vne ~140 kt. [en.wikipedia](https://en.wikipedia.org/wiki/Tecnam_P92)
- Taux de montée ~950–1200 ft/min selon configuration. [tecnamair](https://www.tecnamair.com/wp-content/up … e-Luxe.pdf)
Cela sert de cible pour vos essais en palier et en montée dans FlightGear (masse, centrage, météo standard).
## 2. Ajuster portance / traînée
Dans le FDM, la portance et la traînée principales sont définies par :
- CL en fonction d’alpha : bloc **Lift due to alpha** (`aero/alpha-rad` → CL). [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws … jsbsim.xml)
- CL flap : **Delta Lift due to flaps** (coefficient 0.01333 par degré de volets ici). [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws … jsbsim.xml)
- CD0 : **Drag at zero alpha** (ligne à 0.025). [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws … jsbsim.xml)
- CD(α) : **Drag due to alpha** (table α → CD). [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws … jsbsim.xml)
- CDi : **Induced drag** (coefficient 0.053). [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws … jsbsim.xml)
Modifs typiques :
- Si la vitesse de décrochage est trop basse, réduire le CLmax (valeurs autour de α ≈ 0.20–0.26 rad) jusqu’à retrouver ~34–39 kt avec volets selon la version visée. [en.wikipedia](https://en.wikipedia.org/wiki/Tecnam_P92)
- Si l’avion est trop rapide/planant en croisière (à puissance fixée), augmenter légèrement CD0 et/ou CDi pour retrouver vitesse de croisière et finesse plus réalistes. [tecnamair](https://www.tecnamair.com/wp-content/up … e-Luxe.pdf)
- Si les volets n’aident pas assez au décollage/approche, augmenter un peu le gain de **Delta Lift due to flaps** et la **Drag due to flaps** (0.00100 actuellement) pour créer à la fois plus de portance et de traînée volets sortis. [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws … jsbsim.xml)
## 3. Moteur / hélice et montée
Le FDM actuel provient d’Aeromatic et utilise un jeu générique de courbes de traction hélice. Sur P92, on vise un Rotax 912 100 ch avec pas fixe Sensenich. [tecnam](https://www.tecnam.com/wp-content/uploa … 210720.pdf)
Points à vérifier/adapter dans la section propulseur (fichier moteur/hélice référencé par ce FDM) :
- Courbes de **thrust** / **power** en fonction de J (V / nD) : elles déterminent directement la vitesse plein gaz et le taux de montée à un régime donné. [equipe-flightgear.forumactif](https://equipe-flightgear.forumactif.co … m-p92-echo)
- Régime max au décollage (typiquement ~5500–5800 rpm Rotax 912ULS) et croisière (~5000 rpm) pour obtenir :
- Taux de montée proche du POH (950–1200 ft/min à masse ULM). [en.wikipedia](https://en.wikipedia.org/wiki/Tecnam_P92)
- Vitesse plein gaz horizontale cohérente (~110–115 kt). [tecnamair](https://www.tecnamair.com/wp-content/up … e-Luxe.pdf)
Si le modèle « arrache » trop au décollage mais plafonne bas en vitesse, il faut « allonger » virtuellement l’hélice (modifier les courbes de traction vers un pas un peu plus fort) comme discuté sur le forum FlightGear. [equipe-flightgear.forumactif](https://equipe-flightgear.forumactif.co … m-p92-echo)
## 4. Stabilité longitudinale et comportement au décrochage
Plusieurs retours signalent un décrochage JSBSim du P92 peu réaliste (perte d’altitude sans vrai changement d’assiette). Les réglages clés sont : [forum.flightgear](https://forum.flightgear.org/viewtopic. … tecnam+p92)
- **Pitch moment due to alpha** (Cmα, ici valeur de pente globale -0.5) et **Pitch moment at zero alpha** (trim de base 0.025). [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws … jsbsim.xml)
- **Pitch moment due to elevator** (table en fonction de `fcs/elevator-pos-rad` et Mach) qui fixe l’efficacité de la profondeur. [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws … jsbsim.xml)
- **Lift due to Elevator Deflection** (coefficient 0.2) qui couple profondeur et portance. [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws … jsbsim.xml)
Pistes :
- Augmenter légèrement l’effet nose‑down à fort α (Cm plus négatif autour de l’angle de décrochage) pour obtenir une vraie casse de portance avec abattée. [forum.flightgear](https://forum.flightgear.org/viewtopic. … tecnam+p92)
- Ajuster la courbe de CL(α) après CLmax pour que la portance chute franchement, au lieu de rester plate ou remonter. [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws … jsbsim.xml)
- Vérifier que la profondeur ne permet pas de maintenir un angle d’attaque irréaliste après le décrochage (si besoin, limiter légèrement son efficacité à très forte déflexion).
## 5. Stabilité latérale / directionnelle et tenue au sol
Le P92 réel est sain mais pas hyper vif ; certains utilisateurs trouvent la version JSBSim très nerveuse en roulis et au sol. [forum.flightgear](https://forum.flightgear.org/viewtopic.php?f=49&t=15039)
Dans le fichier :
- **Roll moment due to aileron** (0.17) et **Roll moment due to roll rate** (-0.4) déterminent vivacité et amortissement en roulis. [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws … jsbsim.xml)
- **Yaw moment due to rudder** (-0.1), **Yaw moment due to beta** (table), **Yaw moment due to yaw rate** (-0.15) jouent sur la stabilité en lacet. [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws … jsbsim.xml)
- **Adverse yaw** (-0.02) gère le lacet inverse au manche. [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws … jsbsim.xml)
Idées de retouche :
- Diminuer un peu l’efficacité aileron (0.17 → 0.14–0.15) et renforcer l’amortissement en roulis (valeur plus négative en « Roll moment due to roll rate ») pour un comportement moins « twitchy ». [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws … jsbsim.xml)
- Ajuster la dérive : si l’avion « serpente » trop, rendre **Yaw moment due to yaw rate** un peu plus négatif en module ; si le lacet inverse est trop marqué ou absent, jouer sur **Adverse yaw**. [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws … jsbsim.xml)
- Pour la tenue au sol, c’est plutôt dans les définitions de gear (position, amortisseurs, friction pneus) qu’il faudra regarder, mais ce n’est pas dans l’extrait lu ici.
## 6. Masse, centrage et inerties
Les masses et bras de levier définis par Aeromatic peuvent être éloignés de la réalité ULM :
- Vérifier masse à vide, masse maxi et répartition (fuselage, ailes, empennage, moteur) par rapport aux données P92 Echo (~327 kg à vide, 600 kg MTOW en version certifiée). [tecnam](https://www.tecnam.com/wp-content/uploa … 210720.pdf)
- Les moments d’inertie (Ix, Iy, Iz) influencent beaucoup le « feeling » : des valeurs trop faibles rendent l’avion trop vif et trop sensible aux rafales. Si nécessaire, augmenter modérément les inerties pour retrouver une sensation de « masse » plus crédible. [ppl-ai-file-upload.s3.amazonaws](https://ppl-ai-file-upload.s3.amazonaws … jsbsim.xml)
---
Si vous le souhaitez, il est possible de partir de vos observations de vol (vitesses, assiettes, taux de montée/décrue, comportement au décrochage) pour proposer des ajustements chiffrés plus précis (coefficients avant/après) sur quelques tables clés du fichier XML.

Dernière modification par Patten (22/01/2026 12:17:46)

dany93 · 24/01/2026 12:44:21

Bonjour à tous,
bonjour Patten, content de te relire.

Merci, test intéressant.

Ce commentaire IA contient beaucoup de généralités sur la méthodologie et JSBSim.

Le FDM actuel provient d’Aeromatic et utilise un jeu générique de courbes de traction hélice. Sur P92, on vise un Rotax 912 100 ch avec pas fixe Sensenich. [tecnam
https://www.tecnam.com/wp-content/uploa … 210720.pdf]

On aurait aimé qu'il nous dirige vers un jeu de courbes d'hélice adapté...
De plus, archi faux. Il ne sait pas lire les fichiers XML mais cela ne l'empêche pas d'affirmer que leur contenu ne convient pas...
Je suis bien parti du fichier Aeromatic (pour la structure générale), mais j'ai commencé par remplacer les courbes génériques de portance, traînée, hélice par des valeurs publiées ou, au moins, plus spécifiques. Puis affiné par calculs (pas "au pif") pour traînée et vitesse de meilleure finesse, pour s'approcher des valeurs connues.

Plusieurs retours signalent un décrochage JSBSim du P92 peu réaliste (perte d’altitude sans vrai changement d’assiette). Les réglages clés sont : - **Pitch moment due to alpha** (Cmα, ici valeur de pente globale -0.5) et **Pitch moment at zero alpha** (trim de base 0.025). [ppl-ai-file-upload.s3.amazonaws]
https://forum.flightgear.org/viewtopic. … tecnam+p92

Les liens (ceux ouvrables) renvoient au FDM initial YASim (vivement critiqué à l'époque).
Suggestion qui serait malgré tout à considérer sous JSBSim. Cependant...
Le P92 JSBSim "salue" au décrochage. Pour comparaison j'ignore le comportement réel. J'ai connu des ULM qui piquaient bien du nez au décrochage, d'autres qui résistaient et qui se contentaient de "parachuter" (sauf si on les poussait en les faisant décrocher en montant).

Le P92 réel est sain mais pas hyper vif ; certains utilisateurs trouvent la version JSBSim très nerveuse en roulis et au sol. [forum.flightgear](https://forum.flightgear.org/viewtopic.php?f=49&t=15039)

Sauf que... Mal vu. Encore YASim

Je ne vois aucune proposition concrète et ciblée (pour le P92 JSBSim) d'amélioration pour se rapprocher du comportement réel.
Il est vrai que si

Euria l'IA de Infomaniak ne prend pas encore les fichiers xml

on ne peut pas s'attendre à du concret ciblé.

Mais quand on ne sait pas, il vaut souvent mieux l'admettre et en dire moins...

Attendons de lire ce que répondra ChatGPT sur l'Alouette II JSBSim (la nôtre !)...

HH64 · 25/01/2026 14:26:53

Bonjour à tous,

Le débat étant ouvert, j'ai proposé à chatGPT d'étudier le FDM de l'Alouette-II (jsbsim) et vous en soumets le résultat.

https://www.mediafire.com/file/7g4sfesa … l.pdf/file

Confronté à des travaux de mise à niveau de mon PC, j'ai fait cela dans la précipitation et le résultat est brut de coffrage. Ne pas s'arrêter aux pages blanches parasites, le document a bien un début et une fin. Je reste impressionné même si j'en conviens, l'apport de chatGPT n'a de valeur qu'avec un bon sens critique à lui opposer.

Clm76 · 25/01/2026 16:35:07

Bonjour à tous, bonjour HH64 et dany93,

Je suis très impressionné par les conclusions de chatGPT.
Un commentaire m'interpelle particulièrement :

Mauvais
var alt = getprop("/position/altitude-ft");
var spd = getprop("/velocities/airspeed-kt");
Bon
var altProp = props.globals.getNode("/position/altitude-ft");
var spdProp = props.globals.getNode("/velocities/airspeed-kt");
var alt = altProp.getValue();
var spd = spdProp.getValue();
Gain énorme si appelé souvent.

Et pourtant, les tests effectués par plusieurs programmeurs de FG indique clairement que l'utilisation de "setprop/getprop" est plus rapide que "getValue()/setValue()" car "setprop/getprop" ne remonte pas le node entier. ???

nasal library setValue a écrit :

Note For setting the values of Property Tree nodes, it is recommended to use setprop() if possible, due to performance differences.

A part cette remarque, ça vaut le coup d'essayer ses quelques recommandations.

dany93 · 26/01/2026 16:38:51

Bonjour à tous, bonjour HH64 et Clm76,

Clm76 a écrit :

Je suis très impressionné par les conclusions de chatGPT.

+1
Remarques et suggestions pertinentes, bien focalisées, argumentées. Donne la sensation d'une bonne compréhension.
Au moins en ce qui concerne ce que je connais (le FDM).

Clm76 · 26/01/2026 17:59:38

J'ai apporté les modifications préconisées par chatGPT sauf ce qui concerne les moments de roulis (aero.xml) car je ne sais pas trop comment apporter cette amélioration:

Suggestion légère (optionnelle) :
multiplier par une table en mu :
table(mu): 0 → 0 ; 0.3 → 1
→ améliore la progressivité sans casser l’équilibre.

Puis j'ai volé avec l'alouette II. Elle vole bien, mais comme cela fait longtemps que je n'ai pas volé avec, je ne sais pas dire si les améliorations sont sensibles ou non.

dany93 · 26/01/2026 18:57:24

Clm76 a écrit :

sauf ce qui concerne les moments de roulis (aero.xml) car je ne sais pas trop comment apporter cette amélioration

"mu" (ligne 106 de aero.xml) c'est l' "Advance ratio" de l'hélice. [Wikipedia]

Pour un avion [Wikipedia], c'est

J = V/nD

V étant approximativement la vitesse air de l'avion. C'est une variable réduite (sans dimensions). Elle sert à tracer les caractéristiques de l'hélice (Cp, Ct) en fonction de la vitesse air de l'avion. Dans ce cas d'un avion, la logique est solide, compréhensible quand on pense "pas d'hélice" (avec glissement).

- Pour un hélicoptère [Wikipedia] , c'est

mu = Vinfini / omega * r

Vinfini est alors typiquement la vitesse air de l'hélicoptère. Ici, la logique semble être : si mu = 1, l'extrémité de la pale reculante a une vitesse air = 0.

Mathématiquement, les deux définitions J et mu sont similaires (mais pas la même valeur).
La différence fondamentale entre les deux est évidemment l'orientation de la vitesse air de l'aéronef (Vinfini pour hélico) par rapport au plan des pales.

Lire éventuellement mes commentaires ajoutés lignes 383 à 385. Et Wikipedia.
ChatGPT reproche que le moment roulis ne dépend que de (ligne 390) :

<property>velocities/u-aero-fps</property> <!-- air-speed -->

Dans le cas d'un hélicoptère (si je comprends bien), "air-speed" est déjà pris en compte via Vinfini. Je ne vois pas bien ce que cela apporterait. Qui plus est, pour un effet estimé.

L'écart à la rigueur que je vois pour ce FDM est que la pertinence de "mu" pour des effets sur des appendices (autres que l'hélice) n'est pas évidente. De toutes façons, dans aero.xml, l'effet de mu est associé à des coefficients estimés.
Je n'ai personnellement pas approfondi ce point.

La remarque était quand même judicieuse.

Dernière modification par dany93 (2/02/2026 12:13:53)

Clm76 · 27/01/2026 11:00:40

Merci dany93 pour ces précisions.

Pour ma part, je confirme que "setprop/getprop" est deux fois plus rapide que "setValue/getValue" (benchmark_time()).

dany93 · 28/01/2026 13:17:39

Petits compléments :
Le moment en roulis dû à la vitesse est actuellement en progression linéaire avec u-aero-fps, selon mes calculs élémentaires.

La suggestion de ChatGPT

multiplier par une table en mu :
table(mu): 0 → 0 ; 0.3 → 1

revient à rendre cette progression quadratique avec la vitesse air entre mu = 0 et mu = 0.3 (mu est d’environ 0.3 à 200 km/h). Ce qui donne une progression plus lente à basse vitesse, plus rapide à haute vitesse. Pour aboutir à 100% de la valeur actuelle pour mu = 0.3 (sans augmenter cette contribution au roulis).

Avec mes limites (connaissance sommaire de la technologie hélicos, pas de pratique du pilotage hélico), je n'en vois pas bien l’intérêt.
Mais je vous laisse juges. Quitte à réajuster aero/coefficient/Cl_V_Rot_K dans ce cas.

Merci éventuellement si vous pouvez rectifier ce que j'écris (ce sont des réflexions en temps réel)...

HH64 · 5/02/2026 13:22:59

Bonjour à tous,

@ clm76 & dany93

Après avoir bouleversé mon PC par la mise en place (aidé par chatGPT!) d'une nouvelle carte graphique et d'un SSD en double boot, j'ai pris le temps d'étudier les propositions de chatGPT. Dans l'ensemble, je les trouve pertinentes. Elles me semblent apporter de légers mieux même si cela reste à consolider.

table(mu), plutôt favorable.

Ixx porté à 500, plutôt favorable, moins de nervosité latérale

ground reactions: <spring_coeff unit="LBS/FT">10000</spring_coeff> <damping_coeff unit="LBS/FT/SEC">2000</damping_coeff> difficile d'apprécier entre différents terrains...
A ce propos, en vue "Pilot", l'écran s'assombrit quand l'atterrissage est un peu ferme (pas loin du crash). Sauriez-vous comment le régler pour que ce soit moins sensible.

Un peu plus délicat la mise en oeuvre de la suggestion ? Points perfectibles (mineurs) et de créer
/_tuning/aero/coefficient/CLmax_ht, /_tuning/aero/coefficient/a_ht, /_tuning/aero/coefficient/solidity
pour faciliter une dernière mise au point.

Après avoir bouleversé mon PC, j'ai rencontré un alea curieux en la disparition du Pas général. La correction a consisté à corriger pasgeneral.xml et supprimer quelques \ "parasites".

 <path>Aircraft/Alouette-II-jsbsim/Models/Instruments/Pasgeneral/pasgeneral.ac</path>

Souhaitez-vous que nous procédions à l'émission d'une nouvelle version? En dehors de la fonction téléchargement, j'ai perdu la main sur le GIT.

Je vais poursuivre (à un rythme de sénateur) avec les fichiers Nasal et les autres XML.

Merci de vos commentaires, bonne journée.

dany93 · 6/02/2026 18:38:00

HH64 a écrit :

en vue "Pilot", l'écran s'assombrit quand l'atterrissage est un peu ferme (pas loin du crash). Sauriez-vous comment le régler pour que ce soit moins sensible.

Serait-ce un effet de voile noir ?

Cockpit View Options : Enable blackout and Redout due to G-Force

dany93 · 6/02/2026 19:27:48

ChatGPT a écrit :

Cl_V_Rot = HIhat * V * K
MAIS :
dépend uniquement de U
pas de dépendance à mu

C'est faux.

mu fait le rapport entre : la vitesse air hélico, et celle (omega*R) de l'extrémité des pales par rapport à l'hélico. Selon ma compréhension, l'idée est que, quand la vitesse air hélico est telle que l'extrémité de la pale reculante a la même vitesse linéaire en valeur absolue (par rapport à l'hélico), la vitesse air de l'extrémité de la pale, donc sa portance, devient nulle.

Or, j'ai fait ce calcul sur des considérations élémentaires, mais quand même :
Le moment de roulis ainsi calculé prend en compte la différence entre les vitesses air des pales avançantes et reculantes. Ceci évidemment à partir de :
- la vitesse air hélico et
- de la vitesse linéaire des pales par rapport à l'hélico, à partir de la rotation (et du diamètre) du rotor.
C'est du calcul V = omega x R, avec forces = 1/2 ro x V^2, et différences de moments associés.

Même genre de calcul que, pour un avion, "roll moment due to yaw rate". Dépendance linéaire aussi à V.

ChatGPT a écrit :

Suggestion légère (optionnelle) :
multiplier par une table en mu :
xml
Copy code
table(mu): 0 → 0 ; 0.3 → 1

HH64 a écrit :

table(mu), plutôt favorable

Ceci soulève deux interrogations :
1- Justification observationnelle (comportementale) de cette modification ?
2- mu étant lui-même proportionnel à la vitesse hélico, elle donnerait une variation quadratique du moment de roulis avec la vitesse dont je ne vois pas la justification aérodynamique. Sauf erreur, mauvaise compréhension ou oubli de ma part...

@HH64
Je t'avais envoyé mon calcul (dans une première version encore courte, mais qui donne la dépendance linéaire avec V) par e-mail le 07/10/2021.

HH64 · 7/02/2026 12:35:42

Bonjour à tous,

@dany93

Cockpit View Options : Enable blackout and Redout due to G-Force

C'est bien de cela dont il s'agissait. A moi de le paramétrer correctement... Merci.

Pour le fdm (chatGPT), bien entendu "plutôt favorable" ne relève d'aucune démarche raisonnée, une question de ressenti uniquement. Je ne suis pas suffisamment armé pour challenger chatGPT côté aérodynamique. Ma démarche initiale allait dans le sens de l'allègement du code mais je me suis pris au jeu de l'amélioration du fdm et ne le regrette pas. Jamais trop tard pour s'instruire.

Bonne journée.

dany93 · 3/03/2026 17:26:12

Bonjour à tous,

J'ai créé un sujet dans Tutoriels et exporté le document traitant du roulis dû à la vitesse air.
@HH64 et Clm76 : au départ, vous avez déjà le calcul mais j'ai très largement complété le document.

Forum Flightgear France

Annonce

#1 14/01/2026 18:13:20

chatGPT

#2 15/01/2026 8:23:58

Re : chatGPT

#3 16/01/2026 10:25:13

Re : chatGPT

#4 16/01/2026 13:15:39

Re : chatGPT

#5 16/01/2026 17:54:27

Re : chatGPT

#6 18/01/2026 18:32:47

Re : chatGPT

#7 22/01/2026 11:16:02

Re : chatGPT

#8 24/01/2026 12:44:21

Re : chatGPT

#9 25/01/2026 14:26:53

Re : chatGPT

#10 25/01/2026 16:35:07

Re : chatGPT

#11 26/01/2026 16:38:51

Re : chatGPT

#12 26/01/2026 17:59:38

Re : chatGPT

#13 26/01/2026 18:57:24

Re : chatGPT

#14 27/01/2026 11:00:40

Re : chatGPT

#15 28/01/2026 13:17:39

Re : chatGPT

#16 5/02/2026 13:22:59

Re : chatGPT

#17 6/02/2026 18:38:00

Re : chatGPT

#18 6/02/2026 19:27:48

Re : chatGPT

#19 7/02/2026 12:35:42

Re : chatGPT

#20 3/03/2026 17:26:12

Re : chatGPT

Pied de page des forums