> Those are valid points from a JSBSim centric perspective, > but from FlightGear we have other FDMs that don't support the > same features so that fgfs has its own control methods > independant of specific FDMs. An argument could be made for > having a single control script for flying the same aircraft > type developed using JSBSim, YASim and UIUC models.
Yes, of course I'm coming from a JSBSim-centric approach, but I think what I am getting at is a generic concern for FlightGear. Say, for instance, that someone is using the socket interface to get inputs from FlightGear and to send a new aircraft location back to FlightGear (bypassing any FDM). Say that this user wants to take raw inputs and run them through their own processor and flight model. Any nasal scripts that act on the inputs would already have "corrupted" the pristine state of the inputs from the point of view of this user, no? I look at the JSBSim flight control modeling system as a real benefit for users who are using JSBSim and/or FlightGear-with-JSBSim in an industry or academic setting where they are specifically looking at GNC issues. That use is best served - in my opinion - when the entire flight control spec is consolidated in the <flight_control> section of a JSBSim aircraft config file. Some have modeled electrical systems using the same JSBSim flight control components. The building block/component approach that we use lends itself well to manipulation through the use of a graphical editor. At least one of those already exists and is under further development (in addition to JSBSim Commander, which I have had on the back burner for a while). I intend to make it easier (and in some cases, "possible") to model more systems (hydraulic, pneumatic, etc.) within the JSBSim control system paradigm. That doesn't preclude someone from writing a nasal script to do various things, and it doesn't require that all (or any) JSBSim-fdm aircraft models in the FlightGear base package actually _use_ that capability. But it does underscore the need for some degree of understanding that there are multiple ways that some things can be done, and for communication between various developers so that toes don't get stepped on, where "worlds collide" - particularly in the area of flight control. Since many (most?) FlightGear aircraft are only modeled by one or the other "major" FDM, and since something like automatic spoiler deployment is very aircraft- (or at least type-) specific, my argument is that something like what is in air-ground.nas is best (but not, of course, exclusively) done in the "conventional" way for the specific aircraft/FDM in question. > Perhaps the answer in the long run is to detach the JSBSim > flight control from JSBSim FDM so that they are configured > independantly and communicate to each other through the same > type of interface that FlightGear currently uses. Then users > can choose that as one available method for flight control. > FlightGear is still about creating a set of building blocks, > isn't it? Such an approach would probably be valuable to > folks wanting to use JSBSim in other projects as well. This will probably not happen. The JSBSim flight control code is integrated with the rest of the JSBSim FDM as part of an overall intentional consolidated architecture approach, which doesn't lend itself to being split out. The input/output mechanism is also something that would not lend itself well to being split out. Also, yes FlightGear is about building blocks, but as I mentioned above, and is known, there are now several ways to do the same things in some areas. One has to consider the feature sets of the various parts, the various ways of doing things. That freedom and choice also comes with potential "gotchas" - one can make choices that somewhere down the line will cause problems. There can be some undesirable side effects and interactions. > That said, it is good you brought this up, because obviously > there are some folks that don't realize this exists in > JSBSim. I just happened to know of the feature because you > mentioned it to me and also on the mailing list quite some time ago. > > Best, > > Jim ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
