Re: [Flightgear-devel] c172p scissors interpolations and main rotation interpolations
> On 02/14/2011 11:58 AM, Torsten Dreyer wrote: > >> On 02/12/2011 12:59 PM, Torsten Dreyer wrote: > By the way. The filtering that will remain in the c172p > action-sim.nas for the nav radio could be moved to navradio.cxx. Here > again, the needle damping and the needle behavior when tuned to an > out-of-range frequency or when the gs is out of range is device > dependent. The filtered values are used by > Aircraft/Instruments-3d/vor/vor.xml and vor2.xml. I was afraid that > modifying navradio.cxx to achieve realistic needle behavior for this > vor model might break other vor/gs head or hsi models. > >>> > >>> We can now easily use the autopilot filters for that, just add a file > >>> with the content > >>> > >>> > >>> > >>> CDI0 lowpass > >>> false > >>> exponential > >>> 2.0 > >>> > >>> instrumentation/nav[0]/heading-needle-deflection-norm > >>> instrumentation/nav[0]/filtered-cdiNAV0-deflection > >>> > >>> > >>> > >>> > >>> And add > >>> > >>> A very descriptive name for this file like > >>> Instrument-Filter Aircraft/c172p/path/to/that/file > >>> > >>> > >>> to c172p-set.xml under /sim/systems > >>> > >>> No need for coding here, too. > >>> > >>> Greetings, Torsten > >> > >> I had not tried the kap140 in checking out the changes I submitted today > >> for the c172p. While implementing similar changes to the pa24-250, I > >> noticed that neither the Century IIB not the Century III autopilots work > >> with the above filter method. So I flew the c172p again and sure > >> enough, the kap140 is also broken by the above filter method. > >> Apparently having two autopilots in the same AC "ist verboten". > >> Torsten, have you tried two autopilots on an AC in the past? > > > > No, it's not "verboten" at all. I use four(!) autopilot files in the > > SenecaII (I prefer to call them property-rules because they are much more > > than just autopilot components). > > > > One pitfall is that in preferences.xml there is the generic-autopilot- > > helper.xml included at /sim/systems/autopilot[1]. If you add a second > > autopilot (property-rule), this one gets ignored/overwritten. If you rely > > on the properties handled there (and I assume the 172p does), you need to > > re-add it manually. Add > > > > autopilot helpers > > Aircraft/Generic/generic-autopilot-helper.xml > > > > together with your new rule and it should work. > > > > Torsten > > Thanks Torsten, > > I should have looked at the SenecaII set and base files. The answer to > my question ... have you tried ... was there. I still would not have > thought of the generic helper. > > Thanks again, > Dave P. Credit goes to James Turner, who figured that out after we had moved the autopilot helpers to the xml file. Back than, we decided to call this a "feature" and a way to encourage people to move away from the generic "helper" classes. Didn't turn out so well ;-) Torsten -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p scissors interpolations and main rotation interpolations
On 02/14/2011 11:58 AM, Torsten Dreyer wrote: >> On 02/12/2011 12:59 PM, Torsten Dreyer wrote: By the way. The filtering that will remain in the c172p action-sim.nas for the nav radio could be moved to navradio.cxx. Here again, the needle damping and the needle behavior when tuned to an out-of-range frequency or when the gs is out of range is device dependent. The filtered values are used by Aircraft/Instruments-3d/vor/vor.xml and vor2.xml. I was afraid that modifying navradio.cxx to achieve realistic needle behavior for this vor model might break other vor/gs head or hsi models. >>> We can now easily use the autopilot filters for that, just add a file >>> with the content >>> >>> >>> >>> CDI0 lowpass >>> false >>> exponential >>> 2.0 >>> instrumentation/nav[0]/heading-needle-deflection-norm >>> instrumentation/nav[0]/filtered-cdiNAV0-deflection >>> >>> >>> >>> >>> And add >>> >>> A very descriptive name for this file like >>> Instrument-Filter Aircraft/c172p/path/to/that/file >>> >>> >>> to c172p-set.xml under /sim/systems >>> >>> No need for coding here, too. >>> >>> Greetings, Torsten >> I had not tried the kap140 in checking out the changes I submitted today >> for the c172p. While implementing similar changes to the pa24-250, I >> noticed that neither the Century IIB not the Century III autopilots work >> with the above filter method. So I flew the c172p again and sure >> enough, the kap140 is also broken by the above filter method. >> Apparently having two autopilots in the same AC "ist verboten". >> Torsten, have you tried two autopilots on an AC in the past? > No, it's not "verboten" at all. I use four(!) autopilot files in the SenecaII > (I prefer to call them property-rules because they are much more than just > autopilot components). > > One pitfall is that in preferences.xml there is the generic-autopilot- > helper.xml included at /sim/systems/autopilot[1]. If you add a second > autopilot (property-rule), this one gets ignored/overwritten. If you rely on > the properties handled there (and I assume the 172p does), you need to re-add > it manually. Add > > autopilot helpers > Aircraft/Generic/generic-autopilot-helper.xml > > together with your new rule and it should work. > > Torsten > Thanks Torsten, I should have looked at the SenecaII set and base files. The answer to my question ... have you tried ... was there. I still would not have thought of the generic helper. Thanks again, Dave P. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p scissors interpolations and main rotation interpolations
> On 02/12/2011 12:59 PM, Torsten Dreyer wrote: > >> By the way. The filtering that will remain in the c172p action-sim.nas > >> for the nav radio could be moved to navradio.cxx. Here again, the > >> needle damping and the needle behavior when tuned to an out-of-range > >> frequency or when the gs is out of range is device dependent. The > >> filtered values are used by Aircraft/Instruments-3d/vor/vor.xml and > >> vor2.xml. I was afraid that modifying navradio.cxx to achieve realistic > >> needle behavior for this vor model might break other vor/gs head or hsi > >> models. > > > > We can now easily use the autopilot filters for that, just add a file > > with the content > > > > > > > > CDI0 lowpass > > false > > exponential > > 2.0 > > instrumentation/nav[0]/heading-needle-deflection-norm > > instrumentation/nav[0]/filtered-cdiNAV0-deflection > > > > > > > > > > And add > > > >A very descriptive name for this file like > > Instrument-Filter Aircraft/c172p/path/to/that/file > > > > > > to c172p-set.xml under /sim/systems > > > > No need for coding here, too. > > > > Greetings, Torsten > > I had not tried the kap140 in checking out the changes I submitted today > for the c172p. While implementing similar changes to the pa24-250, I > noticed that neither the Century IIB not the Century III autopilots work > with the above filter method. So I flew the c172p again and sure > enough, the kap140 is also broken by the above filter method. > Apparently having two autopilots in the same AC "ist verboten". > Torsten, have you tried two autopilots on an AC in the past? No, it's not "verboten" at all. I use four(!) autopilot files in the SenecaII (I prefer to call them property-rules because they are much more than just autopilot components). One pitfall is that in preferences.xml there is the generic-autopilot- helper.xml included at /sim/systems/autopilot[1]. If you add a second autopilot (property-rule), this one gets ignored/overwritten. If you rely on the properties handled there (and I assume the 172p does), you need to re-add it manually. Add autopilot helpers Aircraft/Generic/generic-autopilot-helper.xml together with your new rule and it should work. Torsten -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p scissors interpolations and main rotation interpolations
On 02/12/2011 12:59 PM, Torsten Dreyer wrote: >> By the way. The filtering that will remain in the c172p action-sim.nas >> for the nav radio could be moved to navradio.cxx. Here again, the >> needle damping and the needle behavior when tuned to an out-of-range >> frequency or when the gs is out of range is device dependent. The >> filtered values are used by Aircraft/Instruments-3d/vor/vor.xml and >> vor2.xml. I was afraid that modifying navradio.cxx to achieve realistic >> needle behavior for this vor model might break other vor/gs head or hsi >> models. > We can now easily use the autopilot filters for that, just add a file with the > content > > > > CDI0 lowpass > false > exponential > 2.0 > instrumentation/nav[0]/heading-needle-deflection-norm > instrumentation/nav[0]/filtered-cdiNAV0-deflection > > > > > And add > >A very descriptive name for this file like Instrument-Filter >Aircraft/c172p/path/to/that/file > > > to c172p-set.xml under /sim/systems > > No need for coding here, too. > > Greetings, Torsten > I had not tried the kap140 in checking out the changes I submitted today for the c172p. While implementing similar changes to the pa24-250, I noticed that neither the Century IIB not the Century III autopilots work with the above filter method. So I flew the c172p again and sure enough, the kap140 is also broken by the above filter method. Apparently having two autopilots in the same AC "ist verboten". Torsten, have you tried two autopilots on an AC in the past? I also tried using at the top of the actual autopilot xml file so the "new" filters in NAVandGSfilters.xml should have been as if they were part of the autopilot xml file. This gave no load error but also, the filters were not functioning. If I just copy the filters from NAVandGSfilters.xml into the actual autopilot xml right after the tag, everything works including the new filters. This feels like an ugly hack. Should either loading the new filters as a 2nd autopilot of including the pseudo autopilot in the tag have worked? Cheers, Dave P. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p scissors interpolations and main rotation interpolations
Hi All,
I also have the interpolation for the nose gear scissors done and working.
The main gear rotation interpolation is also done and working. I have been
busy on other projects today, so have not had time to clean this up for
a git push.
The main gear requires a different script based on the geometry. I
based the script on that section of action-sim.nas.
One issue in generalizing this approach; apparently jsbsim normalizes so
1 ~ 1 ft while yasim normalizes to compression set in the set file.
I can clean this up and push to git tomorrow or I can use Torsten's
autopilot
filter idea to allow the deletion of all of action-sim.nas. Should get that
done tomorrow also.
Main Gear script follows:
import("math");
var acos = func(x) { math.atan2(math.sqrt(math.abs(1-x*x)), x) }
var R2D = 180.0 / math.pi;
var Radius_main = 0.919879;
# Radius_main is the distance from the center of rotation to the tire
contact point
var h0 = 0.63872;
# ho is the vertical height of the center of rotation with no compression
var h_norm = 0.3048;
# h_norm is the height of the center of rotation with compression-norm = 1
var theta0 = acos(h0/Radius_main);
print( "\n" );
print( "\n" );
for( var i = 0; i < 1.05; i += 0.05 ) {
print( "\n" );
var delta_h = i * h_norm;
print( "" ~ sprintf("%4.3f", i ) ~ "\n" );
print( "" ~ sprintf("%4.3f", (acos( (h0 -delta_h) / Radius_main
) - theta0 ) * R2D ) ~ "\n" );
print( "\n" );
}
print( "\n" );
Dave P.
On 02/12/2011 04:03 PM, Stuart Buchanan wrote:
> Hi Guys,
>
> Thanks very much for looking at this. I had a play with it myself
> yesterday, and have XML interpolation code already working for the
> nose-gear in my local copy. I used an oleo length of 1ft as
> /gear/gear[0]/gear-compression-ft and
> /gear/gear[0]/gear-compression-norm seem to be the same by inspection,
> which looks fine to my eye. I think that should equate to the oleo
> length?
>
> I haven't looked at the main gear yet, and I'd like to get them both
> sorted before committing. Using an oleo length equal to twice the main
> gear compression should give the correct animation I think.
>
> I've also ported Torstens Nasal code to perl, which I'll add to the
> wiki once I've cleaned it up. Like Dave I couldn't get the latest
> version of Nasal to compile :)
>
> Dave - sounds like we've been duplicating effort in our enthusiasm to
> sort this. If you haven't managed to get the Nasal code working yet, I
> suggest I post the perl code and sort out the c172p. Then you should
> be able to sort out the pa24& pa28 pretty easily. First one finished
> gets to do the pittss1c :)
>
> -Stuart
>
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p scissors interpolations and main rotation interpolations
Hi Guys, Thanks very much for looking at this. I had a play with it myself yesterday, and have XML interpolation code already working for the nose-gear in my local copy. I used an oleo length of 1ft as /gear/gear[0]/gear-compression-ft and /gear/gear[0]/gear-compression-norm seem to be the same by inspection, which looks fine to my eye. I think that should equate to the oleo length? I haven't looked at the main gear yet, and I'd like to get them both sorted before committing. Using an oleo length equal to twice the main gear compression should give the correct animation I think. I've also ported Torstens Nasal code to perl, which I'll add to the wiki once I've cleaned it up. Like Dave I couldn't get the latest version of Nasal to compile :) Dave - sounds like we've been duplicating effort in our enthusiasm to sort this. If you haven't managed to get the Nasal code working yet, I suggest I post the perl code and sort out the c172p. Then you should be able to sort out the pa24 & pa28 pretty easily. First one finished gets to do the pittss1c :) -Stuart -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p scissors interpolations and main rotation interpolations
> > The stand-alone nasal compiled fine. Any ideas what is wrong here? > > No idea, sorry. It runs fine here and creates this result Ah - wait a minute, there used to be a release version and a cvs version from nasal and I think I have it installed from cvs here. Haven't used it for a while and have to browse through my harddrive to look for the sources I installed from... Torsten -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p scissors interpolations and main rotation interpolations
> The stand-alone nasal compiled fine. Any ideas what is wrong here? No idea, sorry. It runs fine here and creates this result: 0.000 0.000 0.050 1.751 0.100 3.463 0.150 5.140 0.200 6.786 0.250 8.404 0.300 9.996 0.350 11.565 0.400 13.112 0.450 14.640 0.500 16.151 0.550 17.646 0.600 19.126 0.650 20.593 0.700 22.048 0.750 23.493 0.800 24.928 0.850 26.355 0.900 27.775 0.950 29.188 1.000 30.595 Regards, Torsten -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p scissors interpolations and main rotation interpolations
I am having trouble getting the modified gearscissors.nas to run with
the stand alone nasal.
after adding the three numbers in gedit and saving the file, I get
$ nasal gearscissors.nas > GearScissorInterpolation.xml
Runtime error: undefined symbol
at gearscissors.nas, line 1
If I don't edit the file after copying just your template, I get
$ nasal gearscissors.nas > GearScissorInterpolation.xml
Parse error: parse error at line 5
which is what I would expect as I have not replaced the text with a number.
If I just add the first two numbers, I get a parse error at line 7 (as
expected), but If I add the 3rd number or even just delete or comment
out that line, I get
$ nasal gearscissors.nas > GearScissorInterpolation.xml
Runtime error: undefined symbol
at gearscissors.nas, line 1
Here is the gearscissors.nas after adding in the correct numbers for the
c172p nose strut:
import("math");
var acos = func(x) { math.atan2(math.sqrt(math.abs(1-x*x)), x) }
var R2D = 180.0 / math.pi;
var scissor_dist = 0.240626;
var scissor = 0.194716;
var oleo = 0.1893439;
var theta0 = acos(scissor_dist/2/scissor) * R2D;
print( "\n" );
print( "\n" );
for( var i = 0; i < 1.05; i += 0.05 ) {
print( "\n" );
var l = (1.0-i) * oleo/2;
l += (scissor_dist-oleo)/2;
print( "" ~ sprintf("%4.3f", i ) ~ "\n" );
print( "" ~ sprintf("%4.3f", acos( l / scissor ) * R2D - theta0
) ~ "\n" );
print( "\n" );
}
print( "\n" );
The stand-alone nasal compiled fine. Any ideas what is wrong here?
On 02/12/2011 12:59 PM, Torsten Dreyer wrote:
>> By the way. The filtering that will remain in the c172p action-sim.nas
>> for the nav radio could be moved to navradio.cxx. Here again, the
>> needle damping and the needle behavior when tuned to an out-of-range
>> frequency or when the gs is out of range is device dependent. The
>> filtered values are used by Aircraft/Instruments-3d/vor/vor.xml and
>> vor2.xml. I was afraid that modifying navradio.cxx to achieve realistic
>> needle behavior for this vor model might break other vor/gs head or hsi
>> models.
> We can now easily use the autopilot filters for that, just add a file with the
> content
>
>
>
> CDI0 lowpass
> false
> exponential
> 2.0
> instrumentation/nav[0]/heading-needle-deflection-norm
> instrumentation/nav[0]/filtered-cdiNAV0-deflection
>
>
>
>
> And add
>
>A very descriptive name for this file like Instrument-Filter
>Aircraft/c172p/path/to/that/file
>
>
> to c172p-set.xml under /sim/systems
>
> No need for coding here, too.
>
> Greetings, Torsten
>
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p scissors interpolations and main rotation interpolations
> By the way. The filtering that will remain in the c172p action-sim.nas > for the nav radio could be moved to navradio.cxx. Here again, the > needle damping and the needle behavior when tuned to an out-of-range > frequency or when the gs is out of range is device dependent. The > filtered values are used by Aircraft/Instruments-3d/vor/vor.xml and > vor2.xml. I was afraid that modifying navradio.cxx to achieve realistic > needle behavior for this vor model might break other vor/gs head or hsi > models. We can now easily use the autopilot filters for that, just add a file with the content CDI0 lowpass false exponential 2.0 instrumentation/nav[0]/heading-needle-deflection-norm instrumentation/nav[0]/filtered-cdiNAV0-deflection And add A very descriptive name for this file like Instrument-Filter Aircraft/c172p/path/to/that/file to c172p-set.xml under /sim/systems No need for coding here, too. Greetings, Torsten -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] c172p scissors interpolations and main rotation interpolations
Hi Stuart, Just a heads up. Since the scissors-length and scissors-distance are the H and L in action-sim.nas, I am using Torsten's how-to to move the nose gear link computations from action-sim.nas to xml interpolations. You can check this off your "to do" list. The c172p.ac file detail is not enough to get oleo, so I guessed that oleo is 2 inches less than scissors-distance. This washes out in the computation in any case. I will also replace the nasal main gear rotations as a function of compression with interpolations. I will post a nasal template for this similar to Torsten's gearscissors.nas along with documentation. Hope to have these two done today. I will also replace similar nasal acos and asin use in the pa24-250, the pa28-160 and the pittss1c as time permits. By the way. The filtering that will remain in the c172p action-sim.nas for the nav radio could be moved to navradio.cxx. Here again, the needle damping and the needle behavior when tuned to an out-of-range frequency or when the gs is out of range is device dependent. The filtered values are used by Aircraft/Instruments-3d/vor/vor.xml and vor2.xml. I was afraid that modifying navradio.cxx to achieve realistic needle behavior for this vor model might break other vor/gs head or hsi models. Regards, Dave P. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
