This is starting to enter the realm of my own opinions so please keep that
in mind.
Nasal was never intended to do work at this low level. However, the fact
that it can be used to successfully model an advanced flight control system
[mostly successfully] says a lot about the capabilities of nasal and how
tightly it's been integrated into FlightGear.
Typically in a real time system you'd want to seriously consider coding
stuff that runs often and at high rates of speed in native C/C++. If you
did that, you would be able to tie your code into run at FDM rates.
In my opinion, if someone can write advanced nasal code, it's only a small
step beyond that to be able to write full fledged C code. Nasal is very
"C-like" in many ways. Probably the biggest barrier for most people is
going to be getting their development system setup properly so they can
compile their new code additions or changes.
Regards,
Curt.
On 10/24/07, leee wrote:
>
> On Wednesday 24 October 2007 11:21, Melchior FRANZ wrote:
> [snip...]
> >
> > Listeners should be used on properties to get notice about
> > occasional changes. In cases where we *know* when the property
> > changes -- once per loop or more often -- we can have the same
> > result cheaper with a loop. (Listeners on YASim properties are
> > special in that those can change several times per frame, and
> > one may indeed want the listener triggered every time. But this
> > should be a deliberate decision, not an accident.)
> >
>
> This touches on the area that became a show-stopper for me and while it's
> good
> news to see some of the problems being chased down and cleared imho there
> are
> still some vital things that need to be addressed.
>
> The problem, as I see it, is that there are two different timing regimes
> in
> FG: the fixed rate FDM timing and the variable frame-rate timing. That
> is,
> the FDM operates at a fixed rate (I believe the default is 120 Hz) but
> nearly
> everything else, afaikt, operates at the frame rate, which varies.
>
> This means that if I'm trying to use Nasal (and the A/P PID controllers
> and
> filters) in a FBW framework not only do I need them to run at a specified
> fixed and non-varying rate but ideally I'd want them to run at the FDM
> fixed
> rate and in lock-step with it because if I just run these subsystems at
> the
> FDM fixed rate, but not locked to the FDM clock, they are likely to drift
> and
> I'd end up getting an effective rate that varied between the FDM rate and
> the
> FDM rate/2 as they drift into and out of synchronisation.
>
> Because 120 Hz isn't really that high, in the context of GHz processing
> speeds, I would have thought Nasal would be ok for this purpose but am I
> expecting too much of it?
>
> Perhaps the real problem is that nearly every other subsystem, apart from
> the
> FDM, get their turn on the CPU within the frame-rate loop and although
> this
> would seem to make obvious sense, because the graphics sub-system is by
> far
> the greatest user of resources, I'd suggest that if the other subsystems
> use
> so little of the available resources, giving them priority over the
> graphics
> would have a negligible impact on the frame rate, which is variable
> according
> to graphics load anyway.
>
> For example, if the graphics subsystem uses 95% of resources to produce 40
> fps
> it's still likely to return > 35 fps if it's only given 90% of resources
> (and
> anything much over 25-30 fps is wasted on human eyes anyway).
>
> Perhaps I'm just using the wrong approach but like I said, expecting
> 100-200
> Hz rates doesn't seem too ambitious in the context of GHz processors.
>
> If, however, there are good reasons why Nasal can't run at these rates
> (and
> the A/P PID controllers and filters, being time based _need_ to run at
> fixed
> rates in any case), what would be the best solution?
>
> LeeE
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
