Bill Galbraith wrote:
Can someone point me to a working electrical and/or hydraulic model being used
in a FlightGear aircraft? I saw one around somewhere, but I don't think it was
really being used.
I don't know that any one has done any serious hydraulic system modeling
in FlightGear. However the C172 should have a pretty complete
electrical system model, even to the point that the battery will
discharge and prevent engine start if you leave too many things powered
on for too long. The battery will recharge though once the engine is
running, and the amp meter and volt meter have plausible values through
all of this.
Generally, for systems modeling, Nasal is a *huge* asset for us. It's a
nearly complete programming language. It interfaces very well with the
guts of FlightGear. Finally, Nasal is a scripting langauge so it is
'interpretted' at run time. There is no need to have a development
system or compiler to create nasal scripts for flightgear.
This is a really powerful tool for systems modeling. As you know, the
systems on different aircraft are wildly different and very aircraft
specific. Often it's hard to have canned systems that work everywhere,
and often times 'configurable' canned systems can't cut it either.
Nasal gives you the opportunity to tailer fit your systems models to
your specific aircraft, and you don't need a compiler, you don't need a
development system on your machine, you just need to be able to edit
text files.
And all these nasal scripts can be kept with the other aircraft
configuration files so everything is neat and tidy and you haven't had
to hack up the flightgear code at all and build a custom version.
In one light twin project I used Nasal for the electrical system, then
annunciators (triggering the warnings, flashing for 10 seconds then
solid on, etc.), I used nasal to trigger a gear warning horn if you pull
the throttle all the way back without lowering the gear (well
technically if the MP of either engine drops below 14 as specified in
POH.) I've used Nasal as a bridge to map physical cockpit controls to
the corresponding flightgear controls. Sometimes there isn't a direct
one-to-one correspondence.
Furthermore, with FlightGear's property driven, xml configurable,
instrument panel system, you can build advanced 2d instruments, but hide
all the complexity inside nasal scripts. Our xml panel system is very
powerful on it's own, but sometimes things are a lot more clear and
efficient when done in nasal versus the xml panel system.
As an example, let me try to restate what I've done in another project.
1. We created some code to map the physical cockpit inputs into
corresponding properties. Those properties could be things that exist
as part of the standard set or new things you create.
2. We created some Nasal code to help map some of the complexities of
the hardware inputs to a simple set of FlightGear properties. For
instance, our gear up/down lever only gave an instantaneous blip in one
direction or the other and went back to neutral ... so I had to add some
nasal to map this to a property that was either on or off representing
up or down gear.
3. We created some Nasal code to model some specific aircraft systems
that weren't already handled well by the core FG infrastructure (i.e.
the electrical system.)
4. We created instruments that were driven by FlightGear properties ...
and these properties are driven can be created and updated by internal
code or by the aircrart specific nasal code.
The nice thing about this is that FlightGear can manage information flow
from end to end without needing to know all the specifics. Your
aircraft specific configurations and scripts can create and use new
properties (i.e. variables) on the fly. FlightGear doesn't care where
the information is coming from (i.e. cockpit hardware, joystick,
keyboard, mouse, etc.) It doesn't care if you add nasal scripts in
between to read in one set of property values, do some crunching, and
output another set of property values, and the instrument panel system
(and audio system) will happily be driven from any property (FG
variable) that exists (be it a default property or something created on
the fly by a custom nasal script.)
I'm probably not explaining all of that as well as the system deserves,
but it is ****REALLY**** slick, and gives aircraft designers an
incredible amount of power and flexibility to do just about anything
they would ever want (without needing to drag out a compiler and start
hacking on a large complex set code or learning a complex plugin system.)
Regards,
Curt.
--
Curtis Olson http://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________
Flightgear-users mailing list
[email protected]
http://mail.flightgear.org/mailman/listinfo/flightgear-users
2f585eeea02e2c79d7b1d8c4963bae2d
