Menu
▾
▴
Re: [Jsbsim-devel] JSBSim Script Tutorial 1 - Released
|
From: Bill G. <bi...@be...> - 2010-11-30 10:36:41
|
Curt, I took this public. Oh, I agree completely with you on that. Just between the old FAA standards they varied based on aircraft type (fixed or rotary winged) and level (FLight Training Devie, airplane simulator). The military tests use a different convention. That will partially be solved by the new Part 60, at least for FAA tests, and military trainers that want to use that standard, but non-US trainers won't use that. Maybe all the more reason to go with what I had proposed, where each aircraft contains it's own scripts, and own naming convention. That way, when the convention changes, only aircraft built under the new convention will change. Bill _____ From: Curtis Olson [mailto:cur...@gm...] Sent: Monday, November 29, 2010 10:39 PM To: Bill Galbraith Subject: Re: [Jsbsim-devel] JSBSim Script Tutorial 1 - Released Well if your naming convention in any way involves using the FAA FTD test numbers, you are starting out with a big mess that is hard to salvage. :-) Curt. On Mon, Nov 29, 2010 at 9:33 PM, Bill Galbraith <bi...@be...> wrote: Well, since we are on the subject, maybe a little discussion of Tutorial names and organization would be in order as well, or at least let me plan a seed and see if it grows. I'm working on my next project, integrating Datcom+ into JSBSim better. There are a few minor things that I've done already to make the transition easier, and still some things I need to do. Of course, there will be a comparison between the Aeromatic and Datcom+ models against the criteria data. Other projects that I'd like to tackle include rotary wing models, maybe throw in a prop-powered aircraft with tests, etc. I'll bet there are people out there that have been kicking ideas around in their heads for years, on things they'd like to write about. Those tutorials, plus information already in existance, in the Users manual, newsletters, and other sources, would make for good reference material. Reference material is always better when you can actually find it and reference it. Maybe we should think about how these would be organized, and come up with some subjects. Maybe there would be people out there that would volunteer to write some, so that there are many points of view. Just an idea... Bill _____ From: Jon S. Berndt [mailto:jon...@co...] Sent: Sunday, November 28, 2010 10:51 PM To: 'Development issues' Subject: Re: [Jsbsim-devel] JSBSim Script Tutorial 1 - Released Version 1 of the initialization file format is the only one that most people know about right now. Version 2 has not been formally documented. As for a standard way of doing things, I am constantly amazed at how some people are using JSBSim in various creative ways. It's always good to see how someone else - based on their experience - approaches a problem and arrives at a solution. With that said, there can come a time when too many different approaches can lead to confusion. Another thing I've tried to do is to start creating a check_cases/ subdirectory where more established and stable test scripts can be automatically run - regression tests to see if a code change leads to unexpected results. I'm not sure if the small test directory structure/arrangement I have set up is the best. In fact, I'm pretty sure it's not. We'd like to avoid having the same files present in several places. We'd like to try and have common files residing in one spot. So, a logical explanation (as you have made) describing your approaches for the tutorials is good for helping us decide where to put things formally. Jon From: Bill Galbraith [mailto:bi...@be...] Sent: Sunday, November 28, 2010 6:10 PM To: 'Development issues' Subject: Re: [Jsbsim-devel] JSBSim Script Tutorial 1 - Released I see just the aircraft aspects of this issue, whereas Jon has a more general view of the JSBSim world. This works for me. Note that what I showed previously requires no change in code, only in mindset (if there is one there). I'm assuming that version 1.0 won't go away. Is there any reason that this can't be used for the tutorial, or would it be more desireable to go to version 2, with the possibility of introducing more confusion? Obviously, there is extreme flexibility built into this scripting language. Is this even a discussion that needs to happen, or is there an underlaying current that I'm not aware of trying to set some standard for doing things? Maybe I do things differently than some of the others, but if it works, my way isn't necessarily 'wrong'. It's just another example of how it can be done. I guess the same argument goes for my organization of the scripts under the JSBSim/aircraft/Tutorial_1/scripts directory, instead of in the JSBSim/scripts directory. They both work, and both equally valid. Bill _____ From: Jon S. Berndt [mailto:jon...@co...] Sent: Sunday, November 28, 2010 6:43 PM To: 'Development issues' Subject: Re: [Jsbsim-devel] JSBSim Script Tutorial 1 - Released The initialization file predates the scripting capability. Prior to the scripting capability, one had to have an initialization file, otherwise there was simply no other way to . initialize. On one hand, I also like the ability to initialize within a script file by referring to properties directly. But, it also introduces the possibility to do things in an unsynchronized manner, or forgetting to do something. JSBSim has been designed with the use of an initialization file. Not using one may have unintended (and unintentional) negative consequences - or it may not. We have not tested that, yet. It is also possible that there may be no way to initialize some things which are not (yet) exposed as properties. Additionally, version 2 of the initialization file is currently working, and the initialization file mechanism must be used, because initialization is much more than simply setting some terms. Various parameters must be set and the calculated to be properly represented in various frames, so the transformation matrices are in the right state. Right now there is no way to set via properties the initial velocity, rates, location, and orientation in one of several reference frames. With that said, it may be possible to incorporate into the script file the entire initialization format. For instance (see the <initialize> element in purple, below): <?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" href="http://jsbsim.sf.net/JSBSimScript.xsl"?> <runscript xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://jsbsim.sf.net/JSBSimScript.xsd" name="ball test"> <description>Simplest of all tests</description> <use aircraft="ball"/> <initialize version="2.0"> <position frame="ECEF"> <altitudeMSL unit="FT"> 800000.0 </altitudeMSL> </position> <orientation unit="DEG" frame="LOCAL"> <yaw> 90.0 </yaw> </orientation> <velocity unit="FT/SEC" frame="BODY"> <x> 23889.142721 </x> <!-- For use with WGS84 grav model --> </velocity> <attitude_rate unit="DEG/SEC" frame="ECI"> <y> 5.0 </y> <z> -5.0 </z> </attitude_rate> </initialize> <run start="0.0" end="10800" dt="0.01"> <event name="Initialize integrators"> <condition>simulation/sim-time-sec ge 0.0</condition> <set name="simulation/integrator/rate/rotational" value="2"/> <set name="simulation/integrator/rate/translational" value="3"/> <set name="simulation/integrator/position/rotational" value="2"/> <set name="simulation/integrator/position/translational" value="4"/> </event> </run> </runscript> Is this appealing at all? Jon From: Bill Galbraith [mailto:bi...@be...] Sent: Sunday, November 28, 2010 5:08 PM To: 'Development issues' Subject: Re: [Jsbsim-devel] JSBSim Script Tutorial 1 - Released Concerning my dislike for the initialization file, I can also get it to work this way. Build a generic initialization file to get it airborne with engines running, then inside the individual script, I set the initial conditions for the test before doing the trim, such as this (Bold items are the key items here): <use aircraft="Tutorial_1" initialize="airborne_init"/> <run start="0" end="1" dt="0.00833333"> <!-- Set up the trim conditions --> <event name="Trim"> <condition> simulation/sim-time-sec ge 0.0 </condition> <set name="ic/h-sl-ft" value="4779.0"/> <set name="ic/vc-kts" value="191.0"/> </event> <!-- Perform a full trim --> <event name="Trim"> <condition> simulation/sim-time-sec ge 0.0 </condition> <set name="simulation/do_simple_trim" value="1"/> </event> Is something like this more desirable and in line with what was envisioned when this was implemented? I like it better, because it shows the initial condition right there in the script file. It would also allow me to several snapshot tests in one script, tests that are trim points at varying conditions instead of time histories. ---------------------------------------------------------------------------- -- Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Jsbsim-devel mailing list Jsb...@li... https://lists.sourceforge.net/lists/listinfo/jsbsim-devel _______________________________________________ The JSBSim Flight Dynamics Model project http://www.JSBSim.org _______________________________________________ -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ <http://www.flightgear.org/blogs/category/personal/curt/> |