[Flightgear-devel] Internationalization?
Hi, FlightGear runs very fine on my customized Knoppix-CD. The remaining problems are related to FlightGear itself. Besides the flickering when starting full-screen I have another problem: I want to include FlightGear in a localized version. The kids here just speak German, Swiss German and Bad German :-) I tried starting FlightGear with the following syntax: $ fgfs --language=de But that did not help. Everything was in English. Any hints? Greetings Ronny ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on cockpit hardware
Jon Stockill wrote: The cadets of 127sqn ATC have decided they want to build themselves a flight sim, as I'm an instructor there, and they know of my involvement with flightgear the task has naturally fallen to me to help. I thought people may be interested in the basic cockpit structure that we're using - it's documented on this site: I'm planning on adding some rudder pedals using Alan King's design. It'll have to be a side stick using a standard joystick for now, but ultimately it'd be nice to get a proper floor mounted stick in there. ?? This puzzles me, what type of aircraft are you planning to simulate? It's and F-16 cockpit (which obviously needs a side stick). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: data/Scenery/w130n30/w123n37 light-pat-1.rgb, NONE, 1.1 baybridge-e-fb.ac, 1.1, 1.2 baybridge-fb.ac, 1.6, 1.7 baybridge-fb.xml, 1.4, 1.5 ggb-fb.xml, 1.3, 1.4
Quoting "Curtis L. Olson" <[EMAIL PROTECTED]>: > Frederic BOUVIER wrote: > > Thanks, glad to see you like it and it doesn't kill all the framerate. > > For people that are not following CVS updates, check out : > > http://perso.wanadoo.fr/frbouvi/flightsim/sanfran.htm > > The lights are brighter in FG than on jpeg but you will have an idea. > > > > That remind me that I don't have pictures of the GoldenGate nor > > the East span of Bay Bridge at night. If someone have some, > > I am interested. > > I'm waiting for the reflections of the bridge lights in the water. I saw > this in a commercial A320 sim once and it was a really neat effect. Yes, that would be nice. What I saw on a new A320 (in 1999): Standing at the peer at TOU you could se people walking by behing a shaded glass (so that you don't have to draw all details of people). But anyway, looked very nice. markus ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Oh dear
Norman Vine wrote: I just wish that the rest of the world was as generous with data :-) Very true. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Fwd: One time post to flightgear-devel]
William Earnest wrote: - F-16 Model: Back in november there was some discussion about an F-16 Model for high angle of attack simulation. While browsing the NASA Langley tech report server today, I stumbled across 2 interesting documents: 1.) the much cited 1979 "F16" report TP-1538 (used by Stevens/Lewis) is available on the web (= 31 MB !!). The report includes the full data table, and analysis of simulator flight and control laws for pitch, roll and yaw axis. However, be warned that these control laws might not really be related to the "real" control laws used on the production aircraft. One of the interesting things of the F-16 is that it rolls around it's velocity vector rather than the body axis to prevent high AOA to go into a large sideslip. This should be a challenge to model ... Erik BTW. Thanks for the message, it's quite educative. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalization?
Ronny Standtke wrote: Hi, FlightGear runs very fine on my customized Knoppix-CD. The remaining problems are related to FlightGear itself. Besides the flickering when starting full-screen I have another problem: I want to include FlightGear in a localized version. The kids here just speak German, Swiss German and Bad German :-) I tried starting FlightGear with the following syntax: $ fgfs --language=de But that did not help. Everything was in English. Any hints? The only place where this works (at the moment) is the list of command-line options (fgfs -h -v). It used to work for the menu also, but after a reorganization of the menu structure (which was needed badly) it got lost and hadn't been implemented afterward. It would be really nice if someone got this working again. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalization?
Erik Hofman wrote: > Ronny Standtke wrote: > > Hi, > > > > FlightGear runs very fine on my customized Knoppix-CD. The remaining problems > > are related to FlightGear itself. > > > > Besides the flickering when starting full-screen I have another problem: > > I want to include FlightGear in a localized version. The kids here just speak > > German, Swiss German and Bad German :-) I tried starting FlightGear with the > > following syntax: > > > > $ fgfs --language=de > > > > But that did not help. Everything was in English. Any hints? > > The only place where this works (at the moment) is the list of > command-line options (fgfs -h -v). > > It used to work for the menu also, but after a reorganization of the > menu structure (which was needed badly) it got lost and hadn't been > implemented afterward. > > It would be really nice if someone got this working again. A hard and dirty way to do that is to replace the content of the 'gui' folder in the base package by a translated one. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D aircraft model origins
> Surely that's an approximation, no? A rigid body's response to a > (force + torque) moment has 7 degrees of freedom (one value for mass, > and a 6DOF inertia tensor). A single offset doesn't have enough > complexity to capture that behavior. > > Andy The rigid body response to a force and torque can be in roll, pitch, yaw, and/or X, Y, Z translation. That's six DoF. How does the seventh degree come into play? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] fdm: fcs components
I have a pitch hold function modelled for the A320, activeted if Input = 0. If the A/C is in pitch-rate command, the Integrator for pitch hold is becoming more and more. How do I reset an Integrator component based on a switch like elevator-cmd-norm=0? thx markus PS: I hope you know what I mean, this seems to be not my day for explainations :)) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on cockpit hardware
Good morning, Actually, this begs the question of where to get a good, rugged floor mounted fighter stick. I only know of the jetliner yokes from precision flight controls. http://www.flypfc.com/entertainment%20products/jetliner.html Nickolas HeinMorgantown WV - Original Message - From: Erik Hofman To: FlightGear developers discussions Sent: Saturday, January 10, 2004 4:48 AM Subject: Re: [Flightgear-devel] More on cockpit hardware Jon Stockill wrote:> The cadets of 127sqn ATC have decided they want to build themselves a> flight sim, as I'm an instructor there, and they know of my involvement> with flightgear the task has naturally fallen to me to help. I thought> people may be interested in the basic cockpit structure that we're using -> it's documented on this site:> I'm planning on adding some rudder pedals using Alan King's design. It'll> have to be a side stick using a standard joystick for now, but ultimately> it'd be nice to get a proper floor mounted stick in there.?? This puzzles me, what type of aircraft are you planning to simulate?It's and F-16 cockpit (which obviously needs a side stick).Erik___Flightgear-devel mailing list[EMAIL PROTECTED]http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Oh dear
On Saturday 10 January 2004 01:43, Norman Vine wrote: > Roland Häder writes: > > > > On Saturday 10 January 2004 10:33 am, mat churchill wrote: > > > Worrying times though, > > > > > > A Google search for "publicly available maps" revealed this article: > > > > > > http://www.govexec.com/dailyfed/0901/092501p1.htm > > > > > > hmm > > > > "Big Brother Is Watching Us" > > FWIW when someone throws a punch at me I usually over react > a bit too but when the heat of the moment subsides I usually go > back to my more normal nature > > Governments and societies in general act the same way. > > I just wish that the rest of the world was as generous with data :-) > > http://seamless.usgs.gov/ > http://gisdata.usgs.gov > > Norman I've got to absolutely agree with you concerning the data made available by the USGS. I think it's probably the best organisation in the world, in that respect. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Saturday 10 January 2004 02:35, Jim Wilson wrote: [snip...] > Take a look at the p51d as an example of an aircraft with 0,0,0 at the nose. > In the file p51d-yasim-set.xml there are several "target offset" settings (one > for each view) that represent the distance from the nose to a very approximate > center of gravity. If you want to see the effect, then take those target > offsets out. > [snip...] > > Best, > > Jim I little light-bulb has just switched on here - just finally understood something about this issue myself :) I've been wanting to slightly re-position a couple of models with respect to the camera view but didn't I hadn't figured out how to do it yet. I can see how the a/c wouild have to be updated each time a new view is added, or possibly changed - how difficult would it be to include camera offsets in the 'model' or 'set' files that are used by all the non-VC views? Heh - to clarify that - it would be easy to add the data to the model - what I mean is how difficult would it be to make the code changes? LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Saturday 10 January 2004 03:09, Jon Berndt wrote:
> Paul:
>
> The root of the problem - though it is not really a "problem" - is that the
> FDM cares about modeling where the aircraft "is" in the world based on the
> aircraft CG, and the 3D model wants to be in the correct spot in the world,
> too, but how does one decide where to place it? Can one simply take the
> FDM-reported CG and place the aircraft (0,0,0) point there? No, because the
> various aircraft modelers can use any point they see fit to create their
> aircraft model. There is no universal convention for that.
>
> We discussed here in the group some time ago a convention. The result was
> that the forward most center portion of the aircraft would be the MODEL
> REFERENCE POINT ("MRP" hereafter, not to be confused with the AERODYNAMIC
> REFERENCE POINT). If the FDM can report the position of the MRP (and it
> can), the scene code on the FlightGear side can place the aircraft very
> nicely where it is supposed to be.
>
> This is a slight problem for the FDM, though. The FDM has to make sure that
> it knows where the MRP is IN RELATION TO THE CG. This is very important to
> remember that the FDM reports the lat/lon/alt of the aircraft CG. As fuel
> burns off the aircraft CG moves. So, the vector to the MRP will change with
> time. It's not a big problem, just a little work for the FDM - a little
> work that JSBSim does not currently do.
>
> I hope this clears things up more. Most of this thread will find it's way
> into some documentation I am writing!
>
> Jon
>
> --
>
> Project Coordinator
> JSBSim Flight Dynamics Model
> http://www.jsbsim.org
Perhaps some published 'Standards' might be a good idea - I remember the
earlier discussions about the model origin but didn't realise that a standard
had been established, and so in ignorance, I haven't been following it:(
Personally, I think some published standards would be a good idea and cut down
on the number of problems that occur, but I realise that it's more work to be
done...
LeeE
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Saturday 10 January 2004 02:35, Jim Wilson wrote: > Paul Surgeon <[EMAIL PROTECTED]> said: > > On Saturday, 10 January 2004 00:35, Erik Hofman wrote: > > > No, sorry. AC_EARORP is the published offset from CG to where the > > > forces act. For the F-16 that would be 35% chord (and CG is 25% chord). > > > > Just *maybe* I got it this time around. :) > > > > So any distance in the FDM is just an offset from (0,0,0)? > > > > If that is true I could offset all the distances in the FDM by an > > arbitrary value (let's say 1000 inches) and the FDM will still behave the > > same? I could pick a point 10 meters in front of the plane and measure > > everything from there too. > > In fact I could define all the distances using negative values as well > > (thinking in terms of 2nd Cartesian quadrant). > > > > The way I'm understanding all of this is that the nose of the aircraft > > CAN be used as the origin of the FDM but doesn't have to be. > > I could just as well work from the tail and just enter negative offsets. > > > > Correct? > > That is mostly correct. There is also a visual effect that occurs when you > render a 3D scene with the camera tracking an object. The point you are > tracking always appears stationary. Examples of this in FlightGear are the > "helicopter view" and the "tower view". If the origin is the nose of the > aircraft then the camera moves up and down with the nose. In the air or > from a distance this makes it look like the airplane is wagging like a > dog's tail from the nose, when it really is not. > > Take a look at the p51d as an example of an aircraft with 0,0,0 at the > nose. In the file p51d-yasim-set.xml there are several "target offset" > settings (one for each view) that represent the distance from the nose to a > very approximate center of gravity. If you want to see the effect, then > take those target offsets out. > > As you will see, this is a design weakness (my fault). The model > configuration will always need to be updated whenever more views are > configured. Note that this is a problem with the camera (the viewer code), > and not the model. It only needs to be defined per model because of the > different sizes aircraft come in. > > One solution would be to define this particular offset at a global viewer > level, and the other probably more useful solution would be to allow > parameters in the FDM config that defines the actual location where > lon/lat/alt is reported at as a distance on x/y/z axes from the aircraft's > nose. The 3D artist then only needs to know what those values are for > positioning the model and encoding the animations. > > Best, > > Jim Heh - after just a little more thought on this: wouldn't it be nice if the origin could be made dynamic? i.e it could be changed in flight. I think the most difficult part would be deciding on how to control it - you'd probably have to change into a special mode to do it because all the input devices are already being used to control the a/c. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalization?
On Saturday 10 January 2004 08:17, Ronny Standtke wrote: > Hi, > > FlightGear runs very fine on my customized Knoppix-CD. The remaining > problems are related to FlightGear itself. > > Besides the flickering when starting full-screen I have another problem: > I want to include FlightGear in a localized version. The kids here just > speak German, Swiss German and Bad German :-) I tried starting FlightGear > with the following syntax: > > $ fgfs --language=de > > But that did not help. Everything was in English. Any hints? > > Greetings > > Ronny Heh - it seem to me that most of the kids here (UK) just speak pretty bad english;) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] fdm: fcs components
This is a programming issue I'll tryu and get to ASAP. Today, though, is my twin boys' second birthday. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Hof Markus > Sent: Saturday, January 10, 2004 8:10 AM > To: [EMAIL PROTECTED] > Subject: [Flightgear-devel] fdm: fcs components > > > I have a pitch hold function modelled for the A320, activeted if > Input = 0. > If the A/C is in pitch-rate command, the Integrator for pitch > hold is becoming > more and more. > > How do I reset an Integrator component based on a switch like > elevator-cmd-norm=0? > > thx > markus > > PS: I hope you know what I mean, this seems to be not my day for > explainations > :)) > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D aircraft model origins
> Perhaps some published 'Standards' might be a good idea - I remember the > earlier discussions about the model origin but didn't realise > that a standard > had been established, and so in ignorance, I haven't been following it:( I'm working on it. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Jon S. Berndt wrote: > The rigid body response to a force and torque can be in roll, pitch, > yaw, and/or X, Y, Z translation. That's six DoF. How does the > seventh degree come into play? I wasn't clear: the rigid body response function takes a 6DOF space (force + torque) to another 6DOF space (position + orientation). But the space *of* those functions (that is: how many unique rigid bodies are there?) has 7 degrees of freedom. There is a mass, and a 3x3 inertia tensor. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Saturday 10 January 2004 15:23, Jon Berndt wrote: > > Perhaps some published 'Standards' might be a good idea - I remember the > > earlier discussions about the model origin but didn't realise > > that a standard > > had been established, and so in ignorance, I haven't been following it:( > > I'm working on it. Well done, that man:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on cockpit hardware
On Sat, 10 Jan 2004, Erik Hofman wrote: > ?? This puzzles me, what type of aircraft are you planning to simulate? > It's and F-16 cockpit (which obviously needs a side stick). Well the ideal would be a Grob Tutor - since that's what the cadets do most of their flying in :-) The basic cockpit layout works just as well as half a Grob - the only things which need changing are the panel angle, and height of the seat back - the structure was donated - I certainly wasn't going to refuse it because it was designed for the wrong aircraft :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Jim Wilson wrote: That is mostly correct. There is also a visual effect that occurs when you render a 3D scene with the camera tracking an object. The point you are tracking always appears stationary. Examples of this in FlightGear are the "helicopter view" and the "tower view". If the origin is the nose of the aircraft then the camera moves up and down with the nose. In the air or from a distance this makes it look like the airplane is wagging like a dog's tail from the nose, when it really is not. Take a look at the p51d as an example of an aircraft with 0,0,0 at the nose. In the file p51d-yasim-set.xml there are several "target offset" settings (one for each view) that represent the distance from the nose to a very approximate center of gravity. If you want to see the effect, then take those target offsets out. As you will see, this is a design weakness (my fault). The model configuration will always need to be updated whenever more views are configured. Note that this is a problem with the camera (the viewer code), and not the model. It only needs to be defined per model because of the different sizes aircraft come in. This does seem to have been an odd choice in how things are arranged. Take a basketball for a simple example. CG in the middle. Now hang it by a point on the sphere. Hang point is above, CG has a lever arm against it and makes it hang down. Now spin the basketball and balance it on a finger. The point of suspension is then below the CG, and gyroscopic effects keep things stable with the CG above the POS. Note that CG is not the reference point for what is holding the ball up. A plane 'hangs' on the wing. CG and control moment arms and everything else work around the point that it's hanging from in the air. CG is usually slightly forward, and a small down force on the tail. This makes a line from the CG to the tail through the POS that helps keep the plane more stablilized on the POS, like the fulcrum of a seesaw with some weight on each side. POS is the point all the calculations work around. It's also the point that the whole plane moves around when viewing. The 'nose' is a bad choice for either the viewing center or the FDM center. Everything works around the POS. The nose is just an arbitrary point how ever many feet ahead. That means there will be unneeded translations in all calculations since it's using a point that is not the actual 'center'. A point 27 miles to the right and 33 miles ahead of the POS could also be used, and the FDM calculate from that and the viewing model also translate it's view from that. The computer can do the calculations, it's just a pretty useless thing to do when both models actually center around the POS. Who cares about the point 5 or 10 feet ahead at the nose, any more than the point that's 27 miles right and 33 miles ahead? Until this thread it never would have occurred to me that another point was chosen as the basis for calculations or viewing. It can be done, but it adds extra calculations. POS end up being COL for a plane. It suspends itself by the aerodynamic forces it generates. But POS is a better general term for working out how things hang, it works on anything. Take a person. Your POS is through your hips. And your CG is roughly in your waist. We're slightly unbalanced, that's why we have to have feet and active correction to stand up. A planes nose pitches all over the place when flying level at different angles of attack. The forward vector of a plane in straight and level flight extends out from the POS regardless of angle of attack. While the POS of the plane changes slightly as the CG and and aerodynamic forces shift with attitude changes, it's mainly near COL of the wing. The nose and engine just pull the wing forward. The tail just gives leveraged control. The wing does almost all of the flying by itself in most planes, it takes some consideration and work to get any other part of the plane to help contribute to the flying of the plane and thus shift the POS a bit. I can sort of see the choice if this started from RC, since some people fly by the nose. But the best place of reference to fly a plane in 3D from outside is really the center of the wing, just where you'd expect from all the forces actually working around that point. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Alan King wrote: > The 'nose' is a bad choice for either the viewing center or the FDM > center. Except for the obvious fact that it's 100% unambiguous. It's not uncommon for the FDM definition and 3D model to be done by different authors. Take 21 people and ask them to identify the "POS" (or quarter chord point, or aerodynamic center, or even c.g.) and you'll get 21 different answers. Any child over six can find the tip of the nose on a photograph. Having the FDM coordinates and model coordinates match up is critically important for collision issues like gear compression. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Oh dear
Good morning, I've been told by my colleagues that you can also get worldwide terrain and texture data from Mapquest. Nickolas HeinMorgantown WV - Original Message - From: Lee Elliott To: FlightGear developers discussions Sent: Saturday, January 10, 2004 9:46 AM Subject: Re: [Flightgear-devel] Re: Oh dear On Saturday 10 January 2004 01:43, Norman Vine wrote:> Roland Häder writes:> >> > On Saturday 10 January 2004 10:33 am, mat churchill wrote:> > > Worrying times though,> > >> > > A Google search for "publicly available maps" revealed this article:> > >> > > http://www.govexec.com/dailyfed/0901/092501p1.htm> > >> > > hmm> >> > "Big Brother Is Watching Us"> > FWIW when someone throws a punch at me I usually over react> a bit too but when the heat of the moment subsides I usually go> back to my more normal nature> > Governments and societies in general act the same way.> > I just wish that the rest of the world was as generous with data :-)> > http://seamless.usgs.gov/> http://gisdata.usgs.gov> > NormanI've got to absolutely agree with you concerning the data made available by the USGS. I think it's probably the best organisation in the world, in that respect.LeeE___Flightgear-devel mailing list[EMAIL PROTECTED]http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Saturday 10 January 2004 15:47, Andy Ross wrote: > Alan King wrote: > > The 'nose' is a bad choice for either the viewing center or the FDM > > center. > > Except for the obvious fact that it's 100% unambiguous. It's not > uncommon for the FDM definition and 3D model to be done by different > authors. Take 21 people and ask them to identify the "POS" (or > quarter chord point, or aerodynamic center, or even c.g.) and you'll > get 21 different answers. Any child over six can find the tip of the > nose on a photograph. > > Having the FDM coordinates and model coordinates match up is > critically important for collision issues like gear compression. > > Andy The tip of the nose is fine with me but we need to clarify whether the tip includes any nose-mounted pitots or probes. I'm specifically thinking about the TSR2 here, which has a nose mounted probe but there will probably be others, if there aren't already. This is probably more of an issue for experimental a/c as most production a/c seem to have them elsewhere, which makes sense to me as it'll cut down the ground-space requirements. I'd be inclined to ignore any probes and specify the tip of the nose 'cone', or fuselage. I'm not sure that nose mounted probes are always drawn to the correct size in the drawings we use for modelling, so it's probably not a good idea to use them as reference points. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Lee Elliott wrote: > The tip of the nose is fine with me but we need to clarify whether > the tip includes any nose-mounted pitots or probes. Sure. Obviously it doesn't *really* matter. But picking some unambiguous, obvious point on the fuselage just seems much more sane to me than trying to explain the choice of an aerodynamic parameter for a coordinate origin. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Saturday 10 January 2004 16:08, Andy Ross wrote: > Lee Elliott wrote: > > The tip of the nose is fine with me but we need to clarify whether > > the tip includes any nose-mounted pitots or probes. > > Sure. Obviously it doesn't *really* matter. But picking some > unambiguous, obvious point on the fuselage just seems much more sane > to me than trying to explain the choice of an aerodynamic parameter > for a coordinate origin. > > Andy Definitely - I don't think I could accurately position a model to an aerodynamic center. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Saturday, 10 January 2004 17:47, Andy Ross wrote: > Having the FDM coordinates and model coordinates match up is > critically important for collision issues like gear compression. That is exactly my concern which made me ask about the FDM and model origins in the first place. I don't mind if the origin of the FDM and model can be adjustable but once they are set they MUST be static regardless of CG changes. Just because the aircraft may have burnt some fuel off the FDM should still line up with the model. From what I understand that is not the case but I'll re-read the entire thread again to make sure I haven't misunderstood the whole issue. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim turbulence in CVS
Andy Ross wrote: I just commited a turbulence model that I wrote over the vacation. It seems to work pretty well, but I'd be curious to see what other people think. Tuning it is more subjective than I had expected. Thank you for doing this. I gave the turbulence a test drive with these command lines: fgfs --aircraft=j3cub --altitude=1000 --turbulence=0.5 fgfs --aircraft=j3cub --altitude=1000 --turbulence=1.0 It's very nicely done, but I have some suggestions for tuning. First, the intensity is far too low. At 0.5, I wasn't sure if turbulence was working, and at 1.0 (maximum), I was still able to control the aircraft easily. Here are the Canadian criteria for reporting turbulence, which should match pretty closely with those of other ICAO countries: http://www.megginson.com/Aviation/turbulence.html At 1.0, the turbulence is still only moderate right now -- at 1.0 we should be inducing extreme (beyond severe) turbulence, throwing the plane completely out of control, as might happen inside a cumulo-nimbus cloud. My other suggestion is to fade out turbulence a bit near the ground, say, in the last 50 feet or so (at the point, the main problem is wind gusts). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Saturday 10 January 2004 16:34, Paul Surgeon wrote: > On Saturday, 10 January 2004 17:47, Andy Ross wrote: > > Having the FDM coordinates and model coordinates match up is > > critically important for collision issues like gear compression. > > That is exactly my concern which made me ask about the FDM and model > origins in the first place. > > I don't mind if the origin of the FDM and model can be adjustable but once > they are set they MUST be static regardless of CG changes. > Just because the aircraft may have burnt some fuel off the FDM should still > line up with the model. > From what I understand that is not the case but I'll re-read the entire > thread again to make sure I haven't misunderstood the whole issue. > > Paul It does work - one of the things I have to remember to check is that the plane doesn't tip up backwards on the ground when there's no fuel in it - it can happen :) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D aircraft model origins
Paul wrote: > I don't mind if the origin of the FDM and model can be adjustable but once > they are set they MUST be static regardless of CG changes. The Model Reference Point (MRP) must be static, yes. The CG will change, but so will the vector from the CG to the MRP. It balances out. When the FDM reports the MRP to FlightGear, everything will be OK. > Just because the aircraft may have burnt some fuel off the FDM > should still line up with the model. > From what I understand that is not the case but I'll re-read the > entire thread again to make sure I haven't misunderstood the whole issue. Here's an example (which will also go into the documentation that I am writing as we speak): You are in an A-10 with a maverick on one side. You have an aircraft CG (which the FDM is reporting the position of) and an MRP, which the FDM is also supplying to FlightGear. The MRP is given to FlightGear in lat/lon/alt. The FDM calculates that position because it knows where the CG is absolutely, as well as where the MRP is relatively. Since the 3D model builder and the flight modeler for the aircraft agree on the MRP (we hope!) the aircraft can be placed properly in the scene. Now, say we are stationary on the runway and we drop the missile. The CG shifts instantaneously - however the FDM will not report a different position because no force has caused an acceleration which in turn could not have been integrated to produce ultimately a change in position. This is a flaw that may need to be addressed. In any case, let's assume that the FDM *did* shift the reported lat/lon/alt of the CG as reported to FlightGear by the equal and opposite amount that dropping the Maverick resulted in. The vector to the MRP would be shifted by an equal and opposite amount, and the end result would be that the model would not "jump" and the FDM and the model would agree. In the case of smooth flight where fuel burns off slowly, it's not so critical. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim turbulence in CVS
David Megginson wrote: > First, the intensity is far too low. At 0.5, I wasn't sure if > turbulence was working, and at 1.0 (maximum), I was still able to > control the aircraft easily. Hrm, so it is. :) I must have changed something right at checkin. My memory of the final code is that the Cub would be flipped on its back by max turbulence while on the ground, and that the jets would bounce around noticeably on their gear. If you want to try playing around with the internals, you'll find a MAX_TURBULENCE value in Turbulence.cpp. This defines the upper bound for the velocity field. You can also try tweaking MEANINGFUL_GENS by one or two. This is harder to explain: if you set this low, then all of the energy goes into the high frequency components, and the velocity can swing betwenn +/- MAX_TURBULENCE faster. If you set it high, then more of the "bandwidth" goes into the long-wavelength variation, and there isn't as much spacial "bump" to the turbulence field. There's another secret constant in the rate parameter to the Turbulence::update() function. Right now, it presumes that the "Hz" parameter refers to the highest frequency component of the Perlin field, so there's a hardcoded factor of two. But that doesn't have any fundamental meaning. You could try tweaking this to get faster or slower progression of the field through time. > My other suggestion is to fade out turbulence a bit near the ground, > say, in the last 50 feet or so (at the point, the main problem is > wind gusts). Indeed. Certainly the vertical component of the turbulence field needs to go to zero at the ground. This isn't done yet. I think this is consistent with your description; "wind gusts" aren't quantitatively different from turbulence along the ground plane (someone correct me if I'm wrong). I'm not quite certain of the values to use. I found a reference to the "Dryden" turbulence model, which attenuates *all* turbulence to zero at the ground (clearly wrong; take a walk on a gusty day to see the proof), but drops the horizontal component along a steeper curve than the vertical. I might try something along these lines, but fudge the intercept so that the horizontal component is non-zero at ground level. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] AI satellite
I was flying from Philly to Chicago yesterday morning at O'Dark Thirty and saw the Space Station fly by. It was slightly brighter then the planet it was going past (Jupiter? Saturn?), and I assume it was the ISS rather than some other satellite. Anyway, does anyone think an AISatellite class would be useful? I don't know if placing an object in FlightGear at low Earth orbit would work. I don't know if it would reflect the sun, like the real satellite does, or whether this would have to be faked by lighting it. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AI satellite
On Saturday 10 January 2004 17:36, David Culp wrote: > I was flying from Philly to Chicago yesterday morning at O'Dark Thirty and > saw the Space Station fly by. It was slightly brighter then the planet it > was going past (Jupiter? Saturn?), and I assume it was the ISS rather than > some other satellite. Anyway, does anyone think an AISatellite class would > be useful? I don't know if placing an object in FlightGear at low Earth > orbit would work. I don't know if it would reflect the sun, like the real > satellite does, or whether this would have to be faked by lighting it. > > > > Dave Heh - I was thinking about trying to model some Northern/Southern Lights but I haven't got into the scenery side of FG yet, and currently, thanks to ATI's drivers, FG crashes if I try to fly at night:/. Using the fade/blend texture & animation methods, it could look quite nice. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AI satellite
On Saturday 10 January 2004 17:45, Lee Elliott wrote: > On Saturday 10 January 2004 17:36, David Culp wrote: > > I was flying from Philly to Chicago yesterday morning at O'Dark Thirty > > and saw the Space Station fly by. It was slightly brighter then the > > planet it was going past (Jupiter? Saturn?), and I assume it was the ISS > > rather than some other satellite. Anyway, does anyone think an > > AISatellite class would be useful? I don't know if placing an object in > > FlightGear at low Earth orbit would work. I don't know if it would > > reflect the sun, like the real satellite does, or whether this would have > > to be faked by lighting it. > > > > > > > > Dave > > Heh - I was thinking about trying to model some Northern/Southern Lights > but I haven't got into the scenery side of FG yet, and currently, thanks to > ATI's drivers, FG crashes if I try to fly at night:/. > > Using the fade/blend texture & animation methods, it could look quite nice. > Infact, it could be done using the AI ship stuff, providing the texture/ animation features will still work. The model would be pretty simple - just a wavy curtain shape - so a strip of rectangles should suffice. If each rectangle was an individual object, each one could be 'hinge' joined using cascaded rotate functions, so the shape could be changed over time. The textures would be transparent and emissive, so they could fade in and out, and then the AI function could slowly move them around the polar regions. I'd have a go myself but, as I mentioned, I'm currently getting crashes when trying to fly in darkness. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Sat, 10 Jan 2004 07:20:07 -0800, Andy Ross <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Jon S. Berndt wrote: > > The rigid body response to a force and torque can be in roll, pitch, > > yaw, and/or X, Y, Z translation. That's six DoF. How does the > > seventh degree come into play? > > I wasn't clear: the rigid body response function takes a 6DOF space > (force + torque) to another 6DOF space (position + orientation). But > the space *of* those functions (that is: how many unique rigid bodies > are there?) has 7 degrees of freedom. There is a mass, and a 3x3 > inertia tensor. ..and this assumes a rigid "glass hard" body, or can the body now flex on loads? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] fdm: fcs components
Hi, enjoy your kids birthday. I got one Version running, but don't know if you
like this way of implementaion, You maybe want to create an extra Node for this
property.
I took the keyword: RESET and any other input than 0 resets and holds the
integrator to 0.
Here is the patch:
[EMAIL PROTECTED]:~/dl/fltgear/FlightGear-0.9.3/src/FDM/JSBSim/filtersjb$ diff -2 -u
FGFilter.cpp FGFilter.cpp.orig
--- FGFilter.cpp2004-01-10 20:04:25.0 +0100
+++ FGFilter.cpp.orig 2004-01-10 19:44:09.0 +0100
@@ -94,10 +94,4 @@
OutputNode = PropertyManager->GetNode( sOutputIdx );
}
-else if (token == "RESET")
-{
- // Set the RESET as INPUT[1]
-*AC_cfg >> token;
-InputNodes.push_back( resolveSymbol(token) );
-}
else cerr << "Unknown filter type: " << token << endl;
}
@@ -177,13 +171,5 @@
break;
case eIntegrator:
- if( InputNodes.size() == 2 )
- {
- if ( ( InputNodes[1]->getDoubleValue() ) == 0 )
- Output = Input * ca + PreviousInput1 * ca +
PreviousOutput1;
- else
- Output = 0;
- }
- else
- Output = Input * ca + PreviousInput1 * ca +
PreviousOutput1;
+Output = Input * ca + PreviousInput1 * ca + PreviousOutput1;
break;
case eUnknown:
Quoting Jon Berndt <[EMAIL PROTECTED]>:
> This is a programming issue I'll tryu and get to ASAP. Today, though, is my
> twin boys' second birthday.
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of Hof Markus
> > Sent: Saturday, January 10, 2004 8:10 AM
> > To: [EMAIL PROTECTED]
> > Subject: [Flightgear-devel] fdm: fcs components
> >
> >
> > I have a pitch hold function modelled for the A320, activeted if
> > Input = 0.
> > If the A/C is in pitch-rate command, the Integrator for pitch
> > hold is becoming
> > more and more.
> >
> > How do I reset an Integrator component based on a switch like
> > elevator-cmd-norm=0?
> >
> > thx
> > markus
> >
> > PS: I hope you know what I mean, this seems to be not my day for
> > explainations
> > :))
> >
> >
> > ___
> > Flightgear-devel mailing list
> > [EMAIL PROTECTED]
> > http://mail.flightgear.org/mailman/listinfo/flightgear-devel
>
>
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
>
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Andy Ross wrote: Alan King wrote: The 'nose' is a bad choice for either the viewing center or the FDM center. Except for the obvious fact that it's 100% unambiguous. It's not uncommon for the FDM definition and 3D model to be done by different authors. Take 21 people and ask them to identify the "POS" (or quarter chord point, or aerodynamic center, or even c.g.) and you'll get 21 different answers. Any child over six can find the tip of the nose on a photograph. If the visual model doesn't have EXACTLY the same distance from the nose to the POS as the FDM, then they are out of line, period. No common point of reference is going to make there be any LESS error if it's distance from the POS is not JUST as exact in visual and FDM models. And if you do have error from one model to the other, using the nose will actually exaggerate the error, the longer lever arm from center for the error will actually exaggerate things. It may be a bit easier see the nose visually but the internal models both best work from the POS. There isn't a CHOICE on whether it takes more calculations or not, it takes more to get out to that point of reference and back. Any amount of ambiguity between models is EXACTLY the same but worse from extra translating when using the nose. If we both didn't use "EXACTLY 6" feet back from the nose as our centers, then there is just as much error as if we both didn't use the same "EXACTLY 0" as the center. You can't have your visual distance 5 feet, your FDM distance 6 feet, and have the models match correctly. The nose is just an arbitrary reference point, that child over six won't be any more likely to match the things that really need matching from referencing the nose than by finding the center directly. Couldn't matter less if you found the nose correctly if you didn't find it's offset from the POS correctly. Physics doesn't worry much about what point is easy for you to match up when it's keeping a plane in the air. A plane flies from this central point both visually AND aerodynamically. And so should the models. If any other point is used then there is extra translating required or the models have errors. And it's easy to introduce other errors in all the extra translating. The centers need to match for no error. Using the nose REQUIRES that you have the visual distance from center exactly matched to what the flight model is calculating for distance to center. If it's not then you have a geometry error in the point about which your visual rotates on the axes. No way around it. Using the nose as a point of reference does not magically relieve you of the obligation of knowing exactly where the POS is to match them. You still have error if you don't. And it has worse effects since the error is geared by the distance from the origin. I was simply stating the fact that the best point of calculations for BOTH visual and FDM models is the POS. This has nothing to do at all with what is easier to line up. That point is the simplest for all calculations. Working from any other point for calculations adds translational offsets to the calculations, there isn't any way around it. If you line up by the nose point, then you have to make quite sure that the distance from the nose point to the POS for both models is exactly the same. You can fly an RC plane by looking at the nose for reference. But you can also bet that those who do can't fly 3D nearly as well as those who fly by looking into the center of the wing. That isn't my opinon, it's me relating my observation of the fact that it's much easier to fly a plane from the center point. It is the better reference point because it doesn't have all the translational offsets introduced by looking at the nose. When flying any plane at high angle of attack, the nose is a terrible place of reference compared to the POS. The wing moves straight forward in level flight at any angle of attack without changing height. The nose moves all over the map, changing its distance from and angle to the line of motion like mad. It's offset from the real center makes it a poor choice for calculations. It is FINE to use the nose to match for a point of reference, IF both then reference it to the POS correctly. Then just do the translation once and use POS for both models calculations. BUT, there is no 'extra' better matching from using the nose if it isn't matched to the POS. Take one of your models referenced by the nose. Now multiply it's visual size by 10, leave the FDM alone. It'll look silly flying. Now have the common reference be the POS. Any visual size scaling looks great without any adjustment to the FDM. It is the much better reference point to work from for matching the visual and FDM models. It is where they both agree with the least calculations and problems from any errors. Matching your nose just SHIFTS your error over if you don't have your visu
Re: [Flightgear-devel] 3D aircraft model origins
Lee Elliott wrote: Definitely - I don't think I could accurately position a model to an aerodynamic center. LeeE Then your model's relationship to how it flies is just as inaccurate. It isn't by your or my or anyone else's vote or choice. If the NOSE agrees in both, and you haven't gotten the distance from NOSE to POS correct and exactly the same in both models, then you have a GEOMETRY error between them when it moves. Try to show me how having the nose referenced relieves you of having to know and have the same distance from nose to center in both FDM and the visual. You can't. How would you expect the FDM model to magically get it's relationship from it's nose to where all the calculations are done matched to your model's visual distance from it's nose to where all the calculations should be? You can use the nose all you like. If your distance from your nose to the center isn't exactly the same as what the FDM thinks it is, then your models don't match and your visual is off by just as much as that inaccuracy you couldn't figure for the POS. There is no choice in the matter. The center of the aircraft is the center of the aircraft and is the simplest point of agreement between the visual and the FDM, and simplest point of calculations for both. You can use the nose as a reference point, but you still better make very sure your nose is the same distance visually from POS as it is calculated in the FDM if you want them to match. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D aircraft model origins
>There is no choice in the matter. The center of the aircraft is the center > of the aircraft and is the simplest point of agreement between the visual and > the FDM, and simplest point of calculations for both. You can use the nose as a > reference point, but you still better make very sure your nose is > the same distance visually from POS as it is calculated in the FDM if you > want them to match. Alan: I appreciate your thoughtful inputs, but I suspect you are missing the point, which has a long history here. Initially, we had very large problems and obvious errors in placing the 3D model of the aircraft because the FDM was tracking the CG and the 3D modelers were creating their models based on all sorts of different frames of reference. Then FlightGear was placing the 3D models in the scene with the 3D model origin (0,0,0) at the FDM-reported CG. If the aircraft was oriented at PRY = (0,0,0) there was only a translational error. If the aircraft had any nonzero rotational component, things were magnified. When the aircraft *flight* modelers create a flight model for an aircraft, there is a prerequisite for having intimate knowledge of the aircraft layout. Usually, that means we have a 3-View drawing and oftentimes we have coordinate points of specific items on the aircraft in the manufacturers structural frame (X positive out the back, Y positive out the right side, origin often near the nose or just ahead of it). The aircraft modeler is free to choose their model origin, but the axes must line up with the structural frame. The 3D modeler has no clue about (and probably doesn't care to know about) where the CG is - and that's fine. The FDM and the 3D model, though, *do* need to agree on a common MRP (Model Reference Point) that the FDM can supply to the FlightGear scene code for proper placement of an aircraft. Once that point is agreed upon, it's not a big problem at all for the FDM to send to FlightGear the exact location in world space of the MRP. No matter what the orientation of the aircraft, the 3D model will always have its CG in the correct place if the FDM properly reports to FlightGear the real-world location of the MRP. We (FDM) can do this because, as I've said before, we know where the CG is, and we know where the MRP is in reference to the CG. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Sat, 2004-01-10 at 12:14, Alan King wrote: > Andy Ross wrote: > > > Alan King wrote: > > > >>The 'nose' is a bad choice for either the viewing center or the FDM > >>center. > > > > > > Except for the obvious fact that it's 100% unambiguous. It's not > > uncommon for the FDM definition and 3D model to be done by different > > authors. Take 21 people and ask them to identify the "POS" (or > > quarter chord point, or aerodynamic center, or even c.g.) and you'll > > get 21 different answers. Any child over six can find the tip of the > > nose on a photograph. > >If the visual model doesn't have EXACTLY the same distance from the nose to > the POS as the FDM, then they are out of line, period. No common point of > reference is going to make there be any LESS error if it's distance from the POS > is not JUST as exact in visual and FDM models. And if you do have error from > one model to the other, using the nose will actually exaggerate the error, the > longer lever arm from center for the error will actually exaggerate things. It > may be a bit easier see the nose visually but the internal models both best work > from the POS. There isn't a CHOICE on whether it takes more calculations or > not, it takes more to get out to that point of reference and back. Any amount > of ambiguity between models is EXACTLY the same but worse from extra translating > when using the nose. If we both didn't use "EXACTLY 6" feet back from the nose > as our centers, then there is just as much error as if we both didn't use the > same "EXACTLY 0" as the center. You can't have your visual distance 5 feet, > your FDM distance 6 feet, and have the models match correctly. The nose is just > an arbitrary reference point, that child over six won't be any more likely to > match the things that really need matching from referencing the nose than by > finding the center directly. Couldn't matter less if you found the nose > correctly if you didn't find it's offset from the POS correctly. Physics > doesn't worry much about what point is easy for you to match up when it's > keeping a plane in the air. A plane flies from this central point both visually > AND aerodynamically. And so should the models. If any other point is used then > there is extra translating required or the models have errors. And it's easy to > introduce other errors in all the extra translating. > >The centers need to match for no error. Using the nose REQUIRES that you > have the visual distance from center exactly matched to what the flight model is > calculating for distance to center. If it's not then you have a geometry error > in the point about which your visual rotates on the axes. No way around it. > Using the nose as a point of reference does not magically relieve you of the > obligation of knowing exactly where the POS is to match them. You still have > error if you don't. And it has worse effects since the error is geared by the > distance from the origin. I think its understood that the FDM needs to know the vector to the model's reference point in order to properly calculate its location in space. Once that's info is at hand, all that's needed are the Euler angles and the model will look just fine. > >I was simply stating the fact that the best point of calculations for BOTH > visual and FDM models is the POS. This has nothing to do at all with what is > easier to line up. That point is the simplest for all calculations. Working > from any other point for calculations adds translational offsets to the > calculations, there isn't any way around it. If you line up by the nose point, > then you have to make quite sure that the distance from the nose point to the > POS for both models is exactly the same. You can fly an RC plane by looking at > the nose for reference. But you can also bet that those who do can't fly 3D > nearly as well as those who fly by looking into the center of the wing. That > isn't my opinon, it's me relating my observation of the fact that it's much > easier to fly a plane from the center point. It is the better reference point > because it doesn't have all the translational offsets introduced by looking at > the nose. When flying any plane at high angle of attack, the nose is a terrible > place of reference compared to the POS. The wing moves straight forward in > level flight at any angle of attack without changing height. The nose moves all > over the map, changing its distance from and angle to the line of motion like > mad. It's offset from the real center makes it a poor choice for calculations. > It is FINE to use the nose to match for a point of reference, IF both then > reference it to the POS correctly. Then just do the translation once and use > POS for both models calculations. BUT, there is no 'extra' better matching from > using the nose if it isn't matched to the POS. > > > >Take one of your models referenc
[Flightgear-devel] Aircraft frames and reference points
Is this a comprehensible explanation? Comments/improvements/corrections
welcome and solicited:
It is important to point out the differences in the coordinate frames and
point of origin used for defining the particular flight model for an
aircraft, and the way the aircraft is visually modeled in a 3D modeling
program for display.
The flight dynamics model (FDM) determines where in the world the aircraft
is and by aircraft, it is really the aircraft center of gravity (CG)
that is being tracked. The FDM cares about modeling where the aircraft CG
is, and the 3D model wants to be in the correct spot in the world, too, but
how does one decide where to place the visual model? Can one simply take the
FDM-reported CG and place the aircraft origin (0,0,0) point there? No,
because the various aircraft modelers might use for a coordinate frame
origin any point they see fit when creating their aircraft model. There is
no universal convention for that.
FlightGear developers discussed a possible convention. The idea is that the
forward most center portion of the aircraft would be the MODEL REFERENCE
POINT ("MRP" hereafter - not to be confused with the JSBSim AERODYNAMIC
REFERENCE POINT). If the FDM can report the real world position of the MRP
(and it can), the scene code on the FlightGear side can place the aircraft
very nicely where it is supposed to be.
This is a slight problem for the FDM, though. The FDM has to make sure that
it knows where the MRP is IN RELATION TO THE CG. It is very important to
remember that the FDM reports the lat/lon/alt of the aircraft CG. As fuel
burns off the aircraft CG moves. So, the vector to the MRP will change with
time. It's not a big issue, just a little work for the FDM.
Some definitions:
Aerodynamic Center: The idea of the aerodynamic center is similar to the
idea of the center of gravity. It is the location on the aircraft through
which the total lift and drag can be said to act, just as the center of
gravity is the point through which the total weight acts.
Each part on the aircraft has its own aerodynamic center. In the subsonic
regime, the aero center of the wing airfoil section is generally near the
0.25 chord point. But it moves aft as the aircraft increases speed into the
transonic regime, typically as far back as the
0.5 chord.
Aerodynamic Reference Point (ARP): Think about all the sources of
aerodynamic pitching moment. The largest of those are the wing and the
horizontal tail. That due to the tail comes largely from the tail lift
multiplied by the tail moment arm. But how do we define the tail moment
arm? The aero center of the wing seems like a natural choice, but doesn't
really work since it moves in flight. So typically a point on the wing is
arbitrarily chosen to be the moment arm zero or reference point. That's the
point that I've dubbed the aero reference point. By convention, that point
is typically along the 0.25 chord line on the wing. Spanwise, it is
typically defined to be at the spanwise location of the MAC or mean
aerodynamic chord. The MAC is often computed using:
cbar/croot=2/3*(1+lambda+lambda*lambda)/(1+lambda) where lambda is the wing
taper ratio, ctip/croot. Once this length is computed, the spanwise
location can be found by finding the point on the wing which has that chord.
In the design phase, this point needs to be chosen early and all CFD and
tunnel data reduced using it.
Structural Frame: This is the manufacturers frame of reference used to
define locations of items on the aircraft. These items would include the
center of gravity, the locations of all the wheels, the pilot eyepoint,
point masses, thrusters, etc. The items in the JSBSim configuration file are
located using this frame. In this frame the X-axis increases from the nose
towards the tail, the Y-axis increases from the fuselage out towards the
right (when looking forward from the cockpit), and of course the Z-axis then
is positive upwards. Typically, the origin for this frame is near the front
of the aircraft (at the tip of the nose, at the firewall, or in front of the
nose some distance); the X-axis is typically coincident with the fuselage
centerline and passes through the propeller hub (thrust axis).
Note that the origin can really be anywhere for a JSBSim-modeled aircraft,
because JSBSim internally only uses the distances between the CG and the
various objects not discrete locations themselves.
Body frame: As used in JSBSim the body frame is similar to the structural
frame, but rotated 180 degrees about the Y axis, with the origin coincident
with the CG. This is the frame where the aircraft forces and moments are
summed and the resulting accelerations are integrated to get velocities.
Stability frame (or wind axes): This frame is similar to the body frame,
except that the X axis points into the relative wind
Model Reference Point (MRP): This is the reference point that is agreed
upon by both the aircraft modeler and the 3D m
Re: [Flightgear-devel] 3D aircraft model origins
Jon Berndt wrote: You are in an A-10 with a maverick on one side. You have an aircraft CG (which the FDM is reporting the position of) and an MRP, which the FDM is also supplying to FlightGear. The MRP is given to FlightGear in lat/lon/alt. The FDM calculates that position because it knows where the CG is absolutely, as well as where the MRP is relatively. Since the 3D model builder and the flight modeler for the aircraft agree on the MRP (we hope!) the aircraft can be placed properly in the scene. Now, say we are stationary on the runway and we drop the missile. The CG shifts instantaneously - however the FDM will not report a different position because no force has caused an acceleration which in turn could not have been integrated to produce ultimately a change in position. This is a flaw that may need to be addressed. In any case, let's assume that the FDM *did* shift the reported lat/lon/alt of the CG as reported to FlightGear by the equal and opposite amount that dropping the Maverick resulted in. The vector to the MRP would be shifted by an equal and opposite amount, and the end result would be that the model would not "jump" and the FDM and the model would agree. In the case of smooth flight where fuel burns off slowly, it's not so critical. It is hard to tell from what's said whether you're using the COL as the reference or the CG. COL is the real reference to use in the FDM, the CG is purposefully forward on most craft for stability. The CG swings around the COL pivot point noticably when you change pitch. Also all moment arms are from COL and you actually load the plane to put the CG where you want it, the COL is the real reference point. If you're not already using this, try a very high wing low CG plane. Pivot it around the CG. Then pivot it around the wing's COL. Which looks even close to the real pivot point? To model a bomb drop correctly you simply use the COL as the suspension point, and calculate all forces off of it on each pass, including the moment arms. With the Maverick gone and no longer having it's moment arm in the equation for CG the next calculation pass the CG will shift automatically, and the new distance between the CG and the COL will take care of any resulting motions on it's own and move the plane till things are back to balance. It would be built into the calculation pass, and move on it's own. Really you can just calculate total CG once or rarely and just move the CG when the bomb drops by subtracting it's moment arm. But the COL should be the motion and suspension point of the craft not the CG. The change in the CG relative to the COL should automatically introduce the forces to change the overall orientation around the COL. The COL can shift too as orientation changes but it's the point to calculate from, no one said an accurate model was easy. Just accurate. You can use any point as a point of reference as long as you make sure all translations are in all the calculations. You can start from the CG, and then calculate the COL is over here, and use that to move the craft. But the craft should swing around the COL either way, so you have to do extra translations to make the CG reference point move. COL and CG can both move, but COL is the real hang point of the aircraft so using it simplifies calculations for a truly accurate model. That's why weight and balance calculations are relative to it instead of where the starting CG was. The starting CG is used in the calculations, along with it's moment arm from COL. There are less translation adjustments if you reference everything from that point. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] fdm: fcs components
Jon Berndt wrote: This is a programming issue I'll try and get to ASAP. Today, though, is my twin boys' second birthday. Happy birthday Max and Erik. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on cockpit hardware
Jon Stockill wrote: On Sat, 10 Jan 2004, Erik Hofman wrote: ?? This puzzles me, what type of aircraft are you planning to simulate? It's and F-16 cockpit (which obviously needs a side stick). Well the ideal would be a Grob Tutor - since that's what the cadets do most of their flying in :-) The basic cockpit layout works just as well as half a Grob - the only things which need changing are the panel angle, and height of the seat back - the structure was donated - I certainly wasn't going to refuse it because it was designed for the wrong aircraft I understand, but at least it should resemble the cockpit layout of the simulated aircraft in some way. Oh well. The Grob looks like a nice aircraft though. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Andy Ross wrote: Lee Elliott wrote: The tip of the nose is fine with me but we need to clarify whether the tip includes any nose-mounted pitots or probes. Sure. Obviously it doesn't *really* matter. But picking some unambiguous, obvious point on the fuselage just seems much more sane to me than trying to explain the choice of an aerodynamic parameter for a coordinate origin. Pilot's eye point. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D aircraft model origins
>It is hard to tell from what's said whether you're using the > COL as the > reference or the CG. COL is the real reference to use in the > FDM, the CG is > purposefully forward on most craft for stability. The CG swings > around the COL > pivot point noticably when you change pitch. Also all moment > arms are from COL > and you actually load the plane to put the CG where you want it, > the COL is the > real reference point. If you're not already using this, try a > very high wing > low CG plane. Pivot it around the CG. Then pivot it around the > wing's COL. > Which looks even close to the real pivot point? The forces and moments all act about the center of gravity. It has nothing to do with how things look, it has to do with the laws of physics. I've got some reference material linked from the JSBSim web site. You might want to have a look at some of it. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] fdm: fcs components
> Jon Berndt wrote: > > This is a programming issue I'll try and get to ASAP. Today, > though, is my > > twin boys' second birthday. > > Happy birthday Max and Erik. :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Alan King <[EMAIL PROTECTED]> said: > Andy Ross wrote: > > > Alan King wrote: > > > >>The 'nose' is a bad choice for either the viewing center or the FDM > >>center. > > > > > > Except for the obvious fact that it's 100% unambiguous. It's not > > uncommon for the FDM definition and 3D model to be done by different > > authors. Take 21 people and ask them to identify the "POS" (or > > quarter chord point, or aerodynamic center, or even c.g.) and you'll > > get 21 different answers. Any child over six can find the tip of the > > nose on a photograph. > >If the visual model doesn't have EXACTLY the same distance from the nose to > the POS as the FDM, then they are out of line, period. Alan, Thanks for your input. But please review the last 4 or 5 threads on this subject over the last couple of years. Then think about it for a while. Maybe this will help: Unless you crash the plane, or you are flying a concored sst, the nose will _always_ have exactly the same relationship in 3D space to the furthest aft point of it's tail. The x, y, z distances between the two points will always always be the same no matter what orientation the aircraft takes. This applies to any two fixed points on the aircraft. If above suggestions don't work, try --aircraft=p51d in flightgear. The P51-D uses the nose as the reference point/origin for both the 3D Model and the FDM config. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Alan King <[EMAIL PROTECTED]> said: > >The 'nose' is a bad choice for either the viewing center or the FDM center. It wouldn't be an FDM center. It is only an easy to define reference point. > Everything works around the POS. The nose is just an arbitrary point how ever > many feet ahead. Or that point is an arbitrary distance from the nose, which isn't arbitrary in most cases. > >I can sort of see the choice if this started from RC, since some people fly > by the nose. But the best place of reference to fly a plane in 3D from outside > is really the center of the wing, just where you'd expect from all the forces > actually working around that point. > The 3D Model of the aircraft will be exactly in the correct location in the 3D world and it will look like it is in the correct location. It makes no difference at all in regards to what you are describing. The appearance will be the same regardless and the translations which are required for the camera are trivial. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Lee Elliott <[EMAIL PROTECTED]> said: > > The tip of the nose is fine with me but we need to clarify whether the tip > includes any nose-mounted pitots or probes. > > I'm specifically thinking about the TSR2 here, which has a nose mounted probe > but there will probably be others, if there aren't already. > > This is probably more of an issue for experimental a/c as most production a/c > seem to have them elsewhere, which makes sense to me as it'll cut down the > ground-space requirements. > > I'd be inclined to ignore any probes and specify the tip of the nose 'cone', > or fuselage. I'm not sure that nose mounted probes are always drawn to the > correct size in the drawings we use for modelling, so it's probably not a > good idea to use them as reference points. We could specify probes and tubes narrower than 3" over its length to be excluded. But prop cones would be considered. I don't know...good point. Maybe a description of the nose location should be a standard comment at the top of the FDM config files? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D aircraft model origins
> Maybe a description of the nose location should be a standard > comment at the top of the FDM config files? Yes, that is a very good idea. In fact, the last model I started to write (B747) contained all the data the model was based on as well as source references. The DAVE-ML standard being forged by Langley (&etc.) engineers provides for a "provenance" XML field so sources can be traced. This kind of feature will probably evolve into the JSBSim config file format. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D aircraft model origins
>On Behalf Of Alan King Alan: Visit jsbsim.org, select the "Links" item, and look for the references marked with a yellow checkbox square. Those references are the most important and helpful ones. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Sat, 2004-01-10 at 14:10, Alan King wrote: > Jon Berndt wrote: > > > You are in an A-10 with a maverick on one side. You have an aircraft CG > > (which the FDM is reporting the position of) and an MRP, which the FDM is > > also supplying to FlightGear. The MRP is given to FlightGear in lat/lon/alt. > > The FDM calculates that position because it knows where the CG is > > absolutely, as well as where the MRP is relatively. Since the 3D model > > builder and the flight modeler for the aircraft agree on the MRP (we hope!) > > the aircraft can be placed properly in the scene. Now, say we are stationary > > on the runway and we drop the missile. The CG shifts instantaneously - > > however the FDM will not report a different position because no force has > > caused an acceleration which in turn could not have been integrated to > > produce ultimately a change in position. This is a flaw that may need to be > > addressed. In any case, let's assume that the FDM *did* shift the reported > > lat/lon/alt of the CG as reported to FlightGear by the equal and opposite > > amount that dropping the Maverick resulted in. The vector to the MRP would > > be shifted by an equal and opposite amount, and the end result would be that > > the model would not "jump" and the FDM and the model would agree. > > > > In the case of smooth flight where fuel burns off slowly, it's not so > > critical. > > > > >It is hard to tell from what's said whether you're using the COL as the > reference or the CG. COL is the real reference to use in the FDM, the CG is > purposefully forward on most craft for stability. The CG swings around the COL > pivot point noticably when you change pitch. Also all moment arms are from COL > and you actually load the plane to put the CG where you want it, the COL is the > real reference point. If you're not already using this, try a very high wing > low CG plane. Pivot it around the CG. Then pivot it around the wing's COL. > Which looks even close to the real pivot point? Once the wheels are off the ground, the center of gravity is the point about which the aircraft rotates. It does not rotate around the aero center or any other point. Also, the c.g. does *not* change with pitch attitude. It's location is purely a function of the weight distribution within the vehicle. > >To model a bomb drop correctly you simply use the COL as the suspension > point, and calculate all forces off of it on each pass, including the moment > arms. With the Maverick gone and no longer having it's moment arm in the > equation for CG the next calculation pass the CG will shift automatically, and > the new distance between the CG and the COL will take care of any resulting > motions on it's own and move the plane till things are back to balance. It > would be built into the calculation pass, and move on it's own. Really you can > just calculate total CG once or rarely and just move the CG when the bomb drops > by subtracting it's moment arm. But the COL should be the motion and suspension > point of the craft not the CG. The change in the CG relative to the COL should > automatically introduce the forces to change the overall orientation around the > COL. The COL can shift too as orientation changes but it's the point to > calculate from, no one said an accurate model was easy. Just accurate. > >You can use any point as a point of reference as long as you make sure all > translations are in all the calculations. You can start from the CG, and then > calculate the COL is over here, and use that to move the craft. But the craft > should swing around the COL either way, so you have to do extra translations to > make the CG reference point move. COL and CG can both move, but COL is the real > hang point of the aircraft so using it simplifies calculations for a truly > accurate model. That's why weight and balance calculations are relative to it > instead of where the starting CG was. The starting CG is used in the > calculations, along with it's moment arm from COL. There are less translation > adjustments if you reference everything from that point. > > Alan > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden <[EMAIL PROTECTED]> ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Simulation Environment file
Here is a first cut suggestion for a JSBSim "simulation environment" config file: RATE_IN_HZ 120 SIMULATION OFF ATMOSPHERE ON MASSPROPSON AEROSURFACES ON RATESON VELOCITIES ON FORCES ON MOMENTS ON POSITION ON COEFFICIENTS ON GROUND_REACTIONS ON FCS ON PROPULSION ON This may only be useful for JSBSim in its standalone mode, and defaults will be provided so when run within FlightGear this file would not even need to be supplied. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Jon Berndt wrote: structural frame. The 3D modeler has no clue about (and probably doesn't care to know about) where the CG is - and that's fine. The FDM and the 3D model, though, *do* need to agree on a common MRP (Model Reference Point) that the FDM can supply to the FlightGear scene code for proper placement of an aircraft. Once that point is agreed upon, it's not a big problem at all for the FDM to send to FlightGear the exact location in world space of the MRP. No matter what the orientation of the aircraft, the 3D model will always have its CG in the correct place if the FDM properly reports to FlightGear the real-world location of the MRP. We (FDM) can do this because, as I've said before, we know where the CG is, and we know where the MRP is in reference to the CG. I see what you're doing now. You are letting them just use the nose, and then shifting the FDM nose point until the FDM center is near the visual center. The nose reference point in the visual model isn't referenced and matched to the FDM. It is simply a given point, and then the FDM can be adjusted to it until it's COL matches the visual's approximate COL. That works easily but is different than the model's nose point being matched to the FDM. The 'Model Reference Point' terminology is what is actually ambiguous, it is really just a visual reference point that the FDM is adjusted for after the fact. Handy dandy way to match the visual to the FDM really, but I would have shied away from calling it 'Model Reference Point' without it being the best inertial reference point of the model. It can be considered the reference point of the visual model frame, but since it's going to be translated through by the FDM the actual visual point of motion center will be the same as in the FDM. It's an unusual naming for just the point of visual adjustment. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D aircraft model origins
>I see what you're doing now. You are letting them just use > the nose, and > then shifting the FDM nose point until the FDM center is near the > visual center. Not really. The FDM still calculates the position of the CG of the aircraft. It's just that we know exactly where the agreed-upon MRP is at all moments of time, so we calculate that and give it to FlightGear. We could just as easily agree that the wingtip was the "common known point", calculate that, and have FlightGear place the 3D model in the view so that the wingtip was at the specified point. The only thing the FDM does as an auxiliary calculation to aid the 3D model placement is to additionally calculate the MRP position in world space and make that available to FlightGear. Or, at least, we will when I code it. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Jim Wilson wrote: Maybe this will help: Unless you crash the plane, or you are flying a concored sst, the nose will _always_ have exactly the same relationship in 3D space to the furthest aft point of it's tail. The x, y, z distances between the two points will always always be the same no matter what orientation the aircraft takes. This applies to any two fixed points on the aircraft. Yes but any change in visual scale requires an adjustment in the FDM reference. It's not the overall reference point of the model or general calculations, it's just a known reference point and the FDM is adjusted through it until the real reference point of the FDM model is about where it should be on the visual model. The name Model Reference Point just had bigger implications than what this point is actually used for. More of 'a reference point between the visual and FDM models' than 'the model reference point' for the actual modeling of the airplane. It doesn't make the alignment happen magically by using it, it just lets someone else do the adjustment on the FDM side later. Still a good thing. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Tony Peden wrote: Once the wheels are off the ground, the center of gravity is the point about which the aircraft rotates. It does not rotate around the aero center or any other point. Yes, been a while since I'd used the POS. It is the other way around, with a fixed POS it's the best point to use. With no outside force fixing the point of suspension it will shift around the CG and the CG is the best to use as reference. Also, the c.g. does *not* change with pitch attitude. It's location is purely a function of the weight distribution within the vehicle. Wasn't saying it would actually change, only that it would translate. But it doesn't it's the other way around the CG is the reference point and the suspending point moves around when it's free to move. The motion's all the same relatively as always, but it's when the POS is fixed that it is the better point of reference to work from not when it's free to move. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Jon Berndt wrote: I see what you're doing now. You are letting them just use the nose, and then shifting the FDM nose point until the FDM center is near the visual center. Not really. The FDM still calculates the position of the CG of the aircraft. It's just that we know exactly where the agreed-upon MRP is at all moments of time, so we calculate that and give it to FlightGear. We could just as easily agree that the wingtip was the "common known point", calculate that, and have FlightGear place the 3D model in the view so that the wingtip was at the specified point. The only thing the FDM does as an auxiliary calculation to aid the 3D model placement is to additionally calculate the MRP position in world space and make that available to FlightGear. Or, at least, we will when I code it. Jon Ok that gets back to the same question then. What else besides the nose point does FlightGear use to place the visual model? Say your CG is at the origin. Your nose is 10 feet forward. FG puts the visual model's nose at the 10 foot position since that is the common reference point. What makes sure that where the CG is on the visual model is at 0? You do a 20 foot long plane FDM, with CG at 10 feet. I draw a 3000 foot long plane. The noses match. Does about 2980 feet of my plane sink into the ground? What makes sure that the CG is put at the right place in the visual model with the nose as the only reference? Does FG just scale the total model, the FDM also gave a length for the model, and FG assumes the visual model has the wing in the right place? Maybe FG uses your CG, matches the nose, then just guesses the CG of the visual model of the overall size? There just has to be some other piece of data that correlates. If not there is no telling if the real FDM CG is where it's supposed to be on the visual model. An off center reference point like the nose isn't enough if you have no other data to calculate back and match the center. If they're actually accurate together, there is something else matching. And if there isn't anything else matching in some accurate way, then there is no telling if the FDM CG and where it should be on the visual model are really matching. What else is FG doing to put them in the same place? Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D aircraft model origins
I said the other day and I will say it now the FDM does NOT require a 3D model. Have a look at the attachment this is the 747 flying sideways,quite happily, as a 737.If the 3D model affected the FDM then this should not fly. The 3D model should have its MRP as close to the CofG as you can get, if not you have to supply FG with offsets so the model appears to fly properly. Take Lee's P51 it has its MRP at the nose.Now for a little exercise take the AC3D file and put it in the 737 models file and name it what ever the 737 AC3D file is called and then run FG the A/C will appear to piviot around the nose.Looks a bit like the tail on a dog waging.A word of warning if you do this save your 737 AC3D file first and remove any animations in the model XML file as they will crash the sim. Now I can put Lee's P51 into AC3D and in about 3 sec's move the model so that the origin of the graphics program and the centre of the model are the same.Then when I load the P51 back into FG I would not have to provide any offsets to make the model appear to fly correctly. So it would seem logical to make the MRP as close as possible to the CofG so no offsets have to be supplied and FG does not have to spend time calculating were the model is. It is my understanding that the offset system was devised primarily to allow MSFS A/C to be positioned correctly.I stand corrected if this is not the case. As for moving the CofG as the A/C flies or as it is loaded.If it is not already implimented then it would be a good thing.The CofG is the most important factor because if it is out of limits you dont fly.In Boeing A/C the stabilizer has to be in the green band for T/O if it is not the load has to be shifted till the CofG is in the green band for the stabilizer. The CofL and the reference point I would think are only manufacturing and maintenance figures.The only time I had anything to do with CofL was when I was doing my A/C theory Also if you have a look at most (if not all)MSFS models you will find there MRP in the middle of the model. Having throwen some hand grenades I will retire to my bunker and wait for the incoming LOL. Cheers Innis The Mad Aussi _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp <>___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D aircraft model origins
> I said the other day and I will say it now the FDM does NOT require > a 3D model. True. Our discussion centers on the occasion when a 3D modeler *wants* to add a 3D model to an FDM. > Have a look at the attachment this is the 747 flying sideways,quite happily, > as a 737.If the 3D model affected the FDM then this should not fly. Nobody is saying the 3D model affects the FDM - that's not the point. > The 3D model should have its MRP as close to the CofG as you can get, if Note that 3D modelers will not know where the CG is. That is not an option for pure 3D modelers. > not you have to supply FG with offsets so the model appears to fly > properly. Exactly. Read my earlier long post "Aircraft Frames and Reference Points". Trust us (myself, Jim, Tony ...), we've looked at this situation 'til we were blue in the face. Jon -- Project Coordinator JSBSim Flight Dynamics Model http://www.jsbsim.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Alan King writes > You do a 20 foot long plane FDM, with CG at 10 feet. I draw a 3000 foot long plane. The noses match. Does about 2980 feet of my plane sink into the ground? What makes sure that the CG is put at the right place in the visual model with the nose as the only reference? Does FG just scale the total model, the FDM also gave a length for the model, and FG assumes the visual model has the wing in the right place? It makes no difference if you make the model 1000 miles long or just one foot. All the model is is 1 vertices flying in close formation and the vertices have no mass so the model has no mass so no CofG to work through. The 3D model is like a dog on a lead it can only go were you let it go. And what controls the 3D model dog the FDM and it does not care if the dog is attached at the head the tail or by a leg. Cheers Innis The Mad Aussi _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Saturday 10 January 2004 20:17, Alan King wrote: > Lee Elliott wrote: > > Definitely - I don't think I could accurately position a model to an > > aerodynamic center. > > > > LeeE > >Then your model's relationship to how it flies is just as inaccurate. > It isn't by your or my or anyone else's vote or choice. > >If the NOSE agrees in both, and you haven't gotten the distance from > NOSE to POS correct and exactly the same in both models, then you have a > GEOMETRY error between them when it moves. Try to show me how having the > nose referenced relieves you of having to know and have the same distance > from nose to center in both FDM and the visual. You can't. > >How would you expect the FDM model to magically get it's relationship > from it's nose to where all the calculations are done matched to your > model's visual distance from it's nose to where all the calculations should > be? > >You can use the nose all you like. If your distance from your nose to > the center isn't exactly the same as what the FDM thinks it is, then your > models don't match and your visual is off by just as much as that > inaccuracy you couldn't figure for the POS. > >There is no choice in the matter. The center of the aircraft is the > center of the aircraft and is the simplest point of agreement between the > visual and the FDM, and simplest point of calculations for both. You can > use the nose as a reference point, but you still better make very sure your > nose is the same distance visually from POS as it is calculated in the FDM > if you want them to match. > > Alan Please don't capitalise words for empthasis - it's irritating. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D aircraft model origins
"Jon Berndt writes> > Have a look at the attachment this is the 747 flying sideways,quite happily, > as a 737.If the 3D model affected the FDM then this should not fly. Nobody is saying the 3D model affects the FDM - that's not the point. Reading some of the replys it seem to me that it does > The 3D model should have its MRP as close to the CofG as you can get, if Note that 3D modelers will not know where the CG is. That is not an option for pure 3D modelers. One would assume that anyone who is making a 3D model of an A/C knows something about A/C and how they behave.If not they will soon find out when they put the A/C onto a sim and it flys backward or upside down.I would think that what they would do then is move the model around untill it looked like it flew like they imagined it would.If they had never seen an A/C or seen one fly(hardly likely) them they might be quite happy if it was upsidedown as they would not know that this was incorrect. > not you have to supply FG with offsets so the model appears to fly > properly. Exactly. Read my earlier long post "Aircraft Frames and Reference Points". Trust us (myself, Jim, Tony ...), we've looked at this situation 'til we were blue in the face. So what is the discussion the CofG is where it is and it is upto the 3d modelers to make it appear to fly right. Cheers Innis _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Sat, 2004-01-10 at 19:20, Alan King wrote: > Jon Berndt wrote: > > >> I see what you're doing now. You are letting them just use > >>the nose, and > >>then shifting the FDM nose point until the FDM center is near the > >>visual center. > > > > > > Not really. The FDM still calculates the position of the CG of the aircraft. > > It's just that we know exactly where the agreed-upon MRP is at all moments > > of time, so we calculate that and give it to FlightGear. We could just as > > easily agree that the wingtip was the "common known point", calculate that, > > and have FlightGear place the 3D model in the view so that the wingtip was > > at the specified point. The only thing the FDM does as an auxiliary > > calculation to aid the 3D model placement is to additionally calculate the > > MRP position in world space and make that available to FlightGear. Or, at > > least, we will when I code it. > > > > Jon > >Ok that gets back to the same question then. What else besides the nose > point does FlightGear use to place the visual model? > >Say your CG is at the origin. Your nose is 10 feet forward. FG puts the > visual model's nose at the 10 foot position since that is the common reference > point. What makes sure that where the CG is on the visual model is at 0? Nothing. It's not necessary. Every dimension supplied to the FDM is automatically referenced to the c.g. position. In other words, if the c.g. is at 10 feet and the reference point at 20, the only thing that's relevant to the FDM is the difference between the two. If you follow that, you'll realize that the location of zero is of absolutely no significance. > >You do a 20 foot long plane FDM, with CG at 10 feet. I draw a 3000 foot long > plane. The noses match. Does about 2980 feet of my plane sink into the ground? You need only tell the FDM that model's reference point is 2980 feet forward. >What makes sure that the CG is put at the right place in the visual model > with the nose as the only reference? Does FG just scale the total model, the > FDM also gave a length for the model, and FG assumes the visual model has the > wing in the right place? It doesn't need to be. If the reference point is known to the FDM, it can properly calculate it's location in space, and that's all that's needed. The CG location is 100% irrelevant to the visual model. Only six pieces of info are needed by the code that draws it in the scene: the x, y, and z of the reference point and the pitch, roll, and heading angles. If the x,y, and z are calculated correctly then the model will appear to rotate around it's cg once it's off the gear. > >Maybe FG uses your CG, matches the nose, then just guesses the CG of the > visual model of the overall size? There just has to be some other piece of data > that correlates. If not there is no telling if the real FDM CG is where it's > supposed to be on the visual model. An off center reference point like the nose > isn't enough if you have no other data to calculate back and match the center. > >If they're actually accurate together, there is something else matching. And > if there isn't anything else matching in some accurate way, then there is no > telling if the FDM CG and where it should be on the visual model are really > matching. What else is FG doing to put them in the same place? Nothing at all. It's not needed. > > Alan > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden <[EMAIL PROTECTED]> ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Sat, 2004-01-10 at 18:31, Alan King wrote: > Tony Peden wrote: > > > > > Once the wheels are off the ground, the center of gravity is the point > > about which the aircraft rotates. It does not rotate around the aero > > center or any other point. > >Yes, been a while since I'd used the POS. It is the other way around, with a > fixed POS it's the best point to use. With no outside force fixing the point of > suspension it will shift around the CG and the CG is the best to use as reference. No, it really isn't. The c.g. location is best computed by the FDM as it runs, since it moves in flight as fuel is burned, ordnance is dropped, etc. > > > > > > > Also, the c.g. does *not* change with pitch attitude. It's location is > > purely a function of the weight distribution within the vehicle. > > > >Wasn't saying it would actually change, only that it would translate. OK, I suppose you could argue this if you're thinking in terms of an earth fixed coordinate system. > But it > doesn't it's the other way around the CG is the reference point and the > suspending point moves around when it's free to move. The motion's all the same > relatively as always, but it's when the POS is fixed that it is the better point > of reference to work from not when it's free to move. > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden <[EMAIL PROTECTED]> ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [OT] New Mars Picture
Last night I played with one of the recently received PanCam pictures from the "Spirit" MER on Mars: http://www.hal-pc.org/~jsb/ColorMars.jpg >From what I hear from a friend at one of the NASA centers, some of the JPL guys got a kick out of it. -- Jon JPL Scientist: "We've made two very important discoveries today that are closely related. First, we have confirmed that Gusev Crater - at least where Spirit landed - is indeed a dried up lakebed. Second, we found Nemo." ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Saturday 10 January 2004 21:57, Jim Wilson wrote: > Lee Elliott <[EMAIL PROTECTED]> said: > > The tip of the nose is fine with me but we need to clarify whether the > > tip includes any nose-mounted pitots or probes. > > > > I'm specifically thinking about the TSR2 here, which has a nose mounted > > probe but there will probably be others, if there aren't already. > > > > This is probably more of an issue for experimental a/c as most production > > a/c seem to have them elsewhere, which makes sense to me as it'll cut > > down the ground-space requirements. > > > > I'd be inclined to ignore any probes and specify the tip of the nose > > 'cone', or fuselage. I'm not sure that nose mounted probes are always > > drawn to the correct size in the drawings we use for modelling, so it's > > probably not a good idea to use them as reference points. > > We could specify probes and tubes narrower than 3" over its length to be > excluded. But prop cones would be considered. I don't know...good point. > Maybe a description of the nose location should be a standard comment at > the top of the FDM config files? > > Best, > > Jim Including prop cones sounds fine. I'm not sure about the three inch limit though - one of the later B-52 experimental a/c had a long probe attached to it, that looked thicker than 3" but I'd be inclined not to use that as the reference point, but use the nose location on a standard a/c. How about the frontmost point on the leading edge of the main-wings at the root - or would that be snafu'd by LEXs? e.g. F-18. Could be a bit iffy on the AN-225 as well, now that I think about it, as the wing roots flare into the fuselage. Leading edge of the elevator? LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D aircraft model origins
> Including prop cones sounds fine. I'm not sure about the three inch limit > though - one of the later B-52 experimental a/c had a long probe attached to > it, that looked thicker than 3" but I'd be inclined not to use that as the > reference point, but use the nose location on a standard a/c. > > How about the frontmost point on the leading edge of the main-wings at the > root - or would that be snafu'd by LEXs? e.g. F-18. Could be a bit iffy on > the AN-225 as well, now that I think about it, as the wing roots flare into > the fuselage. > > Leading edge of the elevator? Tip of prop hub or nose, excluding inlet tubes or sensor probes. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalization?
Lee Elliott wrote: Heh - it seem to me that most of the kids here (UK) just speak pretty bad english;) That depends on how you look at it. You could say that english is whatever english speaking people are speaking these days. Or you could flip that around and come up with some defined structure of english as it existed at some point in time (and then compare that with what people are speaking today.) Of course you could argue all day long about current usage being unclear or imprecise since (err I mean because) "proper" english is usually much more clear and precise. I'd suggest that we shoot any one who says "A whole 'nother ..." instead of "Another whole ..." but I catch myself saying it too. There are a lot of people who speak english as a 2nd or 3rd or 4th language who at least right better english in their emails than I could ever hope to. :-) Having studied spanish every year of my life since probably kindergarten up through my junior year of high school, and now not having any hope of being able to follow (or participate in) a real time spanish conversation, I have a lot of respect for those that pop back and forth between multiple languages. And I appreciate all of you who switch to english now and then so that I can understand what you are saying. Curt. -- Curtis Olson Intelligent Vehicles Lab 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
