20,741
edits
Implementing VNAV support in FlightGear: Difference between revisions
Jump to navigation
Jump to search
m
Implementing VNAV support in FlightGear (view source)
Revision as of 07:44, 4 December 2013
, 4 December 2013→Parent & Child FDMs
| Line 527: | Line 527: | ||
{{cquote| | {{cquote|Any time a multiple FDM would be used, the child FDMs would be "resident" for the entire run that the parent was in existence. Child FDMs will not ever be removed and additional ones added during a run. It is possible that a child FDM may cease integrating, but child FDMs are inherent and inseparable characteristics of a parent/child flight model.<ref>{{cite web |url=http://sourceforge.net/p/jsbsim/mailman/message/22902959/ |title=Multiple property tree problem/soution |author=Jon S. Berndt |date= 2009-06-27 18:52:11 }}</ref>|Jon S. Berndt}} | ||
{{cquote|<nowiki>Multiple FDMs would be designed to work within Flightgear or standalone. The main model would always have the base property tree names. I assume that any other capability or feature such as nasal would not be affected. | |||
FlightGear would not know the difference - this is not a FlightGear | |||
capability. Multiple FDMs would be managed and run using JSBSim features. | |||
There is no difference between a single FDM and multi-FDM with JSBSim as far | |||
as FlightGear is concerned. The base aircraft will always be the base | |||
property tree - the first property tree. Let's say that the aircraft is the | |||
B-52 carrying the X-15. In the B-52 there may be a switch that tells a | |||
JSBSim system to drop the X-15. At that point, the X-15 would begin flying | |||
(the integration of the X-15 Equations of Motion would start). Obviously, | |||
there would need to be a way to link up a 3D model with a specific child | |||
flight model, but I don't expect that would be a major issue. | |||
I expect that for the near term (and I use the word "near" as a joke, since | |||
this multi-body capability has been in-work for many years), I expect | |||
FlightGear would not use this multi-body capability. I think it would be | |||
mostly a JSBSim batch mode feature. I'd like to see it used for multi-stage | |||
rockets, too, for instance. | |||
The challenge is to make sure that FlightGear is not adversely affected by | |||
the inclusion of this capability. I think Ron's suggested fix does that.</nowiki><ref>{{cite web |url=http://sourceforge.net/p/jsbsim/mailman/message/22902969/ |title=Multiple property tree problem/soution |author=Jon S. Berndt |date= 2009-06-28 14:51:29 }}</ref>|Jon S. Berndt}} | |||
{{cquote|<nowiki>I've looked further into the code and found some bugs and potential problems. | |||
The first one is in FGFDMExec's destructor. It has a try/catch block, | |||
in which it checks for Root == 0, and if so, deletes the object | |||
pointed to by the static pointer "master". Root can never be zero, so | |||
this part is never executed, and the FGPropertyManager object is never | |||
deleted. Root is never zero because it's set to be the same as master, | |||
in FGFDMExec's constructor right after the line | |||
master = new FGPropertyManager();. | |||
So to try to fix this I added a member variable "bool GotMaster" being | |||
set to true if Root was NULL in FGFDMExec's constructor (thus creating | |||
the master object), and replaced the check for Root == 0 to check if | |||
this flag is true. Then master gets deleted. Also I had to add "master | |||
= NULL;" after deleting it. | |||
This actually fixes my issue. I can create a FGFDMExec object, delete | |||
it again, and create another one, and so on. :-) | |||
But then I tried to run several aircraft at the same time. This works | |||
ok until I try deleting one of them, which causes a crash. I think | |||
this is basically caused because the master pointer is static and | |||
thereby shared by all the FGFDMExec objects. | |||
So then I just removed the static master pointer completely, changed | |||
the constructor so that if Root == 0 then Root = new | |||
FGPropertyManager(), and in the destructor, just delete Root instead. | |||
Now everything works just fine! :-) | |||
So I need some input from you guys now -- I can't really see the real | |||
use for the "master" pointer at all, it's barely used by the FGFDMExec | |||
class, and it's also not declared as a public variable (neither is | |||
Root). The child FDM's (If I understand JSBSim correctly) should get | |||
the Root pointer passed to them anyway so they also don't need it. Now | |||
they actually don't - in FGFDMExec::ReadChild, the object is created | |||
without passing the Root pointer, for some reason, so right now, my | |||
fix has probably broken something somewhere. What are the child FDM's | |||
for?</nowiki><ref>{{cite web |url=http://sourceforge.net/p/jsbsim/mailman/message/26161741/ |title=Release of v1.0 (with a fix suggestion to my multiple JSBSim objects issue) |author=Ola Røer Thorsen |date= 2010-09-14 20:02:55 }}</ref>|Ola Røer Thorsen}} | |||
{{cquote|<nowiki>Unfortunately, Ola's patch introduced a couple of glitches that | |||
prevent Flight Gear to run. | |||
One of them has originally been fixed by Frédéric Bouvier in the | |||
Flight Gear git repository. I have just transposed his patch and | |||
renamed the variable 'delete_root' in 'StandAlone' because I assume | |||
that a new 'Root' property manager would only be created when JSBSim | |||
is running in stand alone mode. | |||
The second issue crashes Flight Gear while starting because the | |||
allocation of a new FDMctr must be done if FDMctr was initially set to | |||
its default NULL value even if Root is not NULL. Otherwise a | |||
segmentation fault occurs when reaching the line 149 of | |||
src/FGFDMExec.cpp: IdFDM = (*FDMctr); // The main (parent) JSBSim instance is always the "zeroth"</nowiki><ref>{{cite web |url=http://sourceforge.net/p/jsbsim/mailman/message/26557324/|title=Release of v1.0 (with a fix suggestion to my multiple JSBSim objects issue) |author=Bertrand Coconnier|date= 2010-11-07 11:37:01 }}</ref>|Bertrand Coconnier}} | |||