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 PropertyList filter nameCDI0 lowpass/name debugfalse/debug typeexponential/type filter-time2.0/filter-time inputinstrumentation/nav[0]/heading-needle-deflection-norm/input outputinstrumentation/nav[0]/filtered-cdiNAV0-deflection/output /filter !-- More filters here -- /PropertyList And add autopilot nameA very descriptive name for this file like Instrument-Filter/name pathAircraft/c172p/path/to/that/file/path /autopilot 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 nameautopilot helpers/name pathAircraft/Generic/generic-autopilot-helper.xml/path /autopilot 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/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 PropertyList filter nameCDI0 lowpass/name debugfalse/debug typeexponential/type filter-time2.0/filter-time inputinstrumentation/nav[0]/heading-needle-deflection-norm/input outputinstrumentation/nav[0]/filtered-cdiNAV0-deflection/output /filter !-- More filters here -- /PropertyList And add autopilot nameA very descriptive name for this file like Instrument-Filter/name pathAircraft/c172p/path/to/that/file/path /autopilot 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 nameautopilot helpers/name pathAircraft/Generic/generic-autopilot-helper.xml/path /autopilot 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/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 PropertyList filter nameCDI0 lowpass/name debugfalse/debug typeexponential/type filter-time2.0/filter-time inputinstrumentation/nav[0]/heading-needle-deflection-norm/input outputinstrumentation/nav[0]/filtered-cdiNAV0-deflection/output /filter !-- More filters here -- /PropertyList And add autopilot nameA very descriptive name for this file like Instrument-Filter/name pathAircraft/c172p/path/to/that/file/path /autopilot 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 nameautopilot helpers/name pathAircraft/Generic/generic-autopilot-helper.xml/path /autopilot 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/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 PropertyList filter nameCDI0 lowpass/name debugfalse/debug typeexponential/type filter-time2.0/filter-time inputinstrumentation/nav[0]/heading-needle-deflection-norm/input outputinstrumentation/nav[0]/filtered-cdiNAV0-deflection/output /filter !-- More filters here -- /PropertyList And add autopilot nameA very descriptive name for this file like Instrument-Filter/name pathAircraft/c172p/path/to/that/file/path /autopilot 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 PropertyList include=NAVandGSfilters.xml 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 PropertyList 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 PropertyList 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
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( ?xml version = '1.0' encoding = 'UTF-8' ?\n );
print( PropertyList\n );
for( var i = 0; i 1.05; i += 0.05 ) {
print( entry\n );
var l = (1.0-i) * oleo/2;
l += (scissor_dist-oleo)/2;
print( ind ~ sprintf(%4.3f, i ) ~ /ind\n );
print( dep ~ sprintf(%4.3f, acos( l / scissor ) * R2D - theta0
) ~ /dep\n );
print( /entry\n );
}
print( /PropertyList\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
PropertyList
filter
nameCDI0 lowpass/name
debugfalse/debug
typeexponential/type
filter-time2.0/filter-time
inputinstrumentation/nav[0]/heading-needle-deflection-norm/input
outputinstrumentation/nav[0]/filtered-cdiNAV0-deflection/output
/filter
!--
More filters here
--
/PropertyList
And add
autopilot
nameA very descriptive name for this file like Instrument-Filter/name
pathAircraft/c172p/path/to/that/file/path
/autopilot
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
The stand-alone nasal compiled fine. Any ideas what is wrong here? No idea, sorry. It runs fine here and creates this result: ?xml version = '1.0' encoding = 'UTF-8' ? PropertyList entry ind0.000/ind dep0.000/dep /entry entry ind0.050/ind dep1.751/dep /entry entry ind0.100/ind dep3.463/dep /entry entry ind0.150/ind dep5.140/dep /entry entry ind0.200/ind dep6.786/dep /entry entry ind0.250/ind dep8.404/dep /entry entry ind0.300/ind dep9.996/dep /entry entry ind0.350/ind dep11.565/dep /entry entry ind0.400/ind dep13.112/dep /entry entry ind0.450/ind dep14.640/dep /entry entry ind0.500/ind dep16.151/dep /entry entry ind0.550/ind dep17.646/dep /entry entry ind0.600/ind dep19.126/dep /entry entry ind0.650/ind dep20.593/dep /entry entry ind0.700/ind dep22.048/dep /entry entry ind0.750/ind dep23.493/dep /entry entry ind0.800/ind dep24.928/dep /entry entry ind0.850/ind dep26.355/dep /entry entry ind0.900/ind dep27.775/dep /entry entry ind0.950/ind dep29.188/dep /entry entry ind1.000/ind dep30.595/dep /entry /PropertyList 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
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
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
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( ?xml version = '1.0' encoding = 'UTF-8' ?\n );
print( PropertyList\n );
for( var i = 0; i 1.05; i += 0.05 ) {
print( entry\n );
var delta_h = i * h_norm;
print( ind ~ sprintf(%4.3f, i ) ~ /ind\n );
print( dep ~ sprintf(%4.3f, (acos( (h0 -delta_h) / Radius_main
) - theta0 ) * R2D ) ~ /dep\n );
print( /entry\n );
}
print( /PropertyList\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
