Re: [Flightgear-devel] Autopilot Bug/Feature
Curt wrote Vivian Meazza wrote: There is one - nearly - as I said orientation/heading-magnetic-deg. But it's not derived from an instrument, and therefore has no supply, neither can it fail, not does it have any error. Further, use of such a property will not stop, AFAIKS, the generation of spurious and unnecessary instruments, caused by incorrect initiation, and a hack to get around this. This looks unprofessional. As has always been the case, if the current instrumentation is not sufficient for your needs, you can always create a new instrument. /orientation/heading-magnetic-deg closely approximates an advanced inertial system you might find on an advanced modern aircraft. Reliable, trust worthy, dead on. You can also get true heading if you prefer that. If you need something that is tied to the electrical system, something that has various failure modes, something that models sensor error, or if you just don't like /orientation/heading-magnetic-deg for any other reason, then you'll need to consider modeling a new heading approximation system in nasal, or create a new instrument in C++ . There are some acronyms for these sorts of things, AHRS, IMU, INS. Your jet probably has some sort of ring laser based gyro system in real life? I don't know how deep you want to get into modeling this system. My goal is to stock the kitchen so all you cooks can create your culinary masterpieces. But if you want some new vegetable, you might need to plant it yourself. As I wrote in my original posting - that's already done - I've done a fluxgate compass suitable for use at least up to the '70s. I'll submit that for inclusion in CVS shortly. An even more modern instrument is trivial, but I haven't done one yet. I also have a patch prepared which prevents xmlauto.cxx from generating spurious instruments, and which uses whichever Heading Indicator that is present. That's probably a 'fancy waistcoat', and I'm still pondering if it's worth submitting. Vivian ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot Bug/Feature
På 16.06.2006 10:19 CEST skrev Vivian Meazza [EMAIL PROTECTED] snip... I also have a patch prepared which prevents xmlauto.cxx from generating spurious instruments, and which uses whichever Heading Indicator that is present. That's probably a 'fancy waistcoat', and I'm still pondering if it's worth submitting. As you can see the helpers in xmlauto are hardcoded to the instruments that existed and were also hardcoded at the time. I think that these helper values should be moved into the instrument code that they belong to. For example the heading error should be moved into the heading indicator instrument code. This would result in the heading error only being available when the heading indicator instrument was present in the instrumentation configuration file. Some other helper values are IMHO redundant and should be removed all together (vertical speed conversion into feet/s). -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot Bug/Feature
Roy Vegard Ovesen wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:flightgear- [EMAIL PROTECTED] On Behalf Of Sent: 16 June 2006 10:26 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Autopilot Bug/Feature På 16.06.2006 10:19 CEST skrev Vivian Meazza [EMAIL PROTECTED] snip... I also have a patch prepared which prevents xmlauto.cxx from generating spurious instruments, and which uses whichever Heading Indicator that is present. That's probably a 'fancy waistcoat', and I'm still pondering if it's worth submitting. As you can see the helpers in xmlauto are hardcoded to the instruments that existed and were also hardcoded at the time. I think that these helper values should be moved into the instrument code that they belong to. For example the heading error should be moved into the heading indicator instrument code. This would result in the heading error only being available when the heading indicator instrument was present in the instrumentation configuration file. Some other helper values are IMHO redundant and should be removed all together (vertical speed conversion into feet/s). I was just thinking of calculating the error values in Nasal, but I personally prefer your suggestion. V. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Autopilot Bug/Feature
Hi, In the course of developing the KC135, I noticed that parts of the autopilot function do not work in that model, copied from the B737 - the bits described as vor/loc and app. Investigation showed that the cause was simple - in JSBSim a jet ac does not have vacuum system. No vacuum - no Heading Indicator - no Heading Indicator - no vor/loc etc. So quick as a flash I rustled up an electrically driven one. Simple solution? Wrong: when I tried to implement a dedicated instrument.xml configuration for the KC135, using the new Heading Indicator, the old one was still present (and still inoperative). This is caused by xmlauto.cxx initiating before instrumentmgr.xml, and creating the unnecessary nodes which it needs. So I changed the initiation order. But by this time I realised that the simple Heading Indicator we have is not what would be fitted to a KC135, or indeed any jet ac since the '50s onward. We need what I would call a flux gate compass (you might know a more modern term). This is more or less just the property orientation/heading-magnetic-deg, but I thought that, for completeness a proper flux gate instrument electrically driven etc, would be nice. So I coded up one, and amended xmlauto.cxx so that it uses whichever sort is configured and does not generate spurious ones. Now, I might have got hold of the wrong end of the stick here, and someone may well know better. I intend to arrange the upload of these pretty trivial changes at the weekend unless otherwise directed, or as I would have said in a former existence UNODIR. Regards Vivian ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot Bug/Feature
I think the simple solution here is to modify the autopilot config so the input is not from a vacuum driven heading indicator since you don't have one, but from a different property that you do have. The autopilot is designed to be very configurable in this respect and even though it can be complex, you can create a custom config for each aircraft that matches it's real world capabilities and design quite closely. Curt. Vivian Meazza wrote: In the course of developing the KC135, I noticed that parts of the autopilot function do not work in that model, copied from the B737 - the bits described as vor/loc and app. Investigation showed that the cause was simple - in JSBSim a jet ac does not have vacuum system. No vacuum - no Heading Indicator - no Heading Indicator - no vor/loc etc. So quick as a flash I rustled up an electrically driven one. Simple solution? Wrong: when I tried to implement a dedicated instrument.xml configuration for the KC135, using the new Heading Indicator, the old one was still present (and still inoperative). This is caused by xmlauto.cxx initiating before instrumentmgr.xml, and creating the unnecessary nodes which it needs. So I changed the initiation order. But by this time I realised that the simple Heading Indicator we have is not what would be fitted to a KC135, or indeed any jet ac since the '50s onward. We need what I would call a flux gate compass (you might know a more modern term). This is more or less just the property orientation/heading-magnetic-deg, but I thought that, for completeness a proper flux gate instrument electrically driven etc, would be nice. So I coded up one, and amended xmlauto.cxx so that it uses whichever sort is configured and does not generate spurious ones. Now, I might have got hold of the wrong end of the stick here, and someone may well know better. I intend to arrange the upload of these pretty trivial changes at the weekend unless otherwise directed, or as I would have said in a former existence UNODIR. Regards Vivian ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot Bug/Feature
In the course of developing the KC135, I noticed that parts of the autopilot function do not work in that model, copied from the B737 - the bits described as vor/loc and app. Investigation showed that the cause was simple - in JSBSim a jet ac does not have vacuum system. No vacuum - no Heading Indicator - no Heading Indicator - no vor/loc etc. Vivian I don't understand this. Is it that JSBSim code is missing some internal capability, or that most JSBSim aircraft models (the XML files) do not seem to have defined a vacuum system? Is this a code or a definition problem? Jon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot Bug/Feature
Vivian Meazza wrote: Hi, In the course of developing the KC135, I noticed that parts of the autopilot function do not work in that model, copied from the B737 - the bits described as vor/loc and app. Investigation showed that the cause was simple - in JSBSim a jet ac does not have vacuum system. No vacuum - no Heading Indicator - no Heading Indicator - no vor/loc etc. So quick as a flash I rustled up an electrically driven one. Simple solution? Wrong: when I tried to implement a dedicated instrument.xml configuration for the KC135, using the new Heading Indicator, the old one was still present (and still inoperative). This is caused by xmlauto.cxx initiating before instrumentmgr.xml, and creating the unnecessary nodes which it needs. So I changed the initiation order. But by this time I realised that the simple Heading Indicator we have is not what would be fitted to a KC135, or indeed any jet ac since the '50s onward. We need what I would call a flux gate compass (you might know a more modern term). This is more or less just the property orientation/heading-magnetic-deg, but I thought that, for completeness a proper flux gate instrument electrically driven etc, would be nice. So I coded up one, and amended xmlauto.cxx so that it uses whichever sort is configured and does not generate spurious ones. Can't you just supply whatever property regarding the vacuum system that the instrument is looking for? Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot Bug/Feature
On Wednesday 14 June 2006 21:51, Josh Babcock wrote: Can't you just supply whatever property regarding the vacuum system that the instrument is looking for? He could (which ISTR I had to do for the Lightning) but I think it would be nice to have the correct system available too. Some aircraft have multiple types of the same instrument to provide emergency backups and providing for this is where the hacks start to get a bit messy I think. Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot Bug/Feature
Curt wrote I think the simple solution here is to modify the autopilot config so the input is not from a vacuum driven heading indicator since you don't have one, but from a different property that you do have. There is one - nearly - as I said orientation/heading-magnetic-deg. But it's not derived from an instrument, and therefore has no supply, neither can it fail, not does it have any error. Further, use of such a property will not stop, AFAIKS, the generation of spurious and unnecessary instruments, caused by incorrect initiation, and a hack to get around this. This looks unprofessional. The autopilot is designed to be very configurable in this respect and even though it can be complex, you can create a custom config for each aircraft that matches it's real world capabilities and design quite closely. So it is. Except the existing Heading Indicator is quite inappropriate for even halfway recent military or civil aircraft. Vivian Meazza wrote: In the course of developing the KC135, I noticed that parts of the autopilot function do not work in that model, copied from the B737 - the bits described as vor/loc and app. Investigation showed that the cause was simple - in JSBSim a jet ac does not have vacuum system. No vacuum - no Heading Indicator - no Heading Indicator - no vor/loc etc. So quick as a flash I rustled up an electrically driven one. Simple solution? Wrong: when I tried to implement a dedicated instrument.xml configuration for the KC135, using the new Heading Indicator, the old one was still present (and still inoperative). This is caused by xmlauto.cxx initiating before instrumentmgr.xml, and creating the unnecessary nodes which it needs. So I changed the initiation order. But by this time I realised that the simple Heading Indicator we have is not what would be fitted to a KC135, or indeed any jet ac since the '50s onward. We need what I would call a flux gate compass (you might know a more modern term). This is more or less just the property orientation/heading-magnetic-deg, but I thought that, for completeness a proper flux gate instrument electrically driven etc, would be nice. So I coded up one, and amended xmlauto.cxx so that it uses whichever sort is configured and does not generate spurious ones. Now, I might have got hold of the wrong end of the stick here, and someone may well know better. I intend to arrange the upload of these pretty trivial changes at the weekend unless otherwise directed, or as I would have said in a former existence UNODIR. Regards Vivian ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot Bug/Feature
Jon In the course of developing the KC135, I noticed that parts of the autopilot function do not work in that model, copied from the B737 - the bits described as vor/loc and app. Investigation showed that the cause was simple - in JSBSim a jet ac does not have vacuum system. No vacuum - no Heading Indicator - no Heading Indicator - no vor/loc etc. Vivian I don't understand this. Is it that JSBSim code is missing some internal capability, or that most JSBSim aircraft models (the XML files) do not seem to have defined a vacuum system? Is this a code or a definition problem? Well, unless you can show me that modern jet aircraft have a vacuum system that is gear driven from the engine or bled from it somewhere - the existing code is just fine and totally realistic. The problem is that the existing Heading Indicator is not the correct instrument, vacuum or electrically driven, and there is some programming that could be improved a little, but not in JSBSim. Vivian ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot Bug/Feature
AJ wrote On Wednesday 14 June 2006 21:51, Josh Babcock wrote: Can't you just supply whatever property regarding the vacuum system that the instrument is looking for? He could (which ISTR I had to do for the Lightning) but I think it would be nice to have the correct system available too. Some aircraft have multiple types of the same instrument to provide emergency backups and providing for this is where the hacks start to get a bit messy I think. We really don't need to hack this one. Sure we could paper over this one with a few lines of Nasal, but that won't solve the underlying problem (minor but below the high standards we set ourselves, or I thought we did) Vivian ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot Bug/Feature
Josh Vivian Meazza wrote: Hi, In the course of developing the KC135, I noticed that parts of the autopilot function do not work in that model, copied from the B737 - the bits described as vor/loc and app. Investigation showed that the cause was simple - in JSBSim a jet ac does not have vacuum system. No vacuum - no Heading Indicator - no Heading Indicator - no vor/loc etc. So quick as a flash I rustled up an electrically driven one. Simple solution? Wrong: when I tried to implement a dedicated instrument.xml configuration for the KC135, using the new Heading Indicator, the old one was still present (and still inoperative). This is caused by xmlauto.cxx initiating before instrumentmgr.xml, and creating the unnecessary nodes which it needs. So I changed the initiation order. But by this time I realised that the simple Heading Indicator we have is not what would be fitted to a KC135, or indeed any jet ac since the '50s onward. We need what I would call a flux gate compass (you might know a more modern term). This is more or less just the property orientation/heading-magnetic-deg, but I thought that, for completeness a proper flux gate instrument electrically driven etc, would be nice. So I coded up one, and amended xmlauto.cxx so that it uses whichever sort is configured and does not generate spurious ones. Can't you just supply whatever property regarding the vacuum system that the instrument is looking for? Why would I want to do that when a proper solution is to hand? It's only a handful of lines of code to fix this, and I've already written them. Vivian ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
