Re: Success! (Was: Re: [Flightgear-devel] Cygwin / SimGear / Clouds 3Dcompile problem)
Durk Talsma wrote: - FlightGear runs fine now, but I seem to have some problems with my joystick configuration (CH yoke and pedals, both USB), specifically the POV-HAT, keeps spinning in circles. All the other buttons and axes seem to be working fine on both the yoke and pedals. Has anybody else had any problems with the POV axes??? Yes, the joysticks profiles you are using must have been written for Linux. It appears that axis numbering differs. Look here for a previous discussion : http://baron.flightgear.org/pipermail/flightgear-devel/2003-December/023455.html -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [PATCH] xmlauto.cxx for ils following
Jim Wilson writes: What we need is something that looks ahead and makes adjustments based on future error in order to avoid overruns due to the momentum of the aircraft. http://baron.flightgear.org/pipermail/flightgear-devel/2003-July/018510.html http://autopilot.sourceforge.net/kalman.html Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SVFR
Straight out of the manual: --- Special VFR allows the relaxation by ATC, in certain circumstances, of some restrictions to facilitate the operation of a flight without lowering the flight safety to an unacceptable level. SVFR is usually applied by ATC in Class D or E Control Zones, when weather and traffic conditions permit to allow private pilots access to aerodromes within them. SVFR flight will not however, be permitted outside of Control Zones. A flight plan is not required for an SVFR flight but ATC approval is. A request for a Special VFR clearance may be made in flight, but it may not necessarily be granted by ATC. Authorisation for an SVFR flight is a concession granted by ATC only when weather and traffic conditions permit. An SVFR clearance absolves the pilot from complying with: - the full requirements of IFR; and - the requirement to maintain a height of 1500ft above the highest fixed object within 600 metres of the aircraft if the height limitation specified in the clearance makes compliance with this requirement impossible. --- The bottom line is it isn't just for getting in and out below minimums. It is a required clearance before you will even be allowed into your destination if it lies within a class D or E CTR. In my *very* limited and mostly theoretical experience, SVFR clearances are given at fairly low altitudes 1000-2000ft to allow SVFR and IFR traffic to continue in the same control zone but obviously the SVFR flights are kept well away from the IFR ones. In most of the busy CTRs more often than not you will be refused an SVFR crossing and vectored around the edge of the CTR under a Radar Advisory Service by ATC. That is certainly the folklore anyway. AFAIK, (again, I may be wrong...) big airports such as Heathrow, Gatwick and Manchester do not allow SEP aircraft to land at all and will not accept non-IFR flights in or out. I've just looked at Southern England on my chart and most of it is class A above 2500' in the vacinity of the airports and class A from 4500' + due to the density of airways converging on the TMAs of the various big airports. Manchester in the North is famed for not permitting movements anywhere near it. SVFR or not. They provide a small low level corridor between Liverpool John Lennon and Manchester Int. which is marked NOT ABOVE 1250' Manchester QNH. This is meant to avoid the sizeable extra distance you would have to travel if routed around them. I've heard that often it is so congested that it's better to go around and pay for the fuel and hours rather than with your life... On the one hand, I am lucky because I live and fly further north where there are hardly any restrictions apart from airways which start at FL85+ (we are allowed to request crossing an airway but only at it's base FL and at 90 deg to the airway). On the other hand, I get very little experience of clearances and procedures coming from an untowered airfield. To try and combat this my flight school make sure we do a qualifying cross country which sees us cross lots of Military Air Traffic Zones (MATZs) and also land at Humberside international airport which is class D, I believe, and allows SEP aircraft and students too :-) There is an excellent piece in this months Flyer magazine which disproves some of the folk lore about refused clearances and makes for interesting reading. If you plan on flying here then I recommend getting hold of a copy and reading it. All the best, Matt. On 21:58 Fri 06 Feb , David Megginson wrote: I love visiting the UK, but it doesn't sound like a fun place to be a pilot with all those costs and restrictions. Outside of the occasional temporary flight restriction (TFR) in the U.S., I'm aware of nowhere in North America below FL180 that you need an instrument rating and IFR clearance to fly. Sometimes pilots have to reserve landing slots at the busiest airports like KLAX, but typically you just show up, and the fees are usually very low (some big airports, like Philadelphia, have no landing fee at all for a piston single). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Development Displays
IIRC, someone had come up with a way to display various properties on the HUD or instrument panel or something for debugging purposes. What was that? Take a look at Aircraft/T38/Instruments/aero.xml There's a more general way to do it, using static text for the field names. I'll make one now. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Development Displays
Take a look at Aircraft/T38/Instruments/aero.xml There's a more general way to do it, using static text for the field names. I'll make one now. Dave I'll want to try and make one for the prop aircraft so I can test the drag of the prop. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SVFR
Matthew Law wrote: The bottom line is it isn't just for getting in and out below minimums. It is a required clearance before you will even be allowed into your destination if it lies within a class D or E CTR. From what you posted, UK SVFR sounded like the same thing we have in North America -- a way to land or depart in MVFR, not a special way to get into controlled airspace when otherwise forbidden. I didn't see anything in the posting suggesting that you needed SVFR to enter class D or E airspace in good VMC, but I don't know all the underlying assumptions and background that a UK pilot would bring to it, so I could be missing something obvious. It's worth noting that ICAO classes D and E are the lightest types of controlled airspace: here's how I understand the ICAO airspace designations (the UK may have some variations): Class A: - IFR clearance required - VFR not allowed - ATC separation applied to all traffic - North America uses this only for traffic between FL180 (or higher in the arctic) and FL600 Class B: - IFR and VFR clearance required - ATC separation applied to all traffic - the U.S. uses this for busy airports like KSFO; Canada uses it for all controlled airspace between 12,500 ft and FL180, but never for airports. Class C: - IFR and VFR clearance required - ATC separation applied to all IFR traffic, and between IFR and VFR, but not between VFR and VFR - traffic advisories to VFR traffic when able - Canada uses this for large airports; the U.S. uses it for medium-sized ones Class D: - IFR clearance required - VFR radio contact with ATC required - ATC separation applied to IFR traffic only - traffic advisories to VFR traffic when able - Canada uses this for terminal area control zones; Canada and the U.S. both use it for small, towered airports Class E: - IFR clearance required - VFR does not require a clearance or radio contact, unless otherwise noted on the charts - ATC separation applied to IFR traffic only - traffic advisories to VFR traffic may be available on request - North America uses this for low-level airways, many untowered airports, control-zone extensions, etc. (but in Canada it all becomes class B at 12,500 ft). Class F: - unknown: the U.S. does not use it, and Canada uses it in a non-standard way (for restricted or advisory airspace) Class G: - no clearance required for IFR or VFR - no separation applied to IFR or VFR traffic So from my, probably flawed reading of the excerpt you posted, SVFR is simply a way to get under weather minima, but it is available only at smaller airports with class D or E airspace. It certainly couldn't get you inside Heathrow's airspace, if that is, in fact, class A as aeroplanner.com claims (we never use class A for airport control zones in North America). aside The separation rules for each class matter a lot to controllers -- if two planes get too close when separation is required, the controllers get a deal, and they lose their jobs after some small number [three or so]. So if two VFR aircraft get too close in class B, they have a deal; if two VFR aircraft get too close in class C, they do not, since they do not have to apply separation to VFR aircraft in class C. Understanding this can help a lot when dealing with ATC. European rules might be a bit different, again. /aside I'll be interested to learn more about how the UK airspace system works. Eventually, we'll have to have all of this knowledge programmed into our AI controllers in FlightGear. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Coding glitch in latest FGFS CVS?
Jon In file included from SkyRenderableInstance.hpp:27, from SkySceneManager.hpp:38, from SkySceneManager.cpp:29: mat33.hpp:60: warning: friend declaration `Vec3Type operator*(const Vec3Type, const Mat33Type)' declares a non-template function mat33.hpp:60: warning: (if this is not what you intended, make sure the function template has already been declared and add after the function name here) -Wno-non-template-friend disables this warning mat33.hpp:64: warning: friend declaration `Mat33Type operator*(Type, const Mat44Type)' declares a non-template function I'd just be taking a blind guess, but it looks like one of those errors that occurs when upgrading a gcc version (I'm running something archaic here so I wouldn't know). Did you try it's advice, regarding about adding after the function name? I think this should be friend Vec3Type operator * (const Vec3Type V, const Mat33Type M); ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Coding glitch in latest FGFS CVS?
In fact Stroustrup C.13.2 I think this is rather appropriate...the examples even about matrix and vector multiplication Chris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Coding glitch in latest FGFS CVS?
Starting to feel quite out of it now... there is NO typo. On Sat, 2004-02-07 at 14:47, Christopher S Horler wrote: In fact Stroustrup C.13.2 I think this is rather appropriate...the examples even about matrix and vector multiplication Chris ___ 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] Coding glitch in latest FGFS CVS?
On Sat, 2004-02-07 at 14:47, Christopher S Horler wrote: In fact Stroustrup C.13.2 I think this is rather appropriate...the examples even about matrix and vector multiplication Bad style replying to myself, before anyone points out the missing punctuation. I also think there's a typo in the example from my version of Stroustrup, in so much as there appears to be a missing T after Vector. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [PATCH] xmlauto.cxx for ils following
Norman Vine [EMAIL PROTECTED] said: Jim Wilson writes: What we need is something that looks ahead and makes adjustments based on future error in order to avoid overruns due to the momentum of the aircraft. http://baron.flightgear.org/pipermail/flightgear-devel/2003-July/018510.html http://autopilot.sourceforge.net/kalman.html For some reason the pupils of my eyes start gravitating together every time I read something with the word quaternion in it (which makes it even harder to read). I'm wondering if this particular application, auto-hovering, is translatable to fixed wing op (i.e. not overkill). How would we apply this (or something similar) to HDG A/P? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [PATCH] xmlauto.cxx for ils following
Jim Wilson writes: What we need is something that looks ahead and makes adjustments based on future error in order to avoid overruns due to the momentum of the aircraft. this is one approach using the Kalman filter http://icat-server.mit.edu/Library/Download/102_ICAT-99-5.pdf Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SVFR
Perhaps this was mentioned already, but I believe in the US in order to request an SVFR clearance at night you also have to be instrument rated and the plane must be equipped for IFR flight. I don't recall whether you have to be IFR current or not though. Sounds like you were fine in this respect though, just wanted to point it out. -Adam Ryan Larson [EMAIL PROTECTED] wrote: I have only had to ask for SVFR once.. and ironically it was because I needed to do a VFR night flight for my multi engine rating. We left KDPA north to KFLD. On the way back the visibility had dropped to about 2 miles and the cloud deck had dropped to about 1200 AGL. Now normally I would simply call up and get an IFR clearance to fly the approach, but to I needed to log this as a VFR trip. So we called up KDPA tower and asked for a SVFR clearance. They told us to hold 7 miles north of the field while they took care of two IFR flights landing. Once they were done with them, they allowed us to enter the airspace and land. We had to dodge some light snow showers and a few low clouds, but with the help of the Garmin 430 GPS, we were able to find the airport and land safely. Ryan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [PATCH] xmlauto.cxx for ils following
Norman Vine [EMAIL PROTECTED] said: Jim Wilson writes: What we need is something that looks ahead and makes adjustments based on future error in order to avoid overruns due to the momentum of the aircraft. this is one approach using the Kalman filter http://icat-server.mit.edu/Library/Download/102_ICAT-99-5.pdf Multi-antenna GPS based attitude sensors?!? I think my patch will take care of it for now. :-) Actually I've been thinking that a lookahead-sec parameter added to the controller config would work for this particular problem. We can always add alternative filters if that prooves insufficient for a particular application. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [PATCH] xmlauto.cxx for ils following
Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: Jim Wilson writes: What we need is something that looks ahead and makes adjustments based on future error in order to avoid overruns due to the momentum of the aircraft. this is one approach using the Kalman filter http://icat-server.mit.edu/Library/Download/102_ICAT-99-5.pdf Multi-antenna GPS based attitude sensors?!? I think my patch will take care of it for now. :-) Read the whole thesis disregarding the GPS correction stuff :-) He develops a simgle antenna GPS assisted Kalman based autopilot This is *very* similar to FGFS in that the position reported by the FDM is ~identical to a 'corrected' GPS signal Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [PATCH] xmlauto.cxx for ils following
Norman Vine [EMAIL PROTECTED] said: Read the whole thesis disregarding the GPS correction stuff :-) He develops a simgle antenna GPS assisted Kalman based autopilot This is *very* similar to FGFS in that the position reported by the FDM is ~identical to a 'corrected' GPS signal Yeah I know. The pdf file is still open on my desktop and I've been picking away at it here and there. It _is_ interesting. But developing this sounds like it's a little more than I was planning to get into right now. There's no doubt in my mind that PID's will do the job, even for hovering helicopters. I'm just looking to tweak them a bit. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [Fwd: Planning Community Based FOSS Event in NYC] (fwd)
Put onto the FGFS list in case east coast FGFS people are interested. Subject: [Fwd: Planning Community Based FOSS Event in NYC] From: Joe Phillips [EMAIL PROTECTED] To: Debian Events NA list [EMAIL PROTECTED] Date: 07 Feb 2004 13:05:02 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: scosug-wheel: Planning Community Based FOSS Event in NYC Date: 04 Feb 2004 20:40:59 -0800 This letter is to inform you and your group's members about current plans to try and organize a community based replacement for LinuxWorld in NYC. This community driven effort is being organized in NYC and will consist of trying to create annual regional FOSS event somewhat analogous to LinuxTag in Germany, with both speaker tracks that are fully open to the public and drawn from the community at large, and exhibit space for both commercial and non-commercial entities to use. Currently, we are asking for those interested in participating in this effort to appoint two delegates. These delegates will meet in NYC on Sunday, February 8th, 2004 (see details below) to elect an event committee. Each delegate so designated will be given one vote. The event committee so chosen will then be empowered to plan and organize this event, currently planned for the summer of 2005. By having delegates from interested parties choose to select the event committee, it is hoped to have a committee that can count on broad community support and legitimacy for their efforts, for working with corporate sponsors where nessisary, etc. We appreciate your time and patience in this effort. Any questions can be referred to Lyn Ohira [EMAIL PROTECTED] David Sugar GNU/FSF Lyn Ohira Gnubies -- Meeting Details: Time: Noon Date: Sunday Feb. 8th Place: The New Yorker Hotel, room 1560. The New Yorker is between 34th and 35th Streets on 8th Avenue. Location Details: New Yorker Hotel 481 8th Ave New York, NY (212-971-0101) mapquest: http://www.mapquest.com/maps/map.adp?latlongtype=internaladdtohistory=latitude=Rd6AEuS47E4%3dlongitude=kpp Fallback Meeting Location: Three Jewels Outreach Ctr 211 E 5th St New York, NY (212-475-6650) mapquest: http://www.mapquest.com/maps/map.adp?latlongtype=internaladdtohistory=latitude=JXYhEOEFUy4%3dlongitude=ucb ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
