[Flightgear-devel] JSBSim Newsletter topic idea solicitation
If there are any suggestions or requests for featured topics to be in the second issue of the JSBSim newsletter, Back of the Envelope, please let me know by the end of the week. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Anyone read polish?
On Fri, 11 Jun 2004 16:22:30 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Curtis L. Olson wrote: Does anyone read enough polish to double check that everything these guys are doing is within the spirit of the GPL? http://www.allegro.pl/show_item.php?item=26723501 As far as I can decipher it (based on a number of words I do somehow recognize) it's just another magazine article that is quite positive about FlightGear. It seems to mention it is Freeware and talks a bit about the amount of scenery available. I wouldn't worry too much. I found a Polish translator online. I think it's worth looking into. It appears to be a FlightGear CD for sale. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Anyone read polish?
On Fri, 11 Jun 2004 09:14:43 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: Does anyone read enough polish to double check that everything these guys are doing is within the spirit of the GPL? http://www.allegro.pl/show_item.php?item=26723501 They are our top web site referrer this month which is how I noticed them ... Play with this: http://www.worldlanguage.com/Translation.htm Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Anyone read polish?
On Fri, 11 Jun 2004 16:54:56 +0200 Gunnstein Lye [EMAIL PROTECTED] wrote: The GPL does not prohibit selling, and does not say anything about how much they can charge, as long as any changes they have made are made available for free (or the cost of the medium and postage). True, that's why I said it should probably be looked into. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD11 Performance notes
On Thu, 10 Jun 2004 21:03:52 +0200 Durk Talsma [EMAIL PROTECTED] wrote: [JSBSim MD-11 Engine comments] Durk: Dave Culp can answer this more precisely if he's around, but for a quick response let me tell you that we have recently made some changes and fixes to the tank operation for JSBSim. These changes have not yet been carried over to FlightGear. I believe you will find that this will feed from all tanks correctly. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question re: bug reporting/tracking/etc.
On Tue, 8 Jun 2004 12:44:33 -0400 Chris Metzler [EMAIL PROTECTED] wrote: When the project was hosted at SF, there was a bug tracking system there. Was it used? Would having a working BTS be a good thing, I think a bug/feature request facility such as the one on the SourceForge site is invaluable. If you ever find an issue with JSBSim in FlightGear, please do report it. You can find the link to the reporting facilities for JSBSim at www.jsbsim.org. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Apple compilers
I'm not an Apple guy, so I can't test this for sure, but can someone tell me if it is still true that some Apple compilers that are used by FlightGear developers still do not have this function: inline char* gcvt (double value, int ndigits, char *buf) ?? Thanks, Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Panels, Properties, and FDMs
For JSBSim (and I imagine, YASim, and others), our turbine model (for example) features various temperatures that can be reported on a panel display. For any unique aircraft, as well, there will be some arbitrary number of engines, with controls associated with each engine. In JSBSim, at least, we have associated properties with each engine control. I had wondered at one point whether properties would make it very simple to hook up various FDM parameters with associated FlightGear-side panel objects -- also (I assumed) referenced via properties. I suspect now that this has a not-so-simple answer, and it will be plain to see here that this is an area I am not at all familiar with. If I was to create an FDM for a hypothetical aircraft (call it the X-100) powered by six turbojets, I would of course like to have a 3D model and a panel for it. I suspect that I could not simply code up the definition for the panel, and link up the live panel components with the associated JSBSim-side properties. Correct? Even if this was possible, it would then (I expect) preclude other FDMs from using the panel model, and this is bad. I haven't looked at the FGInterface code in a while, but I suspect that that is where the handoff occurs, from JSBSim-side properties to FlightGear-side properties. True? If true, is this optimal? Does it provide for good a plug-and-play design approach? Is there a better way? Is there a FAQ? :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: making instrument scales with MetaPost
FWIW, Gimp has a script that creates text arcs that I have considered using if I ever get a chance to make some instruments. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] JSBSim C-172 Performance
Well, I got a note back from Cessna and (as I pretty much expected) they were tight-lipped about supplying any aero/mass props data, saying instead that the owner's manual was about all I could get. After thinking about this some more, there are three possibilities I can see for any perceived problems: 1) The stability derivatives are indeed low-balled. I find this unlikely, as the numbers for rate-damping are in line with other aircraft in the same class. 2) The MoIs are too low. This is possible - I have not yet checked these out, but again I believe we will find these numbers to be pretty good. 3) This one just occurred to me: I wonder if the control inputs from stick and rudder are linear? Or, are they perhaps graduated? In our FCS model, we take the joystick input and map it linearly to the range of values that the control surfaces can see - essentially. It might make sense that for small excursions about center (no control inputs) that control movements are kept small, but as one makes bigger inputs, that the gain increases. Does anyone have any comments on this? If this was in fact the case, it would not be difficult to modify our control system to model this. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim C-172 Performance
On Thu, 20 May 2004 18:48:13 -0400 David Megginson [EMAIL PROTECTED] wrote: I think you might have been onto something with the moments of inertia: our current IXX, IYY, and IZZ apply to a Cessna 182, which is a heavier plane than a 172, though with the same wing area and wingspan. Here are the 182 numbers we're currently using: IXX = 948 IYY = 1346 IZZ = 1967 What numbers do you have for the Cherokee? I'm not sure I see how the 182 figures into this. Higher values for MoI will make the aircraft slower to react to control inputs, and slower to react to damping. From your discussion yesterday I got the feeling that you were stating that the 172 was too wild - i.e. it was not damping out enough. Smaller MoIs would give better damping results (I think). But it would also make the plane more squirrely when it comes to control inputs. I can try and come up with a better estimate of MoI, but we need to be careful how the fuel numbers figure into that - we need to look at the run-time MoI and not the empty weight MoI in the config file. I have two MoI values at least that I can think of offhand: the Navion and the Cherokee. They are both at home. I ought to be able to compare and contrast those, and define a line, then see where the 172 falls with that. It ought to give me a pretty good estimate. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim prop changes
On Wed, 19 May 2004 07:06:04 -0700 Andy Ross [EMAIL PROTECTED] wrote: Vivian Meazza wrote: Performance: max = 437mph at combat emergency power at 25000ft, 413mph at 15000ft, 395mph at 5000ft, cruising speed 362mph, climb rate 3475 ft/min. Service ceiling 41,900ft. I just ordered a copy of the F-15D flight manual from http://www.eflightmanuals.com, hopefully this will have POH-like numbers. I'll let folks know how it turns out. Andy Please do. It will be interesting to see what kind of relationship there is between F-15D numbers and P-51D numbers, and how you relate the two ... ;-) I've been meaning to order that one, too - the Mustang one. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Concorde model
On Tue, 11 May 2004 17:09:57 +0100 Giles Robertson [EMAIL PROTECTED] wrote: Thanks for telling me about a possible duplication of effort. I think Concorde has to be done in JSBsim - I can't honestly see the YASIM solver being able to cope with 6 elevons (and the quite complicated relationship between input and output on them, especially as this should strictly be related to speed - on the real Concorde, outboard elevon deflection decreases as speed increases in order to keep the thing flyable and the airframe temperatures OK), the nose, and no horizontal tail, but if anyone thinks different, please say. It might be interesting to hav ea fly-off . :-) Does JSBsim handle lift generated by a vortex or a delta wing at low speeds - and does it handle the ground effect of deflected air? Giles Robertson It's all coefficient-based, so if you have (or can get or determine) the relevant aero coefficients, the answer is, yes. Note that we now have a version of Digital DATCOM (Which Bill Galbraith calls DATCOM+) that puts out aero coefficient tables in JSBSim format. So perhaps I could try to set up a DATCOM input file that represents the Concorde. That would be another way to get some pretty good estimates. I'm also trying to find a research paper featuring an SST so that we can get some good sanity-checking coefficients to compare against. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11
On Fri, 7 May 2004 19:26:22 +0200 Durk Talsma [EMAIL PROTECTED] wrote: Cool! Drop us a note, when you think you fixed it, and I'm sure Innis and I are eager to compete for the next round of screenshots. :-) Cheers, Durk Someone sent me an MD-11 FDM for JSBSim a couple of weeks ago. I don't have that witrh me at the moment, and I also don't remember who sent it. Who was that, and where does that stand? Do you still need some more help? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11
On Fri, 7 May 2004 20:03:22 +0200 Durk Talsma [EMAIL PROTECTED] wrote: Hi Jon, That was me. The problem was that upon initialization the aircraft tumbles over and settles on the runway with a bang. Innis Cunningham discovered that we could solve the problem in part by moving the main gears and CoG forward to 850 units or less. We have a version in cvs now which still shows the problem. I made the original version using aeromatic. Please let me know whether I need to resend you the files. I can't do it today anymore though. Yes, I suppose I can get it from the base package CVS, but it would be easier if you had a moment if you could send me the latest aircraft and engine files (unless the engine has not changed). Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Beech 99
On Fri, 30 Apr 2004 13:57:03 +0100 David Luff [EMAIL PROTECTED] wrote: The turbocharged piston engine is a completely different beast from a turboprop though, I would imagine the latter has more in common with the turbine model. OTOH, the Piper Navajo is a GA twin that uses turbocharged piston engines, that might be a nice one to model. Cheers - Dave Oops. I knew that. What was I thinking!? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Altitude Hold Autopilot example
Roy Vegard Ovesen [EMAIL PROTECTED] wrote: On Friday 30 April 2004 13:59, Jon Berndt wrote: between where you are and where you want to be. This error term is limited to 100, filtered with a slight lag, and then multiplied by 0.1 in order to get a commanded HDOT (time derivative of altitude, or rate of climb) of 600 ft/min. This is a slightly unusual way of doing it, normally the commanded HDOT would be limited to 600 ft/min instead of the altitude error. But this approach works great too. We don't [_currently_] have a climb rate property in ft/min, although we could add this easily, and I could also manufacture it in the AP using a gain. I finished this up at 3 a.m. this morning, so keep that in mind! I think your observation is a good suggestion for a modification, though. From the plot it looks like the altitude hold performs very well. But if you try another test where you control the throttle in such a way that the aircraft is unable to hold a 600 ft/min vertical speed. I think you will see that the integrator will wind-up as the HDot Error value never reaches zero. This integrator will start winding whenever the elevator is saturating and still unable to achieve the commanded climb rate. Yep. I've got a wind-up protection feature in the integrator, but I haven't used it, yet - that's another area where I want to add some protection. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] COLLISION DETECTION: possible or not?
Andy Ross [EMAIL PROTECTED] wrote: Erik Hofman wrote: Why do you think that collision detection is not implemented? You can crash to the ground and to the buildings (maybe even other aircraft?), so there must be some logic behind this. AFAIK all the FDMs share the same bug here. it's a feature :-P We looked into this some time ago - IIRC Norman was involved in this, too. It would be really nice to do this, but of course we'd need to be able to somehow acquire an altitude location for each gear. This is probably no big deal to calculate, but then, too, you have to worry about boundaries and straddling. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
On Wed, 28 Apr 2004 13:29:08 +0100 David Luff [EMAIL PROTECTED] wrote: The tests compile and link with ../src/libopenal.a, so unless you've hacked their build script or replaced that lib with Norman's then you'll still belinking (the tests) against the original. I'll have to adjust that. Has anyone gotten OpenAL to work with CygWin? I think the long term benefits should far outweigh the short term pain. ... for those _not_ using CygWin. For those using CygWin, it's fatal at the moment. Unfortunately, I have zero time to look into getting it working, with my workload on JSBSim, preparing for the conference later this summer, etc. So, at least at the moment, I'm stuck with the previous revision of Flightgear. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
On Wed, 28 Apr 2004 15:57:55 +0100 David Luff [EMAIL PROTECTED] wrote: Norman, this compiles, links, and produces the expected sound from FlightGear :-) Many thanks for sorting this - I certainly couldn't have got it working otherwise. Cheers - Dave This was all done under CygWin? Can someone summarize the process? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
On Wed, 28 Apr 2004 16:00:20 +0100 David Luff [EMAIL PROTECTED] wrote: On 4/28/04 at 9:04 AM Jon S Berndt wrote: On Wed, 28 Apr 2004 13:29:08 +0100 David Luff [EMAIL PROTECTED] wrote: For those using CygWin, it's fatal at the moment. Norman's latest openal build fixes it :-) You have to admire Curt's methodology - fatally breaking the Cygwin build has certainly created a momentum to fix it, and presumably saved the time and hassle of riddling the sound code with ifdefs! This approach works only when there is a solution somewhere. From what I could tell in this case, that wasn't guaranteed - I was not confident that a viable fix would be found. My only development environment for Flightgear is CygWin. If that environment goes belly up, I'm toast. And sadly I don't have time to support any debugging efforts. I don't know who else uses CygWin exclusively, but I don't think there are many of us, so I get the feeling that the CygWin users don't have so much of a vote as the Linux guys. Thanks to Norman and yourself for getting to this point. Now will the build process integrate nicely with the normal FlightGear build procedure? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
On Wed, 28 Apr 2004 12:12:20 -0400 Norman Vine [EMAIL PROTECTED] wrote: Nor was I, but usually one can find a way to compile Windows code with gcc but it often requires digging into the depths of the gnu linker documentation and studying the x86 specific link options for creating DLLs for WIN32. I was also concerned about the hardware/driver interface issues, and how this would be built in a Unix-like environment. There was an ominous lack of mention of CygWin on the OpenAL site. Maybe the efforts here will be beneficial if fed back to the OpenAL project ... perhaps there's a FAQ entry in this somewhere for them. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
On Tue, 27 Apr 2004 06:58:41 -0700 Andy Ross [EMAIL PROTECTED] wrote: Many/most of the joysticks don't work for windows users. They download the program, try it, and then complain when the view is constantly spinning around. One presumes the axis mappings are simply different between the platforms, but us Linux folks are more or less helpless to handle these cases. There are similar complaints on the avsim.com forum too. Andy With the AvSim forum, the FlightGear mailing lists, and other forums that have seen wider discussions of FlightGear and its consituent programs, I think FAQs take on a whole new importance. I'm getting ready to field one for JSBSim, too. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about flight model
On Fri, 23 Apr 2004 17:43:59 +0200 Luca Masera [EMAIL PROTECTED] wrote: Hi everyone, about JSBBim: the airplane has three tanks, but the flight model uses only the first. In other words, if I start FlightGear with the first tank empty, the engine is off and doesn't starts. This happens even if the first tank is plenty or with few fuel (I've tried with 1gal and when it's all consumed, the engine shuts off, even if the other two tanks are full). How I can solve this problems? There's someone that could helps me? We'll look at that. Tanks, Tanks, Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11
On Fri, 23 Apr 2004 19:03:15 +0200 Durk Talsma [EMAIL PROTECTED] wrote: Hmm, I just played a bit with the main gears' position, moving them backward by just a bit, and right now, I have the situation where upon initialization, the aircraft tumbles over once and than settles with a bang on the runway. Do you have any recommentations about what strategy to follow? Can you email me your config file and engine file? I can try running it in the standalone JSBSim and make some quick plots and see what I can see. Are you initializing on the runway? At altitude? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] VRP and Camera View
On Thu, 22 Apr 2004 13:52:03 -0400 Josh Babcock [EMAIL PROTECTED] wrote: It would be nice to be able to turn on some sort of cursor in FlightGear to show where the VRP and CG are. Maybe three lines through the point and parallel to the axis of the model. I think it would help aircraft design a lot, especially for neophytes and people modifying existing planes. This would be useful for gear and the viewpoint as well. I guess that would be something that SimGear would have to support. Josh I agree 100% - I think this would be very useful. I think Mathias had done something like this once? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11
On Thu, 22 Apr 2004 20:49:25 +0200 Durk Talsma [EMAIL PROTECTED] wrote: Well, that's right. It happened in that order :-) When I first tried loading the MD11, it appeared to initialize a few hundred feet above the ground, and Hmm. I think this would be the first thing to address. I don't know why the aircraft would start up above the ground like that ... Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Web, tables, and image layout
I went ahead and posted the update to the JSBSim web site last night. The slide image buttons don't quite line up. When they do, the effect will be quite nice, I believe. Anyhow, the only thing I can think of that could be responsible at this time is that the images must be an even number of pixels in height. That doesn't sound likely to me, but it's the only cause I can even think of. If anyone else wants to take a look, the website is www.jsbsim.org. The specific panel URL is www.jsbsim.org/Side_Bar.html. Any comments regarding image quality or artistic or navigational issues are solicited and appreciated. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Web, tables, and image layout
I figured it out. This works: tr tdA href=main.html target=MAIN IMG onmouseover=loadImage(this,sbA2);showStatus(alt);return true; onmouseout=defaultStatus();loadImage(this,sbA1); alt=JSBSim Home src=menu_sep_home_1.jpg border=0/A/td /tr tr tdA href=http://sourceforge.net/export/projnews.php?group_id=19399amp;limit=10amp;show_summaries=1; target=MAIN IMG onmouseover=loadImage(this,sbB2);showStatus(alt);return true; onmouseout=defaultStatus();loadImage(this,sbB1); alt=Latest news about JSBSim src=menu_sep_news_2.jpg border=0/A/td /tr While this does not: tr td A href=main.html target=MAIN IMG onmouseover=loadImage(this,sbA2);showStatus(alt);return true; onmouseout=defaultStatus();loadImage(this,sbA1); alt=JSBSim Home src=menu_sep_home_1.jpg border=0/A /td /tr tr td A href=http://sourceforge.net/export/projnews.php?group_id=19399amp;limit=10amp;show_summaries=1; target=MAIN IMG onmouseover=loadImage(this,sbB2);showStatus(alt);return true; onmouseout=defaultStatus();loadImage(this,sbB1); alt=Latest news about JSBSim src=menu_sep_news_2.jpg border=0/A /td /tr The subtlety is that there can be no whitespace between the beginning of a data cell and the first element of the cell, nor can there be any whitespace between the last element in the cell and the close of the cell (i.e. with a /td). In the second case, above, there is a carriage return after the opening td, and also before the closing /td. This is, apparently, a no-no. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] tables and images and borders ... oh my
On Tue, 20 Apr 2004 14:07:28 +0100 Richard Bytheway [EMAIL PROTECTED] wrote: Assuming that you are talking about HTML here... Open the table with: table cellpadding=0 borders=0 cellspacing=0 cellpadding is the space between adjacent cells borders is the width of the border around each cell cellspacing is the space between the border and the content of the cell You can also specify the size of each cell in the table with td height=... width=..., and this should match the size of the graphic, which should also have its size specified in the img tag. Done that. One thing that helped was to set the font size used in teh table to a small number. But, still, I can't get my cut images in the cells with no borders and no padding to line up. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] tables and images and borders ... oh my
On Tue, 20 Apr 2004 09:34:29 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: Jon S Berndt wrote: Done that. One thing that helped was to set the font size used in teh table to a small number. But, still, I can't get my cut images in the cells with no borders and no padding to line up. Browser bug? Curt. No, I don't think so, because the previous version worked. To be more descriptive, I am redesigning the left hand side panel at the JSBSim web site, because we have a different set of pages now in-place than before, and because all the items were not previously viewable. Each of the buttons was 18 pixels high. Now, the new buttons are 17 pixels high. I have reset the height and width attributes, and so on. But there is still a gap between images. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] tables and images and borders ... oh my
Richard Bytheway [EMAIL PROTECTED] wrote: Some browsers get confused if you have CR/LF between elements. Although they shouldn't render white space (except between words) some do. Try putting the whole td.../td on one line in the HMTL file. Send me the table code if you want me to have a look at it. OK, I'll take another look at it this evening. If that doesn't work, I'll send it to you. Thanks. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Building FlightGear / getting some errors
On Mon, 19 Apr 2004 07:11:26 -0700 Andy Ross [EMAIL PROTECTED] wrote: Jon S. Berndt wrote: undefined reference to `___gxx_personality_v0' undefined reference to `__Unwind_Resume' ... Those are internal g++ things. It looks like you upgraded your compiler without doing a full rebuild? Versions of g++ are not binary-compatible between versions*. Yeah, it was my mistake. I think what happened is that I upgraded parts of my CygWin installation in a bad way. When I uninstalled automake and autoconf, then reinstalled them cleanly, then did a make clean, and a complete rebuild of all the parts of FlightGear, things came out a lot nicer. I'm still not getting a full rebuild, but that's because of the recent JSBSim reorg and the Makefile changes that will need to be worked out, which hasn't been done yet. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] MingW and FlightGear
Can anyone tell me if FlightGear has been successfully compiled and linked using mingw? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MingW and FlightGear
On Mon, 12 Apr 2004 11:45:48 -0400 Norman Vine [EMAIL PROTECTED] wrote: Before Fred started providing MSVC compiled executables IIRC the the only Win32 executables ever available for download from flightgear.org were MingW compiled. What problems are you experiencing ? Norman Nothing really. I had compiled JSBSim under MingW for the first time the other day. I had to remove references to snprintf and link with libwsock32, but other than that I was really happy with it. I wanted to make sure that I wasn't going to waste time on something that was not possible. Maybe I am already compiling FlightGear with mingw and didn't even know it. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft Todo List
On Mon, 12 Apr 2004 19:06:27 +0200 [EMAIL PROTECTED] (Wolfram Kuss) wrote: BTW, I had a look for a X15 3D model a short while ago. There is a new MSFS/CFS model, but it is not much better than the old one, so I don't think it is worth it. The one we have now doesn't seem too bad, but the skins need some detail work, I think. If I had a little more time I'd almost think of giving that a try, but FDM (and tax preparations) are sucking up all my time. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Command Line Options
Where in the FlightGear code are command line options parsed? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] DOS escape characters
Does anyone know how to do escape sequences in a DOS console? I mean, how do you tell the DOS command shell to BOLD or Underline or change the color of text? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Mingw
On Thu, 08 Apr 2004 10:14:57 -0500 Jon S Berndt [EMAIL PROTECTED] wrote: How does one get g++ under CygWin to use the mingw includes and libraries instead of the nominally supplied ones (which, I think, require the cygwin dll to execute). Jon http://www.delorie.com/howto/cygwin/mno-cygwin-howto.html Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Mingw
How does one get g++ under CygWin to use the mingw includes and libraries instead of the nominally supplied ones (which, I think, require the cygwin dll to execute). Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Mingw
On Thu, 08 Apr 2004 16:26:08 +0100 David Luff [EMAIL PROTECTED] wrote: On 4/8/04 at 10:14 AM Jon S Berndt wrote: How does one get g++ under CygWin to use the mingw includes and libraries instead of the nominally supplied ones (which, I think, require the cygwin dll to execute). I *think* that you just include the -mno-cygwin flag during compilation. That almost worked, except at link time I got unresolved references for the socket stuff: FGfdmSocket.o(.text+0x2b1):FGfdmSocket.cpp: undefined reference to [EMAIL PROTECTED]' FGfdmSocket.o(.text+0x35d):FGfdmSocket.cpp: undefined reference to [EMAIL PROTECTED]' FGfdmSocket.o(.text+0x3ec):FGfdmSocket.cpp: undefined reference to [EMAIL PROTECTED]' FGfdmSocket.o(.text+0x489):FGfdmSocket.cpp: undefined reference to [EMAIL PROTECTED]' FGfdmSocket.o(.text+0x4de):FGfdmSocket.cpp: undefined reference to [EMAIL PROTECTED]' FGfdmSocket.o(.text+0x542):FGfdmSocket.cpp: undefined reference to [EMAIL PROTECTED]' FGfdmSocket.o(.text+0x75d):FGfdmSocket.cpp: undefined reference to [EMAIL PROTECTED]' FGfdmSocket.o(.text+0x809):FGfdmSocket.cpp: undefined reference to [EMAIL PROTECTED]' FGfdmSocket.o(.text+0x898):FGfdmSocket.cpp: undefined reference to [EMAIL PROTECTED]' FGfdmSocket.o(.text+0x935):FGfdmSocket.cpp: undefined reference to [EMAIL PROTECTED]' FGfdmSocket.o(.text+0x98a):FGfdmSocket.cpp: undefined reference to [EMAIL PROTECTED]' FGfdmSocket.o(.text+0x9ee):FGfdmSocket.cpp: undefined reference to [EMAIL PROTECTED]' FGfdmSocket.o(.text+0xbc2):FGfdmSocket.cpp: undefined reference to [EMAIL PROTECTED]' FGfdmSocket.o(.text+0xcd8):FGfdmSocket.cpp: undefined reference to [EMAIL PROTECTED]' FGfdmSocket.o(.text+0xdee):FGfdmSocket.cpp: undefined reference to [EMAIL PROTECTED]' FGfdmSocket.o(.text+0x1a79):FGfdmSocket.cpp: undefined reference to [EMAIL PROTECTED]' ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Mingw
On Thu, 8 Apr 2004 19:27:50 +0200 Frederic Bouvier [EMAIL PROTECTED] wrote: I guess that you should link with -lwsock32 ( or -lws2_32 if it isn't working ) -Fred That fixed it, thanks. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [OT] g77 and link errors
I'm trying to build an application in gnu fortran (g77) but I end up with these link errors: /usr/bin/../lib/libg2c.a(fmtlib.o)(.text+0x57):fmtlib.c: undefined reference to `__umoddi3' /usr/bin/../lib/libg2c.a(fmtlib.o)(.text+0x79):fmtlib.c: undefined reference to `__udivdi3' Anyone selling clues? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] g77 and link errors
On Wed, 07 Apr 2004 12:21:12 -0700 Andy Ross [EMAIL PROTECTED] wrote: Jon S. Berndt wrote: I'm trying to build an application in gnu fortran (g77) but I end up with these link errors: undefined reference to `__umoddi3' undefined reference to `__udivdi3' Those look like the software math emulation stuff implemented in libgcc. You could try adding -lgcc to your link line, but I'd be suspicious that something else is wrong. On x86, the only functions from that library that should be required are the 64 bit long integer ones... Thanks for the clues, guys. I hadn't seen libgcc.a until I dug down deep into the directory structure. Linking with that got rid of the unresolved references. One last one: ld: warning: cannot find entry symbol _mainCRTStartup; defaulting to 00401000 I suspect there may be an option I can pass to get rid of this one. I do get an executable, but it doesn't do anything as far as I can tell. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Tue, 6 Apr 2004 14:05:38 - Jim Wilson [EMAIL PROTECTED] wrote: Jon Berndt said: As opposed to? I suppose you could say everything I'm asking about is visual, since I'm neither a pilot nor an engineer :-) It would be nice to eventually have the compression values to pull off visual modeling, similar to YASim's output (or an alternative that might be better). We do have those values. I just never thought about publishing them. What do you need? What does YASim provide? What would be best? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Tue, 06 Apr 2004 16:46:53 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Jon wrote: We do have those values. I just never thought about publishing them. What do you need? What does YASim provide? What would be best? normalized compression would be great: gear/gear[]/compression-norm Erik Now, the question is how do we match up the 3D model gear strut with the FDM gear? Is there a common gear numbering scheme? How about gear that have swiveling bogeys (747, etc.)? Skids (X-15)? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying Existing FDM
On Tue, 6 Apr 2004 11:41:43 -0400 Sonny Hammaker [EMAIL PROTECTED] wrote: To Whom it May Concern, and to Whomever may be of assistance, I'm working on modifying a jsbsim FDM to represent an RPV with an autonomous autopilot. The autopilot and gnc systems are designed in Simulink, and we're using flight gear as the visual and dynamics model for the aircraft. I'm having a hard time maintaining an altitude hold, and I believe it is due to my lack of knowledge in terms of incorporating an engine and propeller model. I'm using an existing engine, and prop model, but our specific aircraft is equipped with an electric motor, and I don't see any examples of these in Flight Gear. The GNC system seems to be responding correctly, as is the velocity hold portion of the autopilot, but I'm not getting any response from the aircraft with an increase in thrust or power. Any advice on how to modify the engine or prop file for an electric motor would be greatly appreciated. thanks for the time Very interesting. As you point out, we have not modeled an electric engine, yet, so I guess somehow you have hacked together an electric engine. I'd be interested to see that ... Without seeing your configuration file, it's hard to make a good recommendation, but I would ask if you have tried the data logging feature of JSBSim, yet? You can log a lot of data that I would use to diagnose the problem. You would adjust the OUTPUT section of the aircraft config file to do this. Are you aware of this capability? What are you allowed to share (for debugging purposes) as far as config files go? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Tue, 06 Apr 2004 18:58:03 +0200 Erik Hofman [EMAIL PROTECTED] wrote: JSBSim does basically the same (although there is a name allocated for it), but the real question is: Is left most defined 0, or is right mos define d0, or is it something completely different (numbered in order of appearance)? Erik Here is an example of our gear definition: AC_GEAR NOSE -6.8 .0 -20.0 1800 600 .5 .8 .02 STEERABLE NONE 10 FIXED AC_GEAR L_MAIN 58.2 -43.0 -17.9 5400 1600 .5 .8 .02 CASTERED LEFT 0 FIXED AC_GEAR R_MAIN 58.2 43.0 -17.9 5400 1600 .5 .8 .02 CASTERED RIGHT 0 FIXED AC_GEAR TAIL_SKID 188.0 .0 8.0 2 1000 .2 .2 .2 FIXED NONE 0 FIXED AC_GEAR LEFT_TIP 43.2 -214.8 59.4 1 2000 .2 .2 .2 FIXED NONE 0 FIXED AC_GEAR RIGHT_TIP 43.2 214.8 59.4 1 2000 .2 .2 .2 FIXED NONE 0 FIXED See, we have contact points in addition to actual wheeled bogeys defined. The X, Y, Z coords of the contact point for each gear us there, as are the static and dynamic friction coefficients, rolling resistance, steering type, brake group membership, maximum steering angle, and retreactability. They are not now expected to be in any particular order, nor are they given specific names. The layout is somewhat free form. A questions is, how do you set up the gear model to support animation when you may want to model things as varied as a 747, a C-172, a P-51D, a Harrier, etc.? Perhaps there should be another identifier that relates a specific gear instance with an associated 3D model gear item? Perhaps there ought to be an ordering standard? Suggestions? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Tue, 06 Apr 2004 19:41:08 +0200 Erik Hofman [EMAIL PROTECTED] wrote: /gear/nose /gear/l_main /gear/r_main /gear/tail_skid /gear/left_top /gear/right_tip The only change might be that YASim should allow for defining named gear locations. Erik I don't know anything about how the 3D animation stuff works, but the above idea seems good to me. Andy: Regarding the LEFT|RIGHT group membership thing, there is a reason for it. There also are probably several ways to accomplish the same things - maybe even better ones, but this is the way it occurred to me to do it at the time. The problem is that if we have, say, four main gear (like on a 747) and a nose gear, how do we know which gear to apply braking commands to, since there are only two brake pedals? In JSBSim we can define bogeys in any order, so we can't really take the order to mean anything. We _could_ use some kind of AI to say that if the gear has a negative Y coordinate, then it is on the left side. But, what about (for instance) the outrigger struts on a B-52? I am guessing those have no brakes to speak of. Specifying the brake group membership was a way for us to sort of connect a bogey definition in JSBSim with the relevant brake command coming from FlightGear. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Tue, 6 Apr 2004 18:05:30 - Jim Wilson [EMAIL PROTECTED] wrote: Maybe adding the text description in the gear/gear[n] path (the NOSE, L_MAIN, R_MAIN, etc) might help someone trying to figure out which was which. But of course they could just look at the config file and count (e.g. R_MAIN must be gear[2]). I like Erik's suggestion - but then my assumption is that the 3D modeler will know to look at the FDM and see how the gear is named. A big remaining issue there, however, is that this would require all FDMs to name the gear the same way if there were multiple flight models for a given 3D model. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying Existing FDM
On Tue, 6 Apr 2004 14:42:48 -0400 Sonny Hammaker [EMAIL PROTECTED] wrote: In the prop file prop_75in2f.xml what is the input column for the Look up tables of C_THRUST, and C_POWER. The first column that is thanks This is a 75 inch diameter, 2 bladed, fixed-pitch propeller. The first column is the advance ratio, J: J = Vel / (Diameter * RPS); Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Tue, 6 Apr 2004 19:16:18 - Jim Wilson [EMAIL PROTECTED] wrote: Erik Hofman said: Your idea of simple is different then mine. Most of the time I know the names I've given objects for 3d animations, I never seem to rememberthe order in which I put them in the file ... Yep. It just depends on how your brain is organized I think :-) Or, if ... B^P Personally, I like the naming scheme better. What ought we do, I ask? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Consistent gear modeling for animation compatibility
On Tue, 06 Apr 2004 20:58:24 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Your idea of simple is different then mine. Most of the time I know the names I've given objects for 3d animations, I never seem to remember the order in which I put them in the file ... Erik So ... to get some closure on this issue, do we give the FGLGear class some bindings based on the gear name? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying Existing FDM
On Tue, 6 Apr 2004 16:47:42 -0400 Sonny Hammaker [EMAIL PROTECTED] wrote: thanks for the tips. So you're suggesting that I leave the J (advance ratio), and coefficients alone, and just modify the Ixx and Diameter parameters accordingly? DONE! Well, this kind of leads me back to the original problem. My plane is supposed to be flying to a set of waypoints, lat, long, and altitude, and along this flight, should be tracking a.)velocity and b)altitude. It fly's to the specified lat, and long, but there is no response from the aircraft when the actual alt. drops below the setpoint altitude. I can see the thrust increase, and with this increase I expect an increase in lift, but I continues to ever so slowly loose altitude. It never shows an increase, and hence never tracks the setpoint. Now, this could be a function of my SC derivatives, so maybe I'll go and revisit them. First, let me get clear on what you are using. You are using a JSBSim flight model, within FlightGear, using the FlightGear autopilot? Earlier, you mentioned controlling the OUTPUT portion of the FDM. Why is it that the aircraft reacts differently when different options are enabled? With the right subset enabled, it fly's pretty well, but without, it's a disaster The OUTPUT/OUTPUT section **only** affects how data is logged for post-processing and it has **no** effect on the flight characteristics. I thought you might want to make some plots to see what was happening. Can you send me your aircraft config file so I can see if it is defined properly? Another thing: you can control how JSBSim outputs some debugging messages that are displayed during aircraft loading. This might be helpful. Try setting the environment variable JSBSIM_DEBUG to 1, or 3, or 7, then run again. This ought to echo in what the program thinks it is reading in from your input file. That might help eliminate any parsing errors. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying Existing FDM
On Tue, 6 Apr 2004 17:16:01 -0400 Sonny Hammaker [EMAIL PROTECTED] wrote: Some good thoughts again. Actually, I'm using a JSBSim flight model, within flightgear, but interfacing it to my own autopilot inside of Simulink. I might however switch over to the Flight Gear Autopilot, and see what kind of handling I get. Which address should I send the file to? sonny jsbathal-pc.org Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CG Location
On Tue, 6 Apr 2004 16:59:55 -0400 Sonny Hammaker [EMAIL PROTECTED] wrote: I thought I read somewhere, that in Flight Gear, the CG of your aircraft isn't specific to the aircraft itself, but rather related to some sort of reference. Is this true? Or did I misinterpret something? It also mentioned that you could put the coordinates of (0,0,0) for CG location. sonny For a JSBSim flight model, there are a few reference frames of interest. I just published a newsletter for JSBSim that describes within it some of the various coordinate frames. Go to www.jsbsim.org, and click on the newsletter announcement at the top of the main page. All points that are specified in the config file are referenced to a coordinate frame that has the X axis increasing aft, the Y axis increasing right, and the Z axis increasing up. The origin technically could be anywhere, but is usually at or near the nose of the aircraft - although, technically, it *could* be placed coincident with the CG - even though the CG moves during flight. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Mon, 5 Apr 2004 14:47:11 - Jim Wilson [EMAIL PROTECTED] wrote: What JSBSim does that YASim does not is if the aircraft is a little too close to the ground at initialization JSBSim hurls the thing up in the air. Why is it that only JSBSim reacts by flipping over the Cessna? What does YASim do? Granted, this is bad behavior. My question (and I have not been following this discussion previously as closely as I should have been) is: is fixing the JSBSim side the right approach, or is JSBSim being given a bad value in the first place. Even if that was true, of course, we ought to be robust enough to handle this gracefully. It sounds like maybe the gear routine needs to be informed if a trim is in-progress, but Tony is the trimming expert, not me. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Mon, 5 Apr 2004 11:13:15 -0700 (PDT) Tony Peden [EMAIL PROTECTED] wrote: --- Jim Wilson [EMAIL PROTECTED] wrote: But will we ever know why JSBSim needs to do flip over the 172? :-) Bad data. On the part of ... ? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Lunar flight
1) Is anyone aware of a database of the lunar surface exists that FlightGear could use? 2) How difficult would it be to model other planetary bodies using FlightGear (assuming the FDM had everything it needed)? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Mon, 5 Apr 2004 23:15:42 +0200 Mathias Frhlich [EMAIL PROTECTED] wrote: The onground property is now ok. You can reset now JSBSim aircraft. Thanks for the fix! ?? Was it bad data? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Mon, 5 Apr 2004 23:04:16 - Jim Wilson [EMAIL PROTECTED] wrote: Jon S Berndt said: ?? Was it bad data? I think, that maybe this could be resolved by doing as Andy described earlier. In other words know where the gear is and get it above the pavement (ground elevation) before the simulation starts. Then and only then drop the sucker, start the simulation, and let it settle. Sorry for the simplistic explanation Actually, I suggested this early today (two emails, ~9 a.m. and prior). and my apologies for suggesting that JSBSim could do something about bad data instead of just crashing random aircraft. As it is now we need to test every single JSBSim aircraft every time a modification is made to flightgear because the trim routine is lacks robustness. I was discussing this offline, too. GIGO applies, but we should be more robust in handling the problem - at least giving a good error message. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] What on earth ...
http://www.boeing.com/news/frontiers/archive/2002/may/ts_pw.html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [OT] Application recommendations solicited
Two general application / programming / automation questions: 1) Image conversion Is ayone aware of a program that does on-the-fly image conversion that will run under Cygwin from the command line? Specifically, what I am looking for is a program that will take a specified-resolution image from a Kodak photo-CD format file (.pcd) and convert it to a .png file. That's the most basic requirement. I might want to do other stuff, as well such as resizing, etc. 2) Socket applications Does anyone know of a program/utility thingie that can be assigned to listen to a port and simply spit out whatever comes across? JSBSim has a socket capability and I wanted to play with that some more (after a long hiatus). A command line application would be fine. Anything would be fine. I just want to see what's coming over the wire. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Application recommendations solicited
On Wed, 31 Mar 2004 16:06:26 -0800 Andy Ross [EMAIL PROTECTED] wrote: You want the ImageMagick package. It comes with an amusingly named convert program: convert MyPhoto.pcd MyPhoto.png This is best handled by the nc program (net cat), which I'm sure must be available in cygwin. Doing nc -l -p 12345 will listen on TCP port 12345 and print everything it hears to the console. There are zillions of options to this program, it's a handy tool. Thanks. I think that'll do it! Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Tu-154 / jsbsim beginner needs help
On Fri, 26 Mar 2004 16:02:09 +0100 (CET) Ilja Moderau [EMAIL PROTECTED] wrote: Hello everybody, I created my first aircraft - Tupolev 154. Screenshots: http://mitglied.lycos.de/iljamod/tu154-1.jpg http://mitglied.lycos.de/iljamod/tu154-2.jpg You can download it under: http://mitglied.lycos.de/iljamod/tu154.zip This Tu-154 hasn´t got an own flight model, it is just a copy of the 737 model. I read all the jsbsim docs, but I understood nothing at all! I don´t know where to place AC_CGLOC, C_AERORP and so on. Where can I find out all the data? What would be the best locations? Hi, Ilja: We'll help you out here, don't worry. The first thing you might want to do is try out Aeromatic, which will give you a good start to getting a flight model: http://jsbsim.sourceforge.net/aeromatic.html Follow the directions there and you will get a flight model. You can get to this link normally by going to the JSBSim web site and selecting Aeromatic on the link list on the left side. Unfortunatly, if you have a small screen, some of the links might be off the screen on the bottom (where Aeromatic is linked). Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Tu-154 / jsbsim beginner needs help
On Fri, 26 Mar 2004 16:57:34 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: * Ilja Moderau -- Friday 26 March 2004 16:02: I created my first aircraft - Tupolev 154. Screenshots: http://mitglied.lycos.de/iljamod/tu154-1.jpg http://mitglied.lycos.de/iljamod/tu154-2.jpg Really beautiful! It really is. Ilja - I'll be happy to help you along in creating a flight model for it. Just ask if you need something more. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] next release
On Fri, 26 Mar 2004 23:13:59 +0100 Oliver C. [EMAIL PROTECTED] wrote: On Friday 26 March 2004 22:05, Curtis L. Olson wrote: I have a bit of time this afternoon so I'm going to try to get the official SimGear-0.3.5 and FlightGear-0.9.4 rolled out. I plan to give the mirrors a day or two to catch up and maybe hope for a windows build before make an official announcement. I was also hoping tomorrow morning to try out the newest pre-release. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: releases
On Fri, 26 Mar 2004 23:47:27 +0100 Oliver C. [EMAIL PROTECTED] wrote: Oooops, I wonder if we ever get the chance to do real testing before a release. I agree with that. The pre release version 0.9.4.pre2 was released on March 23.2004. This means that there were only 3 days time for testing thats by far too less in my opinion. I'll third this. I've really only got time on the weekends to do any kind of testing. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releases FlightGear-0.9.4.tar.gz, NONE,
On Fri, 26 Mar 2004 17:28:12 -0600 Curtis L. Olson [EMAIL PROTECTED] wrote: Martin Spott wrote: Oooops, I wonder if we ever get the chance to do real testing before a release. I'm very well aware that this is primarily Curt's project I apologize if the schedule was a bit compressed, but I have to work within the constraints of my own spare time too, since I have a full time job and a family to juggle along with everything else. I have to take my spare time slots when I can get them. It can take several hours to roll out a new release, significantly more than that if it's been a while since the last release. I estimate I put 30-40 hours into getting the 0.9.3 release ready. Curt. I can certainly sympathize with this, but does it make things harder to let the pre-releases sit there a bit longer, though? Even if it turns out that an opportune time passes by and they have to sit there a couple of days or a week longer, is that a bad thing? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] last-minute addition
On Thu, 25 Mar 2004 06:56:31 -0800 Andy Ross [EMAIL PROTECTED] wrote: What exactly does hangaring mean as a FDM feature? It's not exactly a tangible feature from a user perspective. It's almost sort of a minor correction in the way we do things. Right now, engines for JSBSim aircraft are searched for in the Engines/ directory in the base package. Dave Culp mentioned that it would be nice if we could put the engines in an Engines/ subdirectory under the specific Aircraft/ directory, because this would make it very easy to put an entire aircraft package together and unpack it into a single directory tree. This would then allow us to create a virtual Hangar at the JSBSim web site (or wherever) where we can store entire aircraft models, docs, etc. There's going to come a time (or we may have passed that) where we ought to be storing additional aircraft models (3D model and FDM together) outside of the FlightGear packages, so we can reduce download times, etc. For us, the sensible place to do this is at the JSBSim site. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Trademark violations could be a problem
On Wed, 24 Mar 2004 17:28:48 -0600 Curtis L. Olson [EMAIL PROTECTED] wrote: spend too much energy solving non-existant problems. If people want to create ficticioius designs, that can be fun too. Curt. That could be a lot of fun. I'm working on OlsonAir, at the moment. ;-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: base package aircraft and aliases
On Wed, 17 Mar 2004 09:05:03 -0500 David Megginson [EMAIL PROTECTED] wrote: As a matter of fact, I'd suggest getting rid of the yasim, jsbsim, etc. in aircraft names altogether. We have only a tiny handful of aircraft (172, 310, etc.) supported by more than one FDM; in those cases, let's just call them something like 172-alternate, etc., and mention the FDM in the comments (if at all). FYI, There will be more and more duplicate aircraft coming in the not-too-distant future. Let's just put a status property in the config properties for each aircraft, and filter on that. For example, if the statuses available were alpha beta production options like --list-aircraft could, by default, show only aircraft with a status of beta or production, but with the --show-all option, it could show aircraft with any status. JSBSim already has an attribute in the FDM definition for a RELEASE. I think this is a good idea. There's more to an aircraft model than just the FDM, of course, so maybe there should be more than one release specifier. This is one reason I think there ought to be release NOTES included along with each model, and I'm thinking that JSBSim might benefit from a hangar approach that Dave Culp has mentioned. I foresee this is not only a collection of all the files needed for an aircraft, but a resource for the aircraft as well, with useful information embedded in the hosted portal. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft README files
On Wed, 17 Mar 2004 11:19:36 -0500 Josh Babcock [EMAIL PROTECTED] wrote: PropertyList include=ncc1701d-set.xml What I want to know is: where is the NCC-1701D !? :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft README files
On Wed, 17 Mar 2004 11:43:28 -0500 Josh Babcock [EMAIL PROTECTED] wrote: Oh, they're out seeking new life forms. They'll be back in about five years. Now JSBSim *does* support warp core engines, right? sound of rapid keyboard clicking I'm workin' on it! ;-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems building - multiplatform
On Tue, 16 Mar 2004 09:09:15 -0800 (PST) Alex Perry [EMAIL PROTECTED] wrote: From: Orthonormalize [EMAIL PROTECTED] honestly have you ever tried building this thing from scratch? Personally? Last week, on an AMD64 laptop that's running Debian's Sarge. The code downloaded and compiled from scratch (with PLIB and TerraGear) in about 15 minutes. Although that would run with software rendering, On a fresh machine running W2K I can install the cygwin environment (www.cygwin.com) with all the developer tools, and execute this perl script: http://cvs.sourceforge.net/viewcvs.py/*checkout*/jsbsim/JSBSim/createfgfs.pl?rev=1.5 and the entire thing downloads and builds. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGEngine Bug still in Flightgear cvs
On Fri, 12 Mar 2004 17:51:56 + [EMAIL PROTECTED] wrote: Today i updated my flightgear cvs directory and tried to rebuilt it. But there was still this bug in FGEninge.cpp: FGEngine.cpp:71: no matching function for call to `basic_stringchar, string_char_traitschar, __default_alloc_templatetrue, 0 ::clear ()' !! Now, I *know* I fixed this somewhere. Sorry about that. Can you tell me which compiler and platform you are building under? Is clear() not part of the string class in some distributions? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] EasyXML
As far as I can tell, there is no SimGear-devel list, so I'm asking this here. I'm probably going to toy with EasyXML for a C++ side project I'm working on - and if that goes well, perhaps think about using it with JSBSim as well. I am guessing that I ought to be able to grab the EasyXML files from my flightgear installation and place them in my other application development directory, then compile and link them similarly to the way flightgear does it. To actually make any sensible use of it in my application, if I have read the docs correctly, I think I need to derive a class from XMLVisitor and override the handlers. I don't want to burden anyone with any handholding request, but any pointers on where the best documentation is (I am currently reviewing the docs at simgear.org), which files -- other than the EasyXML files themselves -- in the FlightGear tree should I peruse, and any other guidance on using EasyXML would be greatly appreciated and also increase my chance at success given my extremely limited time. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Paraglider model
On Mon, 01 Mar 2004 07:46:16 -0500 David Megginson [EMAIL PROTECTED] wrote: Jon Berndt wrote: If neither of the two (YASim and JSBSim) are appropriate for your expectations, you can code a special flight model in C within LaRCSim or perhaps set up a special model in UIUC-LaRCSim, although I am not very familiar with that. Right, but that's roughly equivalent to writing your own operating system to support your spreadsheet. If there's something that you cannot get from YASim or JSBSim, we'd prefer to improve them if we can, since other people might need the same functionality in the future. David Good point. I was just pointing out that sometimes code changes are required for special needs, such as in the icing studies done using UIUC-Larcsim. I would think we ought to be able to model a paraglider within JSBSim as it is, currently, but I haven't had time to think about that much. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBsim fails to build in FGFS cvs
On Fri, 20 Feb 2004 09:08:26 -0800 (PST) Gopal Mor [EMAIL PROTECTED] wrote: The error messages obtained during compilation are as follow FGEngine.cpp:71: no matching function for call to `basic_stringchar, string_char_traitschar, __default_alloc_templatetrue, 0 ::clear ()' I think I have seen this one before, too. It's this line: Name.clear(); Change it to this: Name = ; It's been the former way for five months, so it's strange to see it causing a problem, now. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Baby
On Wed, 18 Feb 2004 13:55:40 -0600 Curtis L. Olson [EMAIL PROTECTED] wrote: Hi, quick announcement ... baby! Amelia Esther, 8lbs 1oz, born 6:12am this morning, less than 1 hour from first contraction to delivery. 12 minutes from arrival at the hospital to delivery. Everyone is doing good. I'll be pretty much offline for a couple days. If I have any pending business, patches, etc. (Fred, Jim, etc.) I will have to get back to it this weekend. Congrats. One hour. That's good. Time to turn Pro. ;-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 07:07:05 -0800 Andy Ross [EMAIL PROTECTED] wrote: Adding the VRP is yet another mechanism, basically a direct analog of the view offset stuff on the FDM side. I just don't see the need. If we decide the VRP is the right way to do it, we should chuck the view offset stuff for simplicity and orthogonality. Andy Can the view offset or rendering code (whatever it is that draws the 3D aircraft models) move the origin of the set of vertices that defines the model per-frame so that the CG aligns with that reported by the FDM? But then, the FDM still has to report where the FDM is in a common reference frame. The 3D model and the FDM don't really know that much about each other - it's dort of open-loop. It's not clear to me how you are proposing that the 3D modeling code would know how to exactly interpret what the FDM is telling it - apart from there being a convention such as the VRP. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] XML SCripting
On Fri, 13 Feb 2004 11:15:19 -0600 Cameron Moore [EMAIL PROTECTED] wrote: FWIW, Microsoft filed their patent on Dec. 1, 2000. The CVS entry you reference was from Apr. 6, 2001. Can you beat the December date? -- Cameron Moore Probably. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] NASA Open Source Licensing
An interesting article: http://news.osdir.com/article448.html Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 13:09:30 -0700 Russell Suter [EMAIL PROTECTED] wrote: So then the pilot's eyepoint is relative to the dynamic CG? I guess I just assumed JSBSim reported a position from a fixed point on the aircraft. Ack! Would your VRP then become the point from which the pilot's eyepoint is derived? All JSBSim points are defined in structural frame (including the VRP). All of these are fixed in that frame except the CG - which may move as fuel burns off. This is another reason why the VRP is reported. The offset from the VRP to the JSBSim eyepoint is constant. The JSBSim pilot eyepoint isn't used by flightgear, though. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 12:53:45 -0700 Russell Suter [EMAIL PROTECTED] wrote: The VRP is a **solid** point of reference. Yes, that is most likely different for each aircraft, No? Maybe I've missed something here but as I understand it, the VRP is an attempt to define a fixed point of reference in the FDM that correlates to the origin of the visual model. Not necessarily to the origin. The 3D modeler may choose not to make the nose tip the origin. It could not matter, as long as everyone understands that the VRP refers to the nose tip, and by convention the 3D modeler also knows that, so the rendering code would do whatever it needs to do ... The XML file can also have a scale factor and the visual model can be correctly used for both Hornet and Super Hornet. The order of operation for translate, rotate, and scale would need to be defined up front. This might not be a bad idea, but I'm not a rendering guy. I absolutely agree. But, there's more to this than simply getting the visual models to correctly align with the FDM. There are also potential view points that too are fixed. For instance a mounted camera, a maverick missile camera on a rail. Are you going to calculate VRP's for these too? There can be pilot eyepoint, copilot eyepoint, jump seat eyepoint, etc. As long as the FDM reports **one** fixed point relative to the aircraft, all other items can be **easily** made to conform to that point. Ideally, all FDMs would use the same point. I think so, too. As far as calculating viewpoints for missiles, etc. this would come naturally. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 20:30:35 - Jim Wilson [EMAIL PROTECTED] wrote: Jon, I forget, what exactly is the reason for defining a VRP in the config file? I thought that JSBSim already knew where the nose was. We normally track: - Initial empty weight CG - Dynamic CG (includes fuel burnoff) - landing gear ground contact points - scrape points - pilot eyepoint (for calculating pilot accels for motion base systems and instruments) and now, - the Visual Reference Point (tm) The VRP is what is returned to JSBSim.cxx (FGJSBsim == FGInterface) But, as discussed, this has not been given the final push into operations, yet. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 20:30:35 - Jim Wilson [EMAIL PROTECTED] wrote: Jon, I forget, what exactly is the reason for defining a VRP in the config file? I thought that JSBSim already knew where the nose was. Also, Jim: will the view code be able to place a 3D model correctly no matter what the FDM is? I mean, if I have a 747 model, and an A-4, for instance, does that make things difficult? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 21:25:42 - Jim Wilson [EMAIL PROTECTED] wrote: Jon S Berndt [EMAIL PROTECTED] said: We normally track: - Initial empty weight CG - Dynamic CG (includes fuel burnoff) - landing gear ground contact points - scrape points - pilot eyepoint (for calculating pilot accels for motion base systems and instruments) and now, - the Visual Reference Point (tm) The VRP is what is returned to JSBSim.cxx (FGJSBsim == FGInterface) So is the VRP what we see as lon/lat/alt? If not, then what does it look like? If it is, then what do we need to change in the JSBSim config files? Let me clear up something said in an earlier email (by David Culp): I don't recall what the structural frame is for most of our aircraft - but I don't think they have their origins at the nose neccesarily. Although, it doesn't matter. JSBSim reports a lat/lon/alt. Our recent changes will make it the lat/lon/alt of the VRP. It accounts for the offset from the CG and rotation of the aircraft, so that if you place the nose of the aircraft at this spot, all will be well. Given each JSBSim aircraft config file, we will need to add the AC_VRP ### entry to each aircraft file. This may take some measuring ... may take some figuring. The location of the gear will alreay be there, as will the locations of scrape points (in some cases), the location of the eyepoint, etc. So, we ought to be able to figure the location of the nose tip in JSBSim structural coordinates. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 14:33:43 -0700 Russell Suter [EMAIL PROTECTED] wrote: Although I strongly agree that JSBSim reporting a fixed point relative to the aircraft is good, I'm not particularly thrilled with the point you have chosen. I am more than happy to agree to disagree on that one though. Just out of curiousity, which point would you favor -- given that we have multiple FDMs, and model various aircraft, for which there are various modelers who may have no clue about where the CG is? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Eye candy
Any chance of modeling wingtip vortices (when CL is high enough above some threshhold) and rocket engine exhaust? :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
This would be nice: http://www.dfrc.nasa.gov/Gallery/Photo/X-15/Small/EC68-1889.jpg :-) Jon Josh Babcock [EMAIL PROTECTED] wrote: Actually, I'm pretty sure that with nasal and the animations we have we can do exhaust cones right now. Just model a cone, assign it a translucent, emmisive materiel and then use nasal to turn it on and off. You can even make it get bigger and smaller with the animations. Don't know how to do the smoke though. Also, those little clouds that form over the wings at high lift would be cool too. Josh Jon S Berndt wrote: Any chance of modeling wingtip vortices (when CL is high enough above some threshhold) and rocket engine exhaust? :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 16:52:12 -0700 Russell Suter [EMAIL PROTECTED] wrote: Well, Jon, I think you already know the answer to that question. The You probably answered that several times, but I didn't catch it in your email. way you phrase it though implies that I somehow believe that the modeler (aka. graphic artist) must know where the CG is. That is not the case. But, I do believe it is better to match the model to the FDM, and not the other way around. I also We are not really matching the FDM *to* anything. We can report any reference point with ease, and are just giving the location of the reference point that makes it easiest for agreeable placement of the 3D model. Using the empty weight CG would not make the FDM's job any easier. Remember, the CG moves as time goes on and fuel burns off, stores are dropped, etc. It's conceivable that the fuel could be burned off of one wing tank only, which would really skew the CG. The view code will still have a 3D model with an origin at the original (empty) CG, but the FDM will be reporting a location that is perhaps several feet off to one side. So, the solution to that is that instead of the FDM calculating the offset to the VRP, the offset to the empty weight CG is calculated and reported to FlightGear instead. Very well. Yes, that would work. However, it assumes that the 3D modeler is going to know where the empty weight CG is. Otherwise, how will the modeler know where to place the origin? You seem to say that it doesn't matter, that we will just use metadata to relate the CG (which the FDM designer knows about) to the 3D model origin (which the modeler knows about), but that will require that one or both people will need to know both things about a model. I don't see any advantage to your approach. In this case we decided to use the VRP after debating it for a very looong time (and considering many of the same points you bring up here). In this case, the FDM designer only needs to know about what an FDM designer always knows about PLUS where the nose of the aircraft is. Easy. The 3D modeler only needs to know about what a 3D modeler knows about PLUS where the nose is. It's sort of like object-oriented design, with encapsulation. Or, like navigation: you and I don't know where each other are, but we could both meet in Chicago. As for using an A4 FDM with a 747 model or whatever, that's a red herring. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
On Thu, 12 Feb 2004 19:50:48 - Jim Wilson [EMAIL PROTECTED] wrote: You actually want to be very exact about matching the model to the FDM origin. ... Jim (or someone ... *anyone*): Could you summarize the argument taking place here? I seem to only be getting parts of it - I guess I didn't get the original question/comment. Is there now a difference in the way that JSBSim and YASim match up the 3D model with the FDM? Have you had a chance to try out the new way that JSBSim provides position? Is there anything else we (JSBSim and/or FDM developers) need to do? I would like to get an alpha B747 FDM I have been working on to work using the 3D model, but haven't really had time to work on this much. When I did try it out initially, it looked like the origin was wrong between the 3D model and the FDM. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Thu, 12 Feb 2004 15:09:15 -0500 David Megginson [EMAIL PROTECTED] wrote: So, given that the aerodynamic centre of an aircraft can shift based on loading and flight conditions, how can we report that from the FDM back to the 3D model code? Is this something people worked out in a previous thread? I'm assuming that the 3D model and the FDM config file are using the same reference datum for coordinates. First, the aircraft - like any body - rotates about its CG (according to the EOM) - not usually the same as the AC. JSBSim made a change recently that is likely not yet in FlightGear CVS. The lat/lon/alt position now reported by JSBSim (CVS) is the position of the VRP (Visual Reference Point) - i.e. the tip of the prop hub (or similar nose tip location on non-prop aircraft). As long as the aircraft is placed in the scene so that the nose of the 3D model falls at the location reported by JSBSim - everything works out. This assumes that the aircraft model is defined using the correct English units - because all points that the FDM is concerned with are measured in the structural frame and in inches. Yes, we have gone over this ad nauseum in the past. :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Thu, 12 Feb 2004 15:35:59 -0500 David Megginson [EMAIL PROTECTED] wrote: Jon S Berndt wrote: I'm not sure I see how this helps -- the model code still doesn't know where the CG is, so it still doesn't know where the centre of rotation for the model should be. This is precisely *why* the nose is used as a reference point. If the scene graph (is that the right term/subsystem?) places the aircraft at the spot reported by JSBSim -- that is, where JSBSim says the nose of the aircraft is -- the perceived CG of the 3D aircraft as viewed in the scene will fall exactly in the spot that the FDM says it should be at. Look at it this way: the FDM tracks the motion of the CG, and the rotation of the aircraft about the CG. The FDM knows teh location of the CG at any point in time, as well as the euler angles of the aircraft at that point in time. If we were to report the location of this CG to FlightGear, and IF the origin of the 3D model was allowed to shift (by some magic) and always be coincident with the virtual CG in the 3D model, then we'd all always be happy and everything would match up fine. The problem is, the CG shifts and the 3D model coordinate system can't. Since the FDM knows (or can calculate) where the nose is at all times, we simply report the nose location to FlightGear, and by convention FlightGear places the 3D model's nose at the point reported by JSBSim - the CG falls into place as needed IFF the 3D model is defined (or scaled/rotated/translated in the scene graph) correctly as described previously. Takeoffs and landings would look fine, etc. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Thu, 12 Feb 2004 21:19:25 - Vivian Meazza [EMAIL PROTECTED] wrote: Jon S Berndt tells us First, the aircraft - like any body - rotates about its CG (according to the EOM) - not usually the same as the AC. So put the (visual) model origin at or near the CofG - what's the problem? Seems to work OK in practice. Really confused now That is certainly one solution. Then define the VRP in the JSBSim config file (for JSBSim aircraft - I don't know how YASim does this), as coincident with the CG. Then, build your 3D model with the origina at the CG. HOWEVER: when the CG moves due to leanding gear deployment, or dropping loads, or fuel burnoff, the vehicle will rotate about the wrong point, eventually. It won't be real noticeable, but it will be there. That's why we provide the capability for both the 3D model designer and the FDM designer to agree on a common visual reference point, and things can be made much more accurate and allow for dynamic effects. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RAM disk / Unix
Is anyone aware of a RAM disk utility or feature under Unix (specifically, IRIX)? When running a simulation on IRIX we are finding that the disk access is taking too much time at various phase boundaries. It is thought that the use of a RAM disk might help. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RAM disk / Unix
On Tue, 10 Feb 2004 15:06:41 -0800 Andy Ross [EMAIL PROTECTED] wrote: Norman Vine wrote: Jon S. Berndt wrote: It is thought that the use of a RAM disk might help. On Windows I have found that increading disk cache size and / or using memory mapped files is more productive then a DAM disk My interpretation was that their problem was latency, not I/O throughput. The program cooks along using 100% of the CPU, then it needs to load a giant data set off the disk, so it has to wait (making 0% use of the CPU) while the I/O system does its job. If they could ensure that the dataset was in memory they could avoid this delay. Andy Yes, it seems to be a latency issue. Thanks for all the inputs - at least we have somewhere to start, if not viable solutions. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Book recommendations sought
On Wed, 4 Feb 2004 09:39:16 +0100 [EMAIL PROTECTED] (Gerhard Wesp) wrote: Hello, I'm looking for good resources on flight simulations. For the aerodynamics and flight dynamics it seems that Stevens, Aircraft Control and Simulation, is (one of) the standard references. Things which Stevens does not cover but which I need also are the modeling of: - landing gear/ground reaction - engines (jet engines in particular) - propeller - environmental effects like turbulence Greetings: I have heard of the Stevens book but have only glanced at a copy that some friends have. I actually did not find it more useful than some of the other references available. As far as books go there is one that is a very good introduction to the techniques involved in flight simulation (the math and physics part): Physics for Game Developers by David Bourg, O'Reilly Press, ISBN 0-596-6-5. You can get this from Amazon.com for less than $20, I think. For landing gear and ground reactions, go to the JSBSim web site (www.jsbsim.org), click on the Links button at left, and browse the links I have placed there - particularly the ones with a highlighted yellow checkbox. You will find an article on landing gear ground reactions. For propellers, try searching through the NACA archives at naca.larc.nasa.gov. Enter Propeller in the search criteria and take a look. We used some NACA reports as well as some information presented in Barne's W. McCormick's textbook, Aeronautics, Aerodynamics and Flight Mechanics. For turbulence you might try doing a google search on AIAA turbulence and you might get some articles on turbulence. Additionally, I have written some things at the JSBSim web site on our experiences in designing JSBSim which ought to be of help to you, and you could also peruse our source code. Jon Berndt Aerospace Engineer Coordinator, JSBSim Project www.jsbsim.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Autopilot Documentation
On Wed, 4 Feb 2004 21:39:23 - Jim Wilson [EMAIL PROTECTED] wrote: Curt fixed that today. It even works pretty well with the 747. With the one he commited, the gain is higher than what you have (Kp=1.0), a little longer intergration period (Ti=25.0) and the derivator is way down to almost 0 (Td=0.1). I'm wondering if a PID controller is only marginally better than a PI controller. What if you remove the D control altogether? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
