JSBSim acceleration properties

[seanmcleod]

I noticed you're using the following JSBSim properties as the ground truth acceleration values.

px4-jsbsim-bridge/src/sensor_imu_plugin.cpp

Lines 76 to 82 in 3c4d038

	Eigen::Vector3d SensorImuPlugin::getAccelFromJSBSim() {
	double x = _sim_ptr->GetPropertyValue("accelerations/a-pilot-x-ft_sec2");
	double y = _sim_ptr->GetPropertyValue("accelerations/a-pilot-y-ft_sec2");
	double z = _sim_ptr->GetPropertyValue("accelerations/a-pilot-z-ft_sec2");
	return Eigen::Vector3d(ftToM(x), ftToM(y), ftToM(z));
	}

However those aren't the accelerations of the aircraft's cg, they include additional accelerations based on the pilot's position relative to the cg and angular rates.

https://github.com/JSBSim-Team/jsbsim/blob/eccfd64bbe09fc209c399bead031a8ccc5873118/src/models/FGAuxiliary.cpp#L206-L212

Unless the model has the pilot's position coincident with the cg at all times or the overall effect is small enough particularly with small UAVs that you don't care. In terms of body rates you are using the body rates around the aircraft's cg.

The accelerations of the aircraft's cg can be retrieved via the following JSBSim properties:

https://github.com/JSBSim-Team/jsbsim/blob/eccfd64bbe09fc209c399bead031a8ccc5873118/src/models/FGAuxiliary.cpp#L338-L340

[Jaeyoung-Lim]

@seanmcleod Thanks for pointing this out!

I think this just comes more from the fact that accelerations/Nx is the actual acceleration while accelerations/a-pilot-x-ft_sec2 includes gravity, which is actually similar to the imu sensor measurements.

I think this would be worth switching to the correct property, but would require the imu plugin to read the attitude of the vehicle and adding the gravity acceleration, since this is what get measured on the imu

[seanmcleod]

@Jaeyoung-Lim how sure are you that accelerations/Nx|y|z don't include gravity?

I ran the 737_cruise.xml script which trims the 737 model at altitude and runs for 100s.

JSBSim.exe --root=.\ --script=scripts\737_cruise.xml

I added the following properties to the 5s repeating notification event.

<property>accelerations/a-pilot-x-ft_sec2</property>
<property>accelerations/a-pilot-y-ft_sec2</property>
<property>accelerations/a-pilot-z-ft_sec2</property>

<property>accelerations/Nx</property>
<property>accelerations/Ny</property>
<property>accelerations/Nz</property>

The aircraft is trimmed with a pitch attitude of ~2.28 degrees. Example output:

Repeating Notify (Event 2) executed at time: 95.004533
    position/h-agl-ft = 30052.925128
    velocities/vc-kts = 284.085207
    attitude/theta-rad = 0.040393
    accelerations/a-pilot-x-ft_sec2 = 1.220113
    accelerations/a-pilot-y-ft_sec2 = 0.000034
    accelerations/a-pilot-z-ft_sec2 = -31.978552
    accelerations/Nx = 0.037923
    accelerations/Ny = 0.000001
    accelerations/Nz = 0.993920

Repeating Notify (Event 2) executed at time: 100.004333
    position/h-agl-ft = 30053.519765
    velocities/vc-kts = 284.088327
    attitude/theta-rad = 0.040470
    accelerations/a-pilot-x-ft_sec2 = 1.220611
    accelerations/a-pilot-y-ft_sec2 = 0.000034
    accelerations/a-pilot-z-ft_sec2 = -31.987705
    accelerations/Nx = 0.037938
    accelerations/Ny = 0.000001
    accelerations/Nz = 0.994205

[mvacanti]

@seanmcleod & @Jaeyoung-Lim to resolve the location of the acceleration measurements I propose using the Accelerometer function from JSBSim. This allows the user to define the exact location and orientation of the imu which would solve the issue and enable more accurate modeling of the airframe (as well as location of sensors within it). This will require extending the JSBSim parameter mapping functions I have proposed in this draft pull request for the imu sensors (as planned).

[seanmcleod]

@mvacanti & @Jaeyoung-Lim I was actually going to ask at the time I first looked at your code whether you had considered using JSBSim's accelerometer and gyro sensors in terms of not only physical placement within the airframe but also in terms of modeling noise, bias, drift, quantization etc.

<gyro name="name">
  <lag> number </lag>
  <noise variation="PERCENT|ABSOLUTE"> number </noise>
  <quantization name="name">
    <bits> number </bits>
    <min> number </min>
    <max> number </max>
  </quantization>
  <drift_rate> number </drift_rate>
  <bias> number </bias>
</gyro>

I thought that possibly you wanted more control over the noise model you wanted to implement?

I see based on your draft pull request in terms of updating the GPS sensor you have come across some of the JSBSim sensor features like quantization etc.

[mvacanti]

@seanmcleod & @Jaeyoung-Lim - Yes agreed, the way that I see it is that the two approaches to model the sensors (JSBSim built-in functions and the bridge functions) are not mutually exclusive and can be complementary.

The architecture should allow - as is proposed and currently structured - the user to configure the consumption and modification of JSBSim properties as desired via xml. If the user wishes to "zero out" the bridge functions they can edit them in the configs/[airframe].xml file.

Similarly, the proposed solution in the draft pull request, when applied to the other sensor inputs, will allow the user to map custom JSBSim properties to bridge inputs using the same xml bridge config file and the standard JSBSim conventions as you have enumerated above.

With this setup you can introduce sensor characteristics changes in one or both places.