RE: [Flightgear-devel] JSBSim broken?
I couldn't help but notice that the JSB version of the 747 has a lift-ratio which would make a sailplane pilot envious. One can glide about with full flaps, gear out etc with AoA at 30--40° in 80 kias and keep it level. ;) When running it with --debug-level=debug I get some numbers on JSB's idea about drag, for instance: I appreciate the report. I wanted to let you know I got your email and your bug report is in the queue. I'll put this report in a JSBSim bug report (see www.jsbsim.org). I'd like to emphasize how important it is to get reports from users. THe very best way to let us know about bugs (for JSBSim) is to file a bug report at www.jsbsim.org. That way we are sure it won't get lost. We've got a lot going on right now, and I'll try to get to that ASAP. Maybe someone else can answer that sooner than I. Jon -- Project Coordinator JSBSim Flight Dynamics Model http://www.jsbsim.org ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] JSBSim broken?
I couldn't help but notice that the JSB version of the 747 has a lift-ratio which would make a sailplane pilot envious. One can glide about with full flaps, gear out etc with AoA at 30--40° in 80 kias and keep it level. ;) I've filed the bug as: http://sourceforge.net/tracker/?func=detailatid=119399aid=1372940group_id=19399 Thanks, Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] JSBSim broken?
Log some output parameters. That can be done using the OUTPUT section of the config file. See the X-15 (?) or C-172x config file. I'll get around to it as soon as I can. I'm _sure_ there's a simple explanation for this. Jon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Joacim Persson Sent: Sunday, December 04, 2005 5:55 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] JSBSim broken? On Sun, 4 Dec 2005, Dave Culp wrote: As far as the drag values go, the CD0 looks good, and matches aeromatic well. ... The flap drag looks good. Then for some reason all those numbers are ignored. Either in jsbsim internally or in the fg--jsbsim interface. The plane glides virtually forever. Like overshooting the runway by 15nm (after which I got bored) with an attitude of 30° in 90kts at 180' AGL (=no ground effect). (It looks funny though. =) I've been testing other jsbsim models tonight apart from the 747-100: 737, c150, c182 and they all seem to have extremly low or zero drag. They won't stall. But since the jsbsim guys are busy preparing a new release which will affect the config files anyway(?) I think I'll just drop it for now. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] JSBSim broken?
I've been testing other jsbsim models tonight apart from the 747-100: 737, c150, c182 and they all seem to have extremly low or zero drag. They won't stall. Hmmm. I've not heard any complaints about the other aircraft. The 737 has been extensively tested by someone who knows how they fly. Also, if any of these aircraft had zero or artificially low drag, they thrust produced by the engine would propel them to unbelievably high speeds. Now, I haven't tested these models in a long time (yes, I am incredibly busy right now on many fronts), but if the C182 flew at 400 kts I think I'd hear about it. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] yasim vs jsbsim c310
I've just tried out the c310 @KSFO, current metar conditions. The Yasim one develops 38PSI of manifold pressure, ~2700RPM at props and throttle full forward on the ground, brakes applied. The JSBsim gives a (more realistic-?) 29PSI. No surprise the ground roll at the Yasim one's is much shorter. 25 squared in Yasim means the throttle around halfway in at 500agl. I've never been in a c310 myself, passenger or pilot, but one of these aircraft simulations seems wrong. It may be a case of input data being different. There may be several slightly different engines that could be used. I've got bigger fish to fry at the moment, but if you come upon some good specification data, post it here. Some tweaking might be in order. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OpenGL and new video card
I've installed a new video card (eVGA 6800, 128mb) in my Windows 2K box. Unfortunately, now OpenGL apps give an application error - they don't even start up. I'm trying to get some answers out of the card and driver manufacturer, but if anyone here has any suggestions, I'd appreciate hearing them Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OpenGL and new video card
I've installed a new video card (eVGA 6800, 128mb) in my Windows 2K box. Unfortunately, now OpenGL apps give an application error - they don't even start up. I'm trying to get some answers out of the card and driver manufacturer, but if anyone here has any suggestions, I'd appreciate hearing them Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS:data/Aircraft/Lockheed1049/Models
That was my understanding of it, but it seemed to not work with ___'s Connie model. Upon further review it looks like ___'s Connie model has an x-offset of about 14 meters, and I can't figure out why. So, I'll drop my investigation of it. Dave :-) Once we get the new JSBSim FDM into FGFS CVS I'll have a look at it (there's always something _just_before_ the good stuff on my todo list). Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Alpha problems with 2.5D panel on C310 and aftCenter of Gravity
I noticed in the JSBSim file (c310.xml) definitions for pilot, copilot, rear passengers and baggage. It all seems to be in the main cabin (i.e. no baggage in the nose compartment). To lighten the load I'm going to remove the rear pax. Will this automagically bring the CofG forward, or do I need to modify something else? Yes, it will. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS and PLIB
Is there some kind of problem going on with downloading PLIB from CVS? Seems there's been a partial outage in progress on SF.net for weeks. I can't get plib from CVS, though ... :-( Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/Lockheed1049/Models
One thing that may be confusing is that the VRP setting given by aeromatic is wrong. In the JSBSim configuration file If the CG location is X, Y, Z, then the VRP location is -X, -Y, -Z.I had thought that AC_VRP defines the location of the VRP, however it actually defines the location of the VRP *from* the CG (?). I never noticed it in the T-38 and other smaller airplanes because the effect is hard to see. In a big airplane like the 1049 you can see it. The above may seem authoritative, but I'm really only 90% sure it's correct :) I know you have all been waiting impatiently for another VRP thread. Dave No. The VRP defines the location of an agreed-upon reference point in structural coordinates. The CG, eyepoint, gear locations, etc. are all defined (in JSBSim) in structural frame. By convention, we've agreed that the nose is typically a good reference point, because it is (or should be obvious) to both the 3D model designer and the FDM designer. The CG generally cannot be used, because it moves - sometimes that movement could be profound. Think of it this way: the structural frame is a fixed, solid, coordinate frame that permeates the aircraft structure. The structural frame we use MUST have X positive out the back, and Y out the right wing. The Z axis completes the right-handed system positive upwards. The _origin_ is what is usually found to be confusing. Often, the origin is located by having the X axis be coincident with the fuselage centerline, with X=0 at the tip of the nose - but THAT IS NOT A REQUIREMENT. If the origin is 200 inches in front of the nose, then the VRP could be defined as (200, 0, 0). If the 3D model designer understands that, the aircraft model can be placed with the nose at the location pointed to by JSBSim. The VRP is the registration mark that relates what is reported by JSBSim and what part of the 3D model is placed at what location in the 3D world. Within JSBSim, the equations of motion are all done relative to the CG. However, JSBSim can send to FlightGear the lat/lon/alt of ANY desired point on the aircraft, at any time, in any orientation (it's not hard). We just have to agree on WHICH point is being sent. That's what the VRP is all about. I pray to God that explains it for the last time! :-) Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [BUG] [PATCH] (announcement) throwingstale exceptions and missing copy ctor/assignment
I wonder what compiler was JSB using in his string throwing example, can you please re-read that thread and see if you can find an alternative explanation? Vassilii I use Borland C++, and the g++ compiler in the cygwin distribution. I also compile under a flavor of Linux, just to see what happens. I've been worried that try/catch/throw is something that is not supported similarly on different compilers. I've got other priorities right now, but please make use of our bug reporting mechanism at www.jsbsim.org. It's really the only way to be sure we don't lose track of stuff. Thanks, Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] ATC and aerodynamics docs
Szabolcs Berecz writes: Could you direct me to some good online documentation about ATC and aerodynamics of a helicopter? Okay, I said I was going to email them privately, but then I looked at a 32MB email in my outbound queue and realized that that was beyond bad form. See: http://www.flutterby.com/danlyke/helicoptersimnotes/MinimumComplexityHelicopterS imulationMathModel.pdf http://www.flutterby.com/danlyke/helicoptersimnotes/naca-report-824.pdf http://www.flutterby.com/danlyke/helicoptersimnotes/naca-tn-4357.pdf Robert Heffley (co-author of the Minimum Complexity ... document) has his papers online (including that one): http://robertheffley.com/pages/lib.htm You can also search the NACA technical report server here: http://naca.larc.nasa.gov The papers are online there, too. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/Lockheed1049 - New
The Constellation looks pretty nice, but has a significant drawback: The author has forgotten to implement the offset between FDM center and visual reference point. This means the aircraft rotates around it's nose which makes it almost impossible to accurately rotate for liftoff. Furtheron it looks really funny when the aircraft wags the whole body when you use the elevator ;-) Syd, I presume this is your work. Would you mind adding this offset ? Thanks, Martin. I *think* I know who did this model. I'll notify/ask him abou tit. Thanks for noticing the VRP aspect. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] WARNING: FlightGear / JSBSim changes
As has been mentioned, JSBSim has been undergoing major improvements over the past year (see the newsletters) centering on added capabilities and improved XML well-formed-ness. The majority of those improvements have been completed and tested, both in a standalone, scripted mode, and in the previous release of FlightGear itself. We will be moving the new code into FlightGear development CVS shortly. My goals during that process are as follows: A-1) Don't break FlightGear compilation for other FDMs. 2) Provide replacement models for JSBSim aircraft as soon as practical. 3) Make sure that existing JSBSim aircraft models function correctly as soon as possible. 4) Provide documentation on the new format, and a converter. We've done all we can in the way of testing and validation of our code prior to the next step. However, once that is accomplished and refined, I think we'll see some real benefits to this. The new config file spec (the new format) is pretty nice. It was designed to be compatible with the emerging AIAA standard for aircraft flight model exchange, to be called AeroML (see: http://daveml.nasa.gov). I have heard from at least two other flight model programmers who have expressed a desire to use the JSBSim config file format as their own spec. So, I believe the new spec (v2.0 - that's the version number for the config spec - not JSBSim itself) may lead to more aircraft eventually being available for FlightGear and other sims. I'm not sure exactly when the changes will be incorporated into FlightGear (I have to discuss this with the other JSBSim developers - particularly Erik). But, this serves as a heads-up and an open period for questions and comments. Jon -- Jon S. Berndt Project Coordinator JSBSim Flight Dynamics Model http://www.jsbsim.org ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 31, Issue 101
Syd, I presume this is your work. Would you mind adding this offset ? Thanks, Martin. I *think* I know who did this model. I'll notify/ask him abou tit. Thanks for noticing the VRP aspect. Jon Hi guys no that one isn't mine. As they say: The issue is being worked. :-) Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Speaking of carriers ...
A nice shot of a carrier landing: http://www.airliners.net/open.file/961401/M/ Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Release of v0.9.9 source code
And if none of this is possible, then I'm afraid I don't have a TODO list and this will be the most boring release cycle ever. m. Heh. Maybe. Maybe not. I hope that from your point of view it turns out to be a boring release cycle. In one respect, it should not be very noticeable to users what has happened, apart from the fact that none of the existing JSBSim aircraft, engines, or thrusters will work in their current form. They will have to be converted to the new JSBSim config file format. A conversion helper tool is available. For over a year myself and others have discussed refining the JSBSim config file format to a more well-formed design. I have also tried to consider what was done by the guys working on the AIAA standard for aircraft simulation model exchange, to be called AEROML (formerly known as DAVEML, see daveml.nasa.gov). As part of the config file format change, new capabilities were added. The version of JSBSim to be added to FlightGear developer CVS in the coming weeks will be a major change. I'll describe the new features in the JSBSim developer list soon. I'm also fixing up the comments in the code to reflect the new changes, and will be publishing a document on the new config file format, as well. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] error:Unknown exception in the main loop
I'm now working on the unsafe throws/catches in the SimGear/FlightGear/Atlas/fgrun codebase. A hefty amount of things to change is in the scope of the JSBsim code. What should I do --- ignore them and hope for JSB doing a correct cleanup upstream, or patch these as well? Vassilii If you are aware of unsafe throw/catch code in JSBSim, go ahead and either email me or post a message in the JSBSim mailing list. I'll be glad to take a look. Thanks, Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Release of v0.9.9 source code
I agree with Franz Melchior. And my question is, why it is so essential to call the next version release 1.0? What's wrong with version numbers like 0.9.10, 0.9.11, 0.9.12 etc. until the above issues are fixed? That's what's been getting done for years. The question now is, why not? Curt's been working on FlightGear for ... what ... about ten years, now? To turn the argument around, there's nothing to fear from calling it 1.0, either. The next release would be a fitting v1.0, IMHO. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] try ... catch ... throw (up)
Vassilii Khachaturov wrote: I am unsure it is OK to through a temporary object like this. It's created on the stack right there at the same frame where it's thrown, but IIRC, as throw unwinds the stack, it is auto-destructed. You should be throwing an object that has lifetime encompassing the outer catch handler. Ah! Yes, that sounds correct. I'll have to go back and change my throws. Thanks, Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] try ... catch ... throw (up)
I've been trying to use exception handling in a particularly appropriate place
in JSBSim,
but am having little success, and it's got me confused.
I have a section where I am reading in some data. If it is inappropriate, I
need to let
the user know and exit.
Here's what I'm doing:
In the Table class:
In FGTable constructor:
if (operation_types.find(parent_type) == string::npos) {
internal = true;
} else {
throw(string(An internal table cannot be ...));
}
Now, this seems to work OK - I throw an exception if a situation occurs that is
invalid.
Here's where the above code is originally called from:
In FGFunction constructor:
try {
Parameters.push_back(new FGTable(PropertyManager, element));
} catch (...) {throw;}
This is supposed to pass the exception on up the chain to here the code that
calls the
above:
In FGAerodynamics::Load():
try {
variables.push_back( new FGFunction(PropertyManager, function_element) );
} catch(string msg) {
return false;
}
Execution seems to get to the throw in FGFunction and dies. Execution never
gets to the
handler in FGAerodynamics. I get a segfault.
I'm probably missing something fundamental here. Anyone have any suggestions?
Jon
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] 737 nosewheel animations
Hi, attached are two small patches for giving the 737 nosewheel some animations. Namely it rotates when steering and compresses on breaking. For the latter I attached a one line patch that let's JSBsim expose compression-norm to the property tree just like YaSim. I don't know if this is in any way correct, but it gives some plausible movement visually. Now if there were some skid sounds you could get an impression how such a large plane feels like on the ground ;) Nine I've got these slated to go into the new JSBSim code, as well. I hope to implement the changes today. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] (electrical) Flightgear-devel Digest, Vol 30, Issue 24
Curt wrote: The nasal script is specific code to impliment a specific aircraft's electrical system, but the overall structure could be copied and adapted to new aircraft. But each aircraft will need it's own aircraft specific script. I'll add that there are probably several ways to do various mechanical/electrical system models. You may recall from Summer 2005 JSBSim newsletter an article about the L410 aircraft model done by Jiri Javurek. They use the JSBSim flight control components to model various systems in ways I had not considered before. For example (and this is old format - the current format in FlightGear CVS - JSBSim specification): FLIGHT_CONTROL NAME=l410 !--Stav baterii-- COMPONENT NAME=battery-all-ok TYPE=SWITCH TEST LOGIC=DEFAULT VALUE=0 /TEST TEST LOGIC=AND VALUE=1 /systems/l410/battery1-ok == 1 /systems/l410/battery2-ok == 1 /TEST /COMPONENT COMPONENT NAME=battery-one-ok TYPE=SWITCH TEST LOGIC=DEFAULT VALUE=0 /TEST TEST LOGIC=OR VALUE=1 /systems/l410/battery1-ok == 1 /systems/l410/battery2-ok == 1 /TEST /COMPONENT COMPONENT NAME=battery-all-ok2 TYPE=PURE_GAIN INPUT fcs/battery-all-ok GAIN 1 OUTPUT /systems/l410/battery-all-ok /COMPONENT COMPONENT NAME=battery-one-ok2 TYPE=PURE_GAIN INPUT fcs/battery-one-ok GAIN 1 OUTPUT /systems/l410/battery-one-ok /COMPONENT !-- specialni nasobne sbernice -- COMPONENT NAME=spec-turn TYPE=SWITCH TEST LOGIC=DEFAULT VALUE=0 /TEST TEST LOGIC=AND VALUE=1 /systems/electrical/outputs/bus28v 10 /systems/electrical/outputs/bus36v 10 /systems/electrical/outputs/bus115v 10 /TEST /COMPONENT COMPONENT NAME=spec-turn2 TYPE=PURE_GAIN INPUT fcs/spec-turn GAIN 1 OUTPUT /controls/switches/specbus_28v_115v_36v /COMPONENT etc. It's quite an impressive use of the components. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Source code
The version of FlightGear used for the MIADC show in May contains a fan/turbine model based on physics and thermo equations, a different approach to tank/engine selection to handle the 747 fuel system, changes in the control packet, and an update to the data packets. It might not be practical to try and incorporate these into the CVS baseline .I'm not sure and not all that conversant on how to create all the ifdefs and other compile/run time options or xml files to handle all the deltas. However, the source is there for anyone brave enough have a go at it or just to consider if it might be feasible. As I recall, Curt first created a diff file against the then current CVS baseline, next ran patch, and IIRCC the build was very clean. Go to http://www.lfstech.com and browse over to the download page. The file is miadc.tgz. John W. Hi, John: Very nice. I looked at FGTurbine.cpp. A couple of things: 1) Of course, it would be nice to incorporate the JSBSim changes into the current JSBSim CVS. However, as you may know, JSBSim has undergone major revisions compared to the version now in FlightGear CVS. Within weeks (maybe sooner) we should be moving the new JSBSim code into FlightGear development CVS. So, to incorporate your changes, the Load() method will need to conform to the use of the new XML parsing method. 2) Question: Is your turbine model generic, or specific to the 747? 3) Did you make note (in code or whatever) of exactly which files you modified? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Source code
Out of interest, did Mathias ever manage to fix the gear jitter at stationary with his fancy integration scheme, and if so will it be going into FlightGear when you merge up next? Cheers - Dave No. (I hope this doesn't open up a can of worms ...) Though it is acknowledged that Mathias' fix would have worked well, and is mathematically precise, the code overhead was sophisticated, large-ish, and somewhat complex - an evaluation that is, of course, open to interpretation and difference of opinion. The quandary I always face as development coordinator is in balancing design goals and actual capabilities. I had to consider the needs and perceived comfort level of the target audience[s], as well as myself. It led to a lot of really excruciatingly uncomfortable choices, some of which were so personally vexing that I continually put them off. At this point, yes, the gear still jitters, and it is still a high priority to be addressed. The route I prefer to take - at this time - is best described this way: The EOM and integration scheme now in use (which Mathias also adeptly refined) works quite well for almost anything that anyone wants to do with JSBSim. The single most important remaining problem that involves the dynamic math model is the same problem that the literature shows afflicts many other simulators: landing gear modeling at low and zero velocity. I do not feel it is the best solution at this time to consider a new and major change to the integration scheme in order to address this one problem. There are probably a few good approaches to fixing the gear problem - and it does need to be fixed. One good one is presented in an AIAA paper (AIAA-200?-4303). In that paper, the tricycle approximation is described. At some point, the integration scheme in JSBSim will probably be revisited, after some other approaches in JSBSim are modified. The gear jitter problem will be addressed. Right now there are other pressing needs. I don't know what else to say ... Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Source code
John Wojnaroski wrote: It's generic, but needs some massaging to handle things like compressor/turbine maps, engine parameters such as inlet area, fan size. Point in fact, the model is based on John Reed's paper for LeRC, but the actual numbers are my best guess to obtain some reasonable numbers for engine performance and response. The start sequence is kind of nice with the EGT showing the typical rise to a peak and then settling into the idle range. Is this the paper: --- A Java simulator for teaching gas turbine operation John A. Reed and Abdollah A. Afjeh (Toledo, Univ., OH) AIAA-1997-850 Aerospace Sciences Meeting and Exhibit, 35th, Reno, NV, Jan. 6-9, 1997 --- I can't find it anywhere online. The FGTurbine code is replaced en masse. No, sorry did not, but you should be able to run a diff. It's been a few months since I worked in that area, recall some changes in the FGEngine, and a few other areas to handle loading in the other engine parameters from the xml files. Probably makes more sense to wait for the next JSBSim release. I'll probably revisit that code in the next few months for another project and update it as needed. Sounds good. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Rita
I'll likely be relatively sparse on the Internet for the next week or so - perhaps much, much longer depending on how things go in League City, due to Rita. I'm about 14 feet above sea level, about a mile inland from Galveston Bay. Anyone else look like they're going to be affected by this? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Release 0.0.7 of Digitrak Autopilot
To everyone who has helped, thanks. My goal is to model the behaviors and capabilities of the Digitrak with as much accuracy is possible given my ability and the limitations of Flight Gear. I doubt it would be possible or desirable to model the electrical characteristics of the sensors or reverse engineer the actual code. The short term goal is to model the basic behavior of the autopilot, to get the basic modes working, then see what is possible. My long term goal is to model the building blocks, the gyros, the magnetic compass and let those feed into the autopilot's calculations. This will help model the autopilot without depending on any of the other instruments. The ultimate goal would be to model it well enough to use as a training tool. Just out of curiosity, have you looked at the flight control system modeling capabilities in JSBSim? I realize that limits you to JSBSim aircraft, which in itself might be a show-stopper. Also, the newest and most useful features are in the codebase which has not yet quite made it into FlightGear CVS. However, it still might be interesting for you. the JSBSim FCS model that will be [shortly?] placed into the FlightGear branch features: - Sensor modeling (for scalar values - not vectors, yet) that features some failure modes controllable via properties. - Sensors can output quantized values of arbitrary bit width. - Sensors can feature noise and drift. - The flight control system components include generic filters and an integrator. - There is a function component that can model a user-defined function that includes sine, cosine, abs, etc. functions. - Other components include summers, gains, scheduled gains, scale-mapping, switches, and kinematic controls (for modeling landing gear, aerosurfaces, etc.) You can read about the flight control system more in some of the JSBSim newsletters. I've already implemented a test autopilot. It's a lot of fun to play with. The point is that you have complete control. Just an idea. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] EasyXML.cxx
I'm not surprised it breaks with malformed XML files.
A suggested fix is below.
if (!input.good()) {
sg_io_exception ex(Problem reading file,
sg_location(path,
XML_GetCurrentLineNumber(parser),
XML_GetCurrentColumnNumber(parser)),
SimGear XML Parser);
XML_ParserFree(parser);
throw ex;
}
--Richard
Has the disposition of this been resolved, yet?
Jon
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [OT] Newsletter
This is off topic for FlightGear specifically, but I also am the Editor and a writer for another newsletter in addition to the JSBSim newsletter. The July/August issue was just posted. I thought you might be interested to read the newsletter for the Houston chapter of the American Institute of Aeronautics and Astronautics: www.aiaa-houston.org/newsletter There's lots of aerospace in there! Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [EMAIL PROTECTED] Conference
I'd give a lot to know what these two papers are presenting! See below: Jon --- [EMAIL PROTECTED] Conference 26 - 29 Sep 2005 Hyatt Regency Crystal City Arlington, Virginia Session 71 COTS Software in Mission Critical Systems 0930 AIAA-2005-7108 Open Source Software: Cheap Isn't Exactly Free! B. Calloni, J. McGowan, and R. Stanley, Lockheed Martin Corporation, Fort Worth, TX 1000 AIAA-2005-7106 Bazaar Meets Cathedral: Concerns About Open Source Software in Mission Critical Systems [invited] R. Kwan, Lightsaber Computing, Fremont, CA ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] 3D Cockpit view, L410 Turbolet
We used red and green in Europe :-( Erik Did you look at it, anyhow? The blue and green channels both are set for the right eye. Red/Green glasses should work, too. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] 3D Cockpit view, L410 Turbolet
I have, and would love to see it added to the FG collection - it appears to be a thoroughly thought-out model. However, it's just too much trouble for me to keep a third copy of FG for the sake of one model. What is the general opinion of the modifications done to the FG source in particular - are they likely to be introduced into CVS any time soon? It seems a pity for such an amount of work to miss wider exposure. Does the new JSBSim version do what their model requires? AJ I've given a quick view to the changes that were made to JSBSim. I'm way busy right now, but I do want to incorporate their changes. It's going to be a little bit of a trick, because their changes were made to the older version of the code. Still, it ought to be possible, and it is my intention to work with them to incorporate their changes as soon as possible. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] 3D Cockpit view, L410 Turbolet
I had a look with a red / green pair and it's quite an impressive effect. I'd love to have a go at making a true stereo HMD (dual display) because the immersion effect 'feels' great. The cockpit itself is stunning; top marks to its creators. Just one point on the anaglyph; the difference in the seats is too great (doesn't work visually) - I think this is probably down to the selected FOV and proximity of the viewpoint to the seats. Dave Martin. The red and green/blue images could be registered better in the post-processing phase. However, had I done that, I would have had to crop the images more horizontally. I didn't feel like doing that at the time. It was sort of a quick-and-dirty post-processing effort. I agree, though, that it would be cool to have a stereo flight simulator. I've got no idea on the mechanics of the visuals though - how that could be implemented. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] New JSBSim release; New JSBSim Newsletter
JSBSim v0.9.9 has been released and is available at www.jsbsim.org. JSBSim is an open source flight dynamics model written in C++. JSBSim is one of the flight models used in the open source flight simulator, FlightGear, but JSBSim is also used in other flight simulator projects around the world. JSBSim can also be run by itself in a standalone mode. The major new features in v0.9.9 can be seen in the latest issue of the JSBSim newsletter, Back of the Envelope (also just released). The newsletter can be viewed at the project web site at www.jsbsim.org. Jon Berndt ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New JSBSim release; New JSBSim Newsletter
JSBSim v0.9.9 has been released and is available at www.jsbsim.org. JSBSim is an open source flight dynamics model written in C++. JSBSim is one of the flight models used in the open source flight simulator, FlightGear, but JSBSim is also used in other flight simulator projects around the world. JSBSim can also be run by itself in a standalone mode. Note: This new version has been tested successfully with the latest version of FlightGear, but has not yet been officially integrated with it. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 3D Cockpit view, L410 Turbolet
Those of you who have read the newsletter have probably seen (and drooled over) the wonderful 3D model of the L410 Turbolet created by Jiri and Jiri Javurek. Jiri created a left and right view of the cockpit, and I created a stereo anaglyph using the images. If you have red/blue glasses, you might have a look at the two images (one is color, one is black and white): http://www.jsbsim.org/L410Cockpit3DBW.png http://www.jsbsim.org/L410Cockpit3DColor.png Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] OT: Mojave, CA
But, an FDM interface needs to do more than shove a datastructure back and forth. There needs to be some higher level communication to tell the remote FDM when it should reset it self or when it should trim for in air or on the ground, and what trim conditions are requested (i.e. start in air at 4500' MSL, 98 kts, 10 degree flaps, gear up, in a 20 degree right banking turn.) Also, it should be able to handle any number of engines (0 ... n), various arbitrary control surface arrangements, any number of landing gear or ground contacts, arbitrary flight control system, etc. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] config.sub ?
Jon Berndt wrote: I've tried these both. This seems to be fatal no matter what I do: [EMAIL PROTECTED]:~/JSBSim$ ./configure configure: error: cannot run /bin/sh ./config.sub There are two things: Is is a symbolic link (and does the target exist) and is it marked executable? Erik I finally got it working. I just copied config.guess and config.sub from the autotools location where they were to the build directory I was running from (JSBSim/). I was doing this on Sourceforge's compile farm server for Mac OSX-2. The make process went very well, the executable built, and the test run went OK. This is in preparation for announcement of v0.9.9, the release of the newsletter, and executables for several platforms. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] JSBSim: Failed to tie propertypropulsion/c-thrust[0] to a pointer
When the JSB a/c model has several engine+propeller we get that JSB message error: Failed to tie property propulsion/c-thrust[0] to a pointer What must be defined in Aircraft.xml to solve it. -- Gerard Which version of JSBSim are you using? Is it the one currently in FlightGear CVS? You'll need to tell me more about your aircraft/propeller config files (or email them to me). Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] config.sub ?
I'm trying to build JSBSim on one of Sourceforge's compile farm boxes, this one running Linux. After running aclocal;automake;autoconf I try to run configure and get this: configure: error: cannot run /bin/sh ./config.sub I don't see a config.sub. Where does that come from? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Free simulator of the Frecce Tricolori aerobaticjet
Since the MB-339 PAN is an on-going project, we plan to release an improved version of the aircraft (with smokes?). If anyone at flightgear.org would like to link our MB-339 PAN project in the Related Projects section, we would be very happy. Bye, Augusto. I will mention it in the upcoming JSBSim newsletter, too. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports
FGLGear.cpp line 507
Here's the code:
// Crash detection logic (really out-of-bounds detection)
if (compressLength 500.0 ||
vForce.Magnitude() 1.0 ||
vMoment.Magnitude() 50.0 ||
SinkRate 1.4666*30)
{
PutMessage(Crash Detected: Simulation FREEZE.);
Exec-Freeze();
}
The undercarriage definition is very flexible. It gives the facilities
to manage an aircraft customised crash animation with the help of a
nasal script.
If an improvement must be done it could be done on the old existing code
with specifics properties like that one which is coming from a Dave
mail.
crash-detection
altitude-agl0/altitude-agl
g-z-max11.0/g-z-max
g-z-min5.0/g-z-min
g-x-max20/g-x-max
g-x-min20/g-x-min
qbar1089.0/qbar
pitch-rate3.7/pitch-rate
yaw-rate3.5/yaw-rate
mach0.99/mach
/crash-detection
The out-of-bounds detection logic was a development piece of code, really. That
can be removed if it is causing a problem.
Jon
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Property Tree Catalog
Well, without the benefit of SimGear as a whole, I've crafted a [probably
non-optimal]
property tree cataloging function for use in JSBSim. Thought you might like to
see it:
//%%
struct PropertyCatalogStructure {
string base_string;
FGPropertyManager *node;
};
void FGFDMExec::BuildPropertyCatalog(struct PropertyCatalogStructure* pcs)
{
struct PropertyCatalogStructure* pcsNew = new struct PropertyCatalogStructure;
int node_idx = 0;
char int_buf[10];
for (int i=0; ipcs-node-nChildren(); i++) {
pcsNew-base_string = pcs-base_string + / +
pcs-node-getChild(i)-getName();
node_idx = pcs-node-getChild(i)-getIndex();
sprintf(int_buf, [%d], node_idx);
if (node_idx != 0) pcsNew-base_string += string(int_buf);
if (pcs-node-getChild(i)-nChildren() == 0) {
PropertyCatalog.push_back(pcsNew-base_string +
pcs-node-getChild(i)-getName());
} else {
pcsNew-node = (FGPropertyManager*)pcs-node-getChild(i);
BuildPropertyCatalog(pcsNew);
}
}
delete pcsNew;
}
//%%
It's called like this:
//%%
struct PropertyCatalogStructure masterPCS;
masterPCS.base_string = ;
masterPCS.node = (FGPropertyManager*)master;
BuildPropertyCatalog(masterPCS);
cout endl Registered properties: endl;
for (int i=0; iPropertyCatalog.size(); i++) cout PropertyCatalog[i]
endl;
//%%
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] sprintf
No, you can't format (the f in printf) the string using the default C++ string class). You have to use the I/O manipulators (Stroustrup: 21.4.6.2, page 633ff.) like std::setprecision(). The string class cannot create a string representation of a floating point number as far as I can tell. The next best thing (IMHO) is sprintf(). I wish we could do this: string myString= double myValue=3.1415; myString = The value of pi is: + string(myValue) + \n; I've had enough trouble with stringstreams that I don't want to go that path. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Properties, by position
In props.cxx I find this code: /** * Get a child node by position (*NOT* index). */ SGPropertyNode * getChild (int position); Can anyone differentiate for me the concept of position as contrasted to index in this situation? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports
I don't know if there are others that use fgfs from front range locations in Colorado, but I use it to practice instrument approaches in this my home area and my two favorite aircraft for this are the c172p and c310, both jsbsim models. _The yasim aircraft still work fine with this scenery._ By the way, I downloaded both w110n30.tgz and w110n40.tgz and reinstalled both with no change to this bug. I have not seen this issue with airports not from these scenery files. This bug showed up about 10 days ago with an update from cvs. Any ideas what is broken? Regards, Dave Perry I've got a hunch. Dave Culp may have an idea. I'll take a look, too. Thanks, Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] sprintf
IIRC, sprintf was a problem for some. Is that still the case? I've compiled under Cygwin, Borland C++, and I think I've also compiled code that uses sprintf under IRIX. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New super/turbo MP code is in
All the 3350s had this turbo/super setup. You can see it in some of these images: http://www.enginehistory.org/GjJBrossett/RAFCosford/Wright%20Cyclone%20R-3350%20cutaway.J PG http://www.enginehistory.org/GjJBrossett/RAFCosford/Wright%20Cyclone%20R-3350%20cutaway%2 0view.JPG http://www.saunalahti.fi/sariri/Img/UKRAFC05/Eng/slides/P2060078.html http://www.midwaysailor.com/eddiemiller/eddiemiller-761b.jpg ** Please ** trim your quotes. Also, for sending emails in text mode that include long links, you might try going to www.tinyurl.com and making shorter links to include in emails. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New super/turbo MP code is in
But that's not the only way to do it. I've been preparing a series of articles on supercharging reciprocating engines. Is there any interest for me to pull some of it out and present it here? -- Pete Stickney Hmm. This might be interesting for the next issue of the JSBSim newsletter, Back of the Envelope - even if it is not strictly JSBSim-related. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Diamond Katana model
Hi, folks, I'm trying to build a Katana model (the flight model, at least) so I don't have to perpetually terrorize the airfield's neighbors and my CFI while I practice touch go's. I went through the Aero-Matic and came out with a starting set of files, which I've been combing through and changing where appropriate. I can't find a reference for the properties in the 'metrics' element, however. Can anyone tell me what they are? I also see a lot of 'coefficient' elements in there, a number of which look important to someone landing a plane (dCLflap - Delta_Lift_due_to_flaps, for instance, looks rather important). Anyone know where these might be published, if at all? Thanks! -joe I'm going to forward this one to the JSBSim list and answer it there sometime today. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] how do I access GetCoefficientValuesfromFGAerodynamics?
With the potential of exposing my C++ knowledge deficiency, I'll explain how far I got ;-) As mentioned in the last post, I have two variables I can access through the existing code I have. One variable is cur_fdm_state which is of type FGInterface. FGInterface is a parent class of JSBSim so accessing accessing the said 'get_fdmex()' method isn't easily done. I tried declaring a virtual method in FGInterface and defining it in JSBSim, but this only got ugly. The other variable is 'globals', but I haven't had much luck here either. With your knowledge of flightgear, do you know if it is possible to access methods from the JSBSim object via either of these variables? If so, could you provide suggestions? In FGJSBSim (the JSBSim object derived from FGInterface) there is a private member called Aerodynamics that points to the FGAerodynamics object of JSBSim. If you have your own cur_fdm_state object, however, the Aerodynamics object won't be accessible unless you change the Aerodynamics object to be protected instead of private, or unless you provide a getter such as GetAerodynamics() that returns the pointer to the Aerodynamics object. Then, you could simply do: my_string = cur_fdm_object-Aerodynamics-GetCoefficientStrings(delimiter); -or- my_string = cur_fdm_object-GetAerodynamics()-GetCoefficientStrings(delimiter); With the other option of using the XML file, could you give me an example of how the values would be retrieved? output name=localhost type=SOCKET port=1139 rate=10 coefficients ON /coefficients /output If you were to do the above (i.e. place it in your aircraft config file) you would have to have a listening socket somewhere ready to receive the data. In another shell window you could type: nc -l -p 1139 to listen to the data output by the sim. I've only done this with JSBSim standalone - not with FlightGear. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] how do I access GetCoefficientValues fromFGAerodynamics?
Can anyone suggest a way of accessing the methods: GetCoefficientValues(...) and GetCoefficientStrings(...) from a --native socket? I have a piece of code within flightgear which uses 'globals' and 'cur_fdm_state' via a socket similar to the --native socket provided with flightgear. I'd need to access internal JSBSim data but am at a loss how to do it from that socket. any suggestions? You can access JSBSim aero data via properties if you know the property names. Problem is, the aero properties are sort of internal, and there's not a simple way (that I know of) to get all aero properties. So, I see you want to try (from FlightGear) to get the strings via the FGAerodynamics calls. To do that, you'd need to know the FGFDMExec pointer in the interface (FGJSBSim). The value you need is a private attribute, fdmex. You could add a getter for that, GetExec(), perhaps. Then you could use that: my_string = GetExec()-GetAerodynamics()-GetCoefficientStrings(delimeter); I haven't tried this, but I think this should work. Is this what you are looking for? On the other hand, JSBSim does have a socket output capability, too. Using the new code (almost ready for commit to FlightGear CVS) you could do the following and get all aero properties: output name=localhost type=SOCKET port=1139 rate=10 coefficients ON /coefficients /output The above would go in your aircraft config file at the bottom. I'll be glad to clarify this if you need more info. Jon -- Project Coordinator JSBSim Flight Dynamics Model http://www.jsbsim.org ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Strange goings-on: Simgear, ReadXML
I've noticed two things about easyXML.cxx. 1) There is a function or macro called sg_io_exception(). This exception gets thrown in my development version due to an as-yet unidentified problem with readXML(). However, the message that emanates from FlightGear is simply: FlightGear aborting That doesn't seem right, given the arguments passed into sg_io_exception. Is there a compile setting, runtime option, or environment variable that needs to be set in order to get useful error messages out of simgear-thrown exceptions? 2) ReadXML() (easyxml.cxx) contains code that is exhibiting apparently wierd behavior. readXML() takes an input stream reference as an argument (among other things), and from within a while loop, reads from the input stream. However, prior to reading from the input stream, a check for the state of the input stream is made: if (!input.good()) // print message and throw For some reason when the engine files is read for a JSBSim aircraft (and using the new XML code) this check returns false and funnels execution through the thrown exception code. I have checked, and the path name is valid, the XML engine spec is valid, the file permissions are OK, the file is not corrupt, etc. In addition, this failed check for input.good() occurs before any IO occurs. input.good() should return true if the FAIL bit is not set, the EOF flag is not set, and the BAD bit is not set (as I recall). I have not yet found why the state of the input stream is bad, but this is very strange and frustrating. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Strange goings-on: Simgear and easyXML
I've noticed two things about easyXML.cxx. 1) There is a function or macro called sg_io_exception(). This exception gets thrown in my development version due to an as-yet unidentified problem with readXML(). However, the message that emanates from FlightGear is simply: FlightGear aborting That doesn't seem right, given the arguments passed into sg_io_exception. Is there a compile setting, runtime option, or environment variable that needs to be set in order to get useful error messages out of simgear-thrown exceptions? 2) ReadXML() (easyxml.cxx) contains code that is exhibiting apparently weird behavior. readXML() takes an input stream reference as an argument (among other things), and from within a while loop, reads from the input stream. However, prior to reading from the input stream, a check for the state of the input stream is made: if (!input.good()) // print message and throw For some reason when the engine files is read for a JSBSim aircraft (and using the new XML code) this check returns false and funnels execution through the thrown exception code. I have checked, and the path name is valid, the XML engine spec is valid, the file permissions are OK, the file is not corrupt, etc. In addition, this failed check for input.good() occurs before any IO occurs. input.good() should return true if the FAIL bit is not set, the EOF flag is not set, and the BAD bit is not set (as I recall). I have not yet found why the state of the input stream is bad, but this is very strange and frustrating. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Strange goings-on: Simgear and easyXML
I've noticed two things about easyXML.cxx. 1) There is a function or macro called sg_io_exception(). This exception gets thrown in my development version due to an as-yet unidentified problem with readXML(). However, the message that emanates from FlightGear is simply: FlightGear aborting That doesn't seem right, given the arguments passed into sg_io_exception. Is there a compile setting, runtime option, or environment variable that needs to be set in order to get useful error messages out of simgear-thrown exceptions? 2) ReadXML() (easyxml.cxx) contains code that is exhibiting apparently weird behavior. readXML() takes an input stream reference as an argument (among other things), and from within a while loop, reads from the input stream. However, prior to reading from the input stream, a check for the state of the input stream is made: if (!input.good()) // print message and throw For some reason when the engine files is read for a JSBSim aircraft (and using the new XML code) this check returns false and funnels execution through the thrown exception code. I have checked, and the path name is valid, the XML engine spec is valid, the file permissions are OK, the file is not corrupt, etc. In addition, this failed check for input.good() occurs before any IO occurs. input.good() should return true if the FAIL bit is not set, the EOF flag is not set, and the BAD bit is not set (as I recall). I have not yet found why the state of the input stream is bad, but this is very strange and frustrating. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] test
test ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] readXML problems
Here's an update to what I've discovered - hopefully someone can give me a hint
on some
questions I have.
First, I've added some output statements in easyxml.cxx, in this version of the
readXML()
function:
---
-- start --
---
void
readXML (istream input, XMLVisitor visitor, const string path)
{
XML_Parser parser = XML_ParserCreate(0);
XML_SetUserData(parser, visitor);
XML_SetElementHandler(parser, start_element, end_element);
XML_SetCharacterDataHandler(parser, character_data);
XML_SetProcessingInstructionHandler(parser, processing_instruction);
visitor.startXML();
char buf[16384];
while (!input.eof()) {
cout A-1 endl;
if (!input.good()) {
cout A-2 endl;
XML_ParserFree(parser);
cout A-3 endl;
throw sg_io_exception(Problem reading file,
sg_location(path,
XML_GetCurrentLineNumber(parser),
XML_GetCurrentColumnNumber(parser)),
SimGear XML Parser);
cout A-4 endl;
}
---
-- end --
---
The above code fails when called from the JSBSim Load() function on FGPropulsion
(simplified):
---
-- start --
---
Element* engine_element = el-FindElement(engine);
while (engine_element) {
engine_filename = engine_element-GetAttributeValue(file);
...
engine_file_parser = new FGXMLParse();
engine_filename = FindEngineFullPathname(engine_filename);
readXML(engine_filename, *engine_file_parser);
...
Element* engine_element = el-FindNextElement(engine);
}
---
-- end --
---
When I run FlightGear I get this:
A-1
A-2
A-3
FlightGear aborting
And that's all I get. I'm wondering why I don't get a message from the thrown
simgear
exception? Why would input.good() return false?
Let me restate that this all works fine in JSBSim standalone.
Jon
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] readXML problems
void
readXML (istream input, XMLVisitor visitor, const string path)
{
XML_Parser parser = XML_ParserCreate(0);
...
XML_ParserFree(parser);
cout A-3 endl;
throw sg_io_exception(Problem reading file,
sg_location(path,
XML_GetCurrentLineNumber(parser),
What happens to parser after the call to XML_ParserFree(parser)? Can it still
be referenced after that?
Dave
That's interesting. I wonder. Still, I think the problem is occurring earlier,
because for
some reason the check for input.good() is returning bad. I have no idea why.
Jon
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] readXML problems
void
readXML (istream input, XMLVisitor visitor, const string path)
{
engine_filename = FindEngineFullPathname(engine_filename);
readXML(engine_filename, *engine_file_parser);
The parameters don't match up for one thing. engine_filename is a string?
Dave
Sorry - there's an intermediate step. Propulsion calls readXML with a string
filename,
then another variation of readXML() is called with the input stream. Everything
executes
fine up until call to readXML(istream ...
The item I see as most suspect now is the false result from the call to
input.good().
Jon
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] readXML problems
I'm continuing to install the new JSBSim code. I've run into a strange problem. After I start up FlightGear and begin to parse an aircraft, I'll be humming along just fine until I get to the point where the engine file is specified. When the engine file is specified, it causes the file to be opened and read using a call to the easyXML routine, readXML(). It's the same routine, of course, that is being used to successfully parse the main aircraft config file. This works fine in JSBSim standalone, but in FlightGear, when this second call to readXML() is made, the program dies: FlightGear aborting I'm wondering if I missed something in the build process? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] help: .cxx extension not processed inMakefile.am
As far as I know, none. This is the first time I heard of this behavior ?!?? Erik It's frustrating as hell. I don't see that I am doing much different from the Makefile.am from the previous build. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] readXML problems
I'm continuing to install the new JSBSim code. I've run into a strange
problem. After I
start up FlightGear and begin to parse an aircraft, I'll be humming along
just fine
until
I get to the point where the engine file is specified. When the engine file is
specified,
it causes the file to be opened and read using a call to the easyXML routine,
readXML().
It's the same routine, of course, that is being used to successfully parse
the main
aircraft config file. This works fine in JSBSim standalone, but in
FlightGear, when this
second call to readXML() is made, the program dies:
FlightGear aborting
I'm wondering if I missed something in the build process?
Jon
Here's my call to readXML:
--- start ---
bool FGPropulsion::Load(Element* el)
{
string type, engine_filename;
Element* document;
FGXMLParse *engine_file_parser;
ifstream* engine_file;
Element* engine_element = el-FindElement(engine);
while (engine_element) {
engine_filename = engine_element-GetAttributeValue(file);
if (!engine_filename.empty()) {
engine_file = FindEngineFile(engine_filename);
if (!engine_file-is_open()) {
return false;
}
} else {
cerr Engine definition did not supply an engine file. endl;
return false;
}
engine_file_parser = new FGXMLParse();
readXML(*engine_file, *engine_file_parser); // -- dies here
--- end ---
Anyone else out there use readXML()?
Jon
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] readXML problems
Erik: Are you calling readXML while another call to readXML is in progress? Norman: Can't be done unless this other call is in a different thread :-) Jon: I'm doing it in standalone JSBSim (calling readXML from within another readXML()). I thought you simply had to provide new arguments. Why would it work perfectly in standalone JSBSim, but not within FlightGear? Doh!!! Of course Norman is right - and JSBSim is not calling ReadXML() while another call to readXML() is in progress. I still don't know what could be causing our abort, though. In standalone JSBSim we use our own compiled easyXML and eXpat code - though I would assume it's the same code SimGear uses. When building with FlightGear we resolve the references at link time with the simgear libs like everyone else. Seemed to work fine. Until it died when called from the propulsion loading code. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Linking order problems?
Obviously, this doesn't seem optimal. I'm not sure how I could possibly arrange the files so there is only a single link reference to each library. Yet, I don't know how I should modify the Makefile.am to produce a multiplely- referenced library - or even if that is possible. Jon I wonder if I ought to try the same order that is used (successfully) in the JSBSim standalone build process? That's as follows: --- start --- JSBSim_DEPENDENCIES = \ $(top_builddir)/src/libJSBSim.a \ $(top_builddir)/src/initialization/libInit.a \ $(top_builddir)/src/models/libModels.a \ $(top_builddir)/src/models/flight_control/libFlightControl.a \ $(top_builddir)/src/models/atmosphere/libAtmosphere.a \ $(top_builddir)/src/models/propulsion/libPropulsion.a \ $(top_builddir)/src/input_output/libInputOutput.a \ $(top_builddir)/src/math/libMath.a \ --- end --- As I recall, though, link order has not been terribly important in JSBSim standalone. Why should it be different in FlightGear? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] New JSBSim Config File Format Partial Documentation Online
I've placed an early copy of the new JSBSim config file format documentation online. It's incomplete, but I thought it was better to get something out there than wait until it's all done. You can find it here: http://www.jsbsim.org/Overview.pdf Comments welcome. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RE: New JSBSim Config File Format Partial Documentation Online
You can find it here: http://www.jsbsim.org/Overview.pdf Comments welcome. Note, however, that rate_groups are not yet implemented for the flight control system. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Makefile.am and new JSBSim files
I'm working on getting the new JSBSim code into FlightGear. It's going pretty well, actually, but I still have one problem. I can't seem to get JSBSim.cxx to compile in the JSBSim directory. It wants to use JSBSim.cpp - which isn't there. My new Makefile.am looks like this: --- start --- SUBDIRS = initialization models input_output math noinst_LIBRARIES = libJSBSim.a libJSBSim_a_SOURCES = JSBSim.cxx FGFDMExec.cpp FGJSBBase.cpp FGState.cpp INCLUDES = -I$(top_srcdir)/src/FDM/JSBSim AM_CXXFLAGS = -DFGFS --- end --- Am I leaving something out? The problem seems to be somehow with the .cxx extension. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Linking order problems?
I've got the basic build procedure figured out (I think) with the new JSBSim code in FlightGear. However, once it gets to the Big Link, it ultimately fails. Here's the link line: --- start --- g++ -DPKGLIBDIR=\/usr/local/share/FlightGear\ -g -O2 -D_REENTRANT -L/usr/local/lib -o fgfs.exe bootstrap.o ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/ExternalPipe/libExternalPipe.a ../../src/fdm/jsbsim/libJSBSim.a ../../src/fdm/jsbsim/initialization/libInit.a ../../src/fdm/jsbsim/input_output/libInputOutput.a ../../src/fdm/jsbsim/math/libMath.a ../../src/fdm/jsbsim/models/atmosphere/libAtmosphere.a ../../src/fdm/jsbsim/models/flight_control/libFlightControl.a ../../src/fdm/jsbsim/models/libModels.a ../../src/fdm/jsbsim/models/propulsion/libPropulsion.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/FDM/SP/libSPFDM.a ../../src/GUI/libGUI.a ../../src/Autopilot/libAutopilot.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/AIModel/libAIModel.a ../../src/Network/libNetwork.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Scripting/libScripting.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/MultiPlayer/libMultiPlayer.a ../../src/Replay/libReplay.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Traffic/libTraffic.a ../../src/Environment/libEnvironment.a - lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel - lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial -lsgstructure -lsgenvironment -lsgthreads -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lz -lglut32 -lglu32 -lopengl32 -luser32 -lgdi32 -lALut -lopenal32 -lwinmm - ldsound -ldxguid -lole32 --- end --- I don't think I see a problem with this line, but, immediately after this line I start getting pages of errors. --- start --- ../../src/fdm/jsbsim/models/libModels.a(FGFCS.o): In function `_ZN6JSBSim5FGFCS4LoadEPNS_7ElementE': /usr/include/c++/3.3.3/bits/stl_vector.h:596: undefined reference to `JSBSim::FGFilter::FGFilter[in-charge](JSBSim::FGFCS*, JSBSim::Element*)' /usr/include/c++/3.3.3/bits/stl_vector.h:596: undefined reference to `JSBSim::FGGain::FGGain[in-charge](JSBSim::FGFCS*, JSBSim::Element*)' /usr/include/c++/3.3.3/bits/stl_vector.h:596: undefined reference to `JSBSim::FGSummer::FGSummer[in-charge](JSBSim::FGFCS*, JSBSim::Element*)' /usr/include/c++/3.3.3/bits/stl_vector.h:596: undefined reference to `JSBSim::FGDeadBand::FGDeadBand[in-charge](JSBSim::FGFCS*, JSBSim::Element*)' /usr/include/c++/3.3.3/bits/stl_vector.h:596: undefined reference to `JSBSim::FGGradient::FGGradient[in-charge](JSBSim::FGFCS*, JSBSim::Element*)' /usr/include/c++/3.3.3/bits/stl_vector.h:596: undefined reference to `JSBSim::FGSwitch::FGSwitch[in-charge](JSBSim::FGFCS*, JSBSim::Element*)' /usr/include/c++/3.3.3/bits/stl_vector.h:596: undefined reference to `JSBSim::FGKinemat::FGKinemat[in-charge](JSBSim::FGFCS*, JSBSim::Element*)' /usr/include/c++/3.3.3/bits/stl_vector.h:596: undefined reference to `JSBSim::FGFCSFunction::FGFCSFunction[in-charge](JSBSim::FGFCS*, JSBSim::Element*)' ../../src/fdm/jsbsim/models/libModels.a(FGOutput.o): In function `_ZN6JSBSim8FGOutputD2Ev': /usr/include/c++/3.3.3/bits/stl_alloc.h:656: undefined reference to `JSBSim::FGfdmSocket::~FGfdmSocket [in-charge]()' ../../src/fdm/jsbsim/models/libModels.a(FGOutput.o): In function `_ZN6JSBSim8FGOutputD1Ev': /usr/include/c++/3.3.3/bits/stl_alloc.h:656: undefined reference to `JSBSim::FGfdmSocket::~FGfdmSocket [in-charge]()' ../../src/fdm/jsbsim/models/libModels.a(FGOutput.o): In function `_ZN6JSBSim8FGOutputD0Ev': /usr/include/c++/3.3.3/bits/stl_alloc.h:656: undefined reference to `JSBSim::FGfdmSocket::~FGfdmSocket [in-charge]()' ../../src/fdm/jsbsim/models/libModels.a(FGOutput.o): In function `_ZN6JSBSim8FGOutput12SocketOutputEv': /home/jon/src/FlightGear/src/FDM/JSBSim/models/FGOutput.cpp:341: undefined reference to `JSBSim::FGfdmSocket::Clear()' ../../src/fdm/jsbsim/models/libModels.a(FGOutput.o): In function `_ZN6JSBSim8FGOutput12SocketOutputEv': /usr/include/c++/3.3.3/bits/stl_alloc.h:652: undefined reference to `JSBSim::FGfdmSocket::Clear(std::basic_stringchar, std::char_traitschar, std::allocatorchar )' ../../src/fdm/jsbsim/models/libModels.a(FGOutput.o): In function `_ZN6JSBSim8FGOutput12SocketOutputEv': /home/jon/src/FlightGear/src/FDM/JSBSim/models/FGOutput.cpp:344: undefined reference to `JSBSim::FGfdmSocket::Append(char const*)' ... ... ... etc. --- end --- Any suggestions on what might be wrong and/or how to fix this would
RE: [Flightgear-devel] Re: New turbo/supercharger code
That all looks very good. Does your implementation of the Boost Control just control the pressure, or does it act on the throttle as I understand was the way it worked in the Merlin? In simulation terms the outcome is probably the same. V. Hi, Vivian: That would be a question for Dave Luff, who wrote that engine model for JSBSim. If I had time I'd look at the FGPiston.cpp code, but I've got really limited time today and tomorrow; I'm getting the new JSBSim code integrated with FlightGear, among other things I've got to do. The last post I see from Dave was about 6 months ago on the JSBSim list. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Turn Coordinator is out == c172r and others
Beware instrument failure ! C172r and others aircraft have a turn coordinator out of order :=( seems to be property: /instrumentation/turn-indicator/indicated-turn-rate I noticed that. I wonder when that happened? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: New turbo/supercharger code
Thanks, My question could be a question to Jon, Dave, and any JSB specialist. I just wonder, about, the opportunity to get profit of your work for developments on the JSB branch. The properties should be the same on the global FG level. Both FDM -YASim -JSBSim with a different philosophic approach should give the same end results. -- Gerard See the FGPiston.h file in JSBSim. See the constructor in FGPiston.cpp for exact specification in the new XML format (documentation pending). Here is some data on what can be specified: Models Dave Luff's Turbo/Supercharged Piston engine model. Additional elements are required for a supercharged engine. These can be left off a non-supercharged engine, ie. the changes are all backward compatible at present. - NUMBOOSTSPEEDS - zero (or not present) for a naturally-aspirated engine, either 1, 2 or 3 for a boosted engine. This corresponds to the number of supercharger speeds. Merlin XII had 1 speed, Merlin 61 had 2, a late Griffon engine apparently had 3. No known engine more than 3, although some German engines apparently had a continuously variable-speed supercharger. - BOOSTOVERRIDE - whether the boost pressure control system (either a boost control valve for superchargers or wastegate for turbochargers) can be overriden by the pilot. During wartime this was commonly possible, and known as War Emergency Power by the Brits. 1 or 0 in the config file. This isn't implemented in the model yet though, there would need to be some way of getting the boost control cutout lever position (on or off) from FlightGear first. - The next items are all appended with either 1, 2 or 3 depending on which boost speed they refer to, eg RATEDBOOST1. The rated values seems to have been a common convention at the time to express the maximum continuously available power, and the conditions to attain that power. - RATEDBOOST[123] - the absolute rated boost above sea level ambient for a given boost speed, in psi. Eg the Merlin XII had a rated boost of 9psi, giving approximately 42inHg manifold pressure up to the rated altitude. - RATEDALTITUDE[123] - The altitude up to which rated boost can be maintained. Up to this altitude the boost is maintained constant for a given throttle position by the BCV or wastegate. Beyond this altitude the manifold pressure must drop, since the supercharger is now at maximum unregulated output. The actual pressure multiplier of the supercharger system is calculated at initialisation from this value. - RATEDPOWER[123] - The power developed at rated boost at rated altitude at rated rpm. - RATEDRPM[123] - The rpm at which rated power is developed. - TAKEOFFBOOST - Takeoff boost in psi above ambient. Many aircraft had an extra boost setting beyond rated boost, but not totally uncontrolled as in the already mentioned boost-control-cutout, typically attained by pushing the throttle past a mechanical 'gate' preventing its inadvertant use. This was typically used for takeoff, and emergency situations, generally for not more than five minutes. This is a change in the boost control setting, not the actual supercharger speed, and so would only give extra power below the rated altitude. When TAKEOFFBOOST is specified in the config file (and is above RATEDBOOST1), then the throttle position is interpreted as: - 0 to 0.95 : idle manifold pressure to rated boost (where attainable) - 0.96, 0.97, 0.98 : rated boost (where attainable). - 0.99, 1.0 : takeoff boost (where attainable). A typical takeoff boost for an earlyish Merlin was about 12psi, compared with a rated boost of 9psi. It is quite possible that other boost control settings could have been used on some aircraft, or that takeoff/extra boost could have activated by other means than pushing the throttle full forward through a gate, but this will suffice for now. Note that MAXMP is still the non-boosted max manifold pressure even for boosted engines - effectively this is simply a measure of the pressure drop through the fully open throttle. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] FGFS 0.9.8 Compilation Error #2
[EMAIL PROTECTED] wrote: I typed make and I got the following error: FGNozzle.cpp: In method 'JSBSim::FGNozzle(JSBSim::FGFDMExec *, JSBSim::FGConfigFile *, int =0)': FGNozzle.cpp:74: implicit declaration of function 'int JSBSim::snprintf(..)' Does someone knows what is wrong? Platform? Compiler? As always, more information is better than less. Surely you did more than just type make to get this far. :) Yes, this is important. If you grep our source code (JSBSim) you'll see this in some places (notably FGFCS.cpp): #if defined(WIN32) !defined(__CYGWIN__) # define snprintf _snprintf #endif I remember there is an issue with snprintf(), I just can't remember the details offhand, nor why the above fix seems to work. As a WAG, you might try adding the above three lines to the top of FGNozzle.cpp. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] FlightGear Wind and Turbulence
I used this command line: fgfs [EMAIL PROTECTED] --aircraft=c172r --turbulence=0.0 This set up the winds as I wanted. However, even though turbulence was set to zero, there was still lots of noise present in the wind velocity coming from FlightGear. The wind seemed to vary +/- 5 to 10 ft/sec. Also, the variance rate of chance was on the order of tens of milliseconds. I was logging data at 20Hz, and at one time step the wind velocity would be at 10 ft/sec, the next it would be at 20, and the next it would be back at 10. Obviously, that's physically impossible. Jon Never mind :-/ The spikes I was seeing were artificial, and due to the test setup I was using. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Property Manager enumeration of properties
Is anyone aware of a [simple?] way to print out the property tree once it has been populated? It seems to me that there ought to be a class attribute in the property manager somewhere that is a pointer to a linked list, or a vector, or whatever, that contains the properties, each of which may contain it's own child properties. No? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Short Reference Document error?
This short reference: http://www.flightgear.org/Docs/FGShortRef.pdf shows the rudder control on the numeric keypad as being the 0 and , (comma) keys. There is no comma on the numeric keypad. This is confusing. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Landing Gear Jitters: Resolved?
I am testing out a small preliminary fix for the landing gear jitter seen in various JSBSim aircraft. Curt has relayed that the default C-172 does have this problem - and I have now seen that. The preliminary fix does seem to have fixed that, although when brakes are applied while at rest there is some weird dynamics going on. I think I can fix that, too. So, I believe we are well on our way to having the appearance of a much better gear action. I hope I can get this resolved in the next day or two. Which of the JSBSim models show this problem most noticeably, besides the default C-172? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] FlightGear Wind and Turbulence
What does FlightGear do in the way of wind and turbulence? I assume that winds are set in FlightGear in NED coordinates and that those change slowly? Turbulence is modeled in the FDMs, but parameters are passed in? FlightGear does not model turbulence itself, does it? What is WEATHER_CM? I am looking in JSBSim.cxx and wonder what the defined WEATHER_CM is set to by default. I'm determining which code is compiled in in the atmosphere code. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] FlightGear Wind and Turbulence
I am debugging the gear jittering in JSBSim and I am seeing windNED spike every so often and I have commented out turbulence code in JSBSim, so I am wondering if these wind spikes are coming from FlightGear. OK, in working to fix the gear jitter I've discovered some things about the winds modeled in FlightGear. I used this command line: fgfs [EMAIL PROTECTED] --aircraft=c172r --turbulence=0.0 This set up the winds as I wanted. However, even though turbulence was set to zero, there was still lots of noise present in the wind velocity coming from FlightGear. The wind seemed to vary +/- 5 to 10 ft/sec. Also, the variance rate of chance was on the order of tens of milliseconds. I was logging data at 20Hz, and at one time step the wind velocity would be at 10 ft/sec, the next it would be at 20, and the next it would be back at 10. Obviously, that's physically impossible. Can someone shed some light on FlightGear's modeling of winds and turbulence? BTW, I'm using current code out of FlightGear CVS. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: FlightGear Wind and Turbulence
WeatherCM is the old weather system that has been removed from cvs for fgfs 0.9.4. It's in the old repository's hidden Attic/. I think it's safe to remove all traces to it. m. Thanks. Will do. That simplifies looking at the code. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Short Reference Document error?
So there's nothing wrong with it, it's just that every user has another kind of keyboard layout. ;) Best Regards, Oliver C. Aha! Well, yes, I understand, now, but for newbies from the U.S. it will be wrong. I'll modify the PDF and send it to Curt (or whoever maintains that doc). It needs to be clear. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Short Reference Document error?
Modify the PDF? Of course, you mean the TeX source file from which it was generated, not the PDF itself, right? It's in the docs module. m. I already modified the PDF (I have Acrobat). I didn't know where the doc came from originally, and I don't know TeX. If I have time later I'll take a look at the TeX file, too, though. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Short Reference Document error?
Aha ? In fact the notation in the cheat sheet _is_ correct and clear, why the hell do you want to break it ? It's just a matter of point of view an I assume there are _many_ FlightGear users out there that have a comma as a decimal separator - it's just that they probably don't live in the US. I think you are making a disingenuous assumption, here, on what I am saying. It IS correct and clear for*European*users, yes. All that I did to the PDF document was to add a _note_ in the appropriate section in brackets that says: [U.S. keyboards use . instead of ,] Are you opposed, in principle, to providing U.S. users with accurate information? I don't understand what's got you so hot about this. It's an international project. Let's be clear for everyone. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Tail dragger trouble.
I have been trying to make the JSB flight model for my PA-25 pawnee for over a week now, however, I can not get it to steer on the ground. Every time I start my take off roll the plane goes in circles. Has anybody encountered any similar problems? I am working on trying to resolve the landing gear issues now. There are a couple of aspects to this. I'll try and describe those later, as well as to provide some fixes. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Short Reference Document error?
So, you think the UK is part of Europe, eh? We use the same convention as the US for ./, Vivian. Heh. :-) What's above the number 4 (not on the numeric keypad)? Is it a $ or a ? (not sure that will print correctly)? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Short Reference Document error?
This complies entirely with my intention. Please excuse me for missing the point - from reading your comment I had the impression you simply changed the comma to a dot in the PDF. Please send me a copy of your PDF and I'll change the TeX source accordingly. Thanks - will do. I'm currently thinking of some sort of a small FlightGear internationalization project to avoid such confusion. I'll comment of this the next day Sounds like a great idea. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Native-Ctrls UDP packet structure
bass pumped 3. I send 0s for all the other properties that I do not want to control. I realize now that it was a bad idea... the aircraft sits frozen (none of the usual JSBsim vibration either) on the runway. Can you give me a good example case of where an aircraft is sitting on the runway and jittering a lot? I know that problem existed at one point with the C-172, but it does not seem to happen for me now. I have a possible fix I wanted to try out, so I need a good example. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Native-Ctrls UDP packet structure
Can you give me a good example case of where an aircraft is sitting on the runway and jittering a lot? I know that problem existed at one point with the C-172, but it does not seem to happen for me now. I have a possible fix I wanted to try out, so I need a good example. The default c172 with default wind jitters all over the place if you let it sit for a few seconds. Curt. With default wind ... Has that been removed? I tried the default startup: fgfs a few days ago and let the C172 sit there. It seemed fine to me. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Cygwin and FlightGear startup
It's taking about 3 minutes to initialize FGFS under CygWin. I seem to recall a conversation about that a few weeks ago. Is that something that is being worked, or can it be resolved? Is there something I can do to my setup? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] SP_FMDS
..speaking of which; Are those Big-Overhaul-So-Lay-Off-cvs jobs done in the FG and JSBSim cvs trees? Sorry. Yes. I thought I made a small announcement that I had gotten that taken care of. Maybe not. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] OpenAL for CygWin
I have placed a compiled tarball of yesterdays OpenAL CVS files @ http://www.vso.cape.com/~nhv/files/cygwin/cyg_openAL.tgz you might want to test these against the current FGFS before blindly overwriting your currrent installation Is this distribution modified for use with CygWin as discussed in this thread recently? Namely, the _WIN32 - WIN32 issue, as well as the #define MVC? I suspect these statements could be modified in OpenAL CVS to support CygWin without trouble. Has anyone approached them about this? If not, I wonder if I ought to? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Gear jitter
I was looking at the gear jitter in the latest version of FlightGear with the current C172 (JSBSim). I didn't notice much jitter at all - really very little. Is that because winds are off by default, now? Is there a particular setup where I can see it most noticeably? I have a possible fix that I want to try out. Jon -- Project Coordinator JSBSim Flight Dynamics Model http://www.jsbsim.org ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] New JSBSim Branch
It appears as though JSBSim CVS is in a good state, with the new code, and new directory structure. Notes: 1) No attempt has yet been made to test this with FlightGear - that will take a little bit of work. Things are different: the directory structure, the code, the aircraft config files, etc. 2) I have only attempted to build this under Cygwin and Borland C++BuilderX. 3) Some aircraft, engine, script, etc. files have not been validated against the new config spec. 4) Documentation for the new spec is forthcoming. 5) More information on the converter is pending. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] OpenAL for CygWin
Hmmm ... we had to fiddle with it to make it work some months ago ... I forget exactly what we did This seems really unfortunate for FlightGear - that we have to rely on another package where some of us have to fix the code to work for CygWin users. Is this even documented anywhere? jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] OpenAL for CygWin
In the developers' list archives is the best we have. Cygwin wouldn't work at all if it were not for the excellent work by Norman Vine. There's no sign of OpenAL being ported to Cygwin at the moment, so this is the best we have. We are in constant danger of being left behind. Have you got it to work yet??? I guess I could tarball up my version here for you, when I have a bit more time. Yes. I now have a FlightGear executable - though I won't have time to try it until this evening at the earliest. I'd like to submit the text below to a FAQ or wherever it should be on the FlightGear/SimGear site: --- start --- For Cygwin users, OpenAL needs to be retrieved from this site: ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/openal_cyg.tgz I placed this file in the /usr directory and untar'ed it, though some place it in the /usr/local/ directory tree - which might be more appropriate. Some library and dll files are untar'ed into your bin/ and lib/ subdirectories. Once the files are untar'ed, you must cd to the include/AL/ subdirectory and modify all the files where _WIN32 is present (use grep) and change it to simply WIN32 (that is, remove the underscore). Also, in alc.h you must change the code at top to look like this: #ifdef WIN32 --- CHANGE TO THIS #ifdef _OPENAL32LIB #define ALCAPI __declspec(dllexport) #else #define ALCAPI __declspec(dllimport) #endif #ifdef WIN32 --- CHANGE TO THIS typedef struct ALCdevice_struct ALCdevice; typedef struct ALCcontext_struct ALCcontext; #endif Once these changes are made, you should be able to compile simgear. --- end --- Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] C library timing
Is anyone aware of which C library calls for determining time (down to the millisecond) - either elapsed or calendar - are best used under all the platforms that FlightGear runs on? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] OpenAL for CygWin
Jon Berndt wrote: I'm finally getting around to reinstalling FlightGear after a hard drive crash a couple months ago. I have this as a place to get OpenAL for Cygwin: Try this version: ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/openal_cyg.tgz Vivian I got that file. I untarred it in /usr, so the include files, libraries, etc. all went in the right places. However, I've tried building SimGear (under CygWin) and I get this error: --- start --- In file included from ../../simgear/sound/soundmgr_openal.hxx:50, from visual_enviro.cxx:33: /usr/include/AL/alc.h:39: error: syntax error before `*' token /usr/include/AL/alc.h:51: error: `ALCcontext' was not declared in this scope /usr/include/AL/alc.h:51: error: `alcHandle' was not declared in this scope /usr/include/AL/alc.h:51: error: variable `ALCboolean alcMakeContextCurrent' definition is marked dllimport. --- end --- Does anyone have any suggestions for me in configuring OpenAL to work with SimGear? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] C library timing
There is a plib api for accurate timing. You may not want a plib dependency in jsbsim, but you could take a look at which functions they use on which platforms. Curt. Thanks. I'll take a look. I've got something that seems to work well enough at the moment, but at some point I'd like to improve it. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New developer
Well, I had been working on a B717... the flightmodel seemed ok, but hasn't been updated to the newer JSBSim config file formats, so it will need some work in that area. I'll be posting a converter that takes old format files into the new format - not the engines or thrusters, but those are easily changed. It takes the aircraft config file and converts that. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
