[Flightgear-devel] ASTER DEMs
Hi guys! I downloaded ASTER DEM and play with it Nice resolution (30m) but there are so many holes to use it So fightgear/terragear gurus maybe you tell me is there in dem library some tools to approximate aster dem data with gtopo30 data to eliminate holes? Another question: now we have tile size = 1/8 degree. but when you deal with this high resolution data you have to load smaler tiles to have good frame rate where should I search terragear/flightgear code to have tile size 1/16 or 1/32 degree. here as I got another problem tile names. and finnaly about LOD in tiles. Is there any plans or thoughts to implement it? Thanx in advance Bye ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ASTER DEMs
Roman Grigoriev writes: I downloaded ASTER DEM and play with it Nice resolution (30m) but there are so many holes to use it So fightgear/terragear gurus maybe you tell me is there in dem library some tools to approximate aster dem data with gtopo30 data to eliminate holes? It is currently commented out but see src / lib / dem interpolate() It may still work and in any case shouldn't need much to fix there is also an Interpolate in the Lib/Array class also commented out Another question: now we have tile size = 1/8 degree. but when you deal with this high resolution data you have to load smaler tiles to have good frame rate where should I search terragear/flightgear code to have tile size 1/16 or 1/32 degree. The US scenery is made with 30 meter DEM's so things should work OK the least squares fit process removes many points and is 'tunable' if need be Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] re: question
David Megginson writes: [moving to the list] Curtis L. Olson writes: This makes it difficult to just define the power source for the navcom in the instrument panel config file. We need to kill the audio when the power goes out and not have the autopilot continue to track something that is alledgedly off. Right -- the autopilot has to take its input from the nav radio, not from the actual /position and /orientation properties. That's important not only to deal with power-out situations, but to model VORs realistically. The autopilot doesn't have to know where the nav radio is drawing its power from, though, as long as it knows when the nav radio is supplying information. Related to the electrical system there are other non-panel things though to be concerned about as well. For instance, if electrical bus #1 isn't powered, the flaps won't move and the fuel pump won't work. This has flight model implications. Likewise, if the master-bat switch is off and the master-alt switch is off (or the engine is not running) and there is no external power, then the starter motor won't engage. I could hardcode the bus property names provided by the c172 electrical system, but this hoses us for other aircraft. Yes, this is out, I was just throwing it in there for contrast. They should be parameterized in the XML instrument config file so that the aircraft file can plug the right instrument into the right bus. Note how some instruments are already parameterized to use different engines or receivers. I never quite got the hang of your xml parameters ... Another solution that I am favoring at the moment is to allow an arbitrary list of property names for a node. This way avionics-bus-1 could advertise to: /systems/electrical/outputs/avionics-fan-power /systems/electrical/outputs/gps-mfd-power /systems/electrical/outputs/hsi-power /systems/electrical/outputs/navcom-power[0] /systems/electrical/outputs/audio-panel-power[0] I prefer that the GPS connect itself to avionics-bus-1, or more specifically, that the aircraft config file connect the GPS to avionics-bus-1. That's nice for designers, because it will feel a little like actually building an aircraft. Some of this is a bit arbitrary and up to the aircraft designer. The line between the electrical system and instrument panel can be a bit fuzzy. In my case I am also trying to interface some real cockpit hardware, so that makes me lean towards pushing more of this into the electrical system model and less into the instruments/instrument panel. I'm also supporting all those little switches and circuit breakers. It's nice to be able to do this in a generalized electrical system model. It does complicate the electrical system config file, but this is just moving complexity from some where else ... and it would be even worse to have these things hard coded someplace. Essentially this is the difference between the electrical system deciding which buses power which items vs. the instruments deciding which bus they plug into. I.e. when we build the aircraft, do we run the wires from the buses to the instruments or do we run the wires from the instruments to the buses. The end result is really the same (although you might end up with the wire backwards) and since everything is based on the property system, it's more of an aircraft designer choice than a coder choice. The code as it stands would work either way ... it's a matter of modifying the instruments.xml and electrical-system.xml config files. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program 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] re: question
Curtis L. Olson writes: Related to the electrical system there are other non-panel things though to be concerned about as well. For instance, if electrical bus #1 isn't powered, the flaps won't move and the fuel pump won't work. Those are very aircraft-dependent. Many older aircraft have hand-operated flaps, and most retractables (I think) have a manual override for the gear. In my limited experience, only the newest 172's (i.e. the 172R) have fuel pumps at all, though they're probably more common on bigger planes. This has flight model implications. Yes, but not much; we just have to have the FDMs read from /systems/flaps/position rather than /controls/flaps, etc. Likewise, if the master-bat switch is off and the master-alt switch is off (or the engine is not running) and there is no external power, then the starter motor won't engage. Again, this logic should probably be kept out of the FDMs; we can simply tell them whether the starter is engaged. They should be parameterized in the XML instrument config file so that the aircraft file can plug the right instrument into the right bus. Note how some instruments are already parameterized to use different engines or receivers. I never quite got the hang of your xml parameters ... It can be as simple as a property naming a property. I prefer that the GPS connect itself to avionics-bus-1, or more specifically, that the aircraft config file connect the GPS to avionics-bus-1. That's nice for designers, because it will feel a little like actually building an aircraft. Some of this is a bit arbitrary and up to the aircraft designer. The line between the electrical system and instrument panel can be a bit fuzzy. I'm not suggesting putting this in the panel config but in the aircraft config -- that's where we tie all the parts together. It should be easy to connect any device to any bus in the *-set.xml file. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] re: question
override for the gear. In my limited experience, only the newest 172's (i.e. the 172R) have fuel pumps at all, though they're probably more common on bigger planes. All C172s have a engine-operated fuel pump. Because of being high wing, they generally do not _require_ a working fuel pump. However, omitting (or failing an existing) pump either reduces the range of permitted attitudes or increases the unusable fuel in the tanks. Thus, especially the C172 that have larger engines and therefore can take a much higher nose attitude for Vx climb conditions, or are fuel injected and need slightly more pressure than 2 ft of height, have an additional electrical pump. Most low wings require the aux electrical fuel pump to be on for takeoff, so that if the mechanical pump fails, the engine doesn't quit on you. Contrastingly, C172 require it to be checked in runup to make sure it works, then leave it off for takeoff because the departure roll is known to not raise the nose enough to unport the fuel (given legal minimums). ... another example of how our systems state machine drive underlying models, in this case the engine and whether it receives a fuel supply. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Windows binary (fwd)
Can anyone provide this for me? If so, thanks! jj -- Forwarded message -- Date: Thu, 26 Sep 2002 13:16:29 -0500 From: Curtis L. Olson [EMAIL PROTECTED] To: Jim Brennan jjb - [EMAIL PROTECTED] Subject: Re: Windows binary Jim Brennan jjb - writes: Hi Curt: do you know if there is a windows binary available that has a fix for the autopilot heading select problem that I reportesd a while ago? (the one currently reached from the downloads page is still having that problem ,so is likely the original version). Jim, I believe that was fixed post 0.8.0 so no, not until the next release unless you can talk someone into sending you a pre-release / cvs build. One work around is that you can type Ctrl-H to toggle the heading hold. Once in heading hold mode, the rudder keys (Ins/Enter) will adjust the heading, so you can lock on and the adjust to what you want. You can also click on the instrument panel to adjust the heading bug whether you are in heading hold mode or not. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program 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] Re: [Flightgear-users] Re: Windows binary (fwd)
Jim Brennan jjb writes: Can anyone provide this for me? http://www.rockfish.net/~nhv/fgfs/mingw/fgfs_092602.tgz Note this does not have LaRCSim or UIUC support as there is a namespace clash with the beta MingW gcc compiler I am using. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] typical twin-engine elec system
I've posted a schematic of a typical twin-engine transport electrical schematic at: http://home.attbi.com/~davidculp2/Elec_Schematic.jpg The sources of AC power are two engine generators, the APU, and external power. In most airplanes these sources are never paralleled, so connecting one source to the Gen Bus will disconnect any other. The heavy users, like hydraulic pumps, fuel pumps, and galley, are placed on the Main Buses. Vital backup instruments are on the Standby busses (like the standby ADI, VSI). The Battery and Hot Battery busses contain stuff like fire detection, master caution system, backup pressurization, fuel shutoff, passenger oxygen, etc. The battery is 24 volt (not 28 volt like I had posted earlier). 99.9% of the time the DC system is powered by the TR's and the battery charger, so the system runs at 28 volts. The DC sources are usually paralleled, except in some cases where a switch is added to isolate the two sides if required. Well, that's the basic system. To build it with XML you might be able to do something like this (in psuedo-XML): Electrical System Battery name = Battery1 user = HotBatteryBus user = BatterySwitch supplier = BatteryCharger /Battery Generator name = Generator1 user = GenBus1 supplier = CSD1 supplier = APUSwitch1 supplier = GroundPower /Generator Generator name = Generator2 user = GenBus2 supplier = CSD2 supplier = APUSwitch2 supplier = GroundPower /Generator Bus type = AC name = GenBus1 user = MainBus1 supplier = Generator1 /Bus Bus type = AC name = MainBus1 supplier = GenBus1 user = TR1 user = BatteryCharger user = ACStandbyBus user = ElecHydraulicPump2 user = ADC1 user = Main1AftFuelPump user = CenterRightFuelPump user = ADI1 user = CabinCeilingLights user = EquipmentCoolingFan1 /Bus . . . etc /Electrical System In a 737 the engine generators are normally loaded at about 50 amps each, in flight. Dave Culp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-users] Re: Windows binary (fwd)
At 9/26/02, Norman Vine wrote: Jim Brennan jjb writes: Can anyone provide this for me? http://www.rockfish.net/~nhv/fgfs/mingw/fgfs_092602.tgz Note this does not have LaRCSim or UIUC support as there is a namespace clash with the beta MingW gcc compiler I am using. I recall reading some prior email from you on the namespace problem. In that email you seemed to suggest that this was a fairly general problem and not specific to your compiler. Is there something that we can do here at UIUC to resolve this compile issue? Also, does the Windows binary from www.flightgear.org support the LaRCsim/UIUC stuff? Regards, Michael Norman ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-users] Re: Windows binary (fwd)
Michael Selig writes: At 9/26/02, Norman Vine wrote: Jim Brennan jjb writes: Can anyone provide this for me? http://www.rockfish.net/~nhv/fgfs/mingw/fgfs_092602.tgz Note this does not have LaRCSim or UIUC support as there is a namespace clash with the beta MingW gcc compiler I am using. I recall reading some prior email from you on the namespace problem. In that email you seemed to suggest that this was a fairly general problem and not specific to your compiler. Is there something that we can do here at UIUC to resolve this compile issue? YES - it is a bit of work, but I think that it should be done at somepoint The problem is all the #defines in ls_generic cause namespace clashes. M$oft is half to blame here in that they assume you are in a Windows enviroment and insist on bringing in almost the entire header tree when you might only need one structure. I believe the proper thing todo is eventually move LaRCSim into a C++ class and use namespaces. This however is a fair amount of work. BTW this all stems from the libstdc++ that ships with the gcc-3.X compilers which enables the WIN32 threading model. Currently this is still a beta release and trying to find a good solution to this namespace pollution is one of the things keeping gcc3.X beta for WIN32, so this problem may disappear on the MingW32 compiler but having all tose defines exposed is just 'begging for trouble'. I think we have just been lucky that we got away with them as long as we have. Also, does the Windows binary from www.flightgear.org support the LaRCsim/UIUC stuff? Yes, I am sad to say :-( I will work on correcting this by reverting to the older 2.95 compiler when I get a chance should be within the week as I have discovered that I still need it for some other projects too. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Flightdeck-UI Project Homepage.
FYI http://openlight.com/fdui/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 747-400 electrical system
While looking at the 747-400 electrical panel I see that the AC buses are paralleled. In this case there is a bus called a Tie Bus that serves as the connection point for the four engine generators and the two APU generators and the two external power sources. The sychronization of the AC buses must be automatic (it was manual in the 727 - what a pain). Each engine's main bus is connected to the Tie Bus by an Isolation Switch, which can be used to protect the Tie Bus from a bad supplier. I assume the APU and external sources have an internal logic that prevents them all from simultaneously powering the Tie Bus, but I don't know what the logic is. I vaguely remember the 757 and 767 having the same setup, but I'm getting too old to remember such things. Here's a link to my scan of the 747-400 electrical panel layout: http://home.attbi.com/~davidculp2/747_elec.jpg Dave Culp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Hi, compiling winsock2.h problem?
I'd read on your posting about error C2011: 'fd_set' : 'struct' type redefinition warning C4005: 'FD_SET' : macro redefinition Have you found the problem yet? I've got the same problem. any help would be great, thanks, Chao ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
