[Flightgear-devel] Re: [Flightgear-users] Live-CD
Hi Curtis, I post my answers to the list as your questions where so good that they deserve to be answered in public :-) Cool, it seems to actually work on my machine! Great! 1. How big is the source for the CD? This might be interesting to have access to for people who would want to build a us-centric cd that defaults to english and defaults to usa keybindings. The source is the Knoppix CD. I just copied the contents of the original Knoppix CD into a directory, rearranged all the things and made a new CD-Image. There is no real source code here... I thought a while about internationalization of this CD and came to the conclusion that it can only be a compromize. There can only be one default and people with a different locale have to reconfigure. If we try to make this right for everybody we have to provide an extra CD image for every locale. Maybe we should create an extra CD for at least the 3-5 largest locales on our lovely planet. This includes Switzerland because _I_ live here :-) 2. It would be interesting to have flightgear startup automatically rather than just giving an icon to click on. Yes, this would be useful. I read about a program FGKicker or so, which can be used for choosing all the settings before starting FG. Maybe I should add that. 3. It would also be interesting to have a webbrowswer on board with an icon (or icons) to click on for the various documenation. Try opening the help from within FG. There is Konqueror onboard. It can even embed nicely the PDF-Documentation. 4. It would be interesting to possibly incorporate fgrun.sf.net, or have the app start up with --enable-game-mode (which == full screen.) I tried fullscreen that but it does not look good. It flickers horrible at startup and you cant see the browser when you open the help within FG. 5. You also need the following button: [ ] Upgrade your system to Linux and install FlightGear Where do you want to have it? Somewhere in the cockpit panel or in the menu? :-) 7. Another thing that would be nice would be to have the ability to script out a bunch of demo flights with different aircraft, different locations, different times, different weather, etc. Much of the infrastructure for that is in place, but we could probably do some more work to make that easier. I am pretty new to FG and know almost nothing about it. May someone from the list can give me some directions and/or create some example demo flight data for me? Pretty cool, good work! Dito. I am very impressed by the flightgear project and happy to be able to give something back. Greetings Ronny ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
Hi Curt Curtis L. Olson writes FWIW (and hopefully this doesn't mean major breakage) I've been considering some changes to the autopilot infrastructure to make it more flexible. For instance, we (or at least I) could really use a mode to hold speed with pitch, or hold pitch with elevator. And it would be nice to be able to support some of the more advanced FCS concepts that right now are only accessible to JSBSim models (things like yaw dampers, and other fly-by-wire type stuff.) Has someone been playing with the 737 autopilot/autothrottle ?. LOL Also Yaw dampers have been around a little longer than fly by wire(707 vintage). Regards, Curt. Cheers Innis The Mad Aussi _ E-mail just got a whole lot better. New ninemsn Premium. Click here http://ninemsn.com.au/premium/landing.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Changing a model format
Hi Tim Tim Jelliffe writes Hi guys, I have a general question regarding the creation of a model. I have been working on creating a model of a Learjet 55, using CATIA V5. This is mainly because I used this during my degree and am basically familiar with it. I am also determined to have a model which is as close to the real thing as possible. This means if the fuselage is 2m in diameter, I want the model to have a 2m diameter fuselage as well! CATIA is awesome for this. You have just discovered the trade off we all have to make between realism and polygon count. It is not the size of the model but the number of surfaces to make the model that count.E.G: the circle for the fuselage can have 8 points 40 points or 100 points and though the 100 point one will look great it would just bring the sim to a grinding halt.So we need to choose what we think looks reasonable and does not load the sim and this applies to every component on the model. If you already know this then just consider this the ramblings of an old man and ignore it. Tim J cheers Innis The Mad Aussi _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Changing a model format
using CATIA V5. This is a CAD program and not a modeller, so while you can use it, it is not what CATIA was created for. I guess that CATIA does things without polygons internally and uses splines, solid objects, booleans etc instead. Probably it just creates polygons from it (tesselates/polygonises) when you export to wrl. Of the formats you mentioned, wrl is best. Using another format would not make it faster at all. That you see something in FGFS means it is polygonised in the wrl file, as it should be. Like the others said, the problem is the number of polygons it created. I would guess that at some stage, probably during export, it creates the polys from the splines etc and normally it should ask you how fine the mesh should be. This is where you choose rendering speed in FGFS! This means if the fuselage is 2m in diameter, I want the model to have a 2m diameter fuselage as well! This can be done in any serious modeller. http://members.optusnet.com.au/~tjelliffe/Learjet55.jpg Nice. The problem is that CATIA works with surfaces, as you can see in the pic, but things like blender and ac3d seem to use nodes. ? This makes it hard to convert into .ac format. Converting to ac would not make it faster. BTW, if you look at one airplane close up, LoD would not help either. That is not to say you should not model LoDs later (you should ;-)), but first solve the current problem. Try to find out the number of polygons in the wrl. One way is to get PPE (PrettyPolyEditor) and load the model nd then look into the conolse window. Tim J Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-users] Live-CD
Ronny Standtke wrote: Hi Curtis, I post my answers to the list as your questions where so good that they deserve to be answered in public :-) 2. It would be interesting to have flightgear startup automatically rather than just giving an icon to click on. Yes, this would be useful. I read about a program FGKicker or so, which can be used for choosing all the settings before starting FG. Maybe I should add that. I would think it would be best to use FlightGear as the window manager. You could acomplish this: http://baron.flightgear.org/pipermail/flightgear-devel/2002-March/006012.html Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re:Changing a model format
Tim Jelliffe wrote: Hi guys, I have a general question regarding the creation of a model. I have been working on creating a model of a Learjet 55, using CATIA V5. This is mainly because I used this during my degree and am basically familiar with it. I am also determined to have a model which is as close to the real thing as possible. This means if the fuselage is 2m in diameter, I want the model to have a 2m diameter fuselage as well! CATIA is awesome for this. The problem is that CATIA works with surfaces, as you can see in the pic, but things like blender and ac3d seem to use nodes. This makes it hard to convert into .ac format. I can save the file as either wrl, stp, igs, or cgr file formats. I have tried saving it as a wrl format, and using this directly in flightgear. The file size is around 2 Mb, and the frame rate drops from ~20 to ~2 fps. I have also tried using the demo version of AC3D, and saving directly into .ac format. This still gives very big files though. If you can export the model in VRML2, try to use, if you can, 3DSMax. You can import the model and reduce the number of polygons and export it in the ASE format. I've made the same thing with my model of MB339, generating a file of 1.5 Mb, and it looks great in FlightGear and the frames doesn't drop. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-users] Live-CD
Erik Hofman [EMAIL PROTECTED] wrote: I would think it would be best to use FlightGear as the window manager. You could acomplish this: http://baron.flightgear.org/pipermail/flightgear-devel/2002-March/006012.html The idea is correct, the terminology not ;-) The window manager simply is an X client as everyone else - despite the fact that the other clients agree on him to be the master of window positions. On modern Linux distributions you would modify the master Xinit configuration file '/etc/X11/xinit/xinitrc', Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-users] Live-CD
Op woensdag 21 januari 2004 10:10, schreef Erik Hofman: Ronny Standtke wrote: Hi Curtis, I post my answers to the list as your questions where so good that they deserve to be answered in public :-) 2. It would be interesting to have flightgear startup automatically rather than just giving an icon to click on. I would think it would be best to use FlightGear as the window manager. You could acomplish this: http://baron.flightgear.org/pipermail/flightgear-devel/2002-March/006012.ht ml That's how I used to run flightgear. In my bin folder I placed a script startfgfs that I could start from the console, which would start the x server, at a very low resolution and start flight gear. Of course, I could still use the startx for all the other things. Because no window manager runned (resources) and because my resolution was smaller (800*600) I got a noteable increase in frame rate. I used this procedure on a i810 celeron 400Mhz with 128Mb ram and got a frame rate of 8 fps. Still not very fast, but I think that machine was way under the specs for a program like flight gear. Pieter ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
On Tue, 20 Jan 2004 15:09:02 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: Sounds reasonable. Is the current height above terrain in the property tree someplace? FWIW (and hopefully this doesn't mean major breakage) I've been considering some changes to the autopilot infrastructure to make it more flexible. For instance, we (or at least I) could really use a mode to hold speed with pitch, or hold pitch with elevator. And it would be nice to be able to support some of the more advanced FCS concepts that right now are only accessible to JSBSim models (things like yaw dampers, and other fly-by-wire type stuff.) Regards, Curt. Let me share my thoughts about the autopilot: * I would like to see the autopilot move from c++ code into the instrument configuration xml-files. * The autopilot should get input from other instruments (airspeed indicator, altimeter, attitude indicator, etc.), and not from /position/altitude-ft, /velocities/..., etc. That way the wing-leveler would be unuseable if the attitude indicator was broken. Failures in the underlying instruments and systems would affect the autopilot. * A PID-controller that can be accessed from the instrument configuration files. This could be used to build the autopilot controller structure as an instrument. This means that one could build different autopilot instruments for different aircraft. The Cub for example might have a simple autopilot with only heading hold and altitude hold. And because the Cub does not have an attitude indicator instrument, a wing-leveler would not be available. And in addition the heading hold would not be allowed to use roll information. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Testing help wanted (please!)
On 1/20/04 at 9:59 PM Melchior FRANZ wrote: * David Luff -- Tuesday 20 January 2004 19:54: As regards the crashes, at one point I was getting an inexpicible crash right at startup, which gdb indicated was from sgLoad3dModel called from AIMgr::init. I can't understand why it would crash there, and it only happened on Linux, and from one CVS tree. I'd be interested in whether anyone else gets it. Yes, I got that same crash on Linux. I'm investigating ... Hi Melchior, Thanks for looking into this. I don't see this on Cygwin at all. On Linux, I am getting it sometimes on all of my CVS trees now I've tried some more, but not all the time - If I start the program 3 times it might only crash 2 times. I've put another tar file up at http://www.nottingham.ac.uk/~eazdluf/ATCPatches040121.tar.gz This has fixes in to cure crashing that could occur when the user was on a straight-in approach following ATC contact. I *think* I've got all the crashes out of it now except for the startup one, which has me stumped at the moment. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] We could need a cvs directory for the world scenery files
On 1/20/04 at 4:52 PM kreuzritter2000 wrote: Hello, Yesterday we discussed on the flightgear irc channel about the need of a cvs directory for the world scenery. A cvs directory for this would help adding new 3d buildings (*.ac files etc.) to the world scenery. At the moment we can do this only for the area around San Fransisco via the base package (data directory) but not for other areas of the world. So managing the rest of the world via cvs too could help a lot. If bandwith costs is a problem, we could create separate cvs directorys for every scenery package like e000n00, e000n10, wXXXnXX etc. to save bandwith costs. This way volunteers could easily work on their favourite area and add improvements like 3d real world buildings to the world scenery. What is your opionion about that? Absolutely, something like this is pretty essential IMHO. Not just for 3d objects, but also stuff like airports facilities files, basically anything redistributable that comes in small, geographically dispersed packages, and is created manually rather than automatically. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Testing help wanted (please!)
On 1/20/04 at 9:04 PM Erik Hofman wrote: I've set up the AIModel code the publish it's internals just like a real FDM (but only the ones that are available) and told the aircraft loader routine to use /sim/ai/model[] as it property root. I think something similar would be a good thing for your code also. Yes, I'll have to make it play nice with the rest of FlightGear at some point. There's a way to go just writing the core though - in particular getting ai aircraft to improve in-air spacing with the user and other ai aircraft. BTW. I'll test the code, but probably not until tomorrow. Thanks! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Flight Gear - Brasil
Hi Curtis, I am installing Flight Gear and Iwould like to know if there is someone from Brasil that is currently working on the Flight Gear Project. Best Regards, Carlos Renato ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Testing help wanted (please!)
David Luff wrote: On 1/20/04 at 9:04 PM Erik Hofman wrote: I've set up the AIModel code the publish it's internals just like a real FDM (but only the ones that are available) and told the aircraft loader routine to use /sim/ai/model[] as it property root. I think something similar would be a good thing for your code also. Yes, I'll have to make it play nice with the rest of FlightGear at some point. There's a way to go just writing the core though - in particular getting ai aircraft to improve in-air spacing with the user and other ai aircraft. BTW. I'll test the code, but probably not until tomorrow. Just to let you know, I saw nothing odd with that particular piece of code, and got it working (at least) three times today. Maybe something is fishy with gcc/libstdc etc.? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-users] Live-CD
I would think it would be best to use FlightGear as the window manager. You could acomplish this: http://baron.flightgear.org/pipermail/flightgear-devel/2002-March/006012.ht ml I think it is at least problematic to run FlightGear without a window manager. The help system is not integrated into FlightGear. How do you switch to your browser and back into Flightgear when you have no window manager? It would be also a bit problematic to include other programs like the mentioned fgkicker. The worst thing: You could not use the speaker icon and actually had to use the knob at your stereo to adjust the sound volume. :-) Greetings Ronny ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
Roy Vegard Ovesen wrote: Let me share my thoughts about the autopilot: * I would like to see the autopilot move from c++ code into the instrument configuration xml-files. This is my general plan. Right now I have the autopilot config in a separate .xml file * The autopilot should get input from other instruments (airspeed indicator, altimeter, attitude indicator, etc.), and not from /position/altitude-ft, /velocities/..., etc. That way the wing-leveler would be unuseable if the attitude indicator was broken. Failures in the underlying instruments and systems would affect the autopilot. Yup, each autopilot component will be able to take input from any property, and output to any other property. As long as we have the instrument values modeled and placed in the property tree, we can use them. The trick will be for someone who knows a little about autopilots to be able to tell us what inputs drive what functions. * A PID-controller that can be accessed from the instrument configuration files. This could be used to build the autopilot controller structure as an instrument. This means that one could build different autopilot instruments for different aircraft. The Cub for example might have a simple autopilot with only heading hold and altitude hold. And because the Cub does not have an attitude indicator instrument, a wing-leveler would not be available. And in addition the heading hold would not be allowed to use roll information. I've been hacking things out here a bit this evening and here's what I've come up with for a simple proportional wing leveler. All of this is in a state of flux, is subject to change, and only exists on my local HD. I'll intersperse some explanatory comments ... autopilot.xml: proportional nameWing Leveler (Turn Coordinator based)/name enable !-- enable this component when the defined property equals the specified value -- prop/autopilot/locks/heading/prop valuewing-leveler/value /enable input !-- the input source -- prop/instrumentation/turn-indicator/indicated-turn-rate/prop /input target !-- what we want to drive the input value to, this can also be a property name -- value0.0/value /target output !-- the output property name -- prop/controls/flight/aileron/prop /output config !-- output = (target - input) * factor + offset -- factor0.5/factor !-- I don't know if it makes sense to offer an offset here, but it's easy to add and I've seen similar things other places in the code so I stuck it in. -- offset0.0/offset post !-- I might be better off moving this to the output section, but this lets us clamp the output result -- clamp min-1.0/min max1.0/max /clamp /post /config /proportional So if you set /autopilot/locks/heading = wing-leveler, this component will become active and start driving the turn rate to zero using the ailerons. Here's a more complicated two stage heading bug follower (still using simple proportional control): !-- this first stage calculates a target roll degree based on the difference between our current heading and the heading bug heading. It writes the result to a temporary property name. This temp property is the input to the second stage. Both stages use the same enable property and value. -- proportional nameHeading Bug Hold (DG based) Calc Target Roll/name enable prop/autopilot/locks/heading/prop valuedg-heading-hold/value /enable input prop/instrumentation/heading-indicator/indicated-heading-deg/prop /input target prop/autopilot/settings/heading-bug-deg/prop /target output !-- I just made up this property name -- prop/autopilot/internal/target-roll-deg/prop /output config !-- this is an obvious hack that I'm not real comfortable with. It maps the resulting error term to +/- 180 by adding or subtracting 360 until the value get's into that range. -- pre one-eightytrue/one-eighty /pre factor1.5/factor offset0.0/offset post clamp min-30.0/min max30.0/max /clamp /post /config /proportional !-- this second stage calculates the aileron deflection needed to achieve the previously calculated target roll degrees. -- proportional nameHeading Bug Hold (DG based) (Calc target ailerons)/name enable prop/autopilot/locks/heading/prop valuedg-heading-hold/value /enable input prop/orientation/roll-deg/prop /input target !-- this matches the output property name from the first stage -- prop/autopilot/internal/target-roll-deg/prop /target output prop/controls/flight/aileron/prop /output config
RE: [Flightgear-devel] Proposed change to Terrain Following control
* The autopilot should get input from other instruments (airspeed indicator, altimeter, attitude indicator, etc.), and not from /position/altitude-ft, /velocities/..., etc. That way the wing-leveler would be unuseable if the attitude indicator was broken. Failures in the underlying instruments and systems would affect the autopilot. This is something that has been on my mind for a while, too. I wouldn't say that the inputs to the FCS or A/P should be from the instruments always. For my uses, in JSBSim, we might want to have a sensor class that can be failed in one or more ways, and biased, or massaged in some way so as to model a real sensor reading instead of using (as you have pointed out) the perfect EOM state data all the time. With some creativity, in the JSBSim case with our FCS components and the sensor class, maybe we could eventually model independent sensors feeding into quad redundant FCS strings. Not sure we could vote a signal out using the general purpose system we have. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
