Menu
▾
▴
jsbsim-devel
|
From: Fabian G. <fab...@gm...> - 2008-04-27 12:13:10
|
Hello, Both original and new trim algorithms perform the longitudinal trim with the elevator deflection. This is done by iterating with elevator-cmd-norm in the cost function until ~zero pitching moment is achieved. Since not all aircraft trim the pitching moment with the elevator (indeed, most airliners and business jets trim in pitch with the horizontal stabilizer) a more general algorithm would be to do the iterations with the pitch-trim-cmd-norm. The user could then use this pitch-trim-cmd-norm in the FCS block as input to either the elevator or to the horizontal stabilizer, depending on his aerodynamic database buildup components and/or aircraft flight control system. I succeeded in making this modification to my local JSBSim branch for the longitudinal trim case (the TODO comments of Agostino de Marco helped me a lot!); now I can run a script in which I trim the aircraft with the horizontal stabilizer and after a few seconds I perform some maneuver with the elevator while the stab is kept fixed. I put the aircraft on the air at some altitude and speed, make a do_trim_analysis (longitudinal), and then pull up with the elevator. It's really nice! I'm still having problems when starting with the aircraft on the ground ready for takeoff - I still need to debug that. My proposal is to discuss the possibility of making this modification to the official code. So far I see the following advantages and also question marks: 1. Flexibility to trim with either the elevator or the stab. 2. How would this affect JSBSim-Flightgear integration? - I'm having some trouble there, too. 3. Would this change affect something that I do not see right now? 4. There must have been some reason that motivated the use of the elevator for trim (maybe the lack of tail-off aerodynamic data availability?, or downwash?). Comments? Regards, Fabian |
|
From: Jon S. B. <js...@ha...> - 2008-04-27 13:16:20
|
Fabian, This sounds good, but FGTrimAnalysis is temporarily removed from the build process for JSBSim, and will probably not be part of the v1.0 release or built into FlightGear. Once the trim analysis algorithms are fully tested and refined a bit, then we'll add it back in to the build. Of course it's not being removed from CVS. You and Agostino can proceed with this as you want, but note that the code in CVS now doesn't build the trim analysis stuff into the executable, and the code that calls FGTrimAnalysis has been largely removed or commented out. Jon From: jsb...@li... [mailto:jsb...@li...] On Behalf Of Fabian Grodek Sent: Sunday, April 27, 2008 7:13 AM To: Development issues Subject: [Jsbsim-devel] Longitudinal trim: stab or elevator Hello, Both original and new trim algorithms perform the longitudinal trim with the elevator deflection. This is done by iterating with elevator-cmd-norm in the cost function until ~zero pitching moment is achieved. Since not all aircraft trim the pitching moment with the elevator (indeed, most airliners and business jets trim in pitch with the horizontal stabilizer) a more general algorithm would be to do the iterations with the pitch-trim-cmd-norm. The user could then use this pitch-trim-cmd-norm in the FCS block as input to either the elevator or to the horizontal stabilizer, depending on his aerodynamic database buildup components and/or aircraft flight control system. I succeeded in making this modification to my local JSBSim branch for the longitudinal trim case (the TODO comments of Agostino de Marco helped me a lot!); now I can run a script in which I trim the aircraft with the horizontal stabilizer and after a few seconds I perform some maneuver with the elevator while the stab is kept fixed. I put the aircraft on the air at some altitude and speed, make a do_trim_analysis (longitudinal), and then pull up with the elevator. It's really nice! I'm still having problems when starting with the aircraft on the ground ready for takeoff - I still need to debug that. My proposal is to discuss the possibility of making this modification to the official code. So far I see the following advantages and also question marks: 1. Flexibility to trim with either the elevator or the stab. 2. How would this affect JSBSim-Flightgear integration? - I'm having some trouble there, too. 3. Would this change affect something that I do not see right now? 4. There must have been some reason that motivated the use of the elevator for trim (maybe the lack of tail-off aerodynamic data availability?, or downwash?). Comments? Regards, Fabian |
|
From: Tony P. <ton...@co...> - 2008-04-27 16:31:07
|
You're right about the user of the stabilizer. Further, small airplanes often do pitch trim with an elevator tab rather than the elevator itself. Now, that said, changing the position of the elevator tab changes the position of the elevator, so the c172 model sums the pitch trim and elevator commands to emulate that. (which is not entirely accurate ...) The original trimming routine is set up to trim with pitch trim by default. It can be configured to do other things at the C++ level, however. For FG integration, using the trim systems is highly desirable as FG has no way of setting the user's controls (joystick, throttle, ...) _____ From: jsb...@li... [mailto:jsb...@li...] On Behalf Of Fabian Grodek Sent: Sunday, April 27, 2008 5:13 AM To: Development issues Subject: [Jsbsim-devel] Longitudinal trim: stab or elevator Hello, Both original and new trim algorithms perform the longitudinal trim with the elevator deflection. This is done by iterating with elevator-cmd-norm in the cost function until ~zero pitching moment is achieved. Since not all aircraft trim the pitching moment with the elevator (indeed, most airliners and business jets trim in pitch with the horizontal stabilizer) a more general algorithm would be to do the iterations with the pitch-trim-cmd-norm. The user could then use this pitch-trim-cmd-norm in the FCS block as input to either the elevator or to the horizontal stabilizer, depending on his aerodynamic database buildup components and/or aircraft flight control system. I succeeded in making this modification to my local JSBSim branch for the longitudinal trim case (the TODO comments of Agostino de Marco helped me a lot!); now I can run a script in which I trim the aircraft with the horizontal stabilizer and after a few seconds I perform some maneuver with the elevator while the stab is kept fixed. I put the aircraft on the air at some altitude and speed, make a do_trim_analysis (longitudinal), and then pull up with the elevator. It's really nice! I'm still having problems when starting with the aircraft on the ground ready for takeoff - I still need to debug that. My proposal is to discuss the possibility of making this modification to the official code. So far I see the following advantages and also question marks: 1. Flexibility to trim with either the elevator or the stab. 2. How would this affect JSBSim-Flightgear integration? - I'm having some trouble there, too. 3. Would this change affect something that I do not see right now? 4. There must have been some reason that motivated the use of the elevator for trim (maybe the lack of tail-off aerodynamic data availability?, or downwash?). Comments? Regards, Fabian |
|
From: Fabian G. <fab...@gm...> - 2008-04-27 16:56:03
|
On 4/27/08, Tony Peden <ton...@co...> wrote: >The original trimming routine is set up to trim with pitch trim by default. It can be configured to do other things at the >C++ level, however. So, with the original trimming routine, I can input the pitch-trim-cmd-norm to the stab (or maybe a canard) and that will be the surface that will be iterated to achieve trim? >For FG integration, using the trim systems is highly desirable as FG has no way of setting the user's controls (joystick, >throttle, ...) I understand FG do perform a trim by default after initializing. Moreover, there's an option to select NO trim before start. In this case, if the sim is started with the aircraft in the air, it will begin in a crazy roll/pitch/roll until trimmed by the "pilot". I still cannot understand if it used the pitch trim or the elevator for that. If I start with the aircraft in the air without trim, clicking the pitch trim button on the joystick moves the stabilizer (in my model), as expected/wanted. But if I ask for a trimmed start, FG does not start. It seems it tries to trim with the elevator, but it doesn't know the stab position, then it has no enough power to trim, I guess. Interesting. Fabian |
|
From: Tony P. <ton...@co...> - 2008-04-27 17:07:04
|
The trimming routine sets the pitch trim command, yes. The surface that is driven depends entirely on the FCS block in the model config file. A pitch control issue is always a possibility. Are the engines running when you start FG? _____ From: jsb...@li... [mailto:jsb...@li...] On Behalf Of Fabian Grodek Sent: Sunday, April 27, 2008 9:56 AM To: Development issues Subject: Re: [Jsbsim-devel] Longitudinal trim: stab or elevator On 4/27/08, Tony Peden <ton...@co...> wrote: >The original trimming routine is set up to trim with pitch trim by default. It can be configured to do other things at the >C++ level, however. So, with the original trimming routine, I can input the pitch-trim-cmd-norm to the stab (or maybe a canard) and that will be the surface that will be iterated to achieve trim? >For FG integration, using the trim systems is highly desirable as FG has no way of setting the user's controls (joystick, >throttle, ...) I understand FG do perform a trim by default after initializing. Moreover, there's an option to select NO trim before start. In this case, if the sim is started with the aircraft in the air, it will begin in a crazy roll/pitch/roll until trimmed by the "pilot". I still cannot understand if it used the pitch trim or the elevator for that. If I start with the aircraft in the air without trim, clicking the pitch trim button on the joystick moves the stabilizer (in my model), as expected/wanted. But if I ask for a trimmed start, FG does not start. It seems it tries to trim with the elevator, but it doesn't know the stab position, then it has no enough power to trim, I guess. Interesting. Fabian |
|
From: Fabian G. <fab...@gm...> - 2008-04-28 13:25:43
|
On 4/27/08, Tony Peden <ton...@co...> wrote: > > > A pitch control issue is always a possibility. Are the engines running > when you start FG? > > Tony, Well, if you refer to the problem I'm having in FG with my aero model, I start FG in the same way I do with the original HondaJet; engines are at idle by default. In the original HondaJet everything is fine. In my modified HondaJet (only the configuration file is changed with my model, where pitch is buildup from the wing-body-vertical + isolated horizontal tail effect), FG doesn't launch, and I get the following error: FGMultiplayMgr::MP_ProcessData: Domain error. Is this connected to multiplayer mode? but..., I am not running inmultiplayer mode at all! I just changed the aero and FCS models! I see (in the FG code) that it performs "A static map of protocol property id values to property paths,...". Maybe the stabilizer property I defined in the FCS of my model confuses FG? Maybe that's the reason why the way to work with an isolated tail is to "use property names to represent something that they don't exactly name" (see David Culp reply). I saw somewhere in some 747 model that the speedbrakes are used as if they were the horizontal stabilizer. I think this is not the way we should work (even if we don't want to model the speedbrakes effects, together with the stabilizer effects). David Culp wrote: >I also prefer pitch-trim-cmd-norm, but be advised that this will break all the existing model configurations and AeroMatic. If things work as I understand, the user, or aerodynamic/FCS modeler, will input the pitch-trim-cmd-norm to whatever aerosurface he/she wants to use for trim. Existing models will continue to work. Since I've been noticed by Tony that the original trimming routine do use pitch-trim-cmd-norm for trim, then this proves we have no problem here. The only issue is the need to add a stab property (non-existent so far). See issue above. I don't understand how AeroMatic output would be affected. Fabian |
|
From: David C. <dav...@co...> - 2008-04-27 21:46:04
|
On Sunday 27 April 2008 07:13, Fabian Grodek wrote: > ... a more general algorithm would be to do the iterations with the > pitch-trim-cmd-norm. The user could then use this pitch-trim-cmd-norm in > the FCS block as input to either the elevator or to the horizontal > stabilizer, depending on his aerodynamic database buildup components and/or > aircraft flight control system. When I mentioned this a few years ago it was pointed out to me that the current system works fine, as long as you don't mind using property names to represent something that they don't exactly name. I also prefer pitch-trim-cmd-norm, but be advised that this will break all the existing model configurations and AeroMatic. Dave |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X