You can subscribe to this list here.
2001 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(48) 
_{Nov}
(131) 
_{Dec}
(213) 

2002 
_{Jan}
(92) 
_{Feb}
(91) 
_{Mar}
(67) 
_{Apr}
(61) 
_{May}
(27) 
_{Jun}
(26) 
_{Jul}
(55) 
_{Aug}
(61) 
_{Sep}
(165) 
_{Oct}
(20) 
_{Nov}
(51) 
_{Dec}
(36) 
2003 
_{Jan}
(70) 
_{Feb}
(126) 
_{Mar}
(120) 
_{Apr}
(39) 
_{May}
(31) 
_{Jun}
(72) 
_{Jul}
(193) 
_{Aug}
(5) 
_{Sep}
(82) 
_{Oct}
(92) 
_{Nov}
(287) 
_{Dec}
(113) 
2004 
_{Jan}
(139) 
_{Feb}
(296) 
_{Mar}
(201) 
_{Apr}
(276) 
_{May}
(145) 
_{Jun}
(198) 
_{Jul}
(56) 
_{Aug}
(84) 
_{Sep}
(139) 
_{Oct}
(134) 
_{Nov}
(189) 
_{Dec}
(168) 
2005 
_{Jan}
(146) 
_{Feb}
(118) 
_{Mar}
(99) 
_{Apr}
(55) 
_{May}
(119) 
_{Jun}
(167) 
_{Jul}
(77) 
_{Aug}
(65) 
_{Sep}
(89) 
_{Oct}
(21) 
_{Nov}
(71) 
_{Dec}
(193) 
2006 
_{Jan}
(204) 
_{Feb}
(141) 
_{Mar}
(90) 
_{Apr}
(60) 
_{May}
(87) 
_{Jun}
(75) 
_{Jul}
(62) 
_{Aug}
(68) 
_{Sep}
(61) 
_{Oct}
(96) 
_{Nov}
(65) 
_{Dec}
(30) 
2007 
_{Jan}
(104) 
_{Feb}
(31) 
_{Mar}
(45) 
_{Apr}
(101) 
_{May}
(74) 
_{Jun}
(84) 
_{Jul}
(40) 
_{Aug}
(134) 
_{Sep}
(126) 
_{Oct}
(100) 
_{Nov}
(51) 
_{Dec}
(81) 
2008 
_{Jan}
(184) 
_{Feb}
(80) 
_{Mar}
(100) 
_{Apr}
(134) 
_{May}
(195) 
_{Jun}
(88) 
_{Jul}
(85) 
_{Aug}
(81) 
_{Sep}
(31) 
_{Oct}
(92) 
_{Nov}
(105) 
_{Dec}
(62) 
2009 
_{Jan}
(75) 
_{Feb}
(64) 
_{Mar}
(96) 
_{Apr}
(93) 
_{May}
(125) 
_{Jun}
(123) 
_{Jul}
(114) 
_{Aug}
(161) 
_{Sep}
(114) 
_{Oct}
(177) 
_{Nov}
(97) 
_{Dec}
(27) 
2010 
_{Jan}
(89) 
_{Feb}
(72) 
_{Mar}
(172) 
_{Apr}
(137) 
_{May}
(45) 
_{Jun}
(42) 
_{Jul}
(206) 
_{Aug}
(181) 
_{Sep}
(152) 
_{Oct}
(108) 
_{Nov}
(113) 
_{Dec}
(150) 
2011 
_{Jan}
(111) 
_{Feb}
(200) 
_{Mar}
(101) 
_{Apr}
(119) 
_{May}
(232) 
_{Jun}
(182) 
_{Jul}
(243) 
_{Aug}
(80) 
_{Sep}
(77) 
_{Oct}
(141) 
_{Nov}
(50) 
_{Dec}
(36) 
2012 
_{Jan}
(60) 
_{Feb}
(17) 
_{Mar}
(87) 
_{Apr}
(41) 
_{May}
(32) 
_{Jun}
(18) 
_{Jul}
(35) 
_{Aug}
(45) 
_{Sep}
(71) 
_{Oct}
(61) 
_{Nov}
(43) 
_{Dec}
(64) 
2013 
_{Jan}
(114) 
_{Feb}
(26) 
_{Mar}
(55) 
_{Apr}
(24) 
_{May}
(4) 
_{Jun}
(27) 
_{Jul}
(4) 
_{Aug}
(21) 
_{Sep}
(99) 
_{Oct}
(11) 
_{Nov}
(47) 
_{Dec}
(11) 
2014 
_{Jan}
(131) 
_{Feb}
(18) 
_{Mar}
(4) 
_{Apr}
(1) 
_{May}
(24) 
_{Jun}
(22) 
_{Jul}
(14) 
_{Aug}
(49) 
_{Sep}
(13) 
_{Oct}
(26) 
_{Nov}

_{Dec}

From: Jon S. Berndt <jonsberndt@co...>  20141024 22:43:37

Glad it's working. Let us know if you have any more questions. JB > I've just tried another test on my F14 using AeroRP and it looks like > it works fine. When Tony said "It's just geometry" he was right and I > wish I'd understood and not tried to overcomplicate things. > > Richard 
From: Richard Harrison <rjh@za...>  20141024 19:22:12

> I'm not sure I follow this. In the case where wind tunnel data is used as a > I'm now pretty certain that all I've said and thought I understood about AeroRP and my model was wrong[1] and that I can in fact use it together with all of my other coefficients  and it comes down to my misunderstanding of CMBAS and how what it represented in the model. I've just tried another test on my F14 using AeroRP and it looks like it works fine. When Tony said "It's just geometry" he was right and I wish I'd understood and not tried to overcomplicate things. Richard  [1] My excuse is that I had several other things, mainly related to mass/balance, that were wrong and I was incorrectly blaming the AeroRP change which merely highlighted a problem that was already there. 
From: Sean McLeod <sean@se...>  20141023 18:50:08

From: Tony Peden <tony_jsbsim@co...>  20141023 15:32:37

Correct. Nit: aero center and aerorp are not the same. The aerodynamic center on the wing moves around with LE config, TE config, Mach number, and probably other things as well. The aerorp is chosen as one, constant point to take the moments around to facilitate data collection and reduction. Now, it happens that 25% MAC is pretty close to the aero center for a clean wing at low Mach numbers so it's a convenient choice for aerodynamicists. In reducing collected data that way, real movement of the aero center gets reflected in the measured coefficients and that's the reason you typically won't find any explicit accounting of the change in aero center in aero models.  Tony Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs. > On Oct 23, 2014, at 7:11 AM, Sean McLeod <sean@...> wrote: > > Thanks Jon and Tony > > So all the entries in the pitch axis (Cmalpha, Cmde, Cmq and Cmadot) are moments about the aero center (AeroRP). > > Has anyone else tried using the text book examples of the short period approximation and the resulting transfer functions and compared the output from those with the output from JSBSim to see how closely they match during the short period timeframe? > > Whether I make the cg and AeroRP coincident or not I don't get a very good match. > > Cheers > > Original Message > From: Jon S. Berndt [mailto:jonsberndt@...] > Sent: Thursday, October 23, 2014 3:24 PM > To: 'Development issues' > Subject: Re: [Jsbsimdevel] Converting aerodynamic coefficients from AeroRP to cg > >> Based on my work with my F14 model which has CM Basic (alpha) I don't >> think that you can use the built in AeroRP approach if you have values >> for CM(alpha) >> >> JSBSim works out the pitching moment due to Cl based upon the AeroRP  >> CG moment arm; if your CM Basic is the usual "Pitch moment due to >> alpha" >> (see NASA CR1756 for an example) that is balanced by the offset of >> the centre of pressure (AERORP) from the CG; i.e. building up the >> yaw/pitch moments from a base value (CLBAS, CYBAS, CNBAS). If you use >> the normal JSBSim AeroRP then it will double up the pitching moment as >> it is effectively the same force that JSBSim is calculating based on >> the offset of the Cl from the CoP. >> >> Richard > > I'm not sure I follow this. In the case where wind tunnel data is used as a basis for an aerodynamic model, the wind tunnel data will be delivered both in a specified reference frame, and given a specified aerodynamic reference point. The force coefficients are independent of location, of course. But the moments specified in the wind tunnel data report will be highly dependent on the moment reference center, because the moment that acts on the aircraft in flight is found this way (not sure of the sign convention at the moment): > > Moment = Moment_about_aero_center + force * (CG_position  AeroRP_position) > > Moment_about_aero_center is what you get from the wind tunnel report, couple with the AeroRP_position. The other part is calculated by JSBSim and summed with the first part, and it has been validated to work correctly (for quite a long time). > > This is essentially all there is for the calculation of aerodynamic moments. > Sometimes in tech reports there is a lot less information given than would be desired  maybe that is what has happened in your case. In the case where you are given only a total aerodynamic moment, it is possible to prevent the force X moment_arm value from being summed into the mix. You would specify that the force should only be supplied at the CG. This is done with an attribute in the aerodynamic force calculation in an axis element. For > instance: > > <axis name="LIFT"> > > <! Lift axis coefficients functions > > > <function name="aero/force/Lift_wbh" apply_at_cg="true"> > <description> Lift due to alpha </description> > <product> > <property>aero/function/groundeffectfactorlift</property> > <property>aero/qbararea</property> > <table> > <independentVar lookup="row">aero/alpharad</independentVar> > <independentVar > lookup="column">aero/stallhystnorm</independentVar> > <tableData> > 0.0 1.0 > 0.09 0.22 0.22 > 0.34 1.3 1.05 > 0.36 1.15 1.15 > </tableData> > </table> > </product> > </function> > > .... > > The above would cause the lift force to NOT be summed with the native moment calculated later. Note that I am not sure if this code has made it into FlightGear yet. > > I hope this helps. > > Jon > > > >  > _______________________________________________ > Jsbsimdevel mailing list > Jsbsimdevel@... > https://lists.sourceforge.net/lists/listinfo/jsbsimdevel > _______________________________________________ > The JSBSim Flight Dynamics Model project http://www.JSBSim.org _______________________________________________ > > >  > _______________________________________________ > Jsbsimdevel mailing list > Jsbsimdevel@... > https://lists.sourceforge.net/lists/listinfo/jsbsimdevel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ > 
From: Sean McLeod <sean@se...>  20141023 14:12:20

Thanks Jon and Tony So all the entries in the pitch axis (Cmalpha, Cmde, Cmq and Cmadot) are moments about the aero center (AeroRP). Has anyone else tried using the text book examples of the short period approximation and the resulting transfer functions and compared the output from those with the output from JSBSim to see how closely they match during the short period timeframe? Whether I make the cg and AeroRP coincident or not I don't get a very good match. Cheers Original Message From: Jon S. Berndt [mailto:jonsberndt@...] Sent: Thursday, October 23, 2014 3:24 PM To: 'Development issues' Subject: Re: [Jsbsimdevel] Converting aerodynamic coefficients from AeroRP to cg > Based on my work with my F14 model which has CM Basic (alpha) I don't > think that you can use the built in AeroRP approach if you have values > for CM(alpha) > > JSBSim works out the pitching moment due to Cl based upon the AeroRP  > CG moment arm; if your CM Basic is the usual "Pitch moment due to > alpha" > (see NASA CR1756 for an example) that is balanced by the offset of > the centre of pressure (AERORP) from the CG; i.e. building up the > yaw/pitch moments from a base value (CLBAS, CYBAS, CNBAS). If you use > the normal JSBSim AeroRP then it will double up the pitching moment as > it is effectively the same force that JSBSim is calculating based on > the offset of the Cl from the CoP. > > Richard I'm not sure I follow this. In the case where wind tunnel data is used as a basis for an aerodynamic model, the wind tunnel data will be delivered both in a specified reference frame, and given a specified aerodynamic reference point. The force coefficients are independent of location, of course. But the moments specified in the wind tunnel data report will be highly dependent on the moment reference center, because the moment that acts on the aircraft in flight is found this way (not sure of the sign convention at the moment): Moment = Moment_about_aero_center + force * (CG_position  AeroRP_position) Moment_about_aero_center is what you get from the wind tunnel report, couple with the AeroRP_position. The other part is calculated by JSBSim and summed with the first part, and it has been validated to work correctly (for quite a long time). This is essentially all there is for the calculation of aerodynamic moments. Sometimes in tech reports there is a lot less information given than would be desired  maybe that is what has happened in your case. In the case where you are given only a total aerodynamic moment, it is possible to prevent the force X moment_arm value from being summed into the mix. You would specify that the force should only be supplied at the CG. This is done with an attribute in the aerodynamic force calculation in an axis element. For instance: <axis name="LIFT"> <! Lift axis coefficients functions > <function name="aero/force/Lift_wbh" apply_at_cg="true"> <description> Lift due to alpha </description> <product> <property>aero/function/groundeffectfactorlift</property> <property>aero/qbararea</property> <table> <independentVar lookup="row">aero/alpharad</independentVar> <independentVar lookup="column">aero/stallhystnorm</independentVar> <tableData> 0.0 1.0 0.09 0.22 0.22 0.34 1.3 1.05 0.36 1.15 1.15 </tableData> </table> </product> </function> .... The above would cause the lift force to NOT be summed with the native moment calculated later. Note that I am not sure if this code has made it into FlightGear yet. I hope this helps. Jon  _______________________________________________ Jsbsimdevel mailing list Jsbsimdevel@... https://lists.sourceforge.net/lists/listinfo/jsbsimdevel _______________________________________________ The JSBSim Flight Dynamics Model project http://www.JSBSim.org _______________________________________________ 
From: Jon S. Berndt <jonsberndt@co...>  20141023 13:24:48

> Based on my work with my F14 model which has CM Basic (alpha) I don't > think that you can use the built in AeroRP approach if you have values > for CM(alpha) > > JSBSim works out the pitching moment due to Cl based upon the AeroRP  > CG moment arm; if your CM Basic is the usual "Pitch moment due to > alpha" > (see NASA CR1756 for an example) that is balanced by the offset of the > centre of pressure (AERORP) from the CG; i.e. building up the yaw/pitch > moments from a base value (CLBAS, CYBAS, CNBAS). If you use the normal > JSBSim AeroRP then it will double up the pitching moment as it is > effectively the same force that JSBSim is calculating based on the > offset of the Cl from the CoP. > > Richard I'm not sure I follow this. In the case where wind tunnel data is used as a basis for an aerodynamic model, the wind tunnel data will be delivered both in a specified reference frame, and given a specified aerodynamic reference point. The force coefficients are independent of location, of course. But the moments specified in the wind tunnel data report will be highly dependent on the moment reference center, because the moment that acts on the aircraft in flight is found this way (not sure of the sign convention at the moment): Moment = Moment_about_aero_center + force * (CG_position  AeroRP_position) Moment_about_aero_center is what you get from the wind tunnel report, couple with the AeroRP_position. The other part is calculated by JSBSim and summed with the first part, and it has been validated to work correctly (for quite a long time). This is essentially all there is for the calculation of aerodynamic moments. Sometimes in tech reports there is a lot less information given than would be desired  maybe that is what has happened in your case. In the case where you are given only a total aerodynamic moment, it is possible to prevent the force X moment_arm value from being summed into the mix. You would specify that the force should only be supplied at the CG. This is done with an attribute in the aerodynamic force calculation in an axis element. For instance: <axis name="LIFT"> <! Lift axis coefficients functions > <function name="aero/force/Lift_wbh" apply_at_cg="true"> <description> Lift due to alpha </description> <product> <property>aero/function/groundeffectfactorlift</property> <property>aero/qbararea</property> <table> <independentVar lookup="row">aero/alpharad</independentVar> <independentVar lookup="column">aero/stallhystnorm</independentVar> <tableData> 0.0 1.0 0.09 0.22 0.22 0.34 1.3 1.05 0.36 1.15 1.15 </tableData> </table> </product> </function> .... The above would cause the lift force to NOT be summed with the native moment calculated later. Note that I am not sure if this code has made it into FlightGear yet. I hope this helps. Jon 
From: Tony Peden <tony_jsbsim@co...>  20141023 13:08:46

No, it's not. The Coefficient data is derived around the RP and does not change with cg. The cg effects are calculated by computing the moment due to the lift, drag, and side force. The moment arm used is not the actual arm but the delta from the RP so that we get the incremental change due to cg. In an equation it's then: M=M(about RP) + deltaM(due to cg) For pitching moment.  Tony Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs. > On Oct 23, 2014, at 5:40 AM, Sean McLeod <sean@...> wrote: > > I'm using the B737 model that is included with JSBSim so I’m not really sure how the coefficients were derived. > > In the aerodynamics section there are entries for Cmalpha, Cmde, Cmq and Cmadot for the pitch axis. > > <axis name="PITCH"> > <function name="aero/coefficient/Cmalpha"> > <description>Pitch_moment_due_to_alpha</description> > <product> > <property>aero/qbarpsf</property> > <property>metrics/Swsqft</property> > <property>metrics/cbarwft</property> > <property>aero/alpharad</property> > <value>0.6</value> > </product> > </function> > > In FGAerodynamics.cpp I see JSBSim calculating moments based on the forces (lift, drag etc.) and the moment arm between the AeroRP and the cg and then adding in the moments from the pitch axis etc. without any adjustments in terms of the AeroRP and cg. > > vDXYZcg = MassBalance>StructuralToBody(Aircraft>GetXYZrp() + vDeltaRP); > > vMoments = vDXYZcg*vForces; // M = r X F > > for (axis_ctr = 0; axis_ctr < 3; axis_ctr++) { > for (ctr = 0; ctr < Coeff[axis_ctr+3].size(); ctr++) { > vMoments(axis_ctr+1) += Coeff[axis_ctr+3][ctr]>GetValue(); > } > } > > So any cg changes don’t have any affect on the moments produced in the pitch axis section, the only change in moments due to cg change are those calculated based on the lift, drag etc. forces. > > So in this 737 case do you think some of the pitching moments are being doubledup? > > Cheers > > Original Message > From: Richard Harrison [mailto:rjh@...] > Sent: Thursday, October 23, 2014 1:04 PM > To: Development issues > Subject: Re: [Jsbsimdevel] Converting aerodynamic coefficients from AeroRP to cg > > > > Bear in mind that JSBSim performs these transformations itself as the > > cg varies in flight – you do not normally have to do them yourself > > Based on my work with my F14 model which has CM Basic (alpha) I don't think that you can use the built in AeroRP approach if you have values for CM(alpha) > > JSBSim works out the pitching moment due to Cl based upon the AeroRP  CG moment arm; if your CM Basic is the usual "Pitch moment due to alpha" > (see NASA CR1756 for an example) that is balanced by the offset of the centre of pressure (AERORP) from the CG; i.e. building up the yaw/pitch moments from a base value (CLBAS, CYBAS, CNBAS). If you use the normal JSBSim AeroRP then it will double up the pitching moment as it is effectively the same force that JSBSim is calculating based on the offset of the Cl from the CoP. > > In my tests I used the AeroRP method and removed the coefficients for CLBAS(alpha,beta), CYBAS(alpha,beta) and CNBAS(alpha,beta) and the results were (subjectively) acceptable at low aoa; however as you get into the region where you start to experience cross coupling none of these effects will be present; > > This is of course all dependent on how the coefficients that you're using were originally built; so the AeroRP approach may well be sufficient if you just remove CM Basic(alpha). > > Richard > > >  > _______________________________________________ > Jsbsimdevel mailing list > Jsbsimdevel@... > https://lists.sourceforge.net/lists/listinfo/jsbsimdevel > _______________________________________________ > The JSBSim Flight Dynamics Model project http://www.JSBSim.org _______________________________________________ > >  > _______________________________________________ > Jsbsimdevel mailing list > Jsbsimdevel@... > https://lists.sourceforge.net/lists/listinfo/jsbsimdevel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ > 
From: Sean McLeod <sean@se...>  20141023 12:41:22

I'm using the B737 model that is included with JSBSim so I'm not really sure how the coefficients were derived. In the aerodynamics section there are entries for Cmalpha, Cmde, Cmq and Cmadot for the pitch axis. <axis name="PITCH"> <function name="aero/coefficient/Cmalpha"> <description>Pitch_moment_due_to_alpha</description> <product> <property>aero/qbarpsf</property> <property>metrics/Swsqft</property> <property>metrics/cbarwft</property> <property>aero/alpharad</property> <value>0.6</value> </product> </function> In FGAerodynamics.cpp I see JSBSim calculating moments based on the forces (lift, drag etc.) and the moment arm between the AeroRP and the cg and then adding in the moments from the pitch axis etc. without any adjustments in terms of the AeroRP and cg. vDXYZcg = MassBalance>StructuralToBody(Aircraft>GetXYZrp() + vDeltaRP); vMoments = vDXYZcg*vForces; // M = r X F for (axis_ctr = 0; axis_ctr < 3; axis_ctr++) { for (ctr = 0; ctr < Coeff[axis_ctr+3].size(); ctr++) { vMoments(axis_ctr+1) += Coeff[axis_ctr+3][ctr]>GetValue(); } } So any cg changes don't have any affect on the moments produced in the pitch axis section, the only change in moments due to cg change are those calculated based on the lift, drag etc. forces. So in this 737 case do you think some of the pitching moments are being doubledup? Cheers Original Message From: Richard Harrison [mailto:rjh@...] Sent: Thursday, October 23, 2014 1:04 PM To: Development issues Subject: Re: [Jsbsimdevel] Converting aerodynamic coefficients from AeroRP to cg > Bear in mind that JSBSim performs these transformations itself as the > cg varies in flight  you do not normally have to do them yourself Based on my work with my F14 model which has CM Basic (alpha) I don't think that you can use the built in AeroRP approach if you have values for CM(alpha) JSBSim works out the pitching moment due to Cl based upon the AeroRP  CG moment arm; if your CM Basic is the usual "Pitch moment due to alpha" (see NASA CR1756 for an example) that is balanced by the offset of the centre of pressure (AERORP) from the CG; i.e. building up the yaw/pitch moments from a base value (CLBAS, CYBAS, CNBAS). If you use the normal JSBSim AeroRP then it will double up the pitching moment as it is effectively the same force that JSBSim is calculating based on the offset of the Cl from the CoP. In my tests I used the AeroRP method and removed the coefficients for CLBAS(alpha,beta), CYBAS(alpha,beta) and CNBAS(alpha,beta) and the results were (subjectively) acceptable at low aoa; however as you get into the region where you start to experience cross coupling none of these effects will be present; This is of course all dependent on how the coefficients that you're using were originally built; so the AeroRP approach may well be sufficient if you just remove CM Basic(alpha). Richard  _______________________________________________ Jsbsimdevel mailing list Jsbsimdevel@...<mailto:Jsbsimdevel@...> https://lists.sourceforge.net/lists/listinfo/jsbsimdevel _______________________________________________ The JSBSim Flight Dynamics Model project http://www.JSBSim.org _______________________________________________ 
From: Tony Peden <tony_jsbsim@co...>  20141023 12:38:55

The better approach is to set the airplane cg to match the aerorp as that represents a real world situation.  Tony Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs. > On Oct 23, 2014, at 4:04 AM, Richard Harrison <rjh@...> wrote: > > >> Bear in mind that JSBSim performs these transformations itself as the >> cg varies in flight – you do not normally have to do them yourself > > Based on my work with my F14 model which has CM Basic (alpha) I don't > think that you can use the built in AeroRP approach if you have values > for CM(alpha) > > JSBSim works out the pitching moment due to Cl based upon the AeroRP  > CG moment arm; if your CM Basic is the usual "Pitch moment due to alpha" > (see NASA CR1756 for an example) that is balanced by the offset of the > centre of pressure (AERORP) from the CG; i.e. building up the yaw/pitch > moments from a base value (CLBAS, CYBAS, CNBAS). If you use the normal > JSBSim AeroRP then it will double up the pitching moment as it is > effectively the same force that JSBSim is calculating based on the > offset of the Cl from the CoP. > > In my tests I used the AeroRP method and removed the coefficients for > CLBAS(alpha,beta), CYBAS(alpha,beta) and CNBAS(alpha,beta) and the > results were (subjectively) acceptable at low aoa; however as you get > into the region where you start to experience cross coupling none of > these effects will be present; > > This is of course all dependent on how the coefficients that you're > using were originally built; so the AeroRP approach may well be > sufficient if you just remove CM Basic(alpha). > > Richard > > >  > _______________________________________________ > Jsbsimdevel mailing list > Jsbsimdevel@... > https://lists.sourceforge.net/lists/listinfo/jsbsimdevel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ > 
From: Richard Harrison <rjh@za...>  20141023 11:30:23

> Bear in mind that JSBSim performs these transformations itself as the > cg varies in flight – you do not normally have to do them yourself Based on my work with my F14 model which has CM Basic (alpha) I don't think that you can use the built in AeroRP approach if you have values for CM(alpha) JSBSim works out the pitching moment due to Cl based upon the AeroRP  CG moment arm; if your CM Basic is the usual "Pitch moment due to alpha" (see NASA CR1756 for an example) that is balanced by the offset of the centre of pressure (AERORP) from the CG; i.e. building up the yaw/pitch moments from a base value (CLBAS, CYBAS, CNBAS). If you use the normal JSBSim AeroRP then it will double up the pitching moment as it is effectively the same force that JSBSim is calculating based on the offset of the Cl from the CoP. In my tests I used the AeroRP method and removed the coefficients for CLBAS(alpha,beta), CYBAS(alpha,beta) and CNBAS(alpha,beta) and the results were (subjectively) acceptable at low aoa; however as you get into the region where you start to experience cross coupling none of these effects will be present; This is of course all dependent on how the coefficients that you're using were originally built; so the AeroRP approach may well be sufficient if you just remove CM Basic(alpha). Richard 
From: Alan Teeder <ajteeder@v...>  20141023 09:04:16

To get Cm at a different datum the conversion is this: CM’ = CM – CL * deltax/cbar + CD *deltaz/cbar where cbar is the standard mean chord, delatx is measured positive forwards, deltaz is measure positive downwards. Bear in mind that JSBSim performs these transformations itself as the cg varies in flight – you do not normally have to do them yourself unless you wish to change the reference point of your data. In other words if your original Cm data has a reference cg position, then use that cg position as the Aerorp, together with the original Cm data, as they form a matching set. Similar transformations are used for the yaw derivatives. Alan From: Sean McLeod Sent: Thursday, October 23, 2014 9:39 AM To: mailto:jsbsimdevel@... Subject: [Jsbsimdevel] Converting aerodynamic coefficients from AeroRP to cg Hi Given that the AeroRP and the current cg aren’t coincident, e.g. cgxin = 610.813 cgyin = 0 cgzin = 35.0654 aerorpxin = 625 aerorpyin = 0 aerorpzin = 24 How do I go about converting the aerodynamic coefficients like Cm_alpha, Cm_q so that they are relative to the cg? Do I simply need to subtract the AeroRP and cg and then do a cross product of that with the coefficients? Thanks    _______________________________________________ Jsbsimdevel mailing list Jsbsimdevel@... https://lists.sourceforge.net/lists/listinfo/jsbsimdevel _______________________________________________ The JSBSim Flight Dynamics Model project http://www.JSBSim.org _______________________________________________ 
From: Sean McLeod <sean@se...>  20141023 08:39:44

Hi Given that the AeroRP and the current cg aren't coincident, e.g. cgxin = 610.813 cgyin = 0 cgzin = 35.0654 aerorpxin = 625 aerorpyin = 0 aerorpzin = 24 How do I go about converting the aerodynamic coefficients like Cm_alpha, Cm_q so that they are relative to the cg? Do I simply need to subtract the AeroRP and cg and then do a cross product of that with the coefficients? Thanks 
From: Tony Peden <tony_jsbsim@co...>  20141021 21:09:36

Inertia cuts both ways. More makes it harder to start motion but it also makes it harder to stop. So I don't think more overshoot in rate is necessarily the wrong answer  Tony Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs. > On Oct 21, 2014, at 11:36 AM, Sean McLeod <sean@...> wrote: > > Hi David > > Thanks for the feedback. > > I checked earlier, there doesn’t seem to be an inertia/Iyy property that I could use to quickly check, so I set a breakpoint FGMassBalance::Run() and confirmed that the Iyy MOI is different to the one listed in the FDM which was 1.47e6. > > It’s now 1.54e6, presumably from the fuel: > > mJ += Propulsion>CalculateTankInertias(); > > My initial instinct was that the increased moment of inertia would result in a slower pitch response, so a lower overall pitch attitude after 10s and a lower pitch rate overall. > > Which would then more closely match the JSBSim response. > > However the response was the opposite. The higher moment of inertia case ended up with a larger overall pitch attitude after 10s and the pitch rate was higher after the first second or so. > > The increase in Iy resulted in a lower natural frequency, 1.28 rad/s as opposed to 1.31 rad/s and this can be seen in the pitch rate graph with the peak pitch rate occurring slightly later in time. > > However the increase in Iy also resulted in a slightly lower damping ratio, 0.6765 versus 0.6802 and this means that the peak pitch rate and the steady state pitch rate is higher which overall offsets the lower natural frequency and results in a final pitch attitude that is greater than the case with the lower Iy. > > <image001.png> > > <image004.png> > > <image002.png> > > <image003.png> > > So still busy on the drawing board ;) > > My other drawing board plan was to setup a JSBSim script to input an elevator pulse and then use the resulting logged data to work out the short period natural frequency and damping ratio and then use those as the coefficients to the Matlab transfer functions, essentially bypassing the longitudinal derivatives approach. > > Although ideally I would like to be able to use either approach. > > Cheers > > From: David Culp [mailto:dpculp@...] > Sent: Tuesday, October 21, 2014 7:21 PM > To: Development issues > Subject: Re: [Jsbsimdevel] JSBSim model compared to short period approximation > > The MOI value in the FDM is the total MOI minus pointmasses and fuel. I was going to suggest the total MOI is higher after JSBSim adds these in, but I see that a) the FDM config has no pointmasses defined, and b) depending on the age of your JSBSim build the fuel may have no MOI contribution. > > So, back to the drawing board. > > On Mon, Oct 20, 2014 at 12:04 PM, Sean McLeod <sean@...> wrote: > Hi > > In typical airliner FBW implementations there is gain scheduling based on the cg position as it changes during flight. > > “…tabulating the gains as a function of the computed air speed, highlift configuration and centre of gravity location.” > > However for the initial implementation the tests will all be short, a couple of minutes at most so there won't be any real cg change during flight. > > Any thoughts on why there isn't a closer match even after I specifically made the CG and ARP coincident in my test below? I'm guessing I've missed something else, or an assumption in the short period approximation transfer function method. > > In terms of the MOI I'm using the value in the FDM: > > <iyy unit="SLUG*FT2">1.473e+006</iyy> > > Which I assumed matched the initial payload configuration in the FDM, but actually I guess it probably only matches for the empty weight configuration? > > Regards > > P.S > I see you're the author of the 737 model that I'm using in JSBSim. > > Original Message > From: Dave Culp [mailto:daveculp@...] > Sent: Monday, October 20, 2014 8:45 PM > To: jsbsimdevel@... > Subject: Re: [Jsbsimdevel] JSBSim model compared to short period approximation > > Yes, I think adding the lift and drag vectors to your Matlab calcs will be neccessary since the CG and ARP will never be coincident. In an airliner the CG will usually start off forward (with full fuel) then move aft as fuel is burned, resulting in more pitch resposiveness. I remember in the E3A, if you let the fuel load get down to 20K or less before airrefueling, the pitch response got very touchy, making refueling a real chore. The flight engineer would send onloaded fuel to the center (forward) tank first to bring the CG forward and settle the beast down. > > Does the MOI you are using come straight from the FDM configuration file, or is it corrected for added payload and fuel? > > > Dave > > > > > On Mon, 20 Oct 2014 16:53:02 +0000 > Sean McLeod <sean@...> wrote: > > > Hi > > > > Sure enough, the aerodynamic center is behind the cg. > > > > cgxin = 610.813 > > cgyin = 0 > > cgzin = 35.0654 > > aerorpxin = 625 > > aerorpyin = 0 > > aerorpzin = 24 > > > > I guess it makes sense that the calculations of the longitudinal derivatives for the short period approximation and the resulting transfer functions assume that they’re based around the cg and not the aerodynamic center. > > > > So I guess I’ll need to modify the longitudinal derivatives that I use to calculate the coefficients for the transfer function to take into account the arm difference between the cg and the aerodynamic center. > > > > As a quick test I moved the aerorp to coincide with the cg and then compared JSBSim’s output with the Matlab output of the transfer functions. There is a much closer match now. > > > > Although looking at the pitch rate output it still looks as if there is some sort of additional pitch damping in the JSBSim model. > > > > Is this possibly due to the initial Cm_alpha moment based on the trim alpha of about 3 degrees whereas the short period approximation transfer functions assume a zero alpha trim case? > > > > > > [cid:image001.png@...] > > > > [cid:image002.png@...] > > > > Thanks > > > > From: David Culp [mailto:dpculp@...] > > Sent: Sunday, October 19, 2014 6:52 AM > > To: Development issues > > Subject: Re: [Jsbsimdevel] JSBSim model compared to short period > > approximation > > > > > > Is the aerodynamic center aft of the CG? If so, then the decrease in AOA will reduce your total pitching moment in the JSBSIM model. > > > > Dave > > >  > Dave Culp <daveculp@...> > >  > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ > Jsbsimdevel mailing list > Jsbsimdevel@... > https://lists.sourceforge.net/lists/listinfo/jsbsimdevel > _______________________________________________ > The JSBSim Flight Dynamics Model project http://www.JSBSim.org _______________________________________________ > >  > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ > Jsbsimdevel mailing list > Jsbsimdevel@... > https://lists.sourceforge.net/lists/listinfo/jsbsimdevel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ > > >  > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ > Jsbsimdevel mailing list > Jsbsimdevel@... > https://lists.sourceforge.net/lists/listinfo/jsbsimdevel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ > 
From: Sean McLeod <sean@se...>  20141021 18:36:32

From: David Culp <dpculp@gm...>  20141021 17:21:10

The MOI value in the FDM is the total MOI minus pointmasses and fuel. I was going to suggest the total MOI is higher after JSBSim adds these in, but I see that a) the FDM config has no pointmasses defined, and b) depending on the age of your JSBSim build the fuel may have no MOI contribution. So, back to the drawing board. On Mon, Oct 20, 2014 at 12:04 PM, Sean McLeod <sean@...> wrote: > Hi > > In typical airliner FBW implementations there is gain scheduling based on > the cg position as it changes during flight. > > “…tabulating the gains as a function of the computed air speed, highlift > configuration and centre of gravity location.” > > However for the initial implementation the tests will all be short, a > couple of minutes at most so there won't be any real cg change during > flight. > > Any thoughts on why there isn't a closer match even after I specifically > made the CG and ARP coincident in my test below? I'm guessing I've missed > something else, or an assumption in the short period approximation transfer > function method. > > In terms of the MOI I'm using the value in the FDM: > > <iyy unit="SLUG*FT2">1.473e+006</iyy> > > Which I assumed matched the initial payload configuration in the FDM, but > actually I guess it probably only matches for the empty weight > configuration? > > Regards > > P.S > I see you're the author of the 737 model that I'm using in JSBSim. > > Original Message > From: Dave Culp [mailto:daveculp@...] > Sent: Monday, October 20, 2014 8:45 PM > To: jsbsimdevel@... > Subject: Re: [Jsbsimdevel] JSBSim model compared to short period > approximation > > Yes, I think adding the lift and drag vectors to your Matlab calcs will be > neccessary since the CG and ARP will never be coincident. In an airliner > the CG will usually start off forward (with full fuel) then move aft as > fuel is burned, resulting in more pitch resposiveness. I remember in the > E3A, if you let the fuel load get down to 20K or less before > airrefueling, the pitch response got very touchy, making refueling a real > chore. The flight engineer would send onloaded fuel to the center > (forward) tank first to bring the CG forward and settle the beast down. > > Does the MOI you are using come straight from the FDM configuration file, > or is it corrected for added payload and fuel? > > > Dave > > > > > On Mon, 20 Oct 2014 16:53:02 +0000 > Sean McLeod <sean@...> wrote: > > > Hi > > > > Sure enough, the aerodynamic center is behind the cg. > > > > cgxin = 610.813 > > cgyin = 0 > > cgzin = 35.0654 > > aerorpxin = 625 > > aerorpyin = 0 > > aerorpzin = 24 > > > > I guess it makes sense that the calculations of the longitudinal > derivatives for the short period approximation and the resulting transfer > functions assume that they’re based around the cg and not the aerodynamic > center. > > > > So I guess I’ll need to modify the longitudinal derivatives that I use > to calculate the coefficients for the transfer function to take into > account the arm difference between the cg and the aerodynamic center. > > > > As a quick test I moved the aerorp to coincide with the cg and then > compared JSBSim’s output with the Matlab output of the transfer functions. > There is a much closer match now. > > > > Although looking at the pitch rate output it still looks as if there is > some sort of additional pitch damping in the JSBSim model. > > > > Is this possibly due to the initial Cm_alpha moment based on the trim > alpha of about 3 degrees whereas the short period approximation transfer > functions assume a zero alpha trim case? > > > > > > [cid:image001.png@...] > > > > [cid:image002.png@...] > > > > Thanks > > > > From: David Culp [mailto:dpculp@...] > > Sent: Sunday, October 19, 2014 6:52 AM > > To: Development issues > > Subject: Re: [Jsbsimdevel] JSBSim model compared to short period > > approximation > > > > > > Is the aerodynamic center aft of the CG? If so, then the decrease in > AOA will reduce your total pitching moment in the JSBSIM model. > > > > Dave > > >  > Dave Culp <daveculp@...> > > >  > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ > Jsbsimdevel mailing list > Jsbsimdevel@... > https://lists.sourceforge.net/lists/listinfo/jsbsimdevel > _______________________________________________ > The JSBSim Flight Dynamics Model project http://www.JSBSim.org > _______________________________________________ > > >  > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ > Jsbsimdevel mailing list > Jsbsimdevel@... > https://lists.sourceforge.net/lists/listinfo/jsbsimdevel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ > > 
From: Sean McLeod <sean@se...>  20141020 19:04:53

Hi In typical airliner FBW implementations there is gain scheduling based on the cg position as it changes during flight. “…tabulating the gains as a function of the computed air speed, highlift configuration and centre of gravity location.” However for the initial implementation the tests will all be short, a couple of minutes at most so there won't be any real cg change during flight. Any thoughts on why there isn't a closer match even after I specifically made the CG and ARP coincident in my test below? I'm guessing I've missed something else, or an assumption in the short period approximation transfer function method. In terms of the MOI I'm using the value in the FDM: <iyy unit="SLUG*FT2">1.473e+006</iyy> Which I assumed matched the initial payload configuration in the FDM, but actually I guess it probably only matches for the empty weight configuration? Regards P.S I see you're the author of the 737 model that I'm using in JSBSim. Original Message From: Dave Culp [mailto:daveculp@...] Sent: Monday, October 20, 2014 8:45 PM To: jsbsimdevel@... Subject: Re: [Jsbsimdevel] JSBSim model compared to short period approximation Yes, I think adding the lift and drag vectors to your Matlab calcs will be neccessary since the CG and ARP will never be coincident. In an airliner the CG will usually start off forward (with full fuel) then move aft as fuel is burned, resulting in more pitch resposiveness. I remember in the E3A, if you let the fuel load get down to 20K or less before airrefueling, the pitch response got very touchy, making refueling a real chore. The flight engineer would send onloaded fuel to the center (forward) tank first to bring the CG forward and settle the beast down. Does the MOI you are using come straight from the FDM configuration file, or is it corrected for added payload and fuel? Dave On Mon, 20 Oct 2014 16:53:02 +0000 Sean McLeod <sean@...> wrote: > Hi > > Sure enough, the aerodynamic center is behind the cg. > > cgxin = 610.813 > cgyin = 0 > cgzin = 35.0654 > aerorpxin = 625 > aerorpyin = 0 > aerorpzin = 24 > > I guess it makes sense that the calculations of the longitudinal derivatives for the short period approximation and the resulting transfer functions assume that they’re based around the cg and not the aerodynamic center. > > So I guess I’ll need to modify the longitudinal derivatives that I use to calculate the coefficients for the transfer function to take into account the arm difference between the cg and the aerodynamic center. > > As a quick test I moved the aerorp to coincide with the cg and then compared JSBSim’s output with the Matlab output of the transfer functions. There is a much closer match now. > > Although looking at the pitch rate output it still looks as if there is some sort of additional pitch damping in the JSBSim model. > > Is this possibly due to the initial Cm_alpha moment based on the trim alpha of about 3 degrees whereas the short period approximation transfer functions assume a zero alpha trim case? > > > [cid:image001.png@...] > > [cid:image002.png@...] > > Thanks > > From: David Culp [mailto:dpculp@...] > Sent: Sunday, October 19, 2014 6:52 AM > To: Development issues > Subject: Re: [Jsbsimdevel] JSBSim model compared to short period > approximation > > > Is the aerodynamic center aft of the CG? If so, then the decrease in AOA will reduce your total pitching moment in the JSBSIM model. > > Dave  Dave Culp <daveculp@...>  Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Jsbsimdevel mailing list Jsbsimdevel@... https://lists.sourceforge.net/lists/listinfo/jsbsimdevel _______________________________________________ The JSBSim Flight Dynamics Model project http://www.JSBSim.org _______________________________________________ 
From: Dave Culp <daveculp@co...>  20141020 18:39:58

Yes, I think adding the lift and drag vectors to your Matlab calcs will be neccessary since the CG and ARP will never be coincident. In an airliner the CG will usually start off forward (with full fuel) then move aft as fuel is burned, resulting in more pitch resposiveness. I remember in the E3A, if you let the fuel load get down to 20K or less before airrefueling, the pitch response got very touchy, making refueling a real chore. The flight engineer would send onloaded fuel to the center (forward) tank first to bring the CG forward and settle the beast down. Does the MOI you are using come straight from the FDM configuration file, or is it corrected for added payload and fuel? Dave On Mon, 20 Oct 2014 16:53:02 +0000 Sean McLeod <sean@...> wrote: > Hi > > Sure enough, the aerodynamic center is behind the cg. > > cgxin = 610.813 > cgyin = 0 > cgzin = 35.0654 > aerorpxin = 625 > aerorpyin = 0 > aerorpzin = 24 > > I guess it makes sense that the calculations of the longitudinal derivatives for the short period approximation and the resulting transfer functions assume that they’re based around the cg and not the aerodynamic center. > > So I guess I’ll need to modify the longitudinal derivatives that I use to calculate the coefficients for the transfer function to take into account the arm difference between the cg and the aerodynamic center. > > As a quick test I moved the aerorp to coincide with the cg and then compared JSBSim’s output with the Matlab output of the transfer functions. There is a much closer match now. > > Although looking at the pitch rate output it still looks as if there is some sort of additional pitch damping in the JSBSim model. > > Is this possibly due to the initial Cm_alpha moment based on the trim alpha of about 3 degrees whereas the short period approximation transfer functions assume a zero alpha trim case? > > > [cid:image001.png@...] > > [cid:image002.png@...] > > Thanks > > From: David Culp [mailto:dpculp@...] > Sent: Sunday, October 19, 2014 6:52 AM > To: Development issues > Subject: Re: [Jsbsimdevel] JSBSim model compared to short period approximation > > > Is the aerodynamic center aft of the CG? If so, then the decrease in AOA will reduce your total pitching moment in the JSBSIM model. > > Dave  Dave Culp <daveculp@...> 
From: Sean McLeod <sean@se...>  20141020 16:53:46

From: David Culp <dpculp@gm...>  20141019 04:52:16

Is the aerodynamic center aft of the CG? If so, then the decrease in AOA will reduce your total pitching moment in the JSBSIM model. Dave 
From: Jon S. Berndt <jonsberndt@co...>  20141019 02:22:25

From: David Culp <dpculp@gm...>  20141018 23:53:23

Yes. I'll take a look when I get back home and see what the geodesy mismatch is. Dave 
From: Sean McLeod <sean@se...>  20141018 21:29:00

From: Elias Tarasov <elias.tarasov@gm...>  20141016 08:10:29

FG is v.3.0.0. JSBSim is most likely v.1.0 Does it help? 
From: Jon S. Berndt <jonsberndt@co...>  20141015 20:24:37

JSBSim at one time sent geocentric latitude to FlightGear and FlightGear did the conversion. I am not sure which FlightGear expects to get over the network interface. Also, there is no geodetic longitude. Longitude does not change. Jon > Original Message > From: Dave Culp [mailto:daveculp@...] > Sent: Tuesday, October 14, 2014 4:51 PM > To: jsbsimdevel@... > Subject: Re: [Jsbsimdevel] FlightGear Geocentric/Geodetic/Ellipsoid > Issue > > Hello Elias, > > I believe the geodetic systems used by JSBSim and FlightGear have > changed over time, so it won't be possible to help you without knowing > which versions you are using. > > Dave > > > > > > On Tue, 14 Oct 2014 11:40:50 +0400 > Elias Tarasov <elias.tarasov@...> wrote: > > > Hello everybody! > > I realize that "FlightGear" questions are not "pure JSBSim" issues, > > but on the FG forum it is still no answer. > > So i decided to write it down here. > > > > I use JSBSim for external physic engine and FG for visualizing > system. > > Connection between them of course is a socket. > > It works well, everything is ok, except one thing. > > > > JSBSim sends to FG that data for lat/lon position in visual system: > > //FGOutputFG.cpp > > net>latitude = Propagate>GetLocation().GetGeodLatitudeRad(); // > > net>geodetic > > (radians). > > net>longitude = Propagate>GetLocation().GetLongitude(); > > > > It means that latitude is GEODETIC. > > Default KSFO location is: > > lat: 35.36 > > lon: 121.21 > > > > And i can clearly see that net>latitude == 35.359721 and > > net>longitude == 121.21000. It's just before sending to FG through > a socket. > > It's still everything clear and fine. > > > > But when my airplane appears on the "ground", position is: > > lat: 35.21 > > lon: 121.12 > > > > Okay, when i use different approach > > //FGOutputFG.cpp > > net>latitude = Propagate>GetLocation().GetLatitude(); > > net>longitude = Propagate>GetLocation().GetLongitude(); > > > > Now lat is GEOCENTRIC > > And now > > net>latitude == 35.17 > > net>longitude == 121.21 > > > > When an airplane appears on the "ground", postion is: > > lat: 35.10 > > lon 121.12 > > > > So, neither geocentric, nor geodetic positions from JSBSim as a > physic > > source are not exactly match FG visual system. > > There is also ellipsoid position system exists. In this case > > (ellipsoid > > model) lambda as longitude angle is also considered as EQUAL to the > > sphere longitude. > > But it is also clear, when we squeeze a rubber ball on a poles, not > > just lattitude changes slightly, but longitude as well. > > > > So the question is: how can i setup FG (or maybe JSBSim) to match > > position data? > > Appreciate any help, im stuck. > > Thanks a lot and best regards! > > >  > Dave Culp <daveculp@...> > >  >  > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push > notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ > Jsbsimdevel mailing list > Jsbsimdevel@... > https://lists.sourceforge.net/lists/listinfo/jsbsimdevel > _______________________________________________ > The JSBSim Flight Dynamics Model project http://www.JSBSim.org > _______________________________________________ 
From: Dave Culp <daveculp@co...>  20141014 22:47:17

Hello Elias, I believe the geodetic systems used by JSBSim and FlightGear have changed over time, so it won't be possible to help you without knowing which versions you are using. Dave On Tue, 14 Oct 2014 11:40:50 +0400 Elias Tarasov <elias.tarasov@...> wrote: > Hello everybody! > I realize that "FlightGear" questions are not "pure JSBSim" issues, but on > the FG forum it is still no answer. > So i decided to write it down here. > > I use JSBSim for external physic engine and FG for visualizing system. > Connection between them of course is a socket. > It works well, everything is ok, except one thing. > > JSBSim sends to FG that data for lat/lon position in visual system: > //FGOutputFG.cpp > net>latitude = Propagate>GetLocation().GetGeodLatitudeRad(); // geodetic > (radians). > net>longitude = Propagate>GetLocation().GetLongitude(); > > It means that latitude is GEODETIC. > Default KSFO location is: > lat: 35.36 > lon: 121.21 > > And i can clearly see that net>latitude == 35.359721 and net>longitude == > 121.21000. It's just before sending to FG through a socket. > It's still everything clear and fine. > > But when my airplane appears on the "ground", position is: > lat: 35.21 > lon: 121.12 > > Okay, when i use different approach > //FGOutputFG.cpp > net>latitude = Propagate>GetLocation().GetLatitude(); > net>longitude = Propagate>GetLocation().GetLongitude(); > > Now lat is GEOCENTRIC > And now > net>latitude == 35.17 > net>longitude == 121.21 > > When an airplane appears on the "ground", postion is: > lat: 35.10 > lon 121.12 > > So, neither geocentric, nor geodetic positions from JSBSim as a physic > source are not exactly match FG visual system. > There is also ellipsoid position system exists. In this case (ellipsoid > model) lambda as longitude angle is also considered as EQUAL to the sphere > longitude. > But it is also clear, when we squeeze a rubber ball on a poles, not just > lattitude changes slightly, but longitude as well. > > So the question is: how can i setup FG (or maybe JSBSim) to match position > data? > Appreciate any help, im stuck. > Thanks a lot and best regards!  Dave Culp <daveculp@...> 