[Flightgear-devel] Adding realistic textures and objects to scenery
Hi everyone, I'm using FlightGear and I've seen the realistic scenery that could be used. Due to the fact that I'm using it as a base for my thesis and the realistic scenery is good new, I'm asking how I can create one for my country, Italy. The main question is how I can add textures and objects to the scenery (I've used the precompiled version for windows). I've tried to use the FlightGear scenery editor, but the program stops every time I try to import a chunk. There's another way to add textures and objects? The question is very important because I use FlightGeat as a 3D virtual trainer for the pilots but impossible if the scenery isn't enough realisic. Hi, Luca PS: I've also tried to use the scenery created for the airport of San Jose, but I'm not able to corretly load it. I've used the two packed files KSJC-Photo-1.0.tar.gz and KSJC-Photo-2.0.tar.gz that I've found in an ftp site. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Cygwin / SimGear / Clouds 3D compile problem
I have managed to get SimGear and FlightGear to compile on Cygwin with XFree86 installed. But I cannot remember how! It may have been by running configure --with-x=no (or equivalent). I will check when I get home. Richard -Original Message- From: Roy Vegard Ovesen [mailto:[EMAIL PROTECTED] Sent: 04 February 2004 9:26 pm To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Cygwin / SimGear / Clouds 3D compile problem On Wed, 4 Feb 2004 22:01:55 +0100, Durk Talsma [EMAIL PROTECTED] wrote: Hi everybody, I'm having the following problem getting SimGear compiled on a Windows XP system, using cygwin: Compilation halts in simgear/scene/sky/clouds3d with a ton of errors about OpenGL functions being redefined elsewhere (see error msgs below). I'm using gcc 3.3.1 (cygming special), which is running on a recent version of cygwin (installed early Januari). I've done a full install of cygwin, including XFree86. I'm wondering if that's related to the problem. The installation manual says not to install XFree86 when using cygwin. Try uninstalling XFree86. If you have XFree86 installed the make process tries to use the GL libs from XFree86 (or something like that), and it looks like that's what's happening. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Faster responsiveness on the turn
On Thu, 05 Feb 2004 00:05:00 +0100, Roy Vegard Ovesen [EMAIL PROTECTED] wrote: I'm thinking that adding a second indicated-turn-rate property that is filtered with a higher bandwidth would be a good solution. I just tried this, and the control system performance boost was quite noticable. :-) This would be beneficial for all turn-rate-based autopilot implementations KAP140, S-TEC and probably many more. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Voice Capability
David Luff wrote: This is potentially quite a can of worms. Currently, the 'smart AI' aircraft that respond to ATC only exist within the remit of the AIMgr in the ATC directory. This is separate from Dave Culp's scripted AI model code, and any other FG static objects code. Additionally, they don't get put into a property tree anywhere for easy viewing. Just to clarify this part a bit, the AIModels don't show their internal status in the property tree just for easy viewing. It is actually used by the animations bound to the aircraft and will (in the end) be used for radar and EWS purposes. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding realistic textures and objects to scenery
Luca Masera wrote: Hi everyone, I'm using FlightGear and I've seen the realistic scenery that could be used. Due to the fact that I'm using it as a base for my thesis and the realistic scenery is good new, I'm asking how I can create one for my country, Italy. The main question is how I can add textures and objects to the scenery (I've used the precompiled version for windows). I've tried to use the FlightGear scenery editor, but the program stops every time I try to import a chunk. There's another way to add textures and objects? The question is very important because I use FlightGeat as a 3D virtual trainer for the pilots but impossible if the scenery isn't enough realisic. The scenery you have seen was probably derived from a commercially available satellite image CD-ROM set of the UK. I'm not sure something like that exsists for Itally (although that would be nice!). But if you want to know more on how to process them, please take a look at the terragear mailinglist archives: http://baron.flightgear.org/pipermail/terragear-devel/ http://baron.flightgear.org/pipermail/terragear-devel/2004-January/000901.html Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Commercial Ticket..
Well Done! All the best, Matt. On 16:11 Wed 04 Feb , Ryan Larson wrote: I just got back from taking my Commercial Pilot, Airplane Multiengine Land checkride, and I am happy to say that I passed! Doing a single engine ILS down to minimums is lots of fun! I took the test in a Piper Aztec (PA23-250). The hardest part of the checkride was trying to get the aircraft back into the hanger without hitting anything. The area in front of the hanger was shear ice. As for the written test, I got a 92. Ryan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Faster responsiveness on the turn indicator
On Wed, 04 Feb 2004 20:18:15 -0500, David Megginson [EMAIL PROTECTED] wrote: Roy Vegard Ovesen wrote: So I shouldn't touch the responsiveness then?!. But rather add a new property with better responsiveness. Out of curiosity, why do you think that the responsiveness should be better? It improves controller performance. But I still don't want to go beyond what is possible in the real world. I've flown briefly behind two small-plane autopilots (one newer, one older) and they were both extremely jerky things. Do you have any reason to believe that the AP you're modelling gets more responsive input than a real TC can give? No, not more respinsive than possible, but I thought that the damping in FlightGear _and_ in real world was only for display purposes. So maybe there would be a possiblility to get the signal before it was damped. After reading the article on the AVWeb site and noting this: The instrument also contains a dashpot in order to slow down the movement of the gimbal ... and The dashpot is replaced by a viscous dampener ... It seems that since the gimbal is dampened it can not output a more responsive signal. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Console messages
Jon Berndt wrote: HOw do we get the console messages to scroll past (for debugging purposes)? --log-level=info (or --log-level=bulk) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Faster responsiveness on the turn indicator
On Wed, 04 Feb 2004 17:18:33 -0800, Andy Ross [EMAIL PROTECTED] wrote: Roy Vegard Ovesen wrote: David Megginson wrote: Originally, the TC responded instantly -- I had to do a fair bit of work adding the slight lag to make it work like a real TC. The lag smooths out the indication a bit. So I shouldn't touch the responsiveness then?!. But rather add a new property with better responsiveness. What are you trying to model? Real autopilots don't have perfect instrumentation. If David is right about the behavior of the turn coordinator, then a real C172-class aircraft simply won't have the fidelity to drive your autopilot. Are you sure you're not trying to fix a bug with the real world? It was not my intention to do something that wouln't be possible in the real world, and this discussion has brought me to the conclusion that the TC is damped by design, and that I need to tweak my controller tuning. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Commercial Ticket..
There's also various scenarios of asymetric thrust - two running engines but one running roughly or not developing as much power for a plethora of possible reasons. These incidents have killed many pilots on take off as they think they have plenty of power, and they do, but the situation easily gets out of hand and shortens the flight :-) All the best, Matt On 20:57 Wed 04 Feb , Jon Berndt wrote: Aha! OK, I would call that engine-out experience. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Commercial Ticket..
Andy Ross wrote: That's no doubt true, but hopefully it's more a lack of tuning than it is a fundamental flaw. For the specific case of YASim: the asymmetric thrust effects should be more or less correct as-is, because it applies the force at the location of the engine. The blue line speed is almost certainly wrong, but should be relatively easy to find by tuning the rudder effectiveness only. The thrust from the good engine is only half the asymmetry -- the other half is the drag from the windmilling engine (until the pilot feathers the propeller). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Faster responsiveness on the turn indicator
Roy Vegard Ovesen wrote: No, not more respinsive than possible, but I thought that the damping in FlightGear _and_ in real world was only for display purposes. So maybe there would be a possiblility to get the signal before it was damped. After reading the article on the AVWeb site and noting this: The instrument also contains a dashpot in order to slow down the movement of the gimbal ... and The dashpot is replaced by a viscous dampener ... It seems that since the gimbal is dampened it can not output a more responsive signal. Exactly. The article went on to state that the damping was added specifically for autopilots. Consider the alternative -- in rough air, the TC is bouncing back and forth from a medium left turn to a right turn every half second or so, and the AP is flexing the ailerons left and right violently trying to compensate. It's critical that you test your AP in light and moderate turbulence and not just in smooth air, since turbulence is the norm for small planes flying below 8,000 ft or so, especially on a summer afternoon. I think that more modern APs, like the STEC, do their own filtering as well -- I've heard people say that they're the first low-end autopilots that you don't have to disengage in light or moderate turbulence. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: multiplayer status and idea
Adam Boggs wrote: Date: Wed, 04 Feb 2004 16:42:26 -0700 From: Adam Boggs [EMAIL PROTECTED] Subject: [Flightgear-devel] multiplayer status and idea (Long) To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] So my thought was since that code is mostly there and does practically all of the things that we would want to do on the server (with some slight differences), why not reuse as much of that code as possible? In doing this, I came up with a basic server in 500 lines of code that simply rebroadcasts in incoming position update to all of the other clients connected to the server (and using plib netSockets). The existing MultiPlayer code is somewhat reusable, but the globals hork it all up. Grr. Anyway, the clients still use the --multiplay options, but all specify the same out ip address/port (to the server) and different in ip address/ports (for receiving updates). I pretty much have this written and have done some basic testing, but need some help: what's the best way to run multiple flightgear instances on a single machine without hosing the CPU and memory? Any suggestions? NOTE: I'm not necessarily trying to start up a new project here, but am more doing this as a prototype/learning experience. If anyone is interested in checking out the code and playing with it once I've got some of the kinks worked out, that would be awesome! Please feel free to educate me on things I might have overlooked, or express opinions on the idea/approach. I still have not fully proved the concept yet either. More testing will tell. Thanks, -Adam Adam, The multiplayer server you have created is what we had in mind when we wrote the multiplayer code. So I think you're on the right track. Some things that I think should be taken into consideration when creating a multiplayer server based on the current code are: - the multiplayer code limited the number of players to ten. This was done because the frame rate drops as the number of multiplayer aircraft being rendered increases. It is highly likely that ten is too many. - the number of aircraft rendered could be minimised by comparing the position of each player and only sending player data to/from other players within a player's visible range or some fixed radius. - the rate the data is sent to a player should be based on the rate the data is received from that player by the server. The rate that a player sends and processes received position updates is specified on the command line, but limited by the frame rate. There is not much point in sending updates more frequently than the player is able to process them. Basically, when the server receives a packet from a player, it should reply with the cached positions of other players. I had one day hoped to develop a Flightgear multiplayer server along the lines that you're experimenting with, but couldn't find the time. So it would be good to see someone doing this. Regards, Duncan. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [OT] Commercial Ticket..
The thrust from the good engine is only half the asymmetry -- the other half is the drag from the windmilling engine (until the pilot feathers the propeller). Good point. That's something that's also not too hard to fix. I could not (yet) find my NACA report on the light twin, but here are some interesting numbers: Cn_beta for some aircraft (per rad): Navion: 0.071 (Raymer ?) C-172p (JSBSim, from Raymer): -0.349 -0.0205 0 0 0.349 0.0205 This is roughly 0.06. Cherokee (McCormick): 0.067 C-310 (JSBSim): 0.1444 This is twice as high as the other aircraft. It could be due in some measure to a larger vertical tail, but I wonder if perhaps this value is too high? When coupled with the correction of drag due to prop, then I suspect we'll be a lot closer. Thanks for pointing this out, and I am going to submit this to our bug tracker so it doesn't get lost. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Commercial Ticket..
Jon Berndt wrote: How do we not work well in this case? Do you notice a specific inadequacy? Yes -- neither JSBSim nor YASim does a good job generating drag for a windmilling prop. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Commercial Ticket..
Jon Berndt wrote: The thrust from the good engine is only half the asymmetry -- the other half is the drag from the windmilling engine (until the pilot feathers the propeller). Good point. That's something that's also not too hard to fix. I could not (yet) find my NACA report on the light twin, but here are some interesting numbers: Is this the one: http://www.dfrc.nasa.gov/DTRS/1972/ LONGITUDINAL AERODYNAMIC CHARACTERISTICS OF LIGHT, TWIN-ENGINE, PROPELLER-DRIVEN AIRPLANES http://www.dfrc.nasa.gov/DTRS/1972/PDF/H-646.pdf Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Commercial Ticket..
Jon Berndt wrote: Good point. That's something that's also not too hard to fix. I tried to fix this problem in JSBSim a year or two ago, and I seem to recall that no one on the flight model list could quite figure out how to code it back then. I also took a stab at YSBSim, and failed just as miserably. Neither model is set up to have the propeller driving the engine rather than the engine driving the prop. The rule of thumb for pilots is that a windmilling propeller creates as much drag as a disc of the same size, but that's too vague for modelling (plus, it doesn't handle the partial-windmilling situation). What we need to figure out is how much drag we get from the propeller turning the crankshaft, compressing the cylinders, and spinning the accessory drives (vacuum pump, alternator, etc.). I could not (yet) find my NACA report on the light twin, but here are some interesting numbers: Cn_beta for some aircraft (per rad): Navion: 0.071 (Raymer ?) C-172p (JSBSim, from Raymer): -0.349 -0.0205 0 0 0.349 0.0205 This is roughly 0.06. Cherokee (McCormick): 0.067 C-310 (JSBSim): 0.1444 This is twice as high as the other aircraft. It could be due in some measure to a larger vertical tail, but I wonder if perhaps this value is too high? When coupled with the correction of drag due to prop, then I suspect we'll be a lot closer. Twins and taildraggers need a lot of rudder authority; tricycle-gear singles, not so much. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Commercial Ticket..
On 2/5/04 at 2:36 AM David Luff wrote: On 2/4/04 at 8:24 PM Curtis L. Olson wrote: Also, speaking of FDM's. The current JSBSim C172 in cvs seems to have an engine that can break 3000 rpm in level cruise (150-160kts). That's clearly way too high for C172. I'm guessing from the engine rpm's that this is an engine or prop modeling problem??? It seemed to go up in power after the last JSBSim sync, but I couldn't see anything obvious changed. However, maxHP is set to 160HP in the spec file, but to 200HP in the constructor, so my suspiscion (sp?) is that somehow the 160 value isn't getting picked up anymore. This is indeed what is happening. Changing line 89 in FGPiston.cpp from MaxHP = 200; to MaxHP = 160; will cure it as a temporary measure. I guess someone who knows JSBSim well needs to look at why the config file value isn't getting picked up anyone. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: multiplayer status and idea
On Thu, 5 Feb 2004, Duncan McCreanor wrote: Some things that I think should be taken into consideration when creating a multiplayer server based on the current code are: - the multiplayer code limited the number of players to ten. This was done because the frame rate drops as the number of multiplayer aircraft being rendered increases. It is highly likely that ten is too many. - the number of aircraft rendered could be minimised by comparing the position of each player and only sending player data to/from other players within a player's visible range or some fixed radius. - the rate the data is sent to a player should be based on the rate the data is received from that player by the server. The rate that a player sends and processes received position updates is specified on the command line, but limited by the frame rate. There is not much point in sending updates more frequently than the player is able to process them. Basically, when the server receives a packet from a player, it should reply with the cached positions of other players. I had one day hoped to develop a Flightgear multiplayer server along the lines that you're experimenting with, but couldn't find the time. So it would be good to see someone doing this. I know I'm not actually involved in FlightGear development, but please bear with me anyway :) When it comes to multi-player flight sim, one should keep in mind the virtual air traffic control networks out there, like VATSIM http://www.vatsim.net/, IVAO http://www.ivao.org/, and so on. These all have an existing server infrastructure with existing protocols. Now, this doesn't in any way invalidate other multiplayer approaches. But if interoperability with the above-mentioned systems were available, that would make Flightgear an option for those who want to fly in such a simulated controlled environment; and also open the door for flying together with users of other sims. Regards, Duncan. Best wishes, // Christian Brunschen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Voice Capability
No not yet. I have about 25hrs and need to sit the written exams for Flight Planning, Nav, Met, Human Factors and Aircraft Technical. I have sat and passed RT written and Practical and Air Law so far... Hopefully I'll get my PPL sometime later this year but I'm in no rush really. Also, like Curt I have an imminent 'family enlargement event' which will slow everything down a little - especially anything involving money :-) I'll let you all know when I do get my PPL, since I probably wouldn't be doing it were it not for this list. I've already discussed starting IMC training almost immediately after I get the PPL :-) All the best, Matt. On 16:33 Wed 04 Feb , David Megginson wrote: So you have your PPL, then? If so, then double congrats and welcome to the skies. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Commercial Ticket..
David Luff wrote: I guess someone who knows JSBSim well needs to look at why the config file value isn't getting picked up anyone. I guess it would be a good idea to initialize the various variable *before* the get initialized by the configuration file ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Voice Capability
I was sitting my RT Practical. It's a basic test of skill on the radio and ability to request and act on clearances along a preset route etc. Hence the near failure for not requesting SVFR into a zone at or before 15miles/5 min. All the best, Matt. On 16:36 Wed 04 Feb , David Megginson wrote: SVFR must mean something different in the UK, unless you were doing your practical with less than three miles visibility or a very low ceiling. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Commercial Ticket..
David Luff wrote: I guess someone who knows JSBSim well needs to look at why the config file value isn't getting picked up anyone. Done. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Faster responsiveness on the turn indicator
David Megginson writes: Roy Vegard Ovesen wrote: No, not more respinsive than possible, but I thought that the damping in FlightGear _and_ in real world was only for display purposes. So maybe there would be a possiblility to get the signal before it was damped. After reading the article on the AVWeb site and noting this: The instrument also contains a dashpot in order to slow down the movement of the gimbal ... and The dashpot is replaced by a viscous dampener ... It seems that since the gimbal is dampened it can not output a more responsive signal. Exactly. The article went on to state that the damping was added specifically for autopilots. Consider the alternative -- in rough air, the TC is bouncing back and forth from a medium left turn to a right turn every half second or so, and the AP is flexing the ailerons left and right violently trying to compensate. It's critical that you test your AP in light and moderate turbulence and not just in smooth air, since turbulence is the norm for small planes flying below 8,000 ft or so, especially on a summer afternoon. I think that more modern APs, like the STEC, do their own filtering as well -- I've heard people say that they're the first low-end autopilots that you don't have to disengage in light or moderate turbulence. I don't know if this has been been incorporated into Aircraft autopilot's but on any *good* marine autopilot the amount of damping is adjustable so as to be able to tune the AP for the current enviroment Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [OT] Commercial Ticket..
David Luff wrote: I guess someone who knows JSBSim well needs to look at why the config file value isn't getting picked up anyone. Done. Erik smacks forehead Thanks, Erik! Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Aperiodic Texture Mapping
Someone interested in Eye Candy might be able to use this technique http://www.dgp.toronto.edu/people/stam/reality/Research/pdf/R046.pdf to make much nicer Water and Cloud textures for FGFS Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] xmlauto calculations
In xmlauto.cxx, from line 456: // Calculates proportional error: ep_n = beta * r_n - y_n; if ( debug ) coutep_n = ep_n; if ( debug ) coutep_n_1 = ep_n_1; // Calculates error: e_n = r_n - y_n; if ( debug ) cout e_n = e_n; // Calculates derivate error: ed_n = gamma * r_n - y_n; if ( debug ) cout ed_n = ed_n; I think the proportional error and derivate error need some parentheses around the subtraction, ep_n = beta * (r_n - y_n). Alternatively, we can figure e_n first, then use e_n in the other two calculations. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] xmlauto calculations
David Culp wrote: In xmlauto.cxx, from line 456: // Calculates proportional error: ep_n = beta * r_n - y_n; if ( debug ) coutep_n = ep_n; if ( debug ) coutep_n_1 = ep_n_1; // Calculates error: e_n = r_n - y_n; if ( debug ) cout e_n = e_n; // Calculates derivate error: ed_n = gamma * r_n - y_n; if ( debug ) cout ed_n = ed_n; I think the proportional error and derivate error need some parentheses around the subtraction, ep_n = beta * (r_n - y_n). Alternatively, we can figure e_n first, then use e_n in the other two calculations. I thought this initially too, but Roy assures me that it is correct as is. Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] xmlauto calculations, part deux
When I zero out my integral and derivative terms, it seems that the proportional term is doing nothing. Looking through the code I see that the variable proportional is initialised to false, and I can't see where it's set to true. (same for the variable integral). Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] xmlauto calculations, part deux
David Culp wrote: When I zero out my integral and derivative terms, it seems that the proportional term is doing nothing. This can happen because of the anti-integrator wind up logic. If the magnitude of the proportional output is outside of the min/max range, it get's set to zero. In these cases, adding some integral component will get things moving. Part of the reason for doing this is so that algorithm doesn't slam the controls full stop when the autopilot is initially activated and there is a large error term to overcome. Looking through the code I see that the variable proportional is initialised to false, and I can't see where it's set to true. (same for the variable integral). These are part of the old controller that i used as an initial test. They aren't even part of the the official PID controller class anymore. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Commercial Ticket..
David Megginson wrote: I tried to fix this problem in JSBSim a year or two ago, and I seem to recall that no one on the flight model list could quite figure out how to code it back then. I also took a stab at YSBSim, and failed just as miserably. Neither model is set up to have the propeller driving the engine rather than the engine driving the prop. I just hacked up a test rig for the propeller code. Feeding it numbers from the Cub's propeller (my guess for the best tested of the YASim propellers), and using 40 KTAS @ 4000 MSL as a base environment, I came up with the following: Windmill (i.e. zero torque) speed is 450 RPM. Windmill drag at that speed is 47N, about 10.5 pounds of force, or about 5 equivalent horsepower at that airspeed. The rule of thumb for pilots is that a windmilling propeller creates as much drag as a disc of the same size, but that's too vague for modelling What's the drag of a 0.63 square meter (area of a 0.9m disc) flat plate at 40 knots? I wouldn't be shocked if it was in the realm of 10 lbs or so. A pickup truck (about as close to a flat plate as you can get, heh) at the same speed has perhaps 10x the surface area and requires just about 50 HP of engine power to cruise. Certainly we're within the right order of magnitude, anyway. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cygwin / SimGear / Clouds 3D compile problem
It would be cool if that's possible, because there are probably more people like me, who'd like to keep XFree86 and still be able to compile FlightGear/ SimGear. Thanks, Durk On Thursday 05 February 2004 09:33, Richard Bytheway wrote: I have managed to get SimGear and FlightGear to compile on Cygwin with XFree86 installed. But I cannot remember how! It may have been by running configure --with-x=no (or equivalent). I will check when I get home. Richard -Original Message- From: Roy Vegard Ovesen [mailto:[EMAIL PROTECTED] Sent: 04 February 2004 9:26 pm To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Cygwin / SimGear / Clouds 3D compile problem On Wed, 4 Feb 2004 22:01:55 +0100, Durk Talsma [EMAIL PROTECTED] wrote: Hi everybody, I'm having the following problem getting SimGear compiled on a Windows XP system, using cygwin: Compilation halts in simgear/scene/sky/clouds3d with a ton of errors about OpenGL functions being redefined elsewhere (see error msgs below). I'm using gcc 3.3.1 (cygming special), which is running on a recent version of cygwin (installed early Januari). I've done a full install of cygwin, including XFree86. I'm wondering if that's related to the problem. The installation manual says not to install XFree86 when using cygwin. Try uninstalling XFree86. If you have XFree86 installed the make process tries to use the GL libs from XFree86 (or something like that), and it looks like that's what's happening. -- Roy Vegard Ovesen ___ 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] Aperiodic Texture Mapping
Norman Vine wrote: Someone interested in Eye Candy might be able to use this technique http://www.dgp.toronto.edu/people/stam/reality/Research/pdf/R046.pdf Creating these texture would not be much of a problem to me (I've done something quite similar for adjacent cloud textures of a different kind (smooth transition from few clouds to scattered to broken. The question is, how do we implement the required code change. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Commercial Ticket..
Andy Ross wrote: Windmill (i.e. zero torque) speed is 450 RPM. Windmill drag at that speed is 47N, about 10.5 pounds of force, or about 5 equivalent horsepower at that airspeed. When you shut down the engine in YASim, the propeller does not windmill -- it just slowly spins down and stops. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Commercial Ticket..
David Megginson wrote: Andy Ross wrote: Windmill (i.e. zero torque) speed is 450 RPM. Windmill drag at that speed is 47N, about 10.5 pounds of force, or about 5 equivalent horsepower at that airspeed. When you shut down the engine in YASim, the propeller does not windmill -- it just slowly spins down and stops. I see the same thing in the JSBSim c172, except that it spins down rather quickly and stops. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Commercial Ticket..
Curtis L. Olson wrote: I see the same thing in the JSBSim c172, except that it spins down rather quickly and stops. I've never shut down an engine in flight in real life, but from reports I've heard, you have to bring a 172 almost to the stall to stop the propeller from windmilling; once stopped, however, it will stay stopped at a more reasonable speed. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Commercial Ticket..
On 2/5/04 at 7:10 PM David Megginson wrote: Curtis L. Olson wrote: I see the same thing in the JSBSim c172, except that it spins down rather quickly and stops. I've never shut down an engine in flight in real life, but from reports I've heard, you have to bring a 172 almost to the stall to stop the propeller from windmilling; once stopped, however, it will stay stopped at a more reasonable speed. JSBSim - very crude currently - hardwired -1.5 HP resistive power when engine cutoff but still windmilling. This is probably on the very low side - would expect at least 5% of max engine power to be used overcoming friction OTOH, so possibly prop code not windmilling propellor enough? LaRCsim - uses published friction model, but can't remember offhand if rubbing friction only or rubbing + pumping. Assumes fully warm oil I think. Should port it to JSBSim. Note that both the above only cut in when engine cut since power correlation used is for shaft power - by definition it gives zero at (running) idle. Need to check the whole windmilling thing re prop and engine. Closing the throttle should increase pumping losses and help to stop the engine - is this standard procedure for a definately dead one? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding realistic textures and objects to scenery
On Thursday 05 Feb 2004 9:06 am, Erik Hofman wrote: Luca Masera wrote: Hi everyone, I'm using FlightGear and I've seen the realistic scenery that could be used. snip The scenery you have seen was probably derived from a commercially available satellite image CD-ROM set of the UK. I'm not sure something like that exists for Italy (although that would be nice!). Probably a slip of the tongue, as it were, but the imagery is aerial photography, rather than satellite. http://www2.getmapping.com/Catalog/ProductDetails.asp?ProductId=3521 12.5cm resolution at a price of 70.60 GBP per sq km. I'm drooling and sighing at the same time. Messy. Jonathan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding realistic textures and objects to scenery
On 2/6/04 at 1:33 AM Jonathan Richards wrote: 12.5cm resolution at a price of 70.60 GBP per sq km. I'm drooling and sighing at the same time. Messy. If you want to play with photography of that sort or resolution, parts of Maine are available for download in colour at about 15cm (actually 0.5 ft) - see http://apollo.ogis.state.me.us/catalog/catalog.asp?state=2extent=24k for the data and http://megisims.state.me.us/website/orthomap/viewer.htm for an online viewer. Taken in spring with no leaves on deciduous trees, which probably accounts for the rather subdued, brownish colour of a lot of it. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] GA Chute
Seen this? http://researchernews.larc.nasa.gov/archives/2002/121302/Parachute.html# Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
