Ampere,
It's interesting that you should bring up this subject since the
electrical system is something I've been beating my head on this week.
Let me share my thoughts (which go in a bit of a different direction
from yours.)
1. The current electrical system is "data driven" rather than hardcoded,
but it was designed before nasal existed in FG.
2. Electrical systems can vary widely from airplane to airplane. It
makes sense to have a few representative examples, but for accurately
modeling the particular system on a particular aircraft, you are really
going to have to dig in and do some work.
3. The current electrical system model has some serious problems due to
short sighted design and the designer (me) not fully understanding the
problem I was trying to solve. This week I've been taking the Microsoft
"big hammer" approach of trying to beat something of dubious quality and
poor design into something that actually works and is useful ... using
overwhelming force. I'm ready to give up and trash the whole subsystem.
3a. The system is very complex with a lot of subtle interactions and
side effects. It's unclear for someone new coming into the project
exactly how it works and what you have to do to build a successful
electrical system model.
3b. The system can't handle things like battery charging without
introducing horrible hacks.
3c. The system can't do things like balance loads between two
alternators, again without horrible hacks.
3d. Try extracting the information you need to accurately drive an
ammeter gauge from the current system ... we will need even more
horrible hacks. :-(
4a. What we really need is someone who actually understands all this
stuff to build a better data driven electrical system model using a
better, more flexible approach. I am told that SPICE is a good example
of doing this right, but I'm a computer scientist with very little EE
knowledge or ability. Circuits strike fear into my heart.
4b. An alternate approach would be to write a "procedural" electrical
system model for each specific aircraft using nasal. But is there a way
to have a "default" nasal function that can be overwritten by an
aircraft specific function? I am almost favoring the nasal approach
here for many of these aircraft specific subsystems.
I realize this expands the discussion rather than focussing it, but I'm
getting really frustrated with the inabilities of the current electrical
system to do things like model battery charging (without trying to
charge itself and other goofy things), model ammeter gauges (i.e.
measure current flow between two different points in the "network"), do
load balancing between multiple alternators and a host of more complex
things. I like the idea of a v2.0 electrical system that is similar to
the current system, but designed by someone who knows what the
H-E-double toothpicks they are doing (obviously not me.) But in the
mean time, nasal would be a quick and dirty approach to getting a fairly
functional electrical system up and running pretty quickly.
Regards,
Curt.
Ampere K. Hardraade wrote:
A propsal regarding the generalization of aircraft systems
Abstract:
Currently, the electrical system seems to be the only system that can be
configured by the user. Other systems are either fully hardcoded into
Flightgear, or have yet to be modelled. Since dedication to code that
simulates such thing as hydraulic or bleed air system isn't going to appear
anytime soon, it is my opinion that it might be a good idea to modify the
electrical system into a more abstract/generic form. The idea is to make the
simulation of other aircraft systems easier. Of course, instead of being
hardcoded into Flightgear, unique behaviours to individual system may have to
make user-configurable somehow.
Problems:
Why should the electrical system be made generic?
Take the electrical system, hydraulic system, and bleed air system as the
examples. All these system are basically different forms of moving something
from point A, through medium B, to point C. That battery on the electrical
system is similar in function to the hydraulic fluid accumlator, or the air
tank in the bleed air system. In fact, they can all be modelled using a
Queue... or a Stack, storing a table of values. The electrical bus,
hydraulic and bleed air lines are similar in functions, and its
implementation can be as simple as *b = &a; (in C's terms). Because there
are so many commonalities between these systems, it would be wise to combine
them into one piece of code, and implements the behaviours of a specific
system using extensions.
Possible benfitis:
By generalizing systems, a framework is created which will make life easier
for other developers who wish to create new aircraft systems. I guess what I
am trying to advocate here is OOP for aircraft systems. To make this
approach more flexible and worthwhile, Nasal should be allowed to define the
system's behaviour. This way, Nasal scripts can be served as templates in
the creation of new aircraft systems for Flightgear, or allow non-programmers
like me to create new aircraft system without having to use C++. Let's say I
want to define a datalink system between avionics, all I would have to do is
treat the Queues as the buffers and write strings into them.
Possible issues:
As with any other dependency, there is a danger that changes to the generic
system may break all the aircraft systems. Therefore, should this proposal
gets implemented, the generic system would need to be implmented in such a
way to keep possible changes to the minimium. Also, having everything based
on a single framework would create single point failure. Hence, the generic
system would need to be very robust, or more than one implementation would be
needed.
Conclusion:
My intention is to bring attention to the simulation of aircraft systems, and
start some discussions among developers. I hope someone will take this
proposal into consideration.
Ampere
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
--
Curtis Olson http://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
