Requesting a getter function in Python interface: fdm.get_propagate().get_state()

[agodemar]

I'm submitting a feature request

Describe the issue
I am using the Python interface to JSBSim. When I instantiate the object FGFDMExec like so:

PATH_TO_JSBSIM_FILES="../.." # I'm in jsbsim_root/examples/python
AIRCRAFT_NAME="c172x"

# Instantiate the FDMExec object and load the aircraft
fdm = jsbsim.FGFDMExec(PATH_TO_JSBSIM_FILES)

load_status = fdm.load_model(AIRCRAFT_NAME)

I do get access to the low-level FGPropagate object:

fg_propagate = fdm.get_propagate()
fg_propagate.get_uvw()
fg_propagate.get_Tec2b()
fg_propagate.get_Tl2b()
# fg_propagate.get_state() # not defined yet

but at the moment only the 3 above getter functions are available.

How to add the new getter function get_state() that will return a Python object corresponding to the public C++ struct FGPropagate::VehicleState?

In particular, I'm interested into getting the objects containing the state derivatives: dqPQRidot, dqUVWidot, dqInertialVelocity, dqQtrndot (stored as std::deque-s).

[seanmcleod70]

I'm no expert, but take a look at the following 2 snippets.

jsbsim/python/jsbsim.pxd

Lines 168 to 173 in 3003423

	cdef extern from "models/FGPropagate.h" namespace "JSBSim":
	cdef cppclass c_FGPropagate "JSBSim::FGPropagate":
	c_FGPropagate(c_FGFDMExec* fdmex) except +
	c_FGMatrix33& GetTl2b()
	c_FGMatrix33& GetTec2b()
	c_FGColumnVector3& GetUVW()

jsbsim/python/jsbsim.pyx.in

Lines 91 to 125 in 3003423

	cdef class FGPropagate:
	"""@Dox(JSBSim::FGPropagate)"""
	cdef shared_ptr[c_FGPropagate] thisptr
	def __cinit__(self, FGFDMExec fdmex, *args, **kwargs):
	if fdmex is not None:
	self.thisptr.reset(new c_FGPropagate(fdmex.thisptr))
	if not self.thisptr:
	raise MemoryError()
	def __bool__(self) -> bool:
	"""Check if the object is initialized."""
	if self.thisptr:
	return True
	return False
	cdef __intercept_invalid_pointer(self):
	if not self.thisptr:
	raise BaseError("Object is not initialized")
	def get_Tl2b(self) -> numpy.ndarray:
	"""@Dox(JSBSim::FGPropagate::GetTl2b)"""
	self.__intercept_invalid_pointer()
	return _convertToNumpyMat(deref(self.thisptr).GetTl2b())
	def get_Tec2b(self) -> numpy.ndarray:
	"""@Dox(JSBSim::FGPropagate::GetTec2b)"""
	self.__intercept_invalid_pointer()
	return _convertToNumpyMat(deref(self.thisptr).GetTec2b())
	def get_uvw(self) -> numpy.ndarray:
	"""@Dox(JSBSim::FGPropagate::GetUVW)"""
	self.__intercept_invalid_pointer()
	return _convertToNumpyVec(deref(self.thisptr).GetUVW())

[agodemar]

Thanks @seanmcleod70
My question is about how to handle structures like FGPropagate::VehicleState and std::deque<FGColumnVector3> or std::deque <FGQuaternion>.

Having the function

const VehicleState& GetVState(void) const { return VState; }

defined here in FGPropagate.h would be great.
Some of the public getters like FGPropagate::GetVel would be great.

@bcoconni any suggestion?

[agodemar]

@seanmcleod70 Maybe something along the line:

pm = fdm.get_property_manager()
sim_time = pm.get_node("simulation/sim-time-sec")
pdot = pm.get_node("accelerations/pdot-rad_sec2")
qdot = pm.get_node("accelerations/qdot-rad_sec2")
rdot = pm.get_node("accelerations/rdot-rad_sec2")

and returning the dotted values could work.

[seanmcleod70]

@agodemar I was actually meaning to ask you today whether you specifically want access via a Python method or whether the other option is to add the missing state as regular properties that you can access from both Python, xml scripts, CSV logging etc. and/or whether you needed/wanted both options.

It looked like at first glance that the missing state you were looking for, were the accelerations? So pqr angular velocities are already available as properties but not the angular accelerations? Same for the linear velocity versus linear accelerations?

[seanmcleod70]

Linear and angular velocities currently available as properties.

jsbsim/src/models/FGPropagate.cpp

Lines 835 to 849 in 3003423

	PropertyManager->Tie("velocities/u-fps", this, eU, &FGPropagate::GetUVW);
	PropertyManager->Tie("velocities/v-fps", this, eV, &FGPropagate::GetUVW);
	PropertyManager->Tie("velocities/w-fps", this, eW, &FGPropagate::GetUVW);
	PropertyManager->Tie("velocities/p-rad_sec", this, eP, &FGPropagate::GetPQR);
	PropertyManager->Tie("velocities/q-rad_sec", this, eQ, &FGPropagate::GetPQR);
	PropertyManager->Tie("velocities/r-rad_sec", this, eR, &FGPropagate::GetPQR);
	PropertyManager->Tie("velocities/pi-rad_sec", this, eP, &FGPropagate::GetPQRi);
	PropertyManager->Tie("velocities/qi-rad_sec", this, eQ, &FGPropagate::GetPQRi);
	PropertyManager->Tie("velocities/ri-rad_sec", this, eR, &FGPropagate::GetPQRi);
	PropertyManager->Tie("velocities/eci-x-fps", this, eX, &FGPropagate::GetInertialVelocity);
	PropertyManager->Tie("velocities/eci-y-fps", this, eY, &FGPropagate::GetInertialVelocity);
	PropertyManager->Tie("velocities/eci-z-fps", this, eZ, &FGPropagate::GetInertialVelocity);

Ah, I was only looking at FGPropagate, the linear and angular accelerations are already available as properties.

jsbsim/src/models/FGAccelerations.cpp

Lines 347 to 361 in 3003423

	PropertyManager->Tie("accelerations/pdot-rad_sec2", this, eP, &FGAccelerations::GetPQRdot);
	PropertyManager->Tie("accelerations/qdot-rad_sec2", this, eQ, &FGAccelerations::GetPQRdot);
	PropertyManager->Tie("accelerations/rdot-rad_sec2", this, eR, &FGAccelerations::GetPQRdot);
	PropertyManager->Tie("accelerations/pidot-rad_sec2", this, eP, &FGAccelerations::GetPQRidot);
	PropertyManager->Tie("accelerations/qidot-rad_sec2", this, eQ, &FGAccelerations::GetPQRidot);
	PropertyManager->Tie("accelerations/ridot-rad_sec2", this, eR, &FGAccelerations::GetPQRidot);
	PropertyManager->Tie("accelerations/udot-ft_sec2", this, eU, &FGAccelerations::GetUVWdot);
	PropertyManager->Tie("accelerations/vdot-ft_sec2", this, eV, &FGAccelerations::GetUVWdot);
	PropertyManager->Tie("accelerations/wdot-ft_sec2", this, eW, &FGAccelerations::GetUVWdot);
	PropertyManager->Tie("accelerations/uidot-ft_sec2", this, eU, &FGAccelerations::GetUVWidot);
	PropertyManager->Tie("accelerations/vidot-ft_sec2", this, eV, &FGAccelerations::GetUVWidot);
	PropertyManager->Tie("accelerations/widot-ft_sec2", this, eW, &FGAccelerations::GetUVWidot);

[agodemar]

@seanmcleod70 thanks for the pointers. I intend to develop a Python function that returns the time derivatives of all state variables. This will help to integrate JSBSim python module within the PathView project, once the Flask backend will be released.

As I see, after a fdm.run(), from the property manager we can get all the variables I'm interested in.

[seanmcleod70]

Yep, initially I assumed the state you were asking for wasn't currently available as existing properties, but it looks like they are.

So you can use either:

pm = fdm.get_property_manager()
pdot_node = pm.get_node("accelerations/pdot-rad_sec2")
pdot = pdot_node.get_double_value()

Or

pdot = fdm['accelerations/pdot-rad_sec2']

[seanmcleod70]

In terms of time derivatives of all state variables for integration with PathView, is the idea to be able to make use of PathView for the integration step, i.e. PathView will take as output from JSBSim $\dot x$ then integrate it to get the new state $x$?

If so, isn't there some complication then in terms of getting JSBSim not to do the integration, but to rather take the state in from PathView after each timestep?

I had actually been thinking of something along these lines given I was looking at integrating JSBSim with DCS (Digital Combat Simulator), and had been looking at the API for DCS for integrating external FDMs and had come across @Zaretto having done this before.

Basically in the DCS case the state is passed into the external FDM and the FDM returns the net forces and net moments to DCS, which then calculates the accelerations and performs the integration step, then returning the new state to the external FDM. @Zaretto in his JSBSim fork had to make a number of modifications to JSBSim to support this.

So I'm just wondering whether you're going to have to make similar changes to JSBSim that @Zaretto made, and if so whether we should consider providing an option in JSBSim to officially support this via some configuration options.

[agodemar]

Basically in the DCS case the state is passed into the external FDM and the FDM returns the net forces and net moments to DCS, which then calculates the accelerations and performs the integration step, then returning the new state to the external FDM. @Zaretto in his JSBSim fork had to make a number of modifications to JSBSim to support this.
So I'm just wondering whether you're going to have to make similar changes to JSBSim that @Zaretto made, and if so whether we should consider providing an option in JSBSim to officially support this via some configuration options.

I agree on this point. The JSBSim module should provide a way to calculate the net forces and moments, given $x=[u,v,w,p,q,r; \text{lon}, \text{lat}, h]$, $\dot{x}$, and $u=[\delta_{\text{Thrust-cmd}}, \delta_{\text{a-cmd}}, \delta_{\text{e-cmd}}, \delta_{\text{r-cmd}}, \text{etc.}]$.

Is it necessary a configuration option? Couldn't we provide additional functions?

[agodemar]

@Zaretto can you please spot for us the main modifications that you did in this context?

I see this diff, for instance.

[seanmcleod70]

Yep, I was about to point out that particular diff, which is what I came across a couple of months ago. Last commit was Nov 2025, so it appears to be fairly up to date?

In this conversation - Zaretto/acEFM#1 he mentions it working with DCS in Jan 2024.

[agodemar]

@seanmcleod70 @Zaretto
Basically, some models' run method are not invoked:

for (unsigned int i = 0; i < Models.size(); i++) {
    LoadInputs(i);
    Models[i]->Run(holding);
      if (DCS__active) {
          switch (i) {
          // For DCS we only need a subset of the models to run.
          // case ePropagate:
          case eInput:
          // case eInertial:
          // case eAtmosphere:
          // case eWinds:
          case eSystems:
          case eMassBalance:
          // case eAuxiliary:
          case ePropulsion:
          case eAerodynamics:
          case eGroundReactions:
          case eExternalReactions:
          // case eBuoyantForces:
          case eAircraft:
          case eAccelerations:
          case eOutput:
              // case eNumStandardModels:
              LoadInputs(i);
              Models[i]->Run(holding);
              break;

          default:
              break;
          }
      } else {
          LoadInputs(i);
          Models[i]->Run(holding);
      }
  }

We could introduce a RunCustom passing an array of Model id-s to run.

[seanmcleod70]

Correct, that was my thinking in terms of some 'config' option.

Now in the DCS case DCS also provides the atmosphere data (density, pressure, etc.) on each time step, so you'll see he has setter methods he's added for that. In some cases you may want to rather let JSBSim handle that internally.

Looks like DCS must do the calculation of alpha, beta etc. since he also has setters for them.

Ideally in addition to the config option to disable a portion of the models, you may well want to make it dynamic. I'm thinking you may want to make use of JSBSim to perform a trim operation before you start integrating with something like PathView.

[Zaretto]

@Zaretto can you please spot for us the main modifications that you did in this context?

In the context of getting it to work with JSBSim it's all a bit hacky; I pulled apart the main loop and changed what models are used.

I've made a document that details the work. https://github.com/Zaretto/jsbsim/blob/DCS-WIP-hacky/DCS-JSBSim-Fork-Overview.md

I have future plans to come up with a proposal for bringing a non hacky version of these changes back into the project; but that is still a way off in the future.