Re: [Flightgear-devel] Flightdeck-UI Project Homepage.
Norman Vine writes: FYI http://openlight.com/fdui/ Interesting ... are these people aware of FlightGear? It looks like they are doing cockpit UI type research (?) and they could plug right into FlightGear to drive their displays. 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] Flightdeck-UI Project Homepage.
Interesting ... are these people aware of FlightGear? It looks like they are doing cockpit UI type research (?) and they could plug right into FlightGear to drive their displays. Huh? I read into it that they were using flight deck metaphors to create user interfaces - not necessarily flight-related. Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] typical twin-engine elec system
Once upon a time, you were sitting and writing: Thanks Dave. It has more than enough information (although it is not a typical electrical diagram). I have a few dirty tasks for the weekend (like evaluating a signal processing exam), so I won't be working on the computer. All the best, E.Y //// (o)o) (-)-) booom ! ( ._.)(o) Elad (elady) J. Yarkoni Elady for friends or Oh my God... - It's Him ! for fans (or turbofans). eMail: [EMAIL PROTECTED] WWW: http://www.ee.bgu.ac.il/~elady Dept. of ECE, BGU, Beer-Sheva, Israel, 84105. 972-8-647-2417. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightdeck-UI Project Homepage.
On Friday 27 September 2002 9:47 am, Curtis L. Olson wrote: Jon Berndt writes: Interesting ... are these people aware of FlightGear? It looks like they are doing cockpit UI type research (?) and they could plug right into FlightGear to drive their displays. Huh? I read into it that they were using flight deck metaphors to create user interfaces - not necessarily flight-related. Ok, maybe I misread it myself. It's true, after about 8 beers, having one of those attitude indicators on my desktop would definitley come in handy. Curt. After 16 beers attitude indicator takes on a whole new meaning. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CVS error?
I'm now seeing this when I do a 'cvs update -dP' in the development CVS tree. cvs server: cannot open directory /var/cvs/FlightGear-0.9/FlightGear/src/Systems/Vacuum: No such file or directory cvs server: skipping directory src/Systems/Vacuum Is this anything I've done locally? FlightGear/src/Systems/Vacuum exists on my machine and contains files. TIA, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS error?
Matthew Law writes: I'm now seeing this when I do a 'cvs update -dP' in the development CVS tree. cvs server: cannot open directory /var/cvs/FlightGear-0.9/FlightGear/src/Systems/Vacuum: No such file or directory cvs server: skipping directory src/Systems/Vacuum Is this anything I've done locally? FlightGear/src/Systems/Vacuum exists on my machine and contains files. You should be able to remove the Vacuum directory, and edit the Systems/CVS/Entries and remove the reference to the Vacuum subdir. 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] Static port and altimeter
I've just added a static port system and a new altimeter model to CVS. Now, if you set the property /systems/static/serviceable to false, the altimeter will freeze. Otherwise, it displays the altitude based on the difference between outside air pressure (with a slight lag from the static port) and the altimeter setting, without any direct knowledge of the actual aircraft altitude. When I have a chance, I'll write a new VSI model, also connected to the static port. I'll also add a pitot system, then will write an ASI connected both to it and the static system. I need to know more about the ram-air effects in the pitot tube first. The static system itself needs a little more work, including support for multiple static ports, sideslip errors, and alternate air (from inside the cabin); those won't be hard to add, but if anyone (Alex?) wants to take a look at src/System/static.[ch]xx and add them in before I have a chance, feel free. Note that any improvements to the static system automatically propagate themselves to the instruments. 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
[Flightgear-devel] Updating to new CVS trunk repository
Just trying my first CVS update in a couple of weeks. I see there is a new repository for the trunk, so I changed all my CVS/Root files to point to the -0.9 one and logged in with the new password. [Why not just have no password?] But I get: cvs server: Updating . cvs [server aborted]: could not find desired version 1.9 in /var/cvs/FlightGear-0.9/FlightGear/configure.ac,v When the same was done to the SimGear repository a few weeks a go I ended up doing a complete fresh check-out, but in my FlightGear tree I have quite a lot of local changes which I want to keep, and also I'm on a 56k (actually never more than 40kbps) modem link. Can anyone tell me how to get CVS update going again? Thanks, - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Joystick files still contain bad names
Two base package files, Input/Joysticks/CH/pro-pedals-usb.xml Input/Joysticks/CH/pro-yoke-usb.xml both still (or again) contain nameMicrosoft-PC-Joysticktreiber /name namePilote de joystick PC Microsoft /name which is less than useful as discussed before. Please could someone remove those lines, and could contributors please be careful not to include such lines in their contributions. Thanks, - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Joystick files still contain bad names
Julian, which is less than useful as discussed before. Please could someone remove those lines, and could contributors please be careful not to include such lines in their contributions. This was me :-( at a time when we did not yet completely figure where/how the joystick is handled under windows. I thought it was removed already. Could you forgive? Very sorry, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updating to new CVS trunk repository
The username changed too. Just trying my first CVS update in a couple of weeks. I see there is a new repository for the trunk, so I changed all my CVS/Root files to point to the -0.9 one and logged in with the new password. [Why not just have no password?] But I get: cvs server: Updating . cvs [server aborted]: could not find desired version 1.9 in /var/cvs/FlightGear-0.9/FlightGear/configure.ac,v When the same was done to the SimGear repository a few weeks a go I ended up doing a complete fresh check-out, but in my FlightGear tree I have quite a lot of local changes which I want to keep, and also I'm on a 56k (actually never more than 40kbps) modem link. Can anyone tell me how to get CVS update going again? Thanks, - Julian ___ 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] Static port and altimeter
The static system itself needs a little more work, including support for multiple static ports, sideslip errors, and alternate air (from inside the cabin); those won't be hard to add, but if anyone (Alex?) wants to take a look at src/System/static.[ch]xx and add them in before I have a chance, feel free. Note that any improvements to the static system automatically propagate themselves to the instruments. You need to handle the special case of large dt (as well as negative) more carefully ... for the same reasons as I did in Steam's function. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More instruments: VSI and HI
The VSI and ALT are connected to the static port. When that port is blocked, Don't forget to put in the alternate static source switch on the panel, and cause it to read as a slightly rearward facing static port. the ALT will freeze at its current altitude reading, and the VSI will gradually settle to zero; that's particularly nasty, because the two instruments will agree (no climb or descent). However, the airspeed indication will be inconsistent and a full instrument scan will immediately identify the problem. When will you connect the ASI between the pitot and static ? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Static port and altimeter
On Fri, 2002-09-27 at 15:09, Alex Perry wrote: The static system will probably be more challenging as that's where most of the subtle errors seem to crop up. Cessna gives tables relating IAS to CAS (which is largely the static source error). If that's standard practice, incorporating a table read-in and lookup might be a good idea. I don't think so. Static source errors occur mostly 1. In slips, especially for aircraft with one static port 2. When alternate static (i.e. cockpit) is selected Pitot source errors occur mostly 1. In slips, especially in full forward slips 2. At unusual angles of attack, especially no-flap slow flight And so, I stand by my statement. Most of the time the static errors are the ones that you need to worry about. You don't spend alot of time at either high angles of attack or high sideslip angles. The IAS calibration table is mostly for pitot, due to angle of attack. The ALT calibration table is mostly for static, due to the alternate. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Static port and altimeter
Alex Perry writes: The static system itself needs a little more work, including support for multiple static ports, sideslip errors, and alternate air (from inside the cabin); those won't be hard to add, but if anyone (Alex?) wants to take a look at src/System/static.[ch]xx and add them in before I have a chance, feel free. Note that any improvements to the static system automatically propagate themselves to the instruments. You need to handle the special case of large dt (as well as negative) more carefully ... for the same reasons as I did in Steam's function. Yes, if you use an int and track time in increments of 1 / 1,000,000 then you get about 30 minutes before you hit an anomaly. This bug caused problem in the past such as radio station searches to only happen every other 30 minute period, or panel text to stop updating. You have to be very careful to think through the amount of possible time accumulation when doing the math. This is a subtle bug because when you are developing code, you rarely test for more than a few seconds at a time. That said, I haven't looked closely to see if any of these problems are in the latest code ... but it's something to keep in mind when dealing with time sensitive code. 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] Static port and altimeter
Alex Perry writes: You need to handle the special case of large dt (as well as negative) more carefully ... for the same reasons as I did in Steam's function. Nice timing. In fact, I copied your low-pass function into Main/utils.[ch]xx just a short while ago and am now using it. 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] Static port and altimeter
Curtis L. Olson writes: Yes, if you use an int and track time in increments of 1 / 1,000,000 then you get about 30 minutes before you hit an anomaly. This bug caused problem in the past such as radio station searches to only happen every other 30 minute period, or panel text to stop updating. You have to be very careful to think through the amount of possible time accumulation when doing the math. This is a subtle bug because when you are developing code, you rarely test for more than a few seconds at a time. That said, I haven't looked closely to see if any of these problems are in the latest code ... but it's something to keep in mind when dealing with time sensitive code. Yep there is a problem if you try to run a FGFS session on a Windows box much over 49 days :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Static port and altimeter
Tony Peden writes: And so, I stand by my statement. Most of the time the static errors are the ones that you need to worry about. You don't spend alot of time at either high angles of attack or high sideslip angles. Unfortunately, the little bit of time you do spend in heavy sideslips and forward slips is the part of the flight where airspeed margins are tightest: final approach. 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] Static port and altimeter
Curtis L. Olson writes: Yes, if you use an int and track time in increments of 1 / 1,000,000 then you get about 30 minutes before you hit an anomaly. This bug caused problem in the past such as radio station searches to only happen every other 30 minute period, or panel text to stop updating. You have to be very careful to think through the amount of possible time accumulation when doing the math. This is a subtle bug because when you are developing code, you rarely test for more than a few seconds at a time. That said, I haven't looked closely to see if any of these problems are in the latest code ... but it's something to keep in mind when dealing with time sensitive code. Since we pass a dt rather than a counter, it shouldn't be a problem. By the way, I modified main.cxx so that dt=0 whenever the clock is frozen -- that way, the instruments don't keep settling (or drifting) during a pause. 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] More instruments: VSI and HI
However, the airspeed indication will be inconsistent and a full instrument scan will immediately identify the problem. When will you connect the ASI between the pitot and static ? I think I need a fresh day for that one -- it's a little complicated. The TC will be easier as soon as I have a chance to look at Curt's new electrical code. Ignore the reference to the scan; it ain't relevant for the subsystem. The ASI is just a differential pressure sensor indicating the difference between the pitot line and the static line. We need a lookup table to generate IAS numbers from pressure to keep panel XML design simple. It's going to be fun writing a randomized failure manager when everything's ready. I can think of quite a bit, including things that should be caught in the preflight but sometimes are not (like reversed ailerons). Remember my suggestion for multiplayer, where each participant has a single failure at all times chosen from the list of survivable failures. The other players of the multi session get to choose which failure it is, and also change their choice at any time without notice. Grin. I think that would be much more fun than a boring random selection. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Static port and altimeter
Norman Vine writes: Yep there is a problem if you try to run a FGFS session on a Windows box much over 49 days :-) I wouldn't know anything about that, and far be it from me to blatantly bash windows, but if you manage to have your windows box run that long, I'd definitely recommond that you also consider buying lottery tickets, ask your boss for a big promotion, and try googling for britany spear's home number; that kind of luck just doesn't come around every day. :-) 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] Static port and altimeter
David Megginson writes: And so, I stand by my statement. Most of the time the static errors are the ones that you need to worry about. You don't spend alot of time at either high angles of attack or high sideslip angles. Unfortunately, the little bit of time you do spend in heavy sideslips and forward slips is the part of the flight where airspeed margins are tightest: final approach. This is relevant to the discussion (thanks, Google): http://flighttest.navair.navy.mil/unrestricted/FTM108/c2.pdf Here's an excerpt: Errors in total pressure caused by the angle of incidence of a probe to the relative wind are negligible for most flight conditions. Commonly used probes produce no significant errors at angles of attack or sideslip up to approximately 20°. With proper placement, design, and good leak checks of the pitot probe, zero total pressure error is assumed. If any of the engineers on the list want to read all 89 pages and distill it down to something I can actually use, I will be very grateful. 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] More instruments: VSI and HI
David, Just had a look at the latest additions, good work, this is an area that has been very lacking in flightgear and it's nice to finally be addressing it. The airspeed indicator is still working for me, even when the static system not servicable. David Megginson writes: I think I need a fresh day for that one -- it's a little complicated. The TC will be easier as soon as I have a chance to look at Curt's new electrical code. Your code should be able to simply check the property: /systems/electrical/outputs/turn-coordinator We aren't yet modeling a degraded/degrading electrical system so as long as this is 0 you should have power. If you want to parameterize your turn-coordinator modeling code, In the C172S (serial #'s 172S8704 and on) the turn-coordinator is fed from the electrical bus 2 aka: /systems/electrical/outputs/bus[1] But it will likely be someplace else in other aircraft ... even earlier serial numbers of the C172S (which I was referencing) feed the TC from bus #1. Why can't there be a universal standard for how electrical systems are constructed in aircraft?!? I know! I'll come up with a standard myself ... Once the basic stuff's in place, we can go back and add more features like configurable error factors and offsets (the AI on C-GPMR shows a few degrees bank in level flight), acceleration errors, etc. Yes, if someone could come up with a simple model of a battery, and alternator we could add those pretty easy and track power going through the system in whatever units are appropriate. Systems could start dropping off line or degrading (TC gyro?), radio displays could start dimming/flickering, etc. (do they do that?) when the power drops sufficiently. It's going to be fun writing a randomized failure manager when everything's ready. I can think of quite a bit, including things that should be caught in the preflight but sometimes are not (like reversed ailerons). Yes, and the property system makes it conventine to fire off faults in a variety of ways. We could have external scripts that could set up standard training scenarios. There are lot's of possibilities. 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] list traffic
We must all be a bunch of pathetic geeks if the list traffic takes off on friday and saturday nights. :-) Contributing-to-the-traffic-ly yours, 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] Static port and altimeter
Curtis L. Olson Norman Vine writes: Yep there is a problem if you try to run a FGFS session on a Windows box much over 49 days :-) I wouldn't know anything about that, and far be it from me to blatantly bash windows, but if you manage to have your windows box run that long, I'd definitely recommond that you also consider buying lottery tickets, ask your boss for a big promotion, and try googling for britany spear's home number; that kind of luck just doesn't come around every day. :-) Hmm... I can''t rememeber crashing this box in a long time and if it wasn't for needing to reboot in order to access the CVS ... Oh right I don't need to do that anymore :-) So remind me to send you one of these in a cople of months :-) 510 src $ cat /proc/uptime 263847.38 237946.24 511 src $ uname CYGWIN_NT-5.0 Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Static port and altimeter
Norman Vine writes: Hmm... I can't rememeber crashing this box in a long time and if it wasn't for needing to reboot in order to access the CVS ... Oh right I don't need to do that anymore :-) So remind me to send you one of these in a cople of months :-) 510 src $ cat /proc/uptime 263847.38 237946.24 511 src $ uname CYGWIN_NT-5.0 I'll send you a dollar in advance so you can buy me a lottery ticket on that day. :-) 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] Updating to new CVS trunk repository
Alex Perry wrote: The username changed too. Yes, I forgot to mention that. However, you can see that my problem was not logging in but updating. Someone must know how to get around this ... anyone? - Julian Just trying my first CVS update in a couple of weeks. I see there is a new repository for the trunk, so I changed all my CVS/Root files to point to the -0.9 one and logged in with the new password. [Why not just have no password?] But I get: cvs server: Updating . cvs [server aborted]: could not find desired version 1.9 in /var/cvs/FlightGear-0.9/FlightGear/configure.ac,v When the same was done to the SimGear repository a few weeks a go I ended up doing a complete fresh check-out, but in my FlightGear tree I have quite a lot of local changes which I want to keep, and also I'm on a 56k (actually never more than 40kbps) modem link. Can anyone tell me how to get CVS update going again? Thanks, - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updating to new CVS trunk repository
Julian Foad writes: Alex Perry wrote: The username changed too. Yes, I forgot to mention that. However, you can see that my problem was not logging in but updating. Someone must know how to get around this ... anyone? Personally, I just did a fresh checkout. 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] Updating to new CVS trunk repository
Curtis L. Olson wrote: Julian Foad writes: Alex Perry wrote: The username changed too. Yes, I forgot to mention that. However, you can see that my problem was not logging in but updating. Someone must know how to get around this ... anyone? Personally, I just did a fresh checkout. Curt. D'oh. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] external model positioning
I am working on interfacing an external flight model to FlightGear via the network. This particular code reports an altitude of zero/0.0f when the wheels are resting at sea level. The c172 3d model is drawn so that it's center of gravity is at the reported altitude. Also the pilot view point is also relative to this altitude. This means that on the ground, the out-the-window view point is just a few inches above the pavement. And also the 3d model is sunk into the ground. What do I need to do to get the pilot view point and the center of the 3d model up to the correct altitude? Thanks, 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] Updating to new CVS trunk repository
Julian Foad writes: Curtis L. Olson wrote: Julian Foad writes: Alex Perry wrote: The username changed too. Yes, I forgot to mention that. However, you can see that my problem was not logging in but updating. Someone must know how to get around this ... anyone? Personally, I just did a fresh checkout. Curt. D'oh. Depending on how aggrivating this all is/has been you guys might consider a pitch-in-and-buy-curt-a-cvs-book fund. :-) 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] Updating to new CVS trunk repository
Personally, I just did a fresh checkout. D'oh. Depending on how aggrivating this all is/has been you guys might consider a pitch-in-and-buy-curt-a-cvs-book fund. :-) What make you think, that we think, that you'd take the time to read it ? 8-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Static port and altimeter
Alex Perry wrote: Pitot source errors occur mostly 1. In slips, especially in full forward slips 2. At unusual angles of attack, especially no-flap slow flight IIRC, I read that the EuroFighter uses a system which selects the best source of data for this stuff taking into account the last good orientation, speed of the aircraft and direction data. Does this sound right or am I suffering from long term memory problems again ?! Regards, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updating to new CVS trunk repository
Alex Perry writes: Personally, I just did a fresh checkout. D'oh. Depending on how aggrivating this all is/has been you guys might consider a pitch-in-and-buy-curt-a-cvs-book fund. :-) What make you think, that we think, that you'd take the time to read it ? 8-) That's fair :-) there is only a very few books that I look at regularly. Usually buying a book is a sure fire guarantee I'll never look at it. I actually have a rcs/sccs book sitting on my shelf (good thing I proofread my messages ... I originally wrote sitting on myself which is close, but doesn't quite convey the same thing.) I bought it because it advertised a cvs section, but the cvs info turned out to be only a beginner level intro and nothing that useful for me. 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] PDF on pitot-static - comment
Page 46 of the PDF describes the pressure defect, with example values. Whether we can adapt this to be a useful lookup table is another matter. They also have nice equations, later on, converting test data into a model that predicts errors. However, the conversion implies having raw data. Maybe we can try to run the equations in reverse, but that isn't a straightforward derivative from the information in the document. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updating to new CVS trunk repository
Curtis L. Olson I actually have a rcs/sccs book sitting on my shelf (good thing I proofread my messages ... I originally wrote sitting on myself which is close, but doesn't quite convey the same thing.) I bought it because it advertised a cvs section, but the cvs info turned out to be only a beginner level intro and nothing that useful for me. The best things are sometimes free http://cvsbook.red-bean.com/ Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
Norman Vine writes: I am still not convinced that your tile is actually loaded though and don't really know the 'best' way to check for that given the 'lazy' loader. I can think of two options: 1. we can attach a separate deferred model queue to each deferred tile, so that the queue is not run until the tile is actually loaded; or 2. we can add an option to force tile loading. Option #1 is probably more efficient, but option #2 could be useful for other types of requirements (such as determining the elevation of a distant ground station). 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] More instruments: VSI and HI
Curtis L. Olson writes: The airspeed indicator is still working for me, even when the static system not servicable. I haven't done an ASI yet -- I need to model the pitot system for that. If you want to parameterize your turn-coordinator modeling code, In the C172S (serial #'s 172S8704 and on) the turn-coordinator is fed from the electrical bus 2 aka: /systems/electrical/outputs/bus[1] I think that's what I'd prefer to do. Right now, everything in Instrumentation/ is hard-coded, but once the major instruments are roughed in, I'll parameterize them. 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] Aircraft systems, take 1
There is a slightly more complex model for vacuum in Steam. I suggest you snag it and then delete it from Steam. Just out of curiosity, do you know if it's common for twins to have a separate vacuum pump attached to each engine in case of failure in IFR? I have no idea; I'm not AMEL rated. If nobody on the list can easily answer, I'll bounce the question off some of the CFI-AMEL people I know - next week. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external model positioning
Curtis L. Olson writes: I am working on interfacing an external flight model to FlightGear via the network. This particular code reports an altitude of zero/0.0f when the wheels are resting at sea level. The c172 3d model is drawn so that it's center of gravity is at the reported altitude. Also the pilot view point is also relative to this altitude. This means that on the ground, the out-the-window view point is just a few inches above the pavement. And also the 3d model is sunk into the ground. What do I need to do to get the pilot view point and the center of the 3d model up to the correct altitude? It used to be --prop:/sim/model/z-offset=offset in meters but I guess it's --prop:/sim/model/offsets/z-m=X now, but I am not sure if this info is actually available At least I couldn't find it with the httpd interface the closest thing I got was the path name to the model tempting-to-say-data-should-actually-be-in-C'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external model positioning
In src/Main/viewmgr.cxx I found: setPilotXOffset_m(fgGetDouble(/sim/current-view/x-offset-m)); setPilotYOffset_m(fgGetDouble(/sim/current-view/y-offset-m)); setPilotZOffset_m(fgGetDouble(/sim/current-view/z-offset-m)); This looks like it needs to be set in the global preferences file though. I need a way to set the pilot view offset in the aircraft-set.xml file (i.e. on a per aircraft basis.) Then I also need a way to do a similar z offset for the 3d model of the aircraf so it isn't half buried in the ground at startup. Anyone have any ideas? Curt. Norman Vine writes: Curtis L. Olson writes: I am working on interfacing an external flight model to FlightGear via the network. This particular code reports an altitude of zero/0.0f when the wheels are resting at sea level. The c172 3d model is drawn so that it's center of gravity is at the reported altitude. Also the pilot view point is also relative to this altitude. This means that on the ground, the out-the-window view point is just a few inches above the pavement. And also the 3d model is sunk into the ground. What do I need to do to get the pilot view point and the center of the 3d model up to the correct altitude? It used to be --prop:/sim/model/z-offset=offset in meters but I guess it's --prop:/sim/model/offsets/z-m=X now, but I am not sure if this info is actually available At least I couldn't find it with the httpd interface the closest thing I got was the path name to the model tempting-to-say-data-should-actually-be-in-C'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- 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] external model positioning
Curtis L. Olson writes: In src/Main/viewmgr.cxx I found: setPilotXOffset_m(fgGetDouble(/sim/current-view/x-offset-m)); setPilotYOffset_m(fgGetDouble(/sim/current-view/y-offset-m)); setPilotZOffset_m(fgGetDouble(/sim/current-view/z-offset-m)); This looks like it needs to be set in the global preferences file though. I need a way to set the pilot view offset in the aircraft-set.xml file (i.e. on a per aircraft basis.) Then I also need a way to do a similar z offset for the 3d model of the aircraf so it isn't half buried in the ground at startup. Anyone have any ideas? Hey, I have and idea ... I could just add an offset to the altitude I'm passing from the external flight model. That's kind of a hack and I'm not sure it's valid if the plane starts deviating significantly from straight and level, but by then you are probably going to be at altitude so 2' off won't make much difference ... (?) 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] PDF on pitot-static - comment
On Fri, 2002-09-27 at 17:26, Alex Perry wrote: Page 46 of the PDF describes the pressure defect, with example values. Whether we can adapt this to be a useful lookup table is another matter. They also have nice equations, later on, converting test data into a model that predicts errors. However, the conversion implies having raw data. Maybe we can try to run the equations in reverse, but that isn't a straightforward derivative from the information in the document. We can calculate freestream total pressure (eq. 2.29), you can then use that as your raw data. Note that you can't measure what you get from 2.29 supersonically, as a shock wave will form in front of the pitot tube. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external model positioning
Curtis L. Olson [EMAIL PROTECTED] said: In src/Main/viewmgr.cxx I found: setPilotXOffset_m(fgGetDouble(/sim/current-view/x-offset-m)); setPilotYOffset_m(fgGetDouble(/sim/current-view/y-offset-m)); setPilotZOffset_m(fgGetDouble(/sim/current-view/z-offset-m)); This looks like it needs to be set in the global preferences file though. I need a way to set the pilot view offset in the aircraft-set.xml file (i.e. on a per aircraft basis.) Then I also need a way to do a similar z offset for the 3d model of the aircraf so it isn't half buried in the ground at startup. Anyone have any ideas? Take a look at any of the 3d set files, they all have offsets from the origin for the Pilot's eye location (look in the view /view section). For adjusting the 3D model so that it's position is correct and not in or above the pavement, use the following syntax replacing the -0.0 with your values (omitted entries default to 0): offsets x-m-0.0/x-m y-m-0.0/y-m z-m-0.0/z-m /offsets This must be included in the xml file for the MODEL usually in the Aircraft/(AircraftType)/Models directories (not the set files). It has the effect of moving the origin of the 3D model from where it is by defined in the model file. There is also a pitch-deg and i think a heading-deg and roll-deg setting that you can use to twister 'round if necessary. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
