Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 10:23:56 -0700 Russell Suter <[EMAIL PROTECTED]> wrote: Jon S Berndt wrote: But then, the FDM still has to report where the FDM is in a common reference frame. Exactly! At my company, we call this the control point and we have standardized on the Empty Weight CG. The 3D model designer will likely have no idea where the empty weight CG is, nor will they often care. They do know where physical points on the aircraft are, however. Additionally, the empty weight CG will be a slippery item to standardize on. Does that mean no fuel? No cargo? nothing? no stores? the C/D model or the A/B model? etc. The VRP is a **solid** point of reference. I'm not speaking for Andy here, but this is what I'm trying to get across. The VRP is an excellent idea. I know that it can be used to solve the problem. I also know that the cost (for a single instance) is relatively inexpensive. The cost is not even an issue at all. My point is that it really is unnecessary. If you already have a fixed point reference in the FDM, then use it. Translate the visual model to that point ONCE either by the graphic artist moving the model, or doing it automatically when the model is loaded. Instead of the VRP data being used by the FDM, it becomes meta data for the model. What do you mean "metadata for the model" This way, the graphic artists can use whatever origin they want based on the data they have. This is already the case! The 3D modeler can and _do_ use any origin they want. They may often know only what the plane ***looks*** like. This is why the VRP is required. There needs to be a common point of reference that both the FDMs (plural) and the 3D *visual* model know about without question. The empty weight CG and the current (dynamic) CG is **not** it. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 08:22:15 -0800 Andy Ross <[EMAIL PROTECTED]> wrote: Jon S. Berndt wrote: Can the view offset or rendering code (whatever it is that draws the 3D aircraft models) move the origin of the set of vertices that defines the model per-frame so that the CG aligns with that reported by the FDM? Well, yes, because they're just properties. But unless I misunderstand you, you don't want to do that. The FDM reports the lat/lon/alt of the aircraft coordinate origin, not the c.g., no? Andy No. JSBSim currently (the version in in FlightGear, anyhow), reports the position of the CG, since that is what the EOM natively tracks, anyhow. We can *report* anything, though of course, as we have intimate knowledge of euler angles, CG position, and offset from the CG (dynamic) to any other point on the aircraft at any time. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] XML SCripting
On Fri, 13 Feb 2004 11:15:19 -0600 Cameron Moore <[EMAIL PROTECTED]> wrote: FWIW, Microsoft filed their patent on Dec. 1, 2000. The CVS entry you reference was from Apr. 6, 2001. Can you beat the December date? -- Cameron Moore Probably. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 07:07:05 -0800 Andy Ross <[EMAIL PROTECTED]> wrote: Adding the VRP is yet another mechanism, basically a direct analog of the view offset stuff on the FDM side. I just don't see the need. If we decide the VRP is the right way to do it, we should chuck the view offset stuff for simplicity and orthogonality. Andy Can the view offset or rendering code (whatever it is that draws the 3D aircraft models) move the origin of the set of vertices that defines the model per-frame so that the CG aligns with that reported by the FDM? But then, the FDM still has to report where the FDM is in a common reference frame. The 3D model and the FDM don't really know that much about each other - it's dort of open-loop. It's not clear to me how you are proposing that the 3D modeling code would know how to exactly interpret what the FDM is telling it - apart from there being a convention such as the VRP. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Thu, 12 Feb 2004 22:56:46 +0100 Mathias Fröhlich <[EMAIL PROTECTED]> wrote: Even JSBSim CVS does not support this visual reference point yet. There is a patch pending in Jon's mailbox to report the visual reference point to flightgear and define a reference point in each JSBSim aircraft config. ?? I thought I had already committed these. You might want to double check. In any case, I already committed to CVS the code that reports the VRP, as well as to make the corrections to the transforms (as you pointed out). These are committed. However, in JSBSim.cxx, the relevant code *may* still be commented out, waiting for the VRP specification in the aircraft models. It's a matter of timing, I think; we need to get everything together, then submit it. But, I think this will require work for the 3D model, too. ? Jon Also there is a bugfix which is required to make the VRP patch work correct. This one is in JSBSim cvs but I believe did not yet find the way into fightgear. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ 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] Aerodynamic centre and 3D models
On Thu, 12 Feb 2004 21:19:25 - "Vivian Meazza" <[EMAIL PROTECTED]> wrote: Jon S Berndt tells us First, the aircraft - like any body - rotates about its CG (according to the EOM) - not usually the same as the AC. So put the (visual) model origin at or near the CofG - what's the problem? Seems to work OK in practice. Really confused now That is certainly one solution. Then define the VRP in the JSBSim config file (for JSBSim aircraft - I don't know how YASim does this), as coincident with the CG. Then, build your 3D model with the origina at the CG. HOWEVER: when the CG moves due to leanding gear deployment, or dropping loads, or fuel burnoff, the vehicle will rotate about the wrong point, eventually. It won't be real noticeable, but it will be there. That's why we provide the capability for both the 3D model designer and the FDM designer to agree on a common visual reference point, and things can be made much more accurate and allow for dynamic effects. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Thu, 12 Feb 2004 15:35:59 -0500 David Megginson <[EMAIL PROTECTED]> wrote: Jon S Berndt wrote: I'm not sure I see how this helps -- the model code still doesn't know where the CG is, so it still doesn't know where the centre of rotation for the model should be. This is precisely *why* the nose is used as a reference point. If the scene graph (is that the right term/subsystem?) places the aircraft at the spot reported by JSBSim -- that is, where JSBSim says the nose of the aircraft is -- the perceived CG of the 3D aircraft as viewed in the scene will fall exactly in the spot that the FDM says it should be at. Look at it this way: the FDM tracks the motion of the CG, and the rotation of the aircraft about the CG. The FDM knows teh location of the CG at any point in time, as well as the euler angles of the aircraft at that point in time. If we were to report the location of this CG to FlightGear, and IF the origin of the 3D model was allowed to shift (by some magic) and always be coincident with the "virtual CG" in the 3D model, then we'd all always be happy and everything would match up fine. The problem is, the CG shifts and the 3D model coordinate system can't. Since the FDM knows (or can calculate) where the nose is at all times, we simply report the nose location to FlightGear, and by convention FlightGear places the 3D model's nose at the point reported by JSBSim - the CG falls into place as needed IFF the 3D model is defined (or scaled/rotated/translated in the scene graph) correctly as described previously. Takeoffs and landings would look fine, etc. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
On Thu, 12 Feb 2004 15:36:13 -0500 Josh Babcock <[EMAIL PROTECTED]> wrote: This has all got me thinking a bit. This subject seems to come up quite a bit, and frankly I have found it a dificult problem too. In addition, there are some related things that can get hard as well like placing the wheels right on the ground, and getting the landing gear elements for wingtips and other parts that can experience a ground strike positioned correctly. Maybe what we need is the ability to place a visual cursor into the scene graph and slave it's position to a set of positional properties. These could come from the FDM or a view definition (think how useful it would be to go into This is not a bad suggestion. However, I'd be happy if we could specify a set of axes to be displayed as desired. I'd like to see the XYZ axes reported by the FDM, for instance - both nose-cented and CG centered. It could be a valuable visual debugging aid. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Thu, 12 Feb 2004 15:09:15 -0500 David Megginson <[EMAIL PROTECTED]> wrote: So, given that the aerodynamic centre of an aircraft can shift based on loading and flight conditions, how can we report that from the FDM back to the 3D model code? Is this something people worked out in a previous thread? I'm assuming that the 3D model and the FDM config file are using the same reference datum for coordinates. First, the aircraft - like any body - rotates about its CG (according to the EOM) - not usually the same as the AC. JSBSim made a change recently that is likely not yet in FlightGear CVS. The lat/lon/alt position now reported by JSBSim (CVS) is the position of the VRP (Visual Reference Point) - i.e. the tip of the prop hub (or similar nose tip location on non-prop aircraft). As long as the aircraft is placed in the scene so that the nose of the 3D model falls at the location reported by JSBSim - everything works out. This assumes that the aircraft model is defined using the correct English units - because all points that the FDM is concerned with are measured in the structural frame and in inches. Yes, we have gone over this ad nauseum in the past. :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
On Thu, 12 Feb 2004 19:50:48 - "Jim Wilson" <[EMAIL PROTECTED]> wrote: You actually want to be very exact about matching the model to the FDM origin. ... Jim (or someone ... *anyone*): Could you summarize the argument taking place here? I seem to only be getting parts of it - I guess I didn't get the original question/comment. Is there now a difference in the way that JSBSim and YASim match up the 3D model with the FDM? Have you had a chance to try out the new way that JSBSim provides position? Is there anything else we (JSBSim and/or FDM developers) need to do? I would like to get an alpha B747 FDM I have been working on to work using the 3D model, but haven't really had time to work on this much. When I did try it out initially, it looked like the origin was wrong between the 3D model and the FDM. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RAM disk / Unix
On Tue, 10 Feb 2004 15:06:41 -0800 Andy Ross <[EMAIL PROTECTED]> wrote: Norman Vine wrote: Jon S. Berndt wrote: > It is thought that the use of a RAM disk might help. On Windows I have found that increading disk cache size and / or using memory mapped files is more productive then a DAM disk My interpretation was that their problem was latency, not I/O throughput. The program cooks along using 100% of the CPU, then it needs to load a giant data set off the disk, so it has to wait (making 0% use of the CPU) while the I/O system does its job. If they could ensure that the dataset was in memory they could avoid this delay. Andy Yes, it seems to be a latency issue. Thanks for all the inputs - at least we have somewhere to start, if not viable solutions. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RAM disk / Unix
Is anyone aware of a RAM disk utility or feature under Unix (specifically, IRIX)? When running a simulation on IRIX we are finding that the disk access is taking too much time at various phase boundaries. It is thought that the use of a RAM disk might help. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Autopilot Documentation
On Wed, 4 Feb 2004 21:39:23 - "Jim Wilson" <[EMAIL PROTECTED]> wrote: Curt fixed that today. It even works pretty well with the 747. With the one he commited, the gain is higher than what you have (Kp=1.0), a little longer intergration period (Ti=25.0) and the derivator is way down to almost 0 (Td=0.1). I'm wondering if a PID controller is only marginally better than a PI controller. What if you remove the "D" control altogether? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Book recommendations sought
On Wed, 4 Feb 2004 09:39:16 +0100 [EMAIL PROTECTED] (Gerhard Wesp) wrote: Hello, I'm looking for good resources on flight simulations. For the aerodynamics and flight dynamics it seems that Stevens, Aircraft Control and Simulation, is (one of) the standard references. Things which Stevens does not cover but which I need also are the modeling of: - landing gear/ground reaction - engines (jet engines in particular) - propeller - environmental effects like turbulence Greetings: I have heard of the Stevens book but have only glanced at a copy that some friends have. I actually did not find it more useful than some of the other references available. As far as books go there is one that is a very good introduction to the techniques involved in flight simulation (the math and physics part): "Physics for Game Developers" by David Bourg, O'Reilly Press, ISBN 0-596-6-5. You can get this from Amazon.com for less than $20, I think. For landing gear and ground reactions, go to the JSBSim web site (www.jsbsim.org), click on the "Links" button at left, and browse the links I have placed there - particularly the ones with a highlighted yellow checkbox. You will find an article on landing gear ground reactions. For propellers, try searching through the NACA archives at naca.larc.nasa.gov. Enter "Propeller" in the search criteria and take a look. We used some NACA reports as well as some information presented in Barne's W. McCormick's textbook, "Aeronautics, Aerodynamics and Flight Mechanics". For turbulence you might try doing a google search on "AIAA turbulence" and you might get some articles on turbulence. Additionally, I have written some things at the JSBSim web site on our experiences in designing JSBSim which ought to be of help to you, and you could also peruse our source code. Jon Berndt Aerospace Engineer Coordinator, JSBSim Project www.jsbsim.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Mon, 26 Jan 2004 17:42:02 - "Jim Wilson" <[EMAIL PROTECTED]> wrote: Good point (as is Jon's) but in all such design cases there are tradeoffs. What I'm looking at is ease of configuration and that may be a reasonable tradeoff against the limitations of defining a standard set of control surface subclasses (i.e. having to add a special case for the harriers rather unique feature). It could also be possible to design in a way that allows both the complex approach to configuring generic controllers and a set of subclasses for simplified configuration of more standard aircraft. Whatever is done needs to be bypass-able, if desired - which, I suspect it will be, simply by defining _no_ autopilot in Flightgear configuration files for an aircraft. We (JSBSim) already have all this capability for ourselves. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Mon, 26 Jan 2004 16:21:19 - "Jim Wilson" <[EMAIL PROTECTED]> wrote: That has nothing at all to do with what I said. We are controlling individual control surfaces. Period. I don't think we should have subclasses for each desired action/process. Only each control surface type. Roll control ends up being intrinsically part of aileron control is it not? Pitch control is intrinsically part of elevator control, regardless of whether you are targeting speed or pitch (maybe you are confusing control targets with outputs?). The variable input sources and targets and how those are handled are all that needs to be configured per instance. Keeping it to that will make the configuration process much simpler. I'm not sure if this makes a difference for what you are referring to, but it's not necessarily that cut-and-dried. For an aircraft with no H-Tail (like the shuttle), both roll and pitch control are managed with elevons. For an aircraft like the F-14 (IIRC) roll is managed with differential H-Tail, as well as spoilers. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Borland C++BuilderX Personal for $10
On Mon, 26 Jan 2004 08:19:27 -0800 (PST) Gene Buckle <[EMAIL PROTECTED]> wrote: I've had BuilderX installed for a couple of months. Unless it's _really_ well hidden, there is no RAD tool attached to it. It's just a fancy>cross-platform IDE. It is my understanding that you have to cough up serious $$$ to get the RAD functionality. Just to make sure we're both on the same "RAD" page, C++ Builder is a RAD tool, Delphi is a RAD tool. VB.Net is a RAD tool. C++ BuilderX Personal is _not_ a RAD tool. OK. Yes, I've used Delphi and C++ Builder for a while, but haven't upgraded in a few years. The free C++ compiler BC++ 5.5 of course did not come with an IDE. C++Builder (no "X") of course comes with RAD functionality out of the box - that's what it is famous for. It's a bit surprising to me that Borland would put the "Builder" tag on a product that did not have the RAD functionality - that seems misleading and mis-named. The cross-platform IDE might be nice enough by itself I guess, given the support for multiple compilers, and I may try it out just for that. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Borland C++BuilderX Personal for $10
On Mon, 26 Jan 2004 07:10:16 -0800 (PST) Gene Buckle <[EMAIL PROTECTED]> wrote: Unless it's different from the downloaddable version, it does _not_ include any kind of RAD tool. g. You are probably thinking of the free Borland C++ 5.5 compiler. The link I provided refers to the Personal Edition of C++BuilderX. They are different products. Borland C++BuilderX does not exist outside the IDE. I do believe this *is* a RAD tool that is available for download, or I misread the web page. Has anyone tried this? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
On Thu, 22 Jan 2004 16:15:41 -0500 David Megginson <[EMAIL PROTECTED]> wrote: I agree as well. An autopilot driven by the gyro compass should reflect all of the compass's error's, such as drift; ditto for an AP driven by a VOR receiver. If we want to model an AP driven by a GPS, INS, and/or FMS, we should model those as well. David I think more care should be taken with the terminology. This was scaring me for a while, too. What is being done really is providing "sensed" state to the A/P and FCS. In my work, these are called "sensors" - NOT instruments. "Instruments" (in my experience) refer to devices that display sensed state to the pilot. In an aircraft (or spacecraft) "plant", it goes like this: sensors -> FCS -> effectors To close the loop, there would be an arrow from "effectors" to "Environment/Aircraft State", and subsequently back to "sensors". For instance, the F-16 FCS receives rates and accelerations from sensors, as well as taking command input from the pilot. The gyros and accelerometers are the sensors. You could certainly think of them as "sensing instruments", but reading this thread might confuse some that we wanted to take the attitude as displayed by the HSI (for instance) and use that as input to the A/P, which is not correct. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
On Tue, 20 Jan 2004 15:09:02 -0600 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: FWIW (and hopefully this doesn't mean major breakage) I've been considering some changes to the autopilot infrastructure to make it more flexible. For instance, we (or at least I) could really use a mode to hold speed with pitch, or hold pitch with elevator. And it would be nice to be able to support some of the more advanced FCS concepts that right now are only accessible to JSBSim models (things like yaw dampers, and other fly-by-wire type stuff.) Every once in a while I think about looking for a way to make the JSBSim FCS components/system work with FlightGear independently of JSBSim. It was originally conceived to be used by FlightGear as a tool to develop autopilots/FCS implementations, etc. (and it has been used for this purpose inside JSBSim outside of FlightGear). However, since FlightGear features several FDMs, it precludes the strengths (and weaknesses) of one approach from becoming a standard. This is good and bad. It is a disappointment to me to see what I consider one of JSBSim's unique strengths (perhaps even groundbreaking in the flight simulation world) underutilized due to compatibility restrictions. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Linux User & Developer Expo 2004
On Thu, 15 Jan 2004 16:04:32 + "David Luff" <[EMAIL PROTECTED]> wrote: I'm happy to talk if we do get a slot. Cheers - Dave Would it be advantageous -- not only now, but for the future -- for major subsystem "leads" to write up a short monologue? For instance, if there was a concise writeup for each FDM, for visuals, for weather, etc., that might make for a better presentation and would be easier on the presenter, no? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autocoordination : Derivatives in FCS
On Tue, 13 Jan 2004 16:24:42 +0100 "Hof Markus" <[EMAIL PROTECTED]> wrote: Ah. Fine. So you left away the setto feature? Does not matter, I'm sure noone will miss it. What I don't understand is, how you reset the previous inputs? Which application uses this? Can you send me the final FGFilter.* please? Maybe the new TRIGGER feature still needs some work. I coded it pretty fast. Also, maybe we don't need to reset inputs at all - I didn't think about it too hard. I did want to give the ability to reset the previous outputs, though, and I think it works in the new FGFilter.cpp. You can get the new code at the JSBSim web site, either by CVS, or by downloading the tarball on the DOWNLOADS page. See the text at the top of that page. Have you testet the A320-new? Do you like it? I have not had time, yet. It will likely be a few days. Can you tell me how to operate the new capabilities you have added? Or, is it merely part of the regular flight controls? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Mon, 12 Jan 2004 21:38:06 +0200 Paul Surgeon <[EMAIL PROTECTED]> wrote: Excellent! Now go spend some time with your kids Jon. ;) No kidding. Tonight is "library night", so I will be spending some time with the older ones. :-) What would be really useful and helpful is a step-by-step tutorial for the layman of how to configure an FDM and 3D model for FlightGear. Agreed. Our documentation is lacking. I've probably written essentially a how-to over the years in posts here. I'll try and cobble something together. [Any help will be appreciated] Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: yf23 brakes
On Mon, 12 Jan 2004 11:44:27 -0600 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: There is an open issue with JSBSim because it has the concept of a "center brake" which doesn't directly map to the standard cockpit controls. Right now I hardwire that to a value of zero. That may be a misstep on our part. We could easily set that from the flight controls on our side if both "pedals" register as being pushed in - perhaps the average of the two pedals or something ... Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Fri, 9 Jan 2004 23:58:35 +0200 Paul Surgeon <[EMAIL PROTECTED]> wrote: On Thursday, 8 January 2004 23:34, Jon S Berndt wrote: Paul: We (FDM) simply report the location of the reference point (I think we agreed it would be the forward-most position of the aircraft, like the prop hub tip, or nose tip) and FlightGear places the reference point (tip of nose, for example) at that point in "world space". Aha! So AC_AERORP = (0,0,0) in FlightGear's 3D aircraft model space? Er ... no. Sorry. I'll try and post a better description this evening (Texas time). Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot in jsbsim
On Fri, 09 Jan 2004 22:39:20 +0100 Roy Vegard Ovesen <[EMAIL PROTECTED]> wrote: I think this should be implemented in the jsbsim source code, not in the fdm_config xml file. Yes. And it is true there probably should be an initialization capability for filters, integrators, etc. I'll try and look into this very soon. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot in jsbsim
On Fri, 09 Jan 2004 14:52:28 +0100 Roy Vegard Ovesen <[EMAIL PROTECTED]> wrote: Also, note that the derivative part of the example wing leveler control was a complete guess - and I think it actually may not play a large part (or *any* part) in the maintaining wings-level at all. I have also considered using the wing leveler as part of a heading hold control law. Instead of using a roll angle of *zero* to maintain (i.e. wings level) one could insert a desired roll angle. That's only a part of it. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot in jsbsim
On Fri, 09 Jan 2004 15:24:15 +0100 Roy Vegard Ovesen <[EMAIL PROTECTED]> wrote: This is the solution I'm looking to implement, but sadly my knowlege about the jsbsim structure is so limited that I could not think of a way to do it. Maybe the SWITCH component could be used as an if structure? Yes, I think this is exactly a possibility. Have you seen this paper: http://jsbsim.sourceforge.net/AutomaticFlightInJSBSim.pdf ?? There is a decent description of the switch in there. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot in jsbsim
On Fri, 09 Jan 2004 14:52:28 +0100 Roy Vegard Ovesen <[EMAIL PROTECTED]> wrote: The solution to this is to stop the intergation when the actuator goes into saturation. Aha! Good explanation. Yes, I think this should not be too hard to fix, but I don't have time to play with that myself at this time. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autocoordination
On Fri, 9 Jan 2004 00:09:08 +0100 Hof Markus <[EMAIL PROTECTED]> wrote: Take the A320 (on FG) and watch the ball. All I want to know, which property to use for trigger function to keep the ball centered. since you discussed this topic so deeply, I'm sure someone can name me the property... I've been thinking about this a little bit for a while. For an automatic turn, you may want to play around with this approach: 1) Once you know how far you want to turn, you know your "heading error". 2) Command a roll proportional to the heading error, where the roll angle is limited to, say, 30 degrees (what's a standard max roll angle?). 3) Command the elevator to maintain a normal acceleration at the steady level value (0 or 1 g?) *plus* 1/cos(bank_angle). 4) Command the rudder to drive beta to zero I think something like that ought to work. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autocoordination
On Thu, 08 Jan 2004 17:37:25 -0500 David Megginson <[EMAIL PROTECTED]> wrote: John Wojnaroski wrote: Believe it or not, what makes an airplane turn is LIFT... think about it. Same thing -- one wing develops more lift than the other, the plane banks and wants to slip sideways, but as it does the horizontal stabilizer develops (sideways) lift and swings the nose around into the relative wind. That's not what he was referring to, I think. Once you bank, the lift vector has a horizontal component. If you pull back on the stick to maintain altitude (with the corresponding normal force of 1/cos(bank_angle) the force vector points at the center of radius of the turn (roughly) and brings you around. For a non-propeller aircraft (and its characteristic torque) - and particularly for a commercial jetliner - I would think the turn is nearly or completely self-coordinated. Jon Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Linux machines
Dell doesn't seem to market machines with Linux installed anymore, do they? Can anyone point me to a major manufacturer that does? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autocoordination : Derivatives in FCS
On Thu, 8 Jan 2004 20:41:00 +0100 "Hof Markus" <[EMAIL PROTECTED]> wrote: Other topic: Are there any suggestions about how to build a d/d(t) of a property in fdm markus Markus: For JSBSim, you can use the flight control components. This is a quick reply, so maybe I have not thought this all the way out, yet. But, I suspect you can get a derivative control like this: In LaPlace space, a derivative is simply "s", right (it's been a long time since I've worked in LaPlace space - someone correct me if I am wrong, please). You can use the Tustin substitution to go from LaPlace space to the time domain (z domain), as we do with all the JSBSim flight control components (this is typical in industry, too). Have you seen the "Automatic Flight in JSBSim" document at the JSBSim web site? Go to www.jsbsim.org, select Documentation, then select that title. You will see the Lead-Lag and Second order filters described. Select the coefficients for these two filters to give you only an "s" in the numerator. For the lead-lag filter you would selectC1 = 1, C4 = 1, and C2 and C3 would be 0. For the second order filter, C2 and C6 would be 1 and C1, C3, C4, and C5 would be 0. Using these filters should give you the derivative of the input. Now, I have not used these filters for that purpose, yet. Initialization would be very important for them to work correctly. I'd have to test them out to see if that worked correctly. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Thu, 08 Jan 2004 21:34:44 +0100 Erik Hofman <[EMAIL PROTECTED]> wrote: Paul Surgeon wrote: Shucks ... I must be tired or something because this is getting more and more confusing by the minute. What is this "arbitrary point" you are referring to? It is a location which you can choose. You can use the CG, the nose of the aircraft, the center location of the front of the nozzle, anything. Paul: Within the FDM our math model really doesn't care about the specific locations of anything. We really only care about the relative distances from the aircraft CG of things like the wheels, the wings, the aerodynamic reference point, the pilot eyepoint, etc. Also, the FDM always reports the latitude, longitude, and altitude of the center of gravity. One more point (to complicate things further): the CG moves as fuel burns off. So, you may ask: What's a modeler to do? The answer is that we have to agree on a common reference point to report to FlightGear. I mean: the flight model can report to flightgear the position of any point since we have intimate knowledge of the position of the CG and the orientation of the aircraft, and the relative location of the reference point relative to the CG (i.e. the vector from the CG to the reference point). We (FDM) simply report the location of the reference point (I think we agreed it would be the forward-most position of the aircraft, like the prop hub tip, or nose tip) and FlightGear places the reference point (tip of nose, for example) at that point in "world space". I have still not delivered on my promise to provide the reference point to FlightGear. I don't know what we do for the C-172, in order to place it correctly. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autocoordination
On Thu, 08 Jan 2004 14:56:27 +0100 Erik Hofman <[EMAIL PROTECTED]> wrote: Jon Berndt wrote: For JSBSim aircraft, of course, you can by adding in the appropriate control channel in the flight control description for hte aircraft. I think eromatic automatically adds a yaw damper to aircraft created for JSBSim that way (Dave C.?) The X-15 aircraft has a SAS (Satbility Augmentation System) defined similarly. Not automatically. It's upon users request. Erik Oh, that's right. There's a checkbox! Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] different planetary models
I believe we (JSBSim team) will soon have a rudimentary model of the Martian environment integrated within JSBSim. This leads me to a question about FlightGear/SimGear: What is the potential for modeling a planetary body that is different from earth in the following ways: 1) Different radius 2) Different length of day 3) Different inclination angle of axis 4) Different length of year 5) Different moon[s] 6) Earth is in the *sky* - not under your wheels. 7) different oblateness 8) etc. I think much of the surface of Mars has been photographed in decent enough detail - but I don't know about how well the topography is known. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] gear numbering
On Mon, 5 Jan 2004 11:34:15 -0800 "John Wojnaroski" <[EMAIL PROTECTED]> wrote: In JSBSim, for a 747, we would associate both left main gear with the left brake input, etc. Let's not forget that the higher end equipment also has stuff like anti-skid systems which determine when/where and how the brakes are applied. So that for a 747 on rollout for a CAT III landing. the localizer signal is used to maintain runway centerline with a combination of nose wheel steering and braking on the four main gear bogies each with multiple wheels, each tire with it's own anti-skid system. It gets very complicated, very quickly... Perhaps Jim Brennan can add some input on the 747 systems This is where I've considered that we might want to use our FCS capabilities to control the brakes in a more realistic manner. I just haven't had time to try it out. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] gear numbering
On Mon, 05 Jan 2004 10:12:26 -0800 Andy Ross <[EMAIL PROTECTED]> wrote: That convention only works for tricycle gear airplanes with three wheels, though. The problem is that the current input mappings map the following properties to those values: /controls/wheel/gear[0]/brake -- "left" /controls/wheel/gear[1]/brake -- "right" /controls/wheel/gear[2]/brake -- "center/nose" If you have a model with a non-standard undercarriage (the YASim Harrier and 747 have this problem, for example), then it breaks. The notion that there are separate control inputs for each wheel is wrong; in a standard cockpit (i.e. as mapped by the default input bindings), there is a left brake pedal and a right brake pedal. The decision as to which wheels these effect, and how, is the job of the FDM, not the input bindings. Ah. I see. I think. How would brakes work in a Harrier? Would left pedal brake the left outrigger wheel? Would both pedals brake all brakeable gear? In our case, we sort of have a left|center|right brake membership now, that I *think* is versatile enough to handle something like the Harrier, but I'm not sure: how does the "center" brake get set - I mean, what physical control device is used? Is it an average of both pedal inputs? The standard bindings should reflect the controls in a standard cockpit. Right now, for gear, they don't. This complicates life for people writing models for non-standard wheel configurations. Currently, the convention is obviously that there are only three "wheels" for the gear model. My suggestion was to canonize that and call them "left" and "right", instead of numbering them like the gear objects to which they don't (!) correspond. In JSBSim, for a 747, we would associate both left main gear with the left brake input, etc. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] gear numbering
On Mon, 05 Jan 2004 07:12:21 -0800 Andy Ross <[EMAIL PROTECTED]> wrote: But the hard part is that this only works for YASim. I think the other FDMs get their control inputs indirectly, via the FGControls C++ class, instead of out of the property tree. This code would have to be modified before they could use such a system (Jon/Tony/David should correct me if I'm wrong here). Andy In JSBSim.cxx (the JSBSim instance of FGInterface - the FDM/FlightGear bus), we do this in the copy_to_JSBSim() function: ... FCS->SetLBrake(FMAX(globals->get_controls()->get_brake(0), parking_brake)); FCS->SetRBrake(FMAX(globals->get_controls()->get_brake(1), parking_brake)); FCS->SetCBrake( globals->get_controls()->get_brake(2) ); ... In our JSBSim aircraft (and for quite a few years) we have defined a gear object as follows, The gear parameters that can be specified are as follows, IN ORDER OF APPEARANCE: AC_GEAR name of gear entry - no spaces allowed location in aircraft body coords in inches spring constant in lbs/ft damping coefficient in lbs/ft/sec sliding friction coefficient "onset" friction coefficient rolling friction coefficient One of One of Maximum steerable angle in degrees --> AC_GEAR NOSE -6.8 0.0 -20.0 1800 600 0.5 0.8 0.02 STEERABLE NONE 10 FIXED AC_GEAR L_MN 58.2 -43.0 -17.9 5400 1600 0.5 0.8 0.02 CASTERED LEFT 0 FIXED AC_GEAR R_MN 58.2 43.0 -17.9 5400 1600 0.5 0.8 0.02 CASTERED RIGHT 0 FIXED AC_GEAR T_SKID 188.0 0.0 8.0 2 1000 0.2 0.2 0.2 FIXED NONE 0 FIXED AC_GEAR L_TIP 43.2 -214.8 59.4 1 2000 0.2 0.2 0.2 FIXED NONE 0 FIXED AC_GEAR R_TIP 43.2 214.8 59.4 1 2000 0.2 0.2 0.2 FIXED NONE 0 FIXED We've modeled left and right gear for years, so I'm not sure what the problem is. I know I can steer using differential braking on the C-172. I'm not sure I understand the problem. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] INVERT keyword vs minus INPUT
On Wed, 31 Dec 2003 20:59:06 +0200 Paul Surgeon <[EMAIL PROTECTED]> wrote: The minus sign on an INPUT in a JSBSim FDM causes FlightGear to crash. I know the INVERT keywork is being depreciated but it doesn't look like the minus sign is working too well at the moment. You probably don't have the latest version of JSBSim integrated wtih FlightGear. If you have the "ident" program, can you run that on the flightgear executable and post what is output? I can check to see which files you have that built JSBSim and then I can track down the problem. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/dc3/Models dc3-dpm.ac, 1.7, 1.8 dc3-dpm.xml, 1.10, 1.11
On Mon, 29 Dec 2003 15:49:30 -0600
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
David, (Andy?)
It appears that in the latest cvs, we have lost the ability to control
the engines independently. Previously you could type
... etc. to select an engine. Then '{' and '}'
would select the magnetos. Finally, "space bar" would kick in the
starter motor for as long as it was depressed.
Was this an FDM-dependent problem? Or, was it for all FDM's?
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Sky darkening with high altitude
Thinking of the X-15 and its flight profile: does FlightGear do any sky darkening as the aircraft flies up past 100,000 feet altitude? It doesn't seem to me that it would be that hard to do. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] dot no more
Thanks for the overwhelming response to my request for dot. I now have what I need. I'll be trying it out this evening or weekend on the sourceforge site. The dot utility is useful in creating the diagrams such as those seen in the JSBSim documentation I uploaded to the JSBSim.org site. I had to upload it because sf.net shell servers show dot is not installed on the sf.net machines. I've been given the green light to install it under my shell account, so I would be able to run the documentation auto-generation cron job completely. Thanks, Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] (OT) Kid's day at work
On Wed, 3 Dec 2003 19:42:06 - "Jim Wilson" <[EMAIL PROTECTED]> wrote: This should settle the issue: !GASP! He fell OFF! Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] (OT) Kid's day at work
Paul Surgeon <[EMAIL PROTECTED]> wrote: That's the way Boeing USED to make them. Compare that cockpit to a new 737-800 ... The new cockpits must make pilot's lives pretty boring. Paul http://tinyurl.com/xkxh Yep. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG logo Slovenian flag
On Fri, 28 Nov 2003 23:56:34 -0600 Cameron Moore <[EMAIL PROTECTED]> wrote: * [EMAIL PROTECTED] (Jon S Berndt) [2003.11.27 20:37]: On Thu, 27 Nov 2003 10:11:26 + Matthew Law <[EMAIL PROTECTED]> wrote: >On 10:47 Thu 27 Nov , Erik Hofman wrote: >> Yeah, but then you'd get a fight over which flag is put in first and >> which flag is shows just for 0.1 usec (e.g. the last flag) ... >> >> Erik > >Maybe randomise the order ? I'll work on a modified version after the holiday. Might want to start from here: http://unbeatenpath.net/software/fgfs/Developers/Developers.html I don't have Slovenia yet, though. Excellent. Thanks. Can anyone point out a flag for Slovenia? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG logo Slovenian flag
On Thu, 27 Nov 2003 10:11:26 + Matthew Law <[EMAIL PROTECTED]> wrote: On 10:47 Thu 27 Nov , Erik Hofman wrote: Yeah, but then you'd get a fight over which flag is put in first and which flag is shows just for 0.1 usec (e.g. the last flag) ... Erik Maybe randomise the order ? All the best, Matt I'll work on a modified version after the holiday. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Aw: Re: [Flightgear-devel] website
On Wed, 26 Nov 2003 16:22:28 +0100 (CET) [EMAIL PROTECTED] wrote: The FlightGear logo on the top of the website. Yes, I know. I am familiar with it: I made it. :-) What don't you like about it? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] website
On Wed, 26 Nov 2003 15:38:58 +0100 (CET) [EMAIL PROTECTED] wrote: Hello, 1.the design of the website is really good now, but I think we need a new logo. I´m sure there are enough people with painting skills among us. Just post some ideas or pictures! A new logo? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] (no subject)
A good article on the National Geographic web site: http://magma.nationalgeographic.com/ngm/0312/feature1/index.html Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Shut up, already!
On Mon, 24 Nov 2003 13:49:58 -0500
David Megginson <[EMAIL PROTECTED]> wrote:
Andy Ross wrote:
1. The default log level is now FG_ALERT, or at least, it's supposed
to be (though some FG_WARN messages inexplicably still get
through).
What about the presumptively "useful" stuff like the JSBSim touchdown
report or YASim solution data? Would it be a good idea to split out
the "stuff that we actually want to display to the user under normal
conditions" into a separate stream, rather than overloading the
concept of "error importance" to do this?
Or perhaps we could link it to a command ("fdm-report") or something
similar. In JSBSim, I think, it's a function that's called
explicitly by JSBSim.cxx. Perhaps the other FDM's could add a
reporting facility the same way.
First of all, yes, David M. I agree this was a good idea. It was
something I recall I was supposed to have done a while back. The
"philosophy" is one I agree with, but as a developer and with JSBSim
in constant development, I'll probably set my environment variable
here to always show the stuff, anyhow.
As far as the takeoff/landing reports, this is something I've given
some thought to for a while. You might know about the Message setup
we have in JSBSim. We could probably work it so that instead of
giving console output for the takeoff/landing reports (or anything
else that is meant as a user-readable notification), we could instead
send a text message to our FGInterface (in our case, FGJSBSim ??) and
make that text available for the user. I expect they would hit
"Pause", and select a menu option: "Performance Report", or "Takeoff
Report", etc.
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] logging data
On Mon, 24 Nov 2003 09:27:04 -0600 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: David, Now I'm imagining a script that sets up all the initial conditions (altitude, speed, pressure, temp, etc.) as well as specfic logging fields, flies an FAA certification test, logs the results, and graphs the results. Maybe even eventually building a big web page so you can navigate the results of all the tests in your browser, compare fdm A to fdm B, etc. This is pretty much what we set up with JSBSim a year or two ago. We can now plot the data "sets" we want as well as individual properties, and at pretty much whatever rate we want. It's fairly simple. We needed something to regression test our changes, so I modified the command line plotting program I wrote specifically for JSBSim data, and added the ability to run the plotting program in an automated fashion and spit out .png plot file images. I also had the script write out an html page that gave specifics for a test/plot and provided a hyperlink to the property in question. So, we had a set of batch files that could run JSBSim in a specified flight profile (via the JSBSim scripting language) and produced a "report" - all in very few seconds as we were running batch and not real-time. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] concorde
On Wed, 19 Nov 2003 23:16:57 + [EMAIL PROTECTED] wrote: Hahaha! Aeromatic is *for* the end user. The next simplest thing would be to fly to wherever the user is and hold their hand as they type. Jon LOL, I'm free this Sunday if you are, Jon I'm booked for the rest of my life. My wife keeps the "job jar" pretty full. :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] concorde
http://jsbsim.sourceforge.net/aeromatic.html I don't see the concorde button (?!?) :-) Curt. Luckily, of all aircraft, the Concorde ought to be very easily modeled using DATCOM - which I have. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] concorde
On Wed, 19 Nov 2003 16:07:45 -0600 "Jon S Berndt" <[EMAIL PROTECTED]> wrote: On Wed, 19 Nov 2003 16:01:45 -0600 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: Someone needs to whip up a quick flight dynamics model for it. :-) Curt. http://jsbsim.sourceforge.net/aeromatic.html :-) Jon Relevant info found: http://www.aoe.vt.edu/~mason/Mason_f/CrisafulliMS.pdf http://www.janes.com/transport/news/jau/jau000725_1_n.shtml ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] concorde
On Wed, 19 Nov 2003 16:01:45 -0600 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: Someone needs to whip up a quick flight dynamics model for it. :-) Curt. http://jsbsim.sourceforge.net/aeromatic.html :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Landing Gear
On Mon, 17 Nov 2003 11:33:35 -0500 David Megginson <[EMAIL PROTECTED]> wrote: Again, I'm wondering if this is an aerodynamic problem (aside from the bouncing-around-sitting-still thing). Because of its lifting surfaces, a plane is certainly more vulnerable to the wind than a car, even when it is sitting on the ground; however, the coefficients we use in JSBSim are designed to deal with a relative wind near or above the plane's stall speed, coming straight onto the nose +- about 20 deg vertically or horizontally. They probably do a pretty crappy job of modelling (say) a 15 kt gust hitting the plane from 90 deg when it's sitting on the ground. I expect that the same applies to the assumptions made by YASim's solver. Yes, I have considered that. In fact, the realization was the driving idea for the creation of the modified qbar values, qbarUV and qbarUW, which should be used in aircraft aero coefficient definitions instead of simply qbar. For instance, say we are sitting on the runway and have an 80 degree crosswind. We had better be darn sure that CL_alpha is not calculated based on the qbar from straight ahead, because if we have a high (80 or 90 degree) beta, there won't be any appreciable lift - because there would be no wind velocity (thus qbar) over the lifting surface of the wing, parallel to the chord. Also, it emphasizes the fact that our Cn_beta curves ought to cover the range from -180 to 0 to +180. Then, a high crosswind won't adversely (and incorrectly) affect the forces and moments that the gear will be expected to counter. Good observation, and I am aware of the phenomena you describe. As I have laid out, there is a way to get around that by properly defining aircraft aero coefficients throughout the entire range of the flight envelope - EVEN if the off-nominal portion (high values) is a guess, it will be better than not defining it. I think there are also ways to hold the aircraft steady on the ground, change the winds, and record the stabilty derivative (and/or force/moment) that results, in order to "map" the performance and accuracy of the FDM on the runway. This will help for debugging. This involves the property browser and setting of the "dt" to 0.0 during the process. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Landing Gear Dynamics
On Mon, 17 Nov 2003 15:03:39 +0100 Erik Hofman <[EMAIL PROTECTED]> wrote: While the wheel dynamics allow the wheels to move sideways easily, the landing gear dynamics does not allow the landing gear to move sideways (easily). So apart from the the individual wheel dynamics we also need to calculate the dynamics of the complete landing gear. The resulting forces and moments should origin from the point exactly in between the horizontal and vertical location of all wheels. Each tire (bogey, in the case of JSBSim) has a reaction with the ground, which causes it to apply a force and moment to the aircraft about the CG. Now the resulting moments and forces should be added by the results of the individual wheels, not by averaging it, but rather by vector mathematics. Erik Yes, JSBSim applies the contribution of each wheel to the aircraft CG (force and moment), vectorially. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Weight & Balance data...
On Fri, 14 Nov 2003 11:20:42 -0800 (PST) Gene Buckle <[EMAIL PROTECTED]> wrote: Is there any interest in getting that detailed on the W&B calcs? When duplicating a real-world instrument, the weights are easily available and a "generic" weight could be assigned to avionics that don't model a specific real world model/brand. The only problem with that I think is that it won't do much good unless the entire aircraft is itemized, and most of the components' weights won't be known or knowable. I don't think it would buy us anything in noticable dynamic effects. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Property Heirarchy
Is there any designed rhyme or reason to the layout of the properties from the top down in FlightGear? Any particular conventions? I think there ought to be something written down if there is not in order to allow the FDM authors (and others) to splice in nicer. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Version[s]
Suggestion: for debugging purposes (if nothing else) it would be useful to have this command: fgfs --version also spit out info on other pertinent version numbers, e.g. for: plib simgear jsbsim yasim etc. JSBSim has this available in a header file, and IIRC it is also available in a function call. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Instrument and Panel README
Is there a README, FAQ, or manual on making instruments for a panel and/or creating the panel itself? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
On Wed, 5 Nov 2003 13:38:23 -0500 "John Barrett" <[EMAIL PROTECTED]> wrote: I'm looking at creating a new protocol module to handle the low level details of the connection, and a hud overlay like the OLK code to handle Here's a red herring - er ... I mean side note: One thing I've been playing around with (OK, _played_ around with - about a year ago) in JSBSim was the ability to add "child" objects to the main aircraft. Each child would be a separate instance of a JSBSim FDM. The idea would be to provide a way to model an aircraft with attached stores. Each store would transmit forces and moments to the parent aircraft (for example a Mirage) until it was released, at which time the FDM for that child object (for example a Mk-82 or AIM-9) would start integrating and do its own flyout - the parent aircraft now free of the effects of the store. Additionally, each store would have its own config file - and its own flight control system/autopilot/guidance. In theory, the possibilities are limitless for game playing, where one might set up a food drop tank to be released from an aircraft and make a mid-air "connection" to another aircraft, mid-flight, or a water delivery tank could be guided by homing device to a precision landing extremely close to a hostile anti-aircraft battery or needy family (in some cases these are coincident). I've been threatening to complete this for a long time, but one day we'll allwake up and I'll announce that it is finished. ;-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] master and position freeze
On Thu, 23 Oct 2003 15:24:27 -0500
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
Jon S Berndt writes:
On Thu, 23 Oct 2003 13:32:14 -0500
David Culp <[EMAIL PROTECTED]> wrote:
>The command line switch --enable-freeze, as well as the properties
>/sim/freeze/master and /sim/freeze/position don't work (at least
not
>with
>JSBSim or Yasim). I don't know if they ever have, or if they are a
>work in
>progress.
For JSBSim they would need to be wired to the
void Freeze(void) {frozen = true;}
void Resume(void) {frozen = false;}
methods of FGFDMExec. I think ...
Hmmm, /sim/freeze/master worked last I checked, /sim/freeze/position
is probably not implimented for JSBSim or YASim but is still useful
because other FDM's (not necessarily distributed with FlightGear)
might support position freezes.
This could very well be true. You would simply NOT call the FDM in
this case, no?
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] master and position freeze
On Thu, 23 Oct 2003 13:32:14 -0500
David Culp <[EMAIL PROTECTED]> wrote:
The command line switch --enable-freeze, as well as the properties
/sim/freeze/master and /sim/freeze/position don't work (at least not
with
JSBSim or Yasim). I don't know if they ever have, or if they are a
work in
progress.
For JSBSim they would need to be wired to the
void Freeze(void) {frozen = true;}
void Resume(void) {frozen = false;}
methods of FGFDMExec. I think ...
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Lee's TSR2
On Tue, 21 Oct 2003 18:36:58 +0200 Matevz Jekovec <[EMAIL PROTECTED]> wrote: Yes, nVidia graphic cards have drivers capable of twin-view in Linux. You just have to edit your XF86Config file, to match your configuration. Detonator README covers all questions btw. I've used the GeForce card I have (which has twin-view and TV-out) in both capacities and it works well. I could theoretically capture video on the fly, but then it would have to be imported tot he computer again to convert to a .avi or whatever. I have access to equipment to do that, too, but little time. I have been thinking of making a demo video for some time now, though. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
On Thu, 16 Oct 2003 17:15:02 -0400 David Megginson <[EMAIL PROTECTED]> wrote: There are still some problems we need to work out. For example, if you set the wind to 0 and turn off the engine, the helicopter still slides backwards and turns -- we'll have to figure out why there are forces acting on it. To test: fgfs --aircraft=bo105 [EMAIL PROTECTED] --prop:/controls/engines/engine/magnetos=0 This does not happen with fixed-wing JSBSim models. !? Why would it? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] F-16 simulator
On Tue, 14 Oct 2003 22:11:55 +0100 Lee Elliott <[EMAIL PROTECTED]> wrote: Are you sure the differential tail deflections can't be done in JSBSim? Well, it's not so much that it can't be done. However, there are some factors to consider. Depending on the flight conditions and modes, the flight control system will control the ailerons and elevator differently. The control surface mixer may command the aerosurfaces differently depending on conditions and loading, and the flow over the various surfaces is complex and the flow over the tail is especially complex and partially affected by the setting of the aileron (flaperons?). These conditions don't lend themselves well to modeling aerodynamic forces and moments via coefficients in lookup tables. The solution is to model the aerosurfaces by parts, for which JSBSim is not **currently** set up to do. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
Could anyone provide a screen dump image of this aircraft flying in FlightGear? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] web site updates
On Tue, 30 Sep 2003 13:55:05 -0500 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: Andrei Barbu has revamped the flightgear web site layout and made quite a few improvements. I have placed the proposed changes here: http://www.flightgear.org/www.andrei/ Outstanding. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
On Mon, 29 Sep 2003 11:42:18 -0500 David Culp <[EMAIL PROTECTED]> wrote: Failed to untie property /consumables/fuel/tank[0]/level-gal_us Failed to untie property /consumables/fuel/tank[1]/level-gal_us Failed to untie property /engines/engine[0]/fuel-flow-gph Failed to untie property /engines/engine[0]/rpm Failed to untie property /engines/engine[0]/mp-osi Failed to untie property /engines/engine[0]/egt-degf Failed to untie property /engines/engine[1]/fuel-flow-gph Failed to untie property /engines/engine[1]/rpm Failed to untie property /engines/engine[1]/mp-osi Failed to untie property /engines/engine[1]/egt-degf Failed to untie property /engines/engine[2]/fuel-flow-gph Failed to untie property /engines/engine[2]/rpm Failed to untie property /engines/engine[2]/mp-osi Failed to untie property /engines/engine[2]/egt-degf Failed to untie property /engines/engine[3]/fuel-flow-gph Failed to untie property /engines/engine[3]/rpm Failed to untie property /engines/engine[3]/mp-osi Failed to untie property /engines/engine[3]/egt-degf Failed to untie property /engines/engine[4]/fuel-flow-gph Failed to untie property /engines/engine[4]/rpm Failed to untie property /engines/engine[4]/mp-osi Failed to untie property /engines/engine[4]/egt-degf Failed to untie property /engines/engine[5]/fuel-flow-gph Failed to untie property /engines/engine[5]/rpm Failed to untie property /engines/engine[5]/mp-osi Failed to untie property /engines/engine[5]/egt-degf leave NewTgtAirportInit() Dave Oops - sorry - you are probably referring to the AN-225-YASim, which would not be affected by JSBSim changes. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
On Mon, 29 Sep 2003 12:02:26 -0500 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: Did anyone change anything with property names recently? My flight recorder is also broke now. :-( What's the date on JSBSim.cxx? There were some changes that were made to that file for engines, I think. If that was takenf rom JSBSim CVS to FGFS CVS ... maybe ... Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/fokker50/Models
On Fri, 5 Sep 2003 16:01:59 +0100 James Turner <[EMAIL PROTECTED]> wrote: - a similar elevator effect to that martin described, when deploying the flaps at high speeds - very odd high pitch angle behavior ... I can't really describe it, alas. It seems like way too much lift is getting developed at high angles of attack, without a corresponding increase in drag to slow the aircraft. The aerodynamics will only be as good as the coefficient data that is input. :-) Essentially, the aircraft flies pretty well (if a bit twitchy) providing you stick to a 'good' flight regime, but handling deteriorates exponentially when I go even moderately beyond it. I'm aware that part of this may be running 'past the end of the data' in JSBsim, but other models do not seem to have these problems. Can this be alleviated by tuning the last data point for various coefficients, which I assume is what JSBsim extrapolates from? IIRC, the JSBSim data tables are NOT extrapolated. If you fly in conditions outside envelopes for which there is data IN the tables, you will get the value for a coefficient that corresponds to the most xtreme data point available - but not outside the table (is that clear?). So, the advice is to make sure you have made your tables cover all of the regime you want it to cover - e.g. if your table has alpha as a lookup index, make sure it goes to 90 degrees. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] *awk
On Thu, 4 Sep 2003 18:31:11 -0400 David Megginson <[EMAIL PROTECTED]> wrote: Jon S Berndt writes: > Which is better: > > awk > gawk > nawk perl David I'm going to take a wild guess here: I'll bet you and Curt didn't do to well in multiple choice tests in school? ;-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] *awk
Which is better: awk gawk nawk ?? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new scenery samples
On Thu, 4 Sep 2003 16:15:48 -0500 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: Yes. Curt. Is it worth a new screen shot? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
On Tue, 26 Aug 2003 23:37:25 +0200 Erik Hofman <[EMAIL PROTECTED]> wrote: Hi, Curtis is going to do a new scenery release but is unable to get the SRTM30 data include due to time restrictions (they should be generated within a day or two). We might be able to get it going for him if there are enough volunteers to create the data for him. This require quite some dedicated CPU time, so could everybody who wants to participate step forward please? I am volunteering for a good part with a dual processor O200. Erik What are the steps involved? I can help out, I think. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Topographic data
[Sorry if this ends up being a duplicate post] MEDIA RELATIONS OFFICE JET PROPULSION LABORATORY CALIFORNIA INSTITUTE OF TECHNOLOGY NATIONAL AERONAUTICS AND SPACE ADMINISTRATION PASADENA, CALIFORNIA 91109. TELEPHONE (818) 354-5011 http://www.jpl.nasa.gov Nancy Lovato (818) 354-9382 Jet Propulsion Laboratory, Pasadena, Calif. David E. Steitz (202) 358-1730 NASA Headquarters, Washington, D.C. Howard Cohen (301) 227-3105 National Imagery and Mapping Agency, Bethesda, Md. NEWS RELEASE: 2003-116 August 22, 2003 Earth Has a New Look A brand new look and understanding of the place we call home. That's what you'll get in a complete global topographic data set generated by NASA and the National Imagery and Mapping Agency. Produced by the Shuttle Radar Topography Mission, the global data set, called "SRTM30," greatly improves maps of Earth's land mass located between 60 degrees north and 60 degrees south of the equator. That's roughly from the southern tip of Greenland to below the southern tip of South America. Until now, the primary source of digital elevation data for scientists and analysts involved in global studies has been the U.S. Geological Survey's "GTOPO30," published in 1996, which consists of elevation measurements spaced every 30-arc-seconds. An arc-second is a measure of latitude and longitude used by geographers that corresponds to about 928 meters, or 1,496 feet, at the equator. This allows identification of features roughly the size of Disneyland in California. The SRTM30 map matches the GTOPO30 resolution, but with its seamless quality represents a leap in global-scale accuracy. "SRTM30 is a powerful demonstration of the benefits which accrue from NASA's human space flight program and satellite radar mapping technology," said Dr. John LaBrecque, manager, Solid Earth and Natural Hazards Program, NASA Headquarters, Washington. "The quality of previous maps of the Earth varied considerably, because they were compiled from various data gathered by generations of explorers and surveyors. In some places these maps are inaccurate. Using NASA technology, six Space Shuttle astronauts mapped 80 percent of Earth's land surface in just 10 days to produce the first 3-D map of the Earth's surface at a known and uniform accuracy," he said. The need for accurate topographic maps is everywhere from planning a hike to building a highway. Knowing the exact shape and location of mountain peaks and river valleys is as important to the safe and efficient flight of aircraft as it is to the management of water resources and the control of forest fires. Newly released images representing and illustrating the new SRTM30 data products depict Earth in two ways: as an image with all the continents shown (a common map-making method known as a Mercator projection); and as three globe images of Earth as viewed from points in space centered over the Americas, Africa and the western Pacific. Two visualization methods were combined to produce the images: shading and color-coding of topographic height. The shaded image was derived by computing topographic slope in the northwest-southeast direction, so that northwest slopes appear bright and southeast slopes appear dark. Color-coding depicts the lowest elevations in green, rising through yellow and tan, to white at the highest elevations. The STRM30 map is one of a series of land surface products emerging from the very successful Shuttle Radar Topography Mission (SRTM). SRTM has produced more detailed topographic data for North and South America that resolves features approximately 90 feet square, or 10 times the global STRM30 database. The SRTM30 data were processed at NASA's Jet Propulsion Laboratory, Pasadena, Calif., into research-quality digital elevation data. NIMA is providing additional processing to develop mapping products. The U.S. Geological Survey Earth Resources Observation Systems Data Center in Sioux Falls, S.D., provides final archiving and distribution of the SRTM data products. The SRTM mission is a cooperative project of NASA, NIMA, German and Italian space agencies. The project is part of NASA's mission to understand and protect our home planet. The California Institute of Technology in Pasadena manages JPL for NASA. The new images are available on the JPL Planetary Photojournal at http://photojournal.jpl.nasa.gov/catalog/PIA03394 , http://photojournal.jpl.nasa.gov/catalog/PIA03395 and http://photojournal.jpl.nasa.gov/catalog/PIA03396 . Information about the Shuttle Radar Topography Mission is available at http://www.jpl.nasa.gov/srtm/ . -end- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] I think this is relevant
MEDIA RELATIONS OFFICE JET PROPULSION LABORATORY CALIFORNIA INSTITUTE OF TECHNOLOGY NATIONAL AERONAUTICS AND SPACE ADMINISTRATION PASADENA, CALIFORNIA 91109. TELEPHONE (818) 354-5011 http://www.jpl.nasa.gov Nancy Lovato (818) 354-9382 Jet Propulsion Laboratory, Pasadena, Calif. David E. Steitz (202) 358-1730 NASA Headquarters, Washington, D.C. Howard Cohen (301) 227-3105 National Imagery and Mapping Agency, Bethesda, Md. NEWS RELEASE: 2003-116 August 22, 2003 Earth Has a New Look A brand new look and understanding of the place we call home. That's what you'll get in a complete global topographic data set generated by NASA and the National Imagery and Mapping Agency. Produced by the Shuttle Radar Topography Mission, the global data set, called "SRTM30," greatly improves maps of Earth's land mass located between 60 degrees north and 60 degrees south of the equator. That's roughly from the southern tip of Greenland to below the southern tip of South America. Until now, the primary source of digital elevation data for scientists and analysts involved in global studies has been the U.S. Geological Survey's "GTOPO30," published in 1996, which consists of elevation measurements spaced every 30-arc-seconds. An arc-second is a measure of latitude and longitude used by geographers that corresponds to about 928 meters, or 1,496 feet, at the equator. This allows identification of features roughly the size of Disneyland in California. The SRTM30 map matches the GTOPO30 resolution, but with its seamless quality represents a leap in global-scale accuracy. "SRTM30 is a powerful demonstration of the benefits which accrue from NASA's human space flight program and satellite radar mapping technology," said Dr. John LaBrecque, manager, Solid Earth and Natural Hazards Program, NASA Headquarters, Washington. "The quality of previous maps of the Earth varied considerably, because they were compiled from various data gathered by generations of explorers and surveyors. In some places these maps are inaccurate. Using NASA technology, six Space Shuttle astronauts mapped 80 percent of Earth's land surface in just 10 days to produce the first 3-D map of the Earth's surface at a known and uniform accuracy," he said. The need for accurate topographic maps is everywhere from planning a hike to building a highway. Knowing the exact shape and location of mountain peaks and river valleys is as important to the safe and efficient flight of aircraft as it is to the management of water resources and the control of forest fires. Newly released images representing and illustrating the new SRTM30 data products depict Earth in two ways: as an image with all the continents shown (a common map-making method known as a Mercator projection); and as three globe images of Earth as viewed from points in space centered over the Americas, Africa and the western Pacific. Two visualization methods were combined to produce the images: shading and color-coding of topographic height. The shaded image was derived by computing topographic slope in the northwest-southeast direction, so that northwest slopes appear bright and southeast slopes appear dark. Color-coding depicts the lowest elevations in green, rising through yellow and tan, to white at the highest elevations. The STRM30 map is one of a series of land surface products emerging from the very successful Shuttle Radar Topography Mission (SRTM). SRTM has produced more detailed topographic data for North and South America that resolves features approximately 90 feet square, or 10 times the global STRM30 database. The SRTM30 data were processed at NASA's Jet Propulsion Laboratory, Pasadena, Calif., into research-quality digital elevation data. NIMA is providing additional processing to develop mapping products. The U.S. Geological Survey Earth Resources Observation Systems Data Center in Sioux Falls, S.D., provides final archiving and distribution of the SRTM data products. The SRTM mission is a cooperative project of NASA, NIMA, German and Italian space agencies. The project is part of NASA's mission to understand and protect our home planet. The California Institute of Technology in Pasadena manages JPL for NASA. The new images are available on the JPL Planetary Photojournal at http://photojournal.jpl.nasa.gov/catalog/PIA03394 , http://photojournal.jpl.nasa.gov/catalog/PIA03395 and http://photojournal.jpl.nasa.gov/catalog/PIA03396 . Information about the Shuttle Radar Topography Mission is available at http://www.jpl.nasa.gov/srtm/ . -end- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: Aircraft Carriers
On Thu, 21 Aug 2003 18:32:18 +0100 (BST) Jon Stockill <[EMAIL PROTECTED]> wrote: On Thu, 21 Aug 2003, Matevz Jekovec wrote: I think S-3 Viking. C130 http://www.aerospaceweb.org/question/history/q0097.shtml ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim Propeller Drag
On Wed, 6 Aug 2003 17:41:33 -0400 David Megginson <[EMAIL PROTECTED]> wrote: you are flying fast enough (i.e. a dive). Any suggestions? JSBSim does not handle windmilling properly either. Any suggestions? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] request for comments?
On Tue, 5 Aug 2003 11:23:07 -0500 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: but it may give us many more options for moving forward with new and better graphic effects. My uneducated, gut feeling, leads me to opt for the route that gives the most promise for the future. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Network Server
On Tue, 5 Aug 2003 19:36:15 +0100 (BST) Paul Morriss <[EMAIL PROTECTED]> wrote: * Mass Multiplayer Server (MAYS) - Instead of a single How do you get MAYS from Mass MultiPlayer Server? Should it not be MMS, or MMPS? This is serious. The correct acronym is critical in getting project support! ;-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] metakit
On Sat, 2 Aug 2003 16:03:33 -0400 "Norman Vine" <[EMAIL PROTECTED]> wrote: Yes this is *very* annoying :-) Yep. I haven't quite figured out how to work this into my batch build script. If I could figure out how to latch into the result code when simgear checks to whether the latest metakit is installed, then I'd like to pause there and build/install metakit. cd $METAKIT/builds ../unix/configure --disable-shared --with-out-tcl --prefix=/usr make make install I'm a little slow on the uptake - will the above fix the problem I had been having after building and installing metakit, and it still wasn't detected? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Gliding (Stall)
On Fri, 1 Aug 2003 15:14:57 -0400 David Megginson <[EMAIL PROTECTED]> wrote: That's a problem with JSBSim models in general -- most of them tend to drop a wing in the stall. The problem is that JSBSim only recently started supporting wing washout We did? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Lee's YF23
On Wed, 23 Jul 2003 10:07:22 -0500 David Culp <[EMAIL PROTECTED]> wrote: ..cool, then we don't need my F-16 drag shute housing pics. ;-) Do we have drag shutes modelled? Yes. There exists a property called /controls/flight/drag-chute which takes a boolean value. In JSBSim you could add a Kinemat component to the FCS, just like speedbrake, gear or flaps. This would give you an fcs/drag-chute-norm value that you can use by also adding a "Drag-due-to-drag-chute" coefficient to the drag axis. Well, sort of. I hadn't thought of doing it that way. The thing is, you have to keep track of its attach point, and if there are any winds, the the 'chute pulls the attach point parallel to the relative wind vector at that point. If you are landing in a crosswind, the controllability aspects are obvious. Also, the deploy/reefed/unreefed drag coefficients could be modeled and executed by the FCS, I think, as you mention. It bears some more thought. The same ideas that play into 'chute modeling play into master/child relationships that I have been toying with for some time (i.e. aircraft / water & fire retardent / food aid, etc. drops). Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Lee's YF23
On Wed, 23 Jul 2003 16:35:52 +0200 Arnt Karlsen <[EMAIL PROTECTED]> wrote: Do we have drag shutes modelled? I've thought about this extensively. There are lots of reasons I'd like to model it. It would not be too hard, either. It's the *time*. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Lee's YF23
On Tue, 22 Jul 2003 23:36:11 +0200 Matevz Jekovec <[EMAIL PROTECTED]> wrote: That's amazing! Are there any F16 models planned for FlightGear in early future? Because I have few friends from Falcon community who could lend us their models and skins with no problem. There already is. There is a JSBSim F-16 creted by Erik Hofman. Erik: Is that in FlightGear CVS already? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
On 1 Jul 2003 17:20:40 GMT Martin Spott <[EMAIL PROTECTED]> wrote: I'm happy to see those in CVS, I yet have to verify if this breaks build on other platforms. BTW, we have to give notice to Jon about these changes, otherwise he'll revert them on the next JSBSim update. Would anyone commit the fix for SimGear ? Martin. I think Erik has already taken care of this in JSBSim CVS. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Contrails
What's the potential of creating contrails for such a thing as the X-15 rocket engine? Wingtip vortices? etc.? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Scripting
Some of you may know that JSBSim has the ability to make scripted runs. I would like to be able to do this for JSBSim when integrated with FlightGear. It won't be terribly difficult at all - I'll just need to add a few lines inside JSBSim.cxx. If no script is specified, no effect is made on execution. The question for me is, how would I pass a script name into FlightGear? I think the answer will not be too difficult. Would I be correct in guessing that FlightGear already has a sort of scripting capability? If so, can someone point me to an overview or users guide, or provide a quick overview of its capabilities? If there is one, I might suggest that I could simply use the command line option for the scripting file for my own use - that is, if the script specified on the command line is not a FlightGear script, then that option could be passed on to the FDM in use. Or, perhaps there is another way? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New buildings models
On Wed, 18 Jun 2003 16:00:22 +0200 Martin Dressler <[EMAIL PROTECTED]> wrote: You should be able hide your aircraft in Hangar. If I remember it. Even new hits routine has some support for this. Madr I think Norman may know the answer to this one. However, JSBSim simply gets a terrain height from FlightGear in calculating gear forces or contact ... whatever. So, if FlightGear is returning the underlying terrain height - and not the highest point at any position - then we should be OK. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering options
On Tue, 17 Jun 2003 17:00:45 - "Jim Wilson" <[EMAIL PROTECTED]> wrote: Erik Hofman <[EMAIL PROTECTED]> said: /sim/rendering/enhanced-lighting toggle enhanced runway lighting on or off /sim/rendering/distance-attenuation add distance attenuation to the enhanced runway lighting What is the enhanced runway lighting? Screen shots? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A320 progress
On Mon, 16 Jun 2003 16:31:22 +0200 (CEST) Frederic BOUVIER <[EMAIL PROTECTED]> wrote: Martin Spott wrote: > Just an update on the A320 model : > http://perso.wanadoo.fr/frbouvi/flightsim/a320-fgfs-02.png > http://perso.wanadoo.fr/frbouvi/flightsim/a320-fgfs-03.png What was the flight model for this? Was David Culp modifying the 737? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What is ...
On Wed, 11 Jun 2003 19:54:45 +0200 Pieter Pareit <[EMAIL PROTECTED]> wrote: Op woensdag 11 juni 2003 19:37, schreef Jon S Berndt: What's a wiki? http://www.wikipedia.org/w/wiki.phtml?search=wiki&go=Go In short, a web page that can contain anything, that can be updated by anyone at anytime. Hmmm. I'm skeptical over how useful such a thing would really be. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] What is ...
What's a wiki? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
On Fri, 6 Jun 2003 10:27:39 -0700 (PDT) Gene Buckle <[EMAIL PROTECTED]> wrote: If he flies for Aeroflot, they may not notice the difference. *gd&r* You guys are scaring me. ;-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
On Wed, 4 Jun 2003 20:40:42 +0200 Jorge Van Hemelryck <[EMAIL PROTECTED]> wrote: It will be easy to convert the 737 model to an A320. I'll send you one. What about fly-by-wire ? How can it be taken into account ? Since David is making a JSBSim version of the A-310, you can use the JSBSim flight control capability for the flight control system. If you have the flight control block diagram (or can craft a suitable fascimile) you can model the FCS. There is some rough documentation at the JSBSim web site, but I am in the process of creating much better documentation for the flight control system at the moment. I'll need a couple of more days for that. Jon Coordinator, JSBSim Project. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Another pre-release consideration
On 03 Jun 2003 15:30:46 -0700 Tony Peden <[EMAIL PROTECTED]> wrote: The roll trim was bound to the yaw trim props and vice-versa. Probably the fault of the guy who did the properties for JSBSim, can't remember his name offhand, though, ... Well, we'll have to dock his pay when we find out who he is ... ;-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Another pre-release consideration
On Tue, 3 Jun 2003 16:08:50 -0400 David Megginson <[EMAIL PROTECTED]> wrote: Here's something else to worry about before the release: a recent bug fix in JSBSim ?? Which fix ?? meant that all of the JSBSim-based propeller planes are now badly out of trim. I fixed the default C172P, but I need to know what else people actually fly, so that I can fix it for the release. I would think the C-310 for sure should be tested, perhaps all the prop planes. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
