Re: [Flightgear-devel] fgfsbase cvs ??
On Monday 10 June 2002 11:41 pm, Curtis L. Olson wrote: > Norman Vine writes: > > FWIW > > > > I haven't been able to get an update from the fgfsbase cvs all day > > > > I can connect OK but then cvs gets stuck responding with > > > > "cvs server: [ $time ] waiting for cvsroot's lock in > > home/cvsroot/FlightGear/FlightGear" > > > > every 30 seconds > > > > ??? > > > > Norman > > Not to be a person that posts me to messages, but "me too". > > Did someone start a cvs commit and leave the editor open and not > finish the commit or something along those lines? > > Curt. I have an idea who, if. Anyway it's working now ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Rain, snow and thunderstorm
Does anybody is working on the weather effects? []'s Marcio Shimoda ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfsbase cvs ??
Norman Vine writes: > FWIW > > I haven't been able to get an update from the fgfsbase cvs all day > > I can connect OK but then cvs gets stuck responding with > > "cvs server: [ $time ] waiting for cvsroot's lock in > home/cvsroot/FlightGear/FlightGear" > > every 30 seconds > > ??? > > Norman Not to be a person that posts me to messages, but "me too". Did someone start a cvs commit and leave the editor open and not finish the commit or something along those lines? 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] fgfsbase cvs ??
FWIW I haven't been able to get an update from the fgfsbase cvs all day I can connect OK but then cvs gets stuck responding with "cvs server: [ $time ] waiting for cvsroot's lock in home/cvsroot/FlightGear/FlightGear" every 30 seconds ??? Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: progress
James Turner <[EMAIL PROTECTED]> said: > One valuable thing would be to define the 'input' property nodes the > auto-pilot code will have, so I know what I should be setting. > *Ideally*, thus would be broken down into LNAV / VNAV / auto-throttle > stuff (with some coupling, obviously, especially for managed climb and > LOC/APP modes). Not a problem...give me a day or two to get things together. Probably there won't be as much changed as there will be added, but some of the "settings" need to be exposed in the property tree. > And of course, some of these can be missing. IIRC, someone (Alex?) > mentioned that on low end Cessnas, the autopilot will only control > laternal navigation (no VNAV). And of course lots of GA aircraft don't > have an auto-throttle. Yes, the basic cessna autopilot is single axis. > > As far as "autopiloting" is concerned, I'm not sure of the extent of what you > > are trying to model. AFIK, even if you've filed a plan and are using a flight > > computer you still need to clear before climbing or descending, so > > automatically changing FL and going into climb or descent when a given > > waypoint is reached would not be accurate behavior. But perhaps I am > > misunderstanding this. > > Err, I'm simply planing to copy the features I am familiar with from > using the simulated FMCs and MCDUs I've used. As you say, flight level > changes require ATC interaction (usually), but there's all kinds of > other things that the FMS can do automatically. Even the lowly KLN-89b > can automatically trigger the missed-approach for a stored procedure if > it detects a go-around condition. Then I'll let you work with that one and just focus on ap operating modes. The per aircraft configuration (defining capabilities) will be a big part of the autopilot and more than likely I won't get it quite right. But someone who knows how a given AP in a given aircraft works should be able to adjust the functionality through the xml config. > If you're interested, you can download the manuals for various > simulations (notably the Wilco 767-PIC), in PDF format. It's rather > heavy going, but potentially valuable prior to auto-pilot work, I guess. Sounds good. Where is it? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: progress
ahOn Mon, 2002-06-10 at 15:58, Jim Wilson wrote: > James Turner <[EMAIL PROTECTED]> said: > > > (I want to get the flight-plans hooked up to the existing > > auto-pilot code, which isn't really designed to look like a 'big jet' > > model of course, though it seems you already have code *somewhere* that > > handles LNAv and VNAV functions... hmm. > > You might want to hold off on that piece for now, the autopilot code is > getting re-written. The current code will follow the waypoints in the current > waypoint list. But, if you want to do this in the most flexible way, it seems > that your subsystem should be feeding the autopilot lower level target data as > required (i.e. modes, headings, pitches, altitudes), through the property > interface. The new code will still follow radials and probably the current > waypoint functionality will remain, so you could always feed target data > through the waypoint interface. You are correct that I need to be feeding radials / desired ground tracks / speeds / FLs to the autopilot code. The current waypoint code seems pretty misplaced though (translation, I think it should go). No real auto-pilot deals with 'waypoints', that's what an FMS does (which is precisely the systems I'm trying to model). The FMS just feeds the autopilot control commands such as course to fly and so on. (Here I'm treating the autopilot as 'the thing you interact with via the MCP' ...the autopilot has a NAV mode but that's equally happy being driven by a VOR). Anyway... One valuable thing would be to define the 'input' property nodes the auto-pilot code will have, so I know what I should be setting. *Ideally*, thus would be broken down into LNAV / VNAV / auto-throttle stuff (with some coupling, obviously, especially for managed climb and LOC/APP modes). And of course, some of these can be missing. IIRC, someone (Alex?) mentioned that on low end Cessnas, the autopilot will only control laternal navigation (no VNAV). And of course lots of GA aircraft don't have an auto-throttle. > > As far as "autopiloting" is concerned, I'm not sure of the extent of what you > are trying to model. AFIK, even if you've filed a plan and are using a flight > computer you still need to clear before climbing or descending, so > automatically changing FL and going into climb or descent when a given > waypoint is reached would not be accurate behavior. But perhaps I am > misunderstanding this. Err, I'm simply planing to copy the features I am familiar with from using the simulated FMCs and MCDUs I've used. As you say, flight level changes require ATC interaction (usually), but there's all kinds of other things that the FMS can do automatically. Even the lowly KLN-89b can automatically trigger the missed-approach for a stored procedure if it detects a go-around condition. If you're interested, you can download the manuals for various simulations (notably the Wilco 767-PIC), in PDF format. It's rather heavy going, but potentially valuable prior to auto-pilot work, I guess. James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radeon 8500 linux drivers
> Slightly off topic, but I found the following post from Sunday on > dri-devel: > http://sourceforge.net/mailarchive/forum.php?thread_id=772607&forum_id=7177 > Apparently, ATI have released (binary) Linux drivers for their FireGL > 8700/8800 cards. These use the same core as the Radeon 8500, and the > poster implies that they work correctly on those cards. Also worth noting in this context ist that "Weather Channel" has announced funding development of an appropriate OSS driver for the 8500. Jens noted this on 'dri-devel' and posted on TG web site, 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
[Flightgear-devel] Plib smoothing and transparency patches
The AC3D model smoothing and transparency patches are now in the main plib CVS (the transparency patch has been there for a while), so it will no longer be necessary to run a patched version of plib to get smooth aircraft models, as long as you are using the latest plib from CVS. The plib people are making noises about putting out a stable release; with luck, it will be ready in time for our next release. 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: progress
James Turner wrote: > Anyway, I'd like to work out a plan of attack to avoid too much > duplication. I suspect some might be inevitable, since there's slight > different goals. (and, alas, I only have one computer, so I'm kind of > anti the whole 3 computers thing :-) My sense is that any duplication would be in small pieces of code since the OpenGC and FG architectures are significantly different. One of the objectives has been to distribute the gpu functions as widely as possible - the result: FG runs at around 70fps on a 21" (1600x1200) monitor and I have the displays "throttled back" to 24 fps on a dual head GeForce 2. This leaves a lot of margin to add both scenery to the FG side and display details on the OpenGC side. If you can swing it a 2nd networked machine really improves both the performance and visual capabilities of the simulation - Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: progress
> Hmm, this is going to get fiddly. I've got a generic route/flight-plan > backend sort of working (no flight traversal or waypoint sequencing as > of yet), which I am planning to extend with airways, SIDs, STARs and so > on (with editing of course). The long term plan was to build an FMC / > MCDU / GPS on top of this, but it seems like you're a good way ahead of > me. And of course this is built into flightGear so that it can access > the exiting Navaids, fixes and runway data. > Not really, I've been focusing on an approach to build components for home cockpit builders that would most likely use a network of machines. I suspect trying to integrate or "wrap" the source into FlightGear could lead to insanity. > > The not-so-good-news --- it runs as a single opengl app (I've got my > > copy > > running on a laptop) and uses the SimGear library socket functions. (You > > need 3 networked machines, but you do get the *whole enchilada*) > > A full complement of flight deck displays (OpenGC), a multi-function > > control > > unit (MCDU), a flight dynamics model > > and scenery(FlightGear). > > > I'm not sure the best way to proceed. I really think the auto-pilot code > belongs in flight-gear, but the goal of having the FMC / MCDU run > separately is valuable. There are some advantages to having the autopilot external especilly since FG has the hooks to control the flight model via the network. There's a lot of navigation data the FMC/MCDU > needs that is simulator specific though : does your code have it's own > copy or what? Using Robin Peel's nav database, flight/aircraft models are on the FG side. There is some new enviro data that needs to be collected and shipped across for thrust calculations and the like. Still thinking of how to handle wind. the FMC needs to calculate a wind vector based on navigation performance, grabbing the values from the property tree is "cheating" > Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: progress
James Turner <[EMAIL PROTECTED]> said: > (I want to get the flight-plans hooked up to the existing > auto-pilot code, which isn't really designed to look like a 'big jet' > model of course, though it seems you already have code *somewhere* that > handles LNAv and VNAV functions... hmm. You might want to hold off on that piece for now, the autopilot code is getting re-written. The current code will follow the waypoints in the current waypoint list. But, if you want to do this in the most flexible way, it seems that your subsystem should be feeding the autopilot lower level target data as required (i.e. modes, headings, pitches, altitudes), through the property interface. The new code will still follow radials and probably the current waypoint functionality will remain, so you could always feed target data through the waypoint interface. As far as "autopiloting" is concerned, I'm not sure of the extent of what you are trying to model. AFIK, even if you've filed a plan and are using a flight computer you still need to clear before climbing or descending, so automatically changing FL and going into climb or descent when a given waypoint is reached would not be accurate behavior. But perhaps I am misunderstanding this. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Java client library
> I'm currently working on a gui to help users to start fgfs > with their own options (it parses prefernces.xml and show the > user the different options available). I started writing it > in Python with wxPython gui library (works on Linux-gtk, > Windows, MacOSX, and every motif-Unices). If find python + > wxPython much greater than java + swing (to use and to program) This may sound kinda wierd, but I have had some success using Macromedia's Flash MX for this type of stuff. No Linux support, but it is rather ubiquitous on Windows and Mac. It runs within a familar environment for the user (Browser), run-time is free, has a built in XML parser/generator, Can read and write to the file system directly, Can start other applications, and it is easy to make the results look very cool. One could just bring up a local instance of TomCat and use standard web forms as well . :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: progress
Its a bit pricey, but I am partial to EDAS, because it is Ethernet based. http://www.edasce.com - Original Message - From: "Gene Buckle" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 10, 2002 7:05 AM Subject: Re: [Flightgear-devel] Re: progress > > I've spent a little time looking at the EPIC and FSUIPC stuff, but haven't > > really > > looked at how to make a compatible interface with OpenGC and FG sockets. > > You might want to look into http://www.phidgets.com. He's building a 256 > input device for $50. All of his stuff is USB and he's working on Linux > drivers. > > g. > > > > ___ > 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] Re: progress
> I've spent a little time looking at the EPIC and FSUIPC stuff, but haven't > really > looked at how to make a compatible interface with OpenGC and FG sockets. You might want to look into http://www.phidgets.com. He's building a 256 input device for $50. All of his stuff is USB and he's working on Linux drivers. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: progress
* James Turner -- Monday 10 June 2002 11:09: > (and, alas, I only have one computer, so I'm kind of > anti the whole 3 computers thing :-) ACK. I've only one here, too, and that won't change any time soon. Well, there's an Atari ST, but ... and then, opengc doesn't even compile on my machine because it relies on obsolete freetype stuff, that I won't install. :-> I do think that these things belong to the simulator, rather than to some external programs on some external computers. Please go ahead. m. :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] compiling error on MSVC
Did you compile all libraries (and fgfs.exe) with the same
run-time libs (LIBCMTD.LIB: /MTd compiler option)?
regards
georg
> -Original Message-
> From: Christian Stock [mailto:[EMAIL PROTECTED]]
> Sent: Montag, 10. Juni 2002 04:02
> To: [EMAIL PROTECTED]
> Subject: Re: [Flightgear-devel] compiling error on MSVC
>
>
> Thanks, Fred.
>
> I have downloaded the CVS version now, and as you said this
> has been fixed.
> However, I get a lot of link errors when I compile flightgear
> (simgear cvs
> compiled fine). Do I have to be aware where to put the plib
> and simgear
> libs? Or are the incompatibilities between version, eg
> simgear cvs doesn't
> work with flightgear cvs?
>
> Cheers, Christian
>
>
> At 09:58 AM 9/06/2002 +0200, you wrote:
> >This error has been fixed in CVS. MSVC6 is not able to
> choose between two
> >member functions, one const and the other not const, so you
> have to cast
> >the 4th argument :
> >
> > PropertyManager->Tie("atmosphere/p-turb-rad_sec", this,1,
> >&FGAtmosphere::GetTurbPQR);
> >
> >becomes:
> >
> > PropertyManager->Tie("atmosphere/p-turb-rad_sec", this,1,
> > (double (FGAtmosphere::*PMF)(int)
> const)&FGAtmosphere::GetTurbPQR);
> >
> >and so on for different classes in different files.
> >
> >Cheers,
> >
> >-Fred
> >
> >_
> >Frederic Bouvier
> >Maintainer of the FlightGear Scenery Designer project
> >http://fgsd.sourceforge.net
> >
> >
> >- Original Message -
> >From: "Christian Stock" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Sunday, June 09, 2002 5:18 AM
> >Subject: [Flightgear-devel] compiling error on MSVC
> >
> >
> > > I just downloaded flightgear 0.7.10 and I'm trying to get
> it to compile on
> > > Windoze MSVC 6.0.
> > >
> > > I got glut, plib, sim-gear compiled w/o any probs. For FG
> I get this error
> > > at quite a few places.
> > >
> > > error C2661: 'Tie' : no overloaded function takes 4 parameters
> > >
> > > I had a look at the Tie functions in FGPropertyManager,
> but couldn't work
> > > out what's wrong. Maybe I have to include a cast or so
> (doesn't really
> >make
> > > sense because those functions use templates anyway)?
> > >
> > > Anyone come across this and knows how to fix it?
> > >
> > > Cheers, Christian
> > >
> > >
> > > ___
> > > 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
>
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: progress
On Monday, June 10, 2002, at 05:35 am, John Wojnaroski wrote: > Well, I've been working on a Multi-function Control Display Unit (MCDU) > which connects to the FMC and > provides manual control of the nav receivers and other aircraft systems. > Next major effort is adding ability to > insert and edit waypoints and do some flight testing of the LNAV and > VNAV. Hmm, this is going to get fiddly. I've got a generic route/flight-plan backend sort of working (no flight traversal or waypoint sequencing as of yet), which I am planning to extend with airways, SIDs, STARs and so on (with editing of course). The long term plan was to build an FMC / MCDU / GPS on top of this, but it seems like you're a good way ahead of me. And of course this is built into flightGear so that it can access the exiting Navaids, fixes and runway data. > The not-so-good-news --- it runs as a single opengl app (I've got my > copy > running on a laptop) and uses the SimGear library socket functions. (You > need 3 networked machines, but you do get the *whole enchilada*) > A full complement of flight deck displays (OpenGC), a multi-function > control > unit (MCDU), a flight dynamics model > and scenery(FlightGear). I was assuming long-term I'd setup an /fms node in the property tree, with a flightplan [fp?] child containing the waypoints of the active route (with a few other fp slots for secondary and temporary routes, of course), and that would be enough data to generate a reasonably complete and accurate Boeing / Airbus style NAV display, or the list / visual display of any smaller GPS unit (KLN-89b, for example). However, this is some way off (I want to get the flight-plans hooked up to the existing auto-pilot code, which isn't really designed to look like a 'big jet' model of course, though it seems you already have code *somewhere* that handles LNAv and VNAV functions... hmm. I'm not sure the best way to proceed. I really think the auto-pilot code belongs in flight-gear, but the goal of having the FMC / MCDU run separately is valuable. There's a lot of navigation data the FMC/MCDU needs that is simulator specific though : does your code have it's own copy or what? Also, people who just want an in-cockpit GPS unit definitely don't want a separate machine to run it on. One solution I've contemplated (but which I suspect is unworkable) is something like an NFS-mount for the property tree: i.e run the FMC/MCDU as a property 'server', and have every node it exports be located under /fms in the global tree. This would probably get inefficient and / or too complicated in short order though. Anyway, I'd like to work out a plan of attack to avoid too much duplication. I suspect some might be inevitable, since there's slight different goals. (and, alas, I only have one computer, so I'm kind of anti the whole 3 computers thing :-) H&H James -- Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin. -- John Von Neumann, 1951 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
