[Flightgear-devel] TC ball
FWIW, the turn coordinator ball behaves *very* differently between JSBSim and YASim and another FDM I am playing with. All supposedly return accelerations in body axis in ft/sec squared. This means we can't create a single turn coordinator instrument who's ball behaves reasonably well for every FDM. Would it be better to force the FDM's to calculate a ball deflection in degrees/radians, or do we need to investigate why the body axis accelerations are so radically different for 3 different FDM's (who all are trying to model a C172.) If the FDM's do the work, then they all have to do the failure modeling too. It would be nicer to figure out what's going on ... it seems to be more than a simple coordinate system difference, unless JSBSim/YASim swap X/Y axes or something strange like that. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] TC ball
> FWIW, the turn coordinator ball behaves *very* differently between > JSBSim and YASim and another FDM I am playing with. All supposedly > return accelerations in body axis in ft/sec squared. This means we > can't create a single turn coordinator instrument who's ball behaves > reasonably well for every FDM. Body axes must be the coordinate frame used here, IMHO: +X forward, +Y out the right side, +Z down. The issue of whether to include the local acceleration due to gravity I'll leave for Tony to address - this is probably an issue, if my hunch is correct. > Would it be better to force the FDM's to calculate a ball deflection > in degrees/radians, No. That's not the job of the FDM, IMHO. > or do we need to investigate why the body axis > accelerations are so radically different for 3 different FDM's Yes. > (who > all are trying to model a C172.) If the FDM's do the work, then they > all have to do the failure modeling too. No! > It would be nicer to figure out what's going on ... Yes. > it seems to be more than a simple coordinate > system difference, unless JSBSim/YASim swap X/Y axes or something > strange like that. I believe we do. JSBSim uses the industry standard body axis system as described above. Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] TC ball
On Tue, 2002-10-15 at 20:12, Curtis L. Olson wrote: > FWIW, the turn coordinator ball behaves *very* differently between > JSBSim and YASim and another FDM I am playing with. All supposedly > return accelerations in body axis in ft/sec squared. IMO, what we should all be aiming at providing are accels very similar to what three body-axis aligned acclerometers mounted at the pilot eyepoint would give. The FDMs should provide to the TC only that which an airplane would provide, the raw forces or accels. This means we > can't create a single turn coordinator instrument who's ball behaves > reasonably well for every FDM. Well, I tried to compare the two, but got this for the yasim c172: > YASim solution results: Iterations: 404 Drag Coefficient: 18.9992 Lift Ratio: 87.1639 Cruise AoA: -0.124142 Tail Incidence: 0.440443 Approach Elevator: -1.00013 CG: -2.3, -0.0, 0.2 YASim SOLUTION FAILURE: Insufficient elevator to trim for approach [exit] I just used fgfs --aircraft=c172-yasim, is anything else needed? > Would it be better to force the FDM's to calculate a ball deflection > in degrees/radians, or do we need to investigate why the body axis > accelerations are so radically different for 3 different FDM's (who > all are trying to model a C172.) No and yes. If the FDM's do the work, then they > all have to do the failure modeling too. It would be nicer to figure > out what's going on ... it seems to be more than a simple coordinate > system difference, unless JSBSim/YASim swap X/Y axes or something > strange like that. > > Regards, > > Curt. > -- > Curtis Olson IVLab / HumanFIRST Program FlightGear Project > Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] > Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] TC ball
I'd tend to pay some attention to McFarland's document, but haven't had a chance to review it with this in mind. Might get to that today. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Tony Peden > Sent: Wednesday, October 16, 2002 8:28 AM > To: FGFS Devel > Subject: Re: [Flightgear-devel] TC ball > > > On Tue, 2002-10-15 at 20:12, Curtis L. Olson wrote: > > FWIW, the turn coordinator ball behaves *very* differently between > > JSBSim and YASim and another FDM I am playing with. All supposedly > > return accelerations in body axis in ft/sec squared. > > IMO, what we should all be aiming at providing are accels very similar > to what three body-axis aligned acclerometers mounted at the pilot > eyepoint would give. The FDMs should provide to the TC only that which > an airplane would provide, the raw forces or accels. > > > > > This means we > > can't create a single turn coordinator instrument who's ball behaves > > reasonably well for every FDM. > > Well, I tried to compare the two, but got this for the yasim c172: > > > YASim solution results: >Iterations: 404 > Drag Coefficient: 18.9992 >Lift Ratio: 87.1639 >Cruise AoA: -0.124142 >Tail Incidence: 0.440443 > Approach Elevator: -1.00013 > CG: -2.3, -0.0, 0.2 > YASim SOLUTION FAILURE: > Insufficient elevator to trim for approach > [exit] > > I just used fgfs --aircraft=c172-yasim, is anything else needed? > > > Would it be better to force the FDM's to calculate a ball deflection > > in degrees/radians, or do we need to investigate why the body axis > > accelerations are so radically different for 3 different FDM's (who > > all are trying to model a C172.) > > No and yes. > > If the FDM's do the work, then they > > all have to do the failure modeling too. It would be nicer to figure > > out what's going on ... it seems to be more than a simple coordinate > > system difference, unless JSBSim/YASim swap X/Y axes or something > > strange like that. > > > > > > Regards, > > > > Curt. > > -- > > Curtis Olson IVLab / HumanFIRST Program FlightGear Project > > Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] > > Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] TC ball
AFAICT, the behavior with JSBSim is reasonable. This is what I see at 93 kias, power for level flight, a left turn makes the ball go left and needs left rudder to recenter. Opposite for right turn. Same behavior (with similar magnitudes) observed at around 70 kias. At both speeds I did observe asymmetrical behavior, the ball tended to the left a small amount (but still within the vertical lines) in constant heading flight and may have been more sensitive to left turns than right. A power off descent at 70 knots tended to make it symmetric, so I suspect that the propwash effects are causing the aircraft trim at a small slip angle. On Wed, 2002-10-16 at 07:00, Jon Berndt wrote: > I'd tend to pay some attention to McFarland's document, but haven't had a > chance to review it with this in mind. Might get to that today. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Tony Peden > > Sent: Wednesday, October 16, 2002 8:28 AM > > To: FGFS Devel > > Subject: Re: [Flightgear-devel] TC ball > > > > > > On Tue, 2002-10-15 at 20:12, Curtis L. Olson wrote: > > > FWIW, the turn coordinator ball behaves *very* differently between > > > JSBSim and YASim and another FDM I am playing with. All supposedly > > > return accelerations in body axis in ft/sec squared. > > > > IMO, what we should all be aiming at providing are accels very similar > > to what three body-axis aligned acclerometers mounted at the pilot > > eyepoint would give. The FDMs should provide to the TC only that which > > an airplane would provide, the raw forces or accels. > > > > > > > > > > This means we > > > can't create a single turn coordinator instrument who's ball behaves > > > reasonably well for every FDM. > > > > Well, I tried to compare the two, but got this for the yasim c172: > > > > > YASim solution results: > >Iterations: 404 > > Drag Coefficient: 18.9992 > >Lift Ratio: 87.1639 > >Cruise AoA: -0.124142 > >Tail Incidence: 0.440443 > > Approach Elevator: -1.00013 > > CG: -2.3, -0.0, 0.2 > > YASim SOLUTION FAILURE: > > Insufficient elevator to trim for approach > > [exit] > > > > I just used fgfs --aircraft=c172-yasim, is anything else needed? > > > > > Would it be better to force the FDM's to calculate a ball deflection > > > in degrees/radians, or do we need to investigate why the body axis > > > accelerations are so radically different for 3 different FDM's (who > > > all are trying to model a C172.) > > > > No and yes. > > > > If the FDM's do the work, then they > > > all have to do the failure modeling too. It would be nicer to figure > > > out what's going on ... it seems to be more than a simple coordinate > > > system difference, unless JSBSim/YASim swap X/Y axes or something > > > strange like that. > > > > > > > > > > Regards, > > > > > > Curt. > > > -- > > > Curtis Olson IVLab / HumanFIRST Program FlightGear Project > > > Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] > > > Minnesota http://www.menet.umn.edu/~curt > http://www.flightgear.org > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > -- > Tony Peden > [EMAIL PROTECTED] > We all know Linux is great ... it does infinite loops in 5 seconds. > -- attributed to Linus Torvalds > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] TC ball
Tony Peden writes: > AFAICT, the behavior with JSBSim is reasonable. This is what I see > at 93 kias, power for level flight, a left turn makes the ball go left > and needs left rudder to recenter. Opposite for right turn. > > Same behavior (with similar magnitudes) observed at around 70 kias. > > At both speeds I did observe asymmetrical behavior, the ball tended to > the left a small amount (but still within the vertical lines) in > constant heading flight and may have been more sensitive to left turns > than right. A power off descent at 70 knots tended to make it > symmetric, so I suspect that the propwash effects are causing the > aircraft trim at a small slip angle. Tony, I apologize, I should have been more clear in my original message. The JSBSim drives the ball in a reasonable way, as does this other FDM I'm playing with. However, the scaling is about an order of magnitude different between the two, even though they supposedly report the accels in the same units and are modeling the same aircraft. YASim seems to drive the ball yet another order of magnitude further. It's not so much the behavior, but the range of motion and scaling. I found it strange since supposedly all three are reporting body axis accels in ft/sec^2 and it's the same code used in all three cases to compute ball motion based on these accels. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] TC ball
On Wed, 2002-10-16 at 07:27, Curtis L. Olson wrote: > Tony Peden writes: > > AFAICT, the behavior with JSBSim is reasonable. This is what I see > > at 93 kias, power for level flight, a left turn makes the ball go left > > and needs left rudder to recenter. Opposite for right turn. > > > > Same behavior (with similar magnitudes) observed at around 70 kias. > > > > At both speeds I did observe asymmetrical behavior, the ball tended to > > the left a small amount (but still within the vertical lines) in > > constant heading flight and may have been more sensitive to left turns > > than right. A power off descent at 70 knots tended to make it > > symmetric, so I suspect that the propwash effects are causing the > > aircraft trim at a small slip angle. > > Tony, I apologize, I should have been more clear in my original > message. The JSBSim drives the ball in a reasonable way, as does this > other FDM I'm playing with. However, the scaling is about an order of > magnitude different between the two, even though they supposedly > report the accels in the same units and are modeling the same > aircraft. YASim seems to drive the ball yet another order of > magnitude further. It's not so much the behavior, but the range of > motion and scaling. I found it strange since supposedly all three are > reporting body axis accels in ft/sec^2 and it's the same code used in > all three cases to compute ball motion based on these accels. Well, keep in mind that the accels driving the TC are calculated largely from the aero and propulsion models, so differences of degree between different models should not be surprising. Also, the FDM you are using probably has better aero data driving the lateral-directional dynamics (I'd guess it's based on Cessna flight test data). The lateral-directional terms in the JSBSim c172 are based largely on Roskam's estimates and pilot feedback, not actual data, so it doesn't surprise me that they don't agree. > > Regards, > > Curt. > -- > Curtis Olson IVLab / HumanFIRST Program FlightGear Project > Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] > Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TC ball
On 16 Oct 2002 07:58:22 -0700 Tony Peden <[EMAIL PROTECTED]> wrote: >On Wed, 2002-10-16 at 07:27, Curtis L. Olson wrote: >> Tony, I apologize, I should have been more clear in my original >> message. The JSBSim drives the ball in a reasonable way, as does this >> other FDM I'm playing with. However, the scaling is about an order of >> magnitude different between the two, even though they supposedly >> report the accels in the same units and are modeling the same >> aircraft. YASim seems to drive the ball yet another order of >> magnitude further. It's not so much the behavior, but the range of >> motion and scaling. > >Well, keep in mind that the accels driving the TC are calculated largely >from the aero and propulsion models, so differences of degree between >different models should not be surprising. Also, the FDM you are using >probably has better aero data driving the lateral-directional dynamics >(I'd guess it's based on Cessna flight test data). The lateral-directional terms in >the JSBSim c172 are based largely on >Roskam's estimates and pilot feedback, not actual data, so it doesn't >surprise me that they don't agree. There is no way there should be an order of magnitude difference because of this. Off the top pf my head I'd suggest we all ought to be within 10% of each other as far as acceleration at the pilot eyepoint is concerned. If Curt's external FDM says there is a 0.2g side accel at the pilot eyepoint, there is no way we should be saying it is 1g or greater. Need to look at McFarland, and see if he has something we can use to get a sanity check on our stuff. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TC ball
Curtis L. Olson wrote: > it seems to be more than a simple coordinate system difference, > unless JSBSim/YASim swap X/Y axes or something strange like that. Could be a bug, too. What exactly is the behavior you're seeing? The way the code in steam works is to look at the Y and Z "pilot acceleration" vectors and compute a "down" direction. Is it the direction that's wrong? * Not the same as coordinate acceleration, for the reasons discussed before. And it shouldn't use X, which is the longitudinal axis. The ball is constrained by its housing to the YZ plane. The steam.cxx code is the only place that uses these numbers, so a bug could easily have gone unnoticed. I haven't looked at the ball in a while, honestly, but I don't remember being surprised by anything looking wrong. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TC ball
Andy Ross writes: > Curtis L. Olson wrote: > > it seems to be more than a simple coordinate system difference, > > unless JSBSim/YASim swap X/Y axes or something strange like that. > > Could be a bug, too. What exactly is the behavior you're seeing? The > way the code in steam works is to look at the Y and Z "pilot > acceleration" vectors and compute a "down" direction. Is it the > direction that's wrong? > > * Not the same as coordinate acceleration, for the reasons discussed > before. And it shouldn't use X, which is the longitudinal axis. The > ball is constrained by its housing to the YZ plane. > > The steam.cxx code is the only place that uses these numbers, so a bug > could easily have gone unnoticed. I haven't looked at the ball in a > while, honestly, but I don't remember being surprised by anything > looking wrong. I haven't looked at YAsim closely, but FlightGear and this other fdm I'm working on both use nearly the same formula to calculate the ball position. The steam code uses A_Y_pilot / -A_Z_pilot to calculate turn coordinator ball position. This other fdm code bases it's calculation on forces, but also in the Y and Z directions. I'm guessing that Ay / Az is roughly proportional to Fy / Fz so these two methods won't be exactly the same, but should be similar enough. However, I'm not using the TC ball output, but instead passing this FDM's Ay and Az to the steam code so it get's processed the same as JSBsim. The results from both are good and apparently correct, but off by an order of magnitude in scaling. I guess I'll have to try to find some time to dump out the values and see if I can figure out what's going on. Perhaps someplace in one of the pipelines, a units conversion was screwed up (maybe meters vs. ft or something?) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TC ball
Tony Peden wrote: > Well, I tried to compare the two, but got this for the yasim c172: > YASim SOLUTION FAILURE: Are you sure you have current code and base package? I haven't looked at the 172 in a good while, and not much has changed. Do the other YASim aircraft work for you? Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TC ball
Curtis L. Olson wrote: > The JSBSim drives the ball in a reasonable way, as does this other FDM > I'm playing with. However, the scaling is about an order of magnitude > different between the two, even though they supposedly report the > accels in the same units and are modeling the same aircraft. YASim > seems to drive the ball yet another order of magnitude further. Hrm... yup, that sounds awfully wrong. Especially since units shouldn't matter. What the steam.cxx code is doing is taking the sideways acceleration and dividing it by the vertical acceleration to get a "down" direction. The units should drop out. I could be reporting accelerations in mph per year and it should still work. Could you stick some printfs in and get a feel for the numbers that are coming out? I mean, just print Ay and Az for each sim under broadly similar conditions and see if anything is obviously wrong. Unless you're doing aerobatics, Z should be very close to 32 and Y should be near zero. If this is happening in the air, it might not be the acceleration code at all, but the side-force-per-slip-angle behavior that is different. Try testing while doing constant rate turns on the ground to see if they behave the same there. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TC ball
Andy Ross writes: > Hrm... yup, that sounds awfully wrong. Especially since units > shouldn't matter. What the steam.cxx code is doing is taking the > sideways acceleration and dividing it by the vertical acceleration to > get a "down" direction. The units should drop out. I could be > reporting accelerations in mph per year and it should still work. In the past we've had trouble with accelerations because of different references. I have no physics background and a bad memory, so I'll use baby talk: basically, you have to consider whether the accelerations you're reporting include or exclude the earth's rotation (or something similar). Andy, Tony, or Jon can translate that into proper terminology (probably "inertial reference frame" or something similar) and comment on whether it has anything to do with the problem. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TC ball
On Wed, 2002-10-16 at 10:22, Andy Ross wrote: > Tony Peden wrote: > > Well, I tried to compare the two, but got this for the yasim c172: > > YASim SOLUTION FAILURE: > > Are you sure you have current code and base package? I haven't looked > at the 172 in a good while, and not much has changed. Do the other > YASim aircraft work for you? The a4 seems to work. FG, SG, and base were updated this morning. Possibly interesting (and unrelated) data point: I just ran FG on my box but displayed on my wife's. It has a GeForce 4mx ( a GeForce 2, as I understand it) and was getting ~30 fps. Maybe I just had low expectations, but that seems pretty good to me. > > Andy > > -- > Andrew J. RossNextBus Information Systems > Senior Software Engineer Emeryville, CA > [EMAIL PROTECTED] http://www.nextbus.com > "Men go crazy in conflagrations. They only get better one by one." > - Sting (misquoted) > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TC ball
On Wed, 2002-10-16 at 11:05, David Megginson wrote: > Andy Ross writes: > > > Hrm... yup, that sounds awfully wrong. Especially since units > > shouldn't matter. What the steam.cxx code is doing is taking the > > sideways acceleration and dividing it by the vertical acceleration to > > get a "down" direction. The units should drop out. I could be > > reporting accelerations in mph per year and it should still work. > > In the past we've had trouble with accelerations because of different > references. I have no physics background and a bad memory, so I'll > use baby talk: basically, you have to consider whether the > accelerations you're reporting include or exclude the earth's > rotation (or something similar). > > Andy, Tony, or Jon can translate that into proper terminology > (probably "inertial reference frame" or something similar) and comment > on whether it has anything to do with the problem. Well, Yasim and JSBSim do the bulk of their work in different sets of reference frames, but by specifying that these accels are in body axes, we are specifying the reference frame and so should end up with the same thing. > > > All the best, > > > David > > -- > David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TC ball
Curtis L. Olson wrote:
> I'm guessing that Ay / Az is roughly proportional to Fy / Fz so these
> two methods won't be exactly the same, but should be similar enough.
Well, a classic rule of physics is "F = m.a" ("force = mass x
acceleration") and that applies to the directions of the force and
acceleration as well as their magnitudes. Therefore at every instant Ay
/ Az must be precisely equal to Fy / Fz. Well, assuming that "Ay" is in
the same frame of reference as "Fy", etc.
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
