RE: [Flightgear-devel] altitude hold problem
That's actually a counter-example: this is all information that FlightGear will have to have by default, but FDMs like JSBSim will not (necessarily) -- since FlightGear owns the panel and the UI, it is the component that tracks the position of every switch, stick, and so on. JSBSim will need to have all this information to model the aircraft in standalone mode. Additionally, if JSBSim does have all this information, the aircraft should still fly even if FlightGear is started up using the C-172 panel, the FCS using default values. The aircraft modeler will have intimate knowledge (we hope) of the FCS for an aircraft, and the FCS definition for a unique aircraft best resides in the config file along with the rest of the aircraft specific characteristics. JSBSim is not only a FlightGear FDM, as I have mentioned before. We have an excuse to include the FCS (and autopilot and other non-visual but still flight related models) in that JSBSim also serves (and aims to serve) aero engineering students. It's meant to be a flight dynamics tool for study and FCS experimenting. In general, I might agree with you. You could split out the FCS, the autopilot, the EOM, the propulsion, etc. Then, at some point, you might say, Hey! Let's put all of these classes under a base class that gives us some utility, some generality, and it just makes sense. Then you'd put it altogether and you'd have basically what we have. JSBSim has not been put together in a vacuum, nor without industry precedent. Given ten different people (from ten different backgrounds) you'd get ten different flight models. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] altitude hold problem
Jon S. Berndt wrote: Alex wrote: For starters, can the JSB filters (etc) stuff be used without JSBSim? The base class of all JSBSim classes - including the FCS classes - is FGJSBBase. So, technically, no. This would be a good feature to look at breaking out of the FDM. At its most reductionist, a FCS system compares (1) pilot control inputs and (2) FDM output to produce control surface positions. None of that requires access to the internals of the FDM. A well-designed FCS would work with any conceivable FDM. Here's a plausible black-box model: the FCS subsystem takes its control inputs from the /controls/ property tree, and places its output into the /fcs/ tree. So, we'd modify the FDM configurations to look there instead, and no code change would be necessary. We could (unsuccessfully) fly a C172 with a F-16 fly-by-wire system without change. The way I see it now (and it's just off the top of my head) is that *IF* the JSBSim config file specifies an autopilot for an aircraft, then that autopilot would be used instead of the one from the FlightGear side. This is because I'd also like the ability to run it with JSBSim standalone. I don't see why moving the FCS out of JSBSim precludes your ability to run the thing standalone. You could maintain your own tree independant of FlightGear as you do right now (or just keep it in the JSB tree next to the FDM). Alternatively, you could place it in SimGear, which is designed as a library already. There are lots of options. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] altitude hold problem
I don't see why moving the FCS out of JSBSim precludes your ability to run the thing standalone. You could maintain your own tree independant of FlightGear as you do right now (or just keep it in the JSB tree next to the FDM). Alternatively, you could place it in SimGear, which is designed as a library already. There are lots of options. There certainly are a lot of options, including the ones you specify above. My plan is to keep the proposed autopilot classes under the JSBSim base class structure and use already available JSBSim classes as building blocks. Certainly another option is for a separate autopilot code to be built completely apart from JSBSim (indeed this already exists), but I'd still want to build an autopilot for JSBSim - whether or not it even got used. The class structure, config file arrangement, etc. are all already there. The extra code an autopilot would use would be minimal. Also, FlightGear is not the only user of JSBSim, and I suspect an autopilot feature would be useful for them. Jon Jon Berndt Coordinator, JSBSim Project http://jsbsim.sf.net Enter BUG REPORTS at http://sf.net/tracker/?atid=119399group_id=19399 Enter FEATURE REQUESTS at http://sf.net/tracker/?atid=369399group_id=19399 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] altitude hold problem
On Wed, 2002-01-16 at 10:13, Andy Ross wrote: Jon S. Berndt wrote: Alex wrote: For starters, can the JSB filters (etc) stuff be used without JSBSim? The base class of all JSBSim classes - including the FCS classes - is FGJSBBase. So, technically, no. This would be a good feature to look at breaking out of the FDM. At its most reductionist, a FCS system compares (1) pilot control inputs and (2) FDM output to produce control surface positions. None of that requires access to the internals of the FDM. A well-designed FCS would work with any conceivable FDM. For 90% of what FG is used for this is probably true. For the general case, however, it depends on how much data you want to put into the property tree and/or on the bus. Even moderately sophisticated flight control systems can be dependent on quite a number of parameters. Here's a plausible black-box model: the FCS subsystem takes its control inputs from the /controls/ property tree, and places its output into the /fcs/ tree. So, we'd modify the FDM configurations to look there instead, and no code change would be necessary. We could (unsuccessfully) fly a C172 with a F-16 fly-by-wire system without change. The way I see it now (and it's just off the top of my head) is that *IF* the JSBSim config file specifies an autopilot for an aircraft, then that autopilot would be used instead of the one from the FlightGear side. This is because I'd also like the ability to run it with JSBSim standalone. I don't see why moving the FCS out of JSBSim precludes your ability to run the thing standalone. You could maintain your own tree independant of FlightGear as you do right now (or just keep it in the JSB tree next to the FDM). Alternatively, you could place it in SimGear, which is designed as a library already. There are lots of options. Again, viable for 90% of what FG does, but not for the general case. Any FCS that incorporates stability augmentation, for example, will be very specific to that aircraft (and sometimes even sub-models). Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ 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] altitude hold problem
On Tue, 2002-01-15 at 18:52, Alex Perry wrote: On Tue, 2002-01-15 at 07:19, Christian Mayer wrote: What we really need here is for our resident flight control systems expert to whip us up a program for generating the control law gains based on the config file ... It's probably easier to adapt the autoconfiguration algorithms for PID controllers so that the autopilot derives the parameters automatically. It typically only needs to be done once. ___ 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] altitude hold problem
From: Andy Ross In fact, this is a good example: a real F-16A (Dunno about the C) flight control computer takes its input from a set of gyros and from the position of the stick, and that's it The F-16 DFCS (beginning with Block 40) - and I suspect to some degree also the F-16A model - also requires the inputs of a rather lot of switch positions (commonly referred to as notes), e.g. pitch switch position, absolute value of phi greater than some value, WOW, roll switch position, standby gains enabled, control stick steering force greater than some value, other notes, etc. These are very aircraft specific. So, as you state below, yes the FCS needs to know some very specific aircraft information. The issue isn't whether the FCS needs to know specific per-aircraft information. Of course it does. The issue is whether the FCS *code* requires access to the internals of the FDM. I argue that it does not. I'd tend to agree with you, there. The only thing I am really arguing is that for JSBSim: 1) The FCS is already being modeled. We want to do it. We like doing it. 2) We *needed* to do it. There simply wasn't anything like it prior to JSBSim, and still isn't AFAIK. 3) Is there anyone else out there who can model a generic FCS and/or wants to? 4) The class hierarchy we have produced already includes the FCS building blocks and the class hierarchy will be kept intact. 5) An autopilot would be a natural outgrowth of the FCS code we currently have. 6) The FCS theoretically doesn't need to know the innards of the FDM, but it sure makes it easier - perhaps even removing a level of extraneous abstraction. Jon Jon Berndt Coordinator, JSBSim Project http://jsbsim.sf.net Enter BUG REPORTS at http://sf.net/tracker/?atid=119399group_id=19399 Enter FEATURE REQUESTS at http://sf.net/tracker/?atid=369399group_id=19399 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] altitude hold problem
Martin. P.S.: I _really_ believe it would be wise to separate FDM and FCS using a clean interface - but this is different from the above ;-) In JSBSim it already is. There appears to be a misconception that the FDM and FCS are inappropriately linked together. In JSBSim the atmosphere, rotational and translational dynamics, ground reactions, aerodynamic forces, mass properties, flight control system, propulsion, trimming, initialization, etc. are all separate models/entities. Together they comprise everything one needs to simulate an aircraft non-visually. This is one thing JSBSim is designed to do - to simulate aircraft in batch mode or to be the flight model guts for a visual simulator. We keep the FCS code pieces in a separate directory from the rest of the JSBSim FDM code. The FCS class manages a set of FCS building blocks. These building blocks can get the values of parameters they need from a single call to a retrieval mechanism, GetParameter(). Given this mission goal for the JSBSim class hierarchy, we are doing exactly what we set out to do, and in a wise way, I submit. Jon Jon Berndt Coordinator, JSBSim Project http://jsbsim.sf.net Enter BUG REPORTS at http://sf.net/tracker/?atid=119399group_id=19399 Enter FEATURE REQUESTS at http://sf.net/tracker/?atid=369399group_id=19399 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] altitude hold problem
Jim Wilson writes: Speaking of lawn darting there seems to be a problem with autopilot altitude hold with the c310 under jsbsim. You'll see the same problem with any higher-power plane in the JSBSim, YASim, or UIUC models. The current autopilot is closely tuned to the C172 (which, ironically, doesn't usually have an altitude autopilot axis anyway). Now that we support a lot of planes, we'll need to either write a new, configurable autopilot or rehaul the existing one. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] altitude hold problem
David Megginson wrote: Jim Wilson writes: Speaking of lawn darting there seems to be a problem with autopilot altitude hold with the c310 under jsbsim. You'll see the same problem with any higher-power plane in the JSBSim, YASim, or UIUC models. The current autopilot is closely tuned to the C172 (which, ironically, doesn't usually have an altitude autopilot axis anyway). Now that we support a lot of planes, we'll need to either write a new, configurable autopilot or rehaul the existing one. Well, the current aotipilot is usersettable. But the margins are probably too small. Anyway, these settings would be perfect for the aircraft XML. Isn't our property system great? CU, Chrisitan -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] altitude hold problem
On Tue, 2002-01-15 at 07:19, Christian Mayer wrote: What we really need here is for our resident flight control systems expert to whip us up a program for generating the control law gains based on the config file ... It's probably easier to adapt the autoconfiguration algorithms for PID controllers so that the autopilot derives the parameters automatically. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] altitude hold problem
Well, JSBSim theoretically has the building blocks for an autopilot, same as for an FCS. I have mentioned before that this is one thing I'd like to add in. The caveat of course is not to break anything that currently exists, piss anyone off, or preclude some other FDM from working correctly. :-) For starters, can the JSB filters (etc) stuff be used without JSBSim ? Anyhow, it's a ways down the road. Well, someone might give you a ride ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] altitude hold problem
Speaking of lawn darting there seems to be a problem with autopilot altitude hold with the c310 under jsbsim. Or at least that's what I'm getting...an instant lawn dart (stalls and drops). Tried 2000 and 4000ft. Jsb/c172 still works fine. The problem seemed to appear around when the rudder/aerilon trim was added, but I'm not sure. Anyone else seeing this or have I messed something up here? No, I've seen the same behavior, but working in a 747 Flight Mgmt Cptr/autopilot for operation over a LAN so not a real problem here. Running a CVS version from the last week in December which has the new trim functions Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
