Hi Curt, thought I'd better switch the subject line:)
Using C/C++ for this sort of subsystem is probably the best choice and would certainly be the best way to go once an effective framework had been developed but at the stage I was working at, I was just trying to find out if the ideas and approaches I'd thought of would actually work in practice and so Nasal seemed ideal for this sort of rapid development/testing/prototyping. While I think I was able to make some progress and learn a lot about organising the different components, and mostly get things working, I was a long way from establishing a comprehensive framework that could be coded in C++ and then configured via xml. The big problem for me, personally, is that while I can understand C/C++ logic and basic syntax, and have been able to track down a couple of logic bugs in the FG code over the years, I wouldn't know where to start when it came to designing C++ code and integrating it into FG:( I guess it's because of that same gap in my understanding of C++ design that I just don't know how difficult it would be to change the scheduling policy of FG so that most of the subsystems ran at a fixed rate with just the graphics subsystem having a variable rate and using the resources that were left over after the other subsystems had their bite. LeeE > 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. Preamble below 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
