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.



Ampere K. Hardraade wrote:

A propsal regarding the generalization of aircraft systems


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.


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.


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.


Flightgear-devel mailing list

Curtis Olson
HumanFIRST Program
FlightGear Project
Unique text:        2f585eeea02e2c79d7b1d8c4963bae2d

Flightgear-devel mailing list

Reply via email to