On Fri, Jan 2, 2009 at 10:19 AM, James Turner <zakal...@mac.com> wrote:
> > On 2 Jan 2009, at 13:50, Curtis Olson wrote: > > > However, the existing XML based electrical system model is extremely > > difficult to use from an xml configuration standpoint, and although > > it worked ok for the c172 electrical system, I began to run into > > core design barriers when i was attempting to implement the > > electrical system for a light twin. I really don't recommend the > > xml/C++ electrical system for future use. Instead, it's *far* > > easier and much more straight forward to build up a procedural model > > in nasal. This is actually a very good job for nasal because > > aircraft electrical systems are wildly different from each other, > > and nasal allows you to write a per-aircraft electrical system model. > > I don't think doing the complete system is Nasal is sensible - in the > future we might want to apply a 'real' electrical model, which > requires an iterative matrix solution, or something comparable (I > think it's actually solving some differential equations for each node > in the circuit, for example). > > The set of elements is very small, and well defined (as seen in the > existing C++ code) - batteries, switches, breakers, alternators, and > current drains. A few specialised derived types could be added, > especially for lamps (which are very visible), and which occur > frequently. And absolutely, this should be configured and defined > through Nasal, since clearly the arrangement of the above in each > aircraft differs wildly. But that doesn't mean we shouldn't express > (and expose!) the core graph to C++, for simulation, fault-modelling > and various other purposes. The same is true of the hydraulic system - > and indeed, many of the components work the same way. The problem is that as you get beyond a simple single engine electrical model with multiple generators, multiple batteries, all the different feed paths and protection circuitry, etc. life gets really complicated. Now you want to compute proper current draw based on sensors at different points in the system it gets way worse (the current xml based system isn't capable of doing that properly.) And then if you want to start adding some fault modeling for real pilot training it becomes completely insane. The problem with an electrical system model that can compute the result when you throw a bunch of parts and connections at it, is that the complexity explodes on you when you begin to look at all the different requirements. I'm not saying it's impossible, and I'm not saying we don't want such a detailed modeling system in our code. But trust me, no aircraft modeler other than myself (that I'm aware of) ever made any serious attempt at crafting up an xml based connection chart to actually model the correct electrical system of their aircraft. With nasal it is 100x simpler and more straightforward to procedurally meet all the objectives of providing power to the instruments and subsystems, computing loads, and doing fault modeling. Again, there's no reason you can't push forward and build a system that models all the physical properties of an electrical system at a low level. You might be tempted to adapt the current system, but it is hopelessly flawed and you will probably be better off starting from scratch if you really want to produce a system that works. And then to get aircraft designers to actually use it, you'll probably need to design a gui where they can graphically draw up the electrical system and make all the connections. But by then, a 100 line nasal script is starting to look 1,000x to maybe 10,000x easier and faster. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
