Different ground elevation for each gear

[CarloBlanch1967]

Hello all, this is my second question about JSBSim.
I'm working on an integration of JSBSim with X-plane as visual and terrain generator/ Avionics connection/ controls and more.
Everything is working well, but I want to increase the integration.
I was able to develop an X-plane plugin that read the mesh and passed the correct elevation to JSBSim, this is very important in case of sloped runways.
Now I want more.
I was able to read the gear distance and probe the mesh for every single gear, but how to pass these values to the FDM?
In other words, is there a way to set different elevation for every single gear?
In the JSBSim reference Manual in the "ACKNOWLEDGEMENTS" page is written: "Mathias Frölich added a versatile per-gear ground elevation capability, and many other things". How can I have access to these characteristics? As far as I know the only elevation that I can pass is:  FGPropagate::SetTerrainElevation

Thanks!, 

[seanmcleod]

I had a quick glance at the code in FGLGear.cpp. So for each gear:

    FGColumnVector3 normal, terrainVel, dummy;
    FGLocation gearLoc, contact;
    FGColumnVector3 vWhlBodyVec = Ts2b * (vXYZn - in.vXYZcg);

    vLocalGear = in.Tb2l * vWhlBodyVec; // Get local frame wheel location
    gearLoc = in.Location.LocalToLocation(vLocalGear);

    // Compute the height of the theoretical location of the wheel (if strut is
    // not compressed) with respect to the ground level
    double height = fdmex->GetInertial()->GetContactPoint(gearLoc, contact,
                                                          normal, terrainVel,
                                                          dummy);

With the following the code in GetContactPoint():

  /** @name Functions that rely on the ground callback
      The following functions allow to set and get the vehicle position above
      the ground. The ground level is obtained by interrogating an instance of
      FGGroundCallback. A ground callback must therefore be set with
      SetGroundCallback() before calling any of these functions. */
  ///@{
  /** Get terrain contact point information below the current location.
      @param location     Location at which the contact point is evaluated.
      @param contact      Contact point location
      @param normal       Terrain normal vector in contact point    (ECEF frame)
      @param velocity     Terrain linear velocity in contact point  (ECEF frame)
      @param ang_velocity Terrain angular velocity in contact point (ECEF frame)
      @return Location altitude above contact point (AGL) in feet.
      @see SetGroundCallback */
  double GetContactPoint(const FGLocation& location, FGLocation& contact,
                         FGColumnVector3& normal, FGColumnVector3& velocity,
                         FGColumnVector3& ang_velocity) const
  {
    return GroundCallback->GetAGLevel(location, contact, normal, velocity,
                                      ang_velocity); }

The default GroundCallback implementation being:

double FGDefaultGroundCallback::GetAGLevel(double t, const FGLocation& loc,
                                    FGLocation& contact, FGColumnVector3& normal,
                                    FGColumnVector3& vel, FGColumnVector3& angularVel) const
{
  vel.InitMatrix();
  angularVel.InitMatrix();
  FGLocation l = loc;
  l.SetEllipse(a,b);
  double latitude = l.GetGeodLatitudeRad();
  double cosLat = cos(latitude);
  double longitude = l.GetLongitude();
  normal = FGColumnVector3(cosLat*cos(longitude), cosLat*sin(longitude),
                           sin(latitude));
  contact.SetEllipse(a, b);
  contact.SetPositionGeodetic(longitude, latitude, mTerrainElevation);
  return l.GetGeodAltitude() - mTerrainElevation;
}

So it looks like you simply need to implement your own GroundCallback, which will be called to retrieve the AGL for each gear then.

[bcoconni]

@CarloBlanch1967, you can find an example in examples/FlightGear.cxx.

Definition of a custom class FGFSGroundCallback inheriting from FGGroundCallback:

jsbsim/examples/FlightGear.cxx

Lines 87 to 138 in 76a4d4f

	class FGFSGroundCallback : public FGGroundCallback {
	public:
	FGFSGroundCallback(FGJSBsim* ifc) : mInterface(ifc) {}
	virtual ~FGFSGroundCallback() {}
	/** Get the altitude above sea level dependent on the location. */
	virtual double GetAltitude(const FGLocation& l) const {
	double pt[3] = { SG_FEET_TO_METER*l(FGJSBBase::eX),
	SG_FEET_TO_METER*l(FGJSBBase::eY),
	SG_FEET_TO_METER*l(FGJSBBase::eZ) };
	double lat, lon, alt;
	sgCartToGeod( pt, &lat, &lon, &alt);
	return alt * SG_METER_TO_FEET;
	}
	/** Compute the altitude above ground. */
	virtual double GetAGLevel(double t, const FGLocation& l,
	FGLocation& cont, FGColumnVector3& n,
	FGColumnVector3& v, FGColumnVector3& w) const {
	double loc_cart[3] = { l(FGJSBBase::eX), l(FGJSBBase::eY), l(FGJSBBase::eZ) };
	double contact[3], normal[3], vel[3], angularVel[3], agl = 0;
	mInterface->get_agl_ft(t, loc_cart, SG_METER_TO_FEET*2, contact, normal,
	vel, angularVel, &agl);
	n = FGColumnVector3( normal[0], normal[1], normal[2] );
	v = FGColumnVector3( vel[0], vel[1], vel[2] );
	w = FGColumnVector3( angularVel[0], angularVel[1], angularVel[2] );
	cont = FGColumnVector3( contact[0], contact[1], contact[2] );
	return agl;
	}
	virtual double GetTerrainGeoCentRadius(double t, const FGLocation& l) const {
	double loc_cart[3] = { l(FGJSBBase::eX), l(FGJSBBase::eY), l(FGJSBBase::eZ) };
	double contact[3], normal[3], vel[3], angularVel[3], agl = 0;
	mInterface->get_agl_ft(t, loc_cart, SG_METER_TO_FEET*2, contact, normal,
	vel, angularVel, &agl);
	return sqrt(contact[0]*contact[0]+contact[1]*contact[1]+contact[2]*contact[2]);
	}
	virtual double GetSeaLevelRadius(const FGLocation& l) const {
	double seaLevelRadius, latGeoc;
	sgGeodToGeoc(l.GetGeodLatitudeRad(), l.GetGeodAltitude(),
	&seaLevelRadius, &latGeoc);
	return seaLevelRadius * SG_METER_TO_FEET;
	}
	virtual void SetTerrainGeoCentRadius(double radius) {}
	virtual void SetSeaLevelRadius(double radius) {}
	private:
	FGJSBsim* mInterface;
	};

How to tell JSBSim to use the FGFSGroundCallback class as the new ground callback:

jsbsim/examples/FlightGear.cxx

Lines 202 to 206 in 76a4d4f

	PropertyManager = new FGPropertyManager( (FGPropertyNode*)globals->get_props() );
	fdmex = new FGFDMExec( PropertyManager );
	// Register ground callback.
	fdmex->SetGroundCallback( new FGFSGroundCallback(this) );

[CarloBlanch1967]

Ok Thanks,

So I can create 3 custom classes, one for each gear.

[bcoconni]

@CarloBlanch1967 You just need to define one single instance of the FGGroundCallbackclas : JSBSim will automatically call your custom ground callback for each gear instance (i.e. each time step JSBSim will pass a different FGLocation instance to your callback class for each gear).

[seanmcleod]

No, a single instance, it will be called for each gear instance, with the location of that specific gear. Your code then must return the AGL for that specific location of the gear.

[bcoconni]

Oops ! Sorry I did not see you already answered @seanmcleod.

[CarloBlanch1967]

Forgive me, I didn't understand well.

I must create a custom class inheriting from FGGroundCallback, then the new property.
I suppose a header file to be included in my project, right?
Or a new header in the JSBSim project and recompiling the library?
So will I pass the elevation to the new property?

[bcoconni]

You don't need to recompile JSBSim to use a callback. All you need is writing your custom class and call FGFDMExec::SetGroundCallback() to declare the new ground callback to JSBSim.

[sr71684]

Foregive me if this is the wrong place to ask...

Question:
@bcoconni || @seanmcleod, is it possible to know what part of the aircraft corresponds to the GetAGLevel callback (ie, which gear unit or contact of the aircraft the return value of GetAGLevel corresponds to) ?

My Context:
I know the locations of all aircraft contacts and can calculate the AG height of each. This is done in a program separate from JSBSim.

However, when the GetAGLevel callback is invoked it can't figure out how to map my own above-ground heights to the return value of each GetAGLevel callback.

I tried matching each manually calculated AG height to its GetAGLevel return value by comparing the corresponding latitude-longitude values of each. However, this is a course mapping and makes me cringe.

[seanmcleod]

@sr71684 I'm trying to understand exactly what sort of data and information you have and how you're trying to use it.

I sort of assumed you have a high resolution DEM (Digital Elevation Model) which is fine enough such that when JSBSim calls your call back for each gear you can use the latitude longitude of the specific gear to return a distinct AGL value for each gear. In other words there is no need to know exactly which gear's AGL is being queried.

[sr71684]

Hi @seanmcleod, thanks for the reply.

Yes, correct assumption, I have access to a DEM. This is provided by my separate program.

A little more context:
I have two independent programs here:
Program A: Is a simulation backend which runs a JSBSim instance. It has no immediate knowledge of the DEM.
Program B: Is a visualisation tool to render JSBSim aircraft state with 3D terrain. It has perfect knowledge of the DEM.

I have designed a bi-directional communication protocol to bridge program A and program B. During each JSBSim iteration in program A:

1. JSBSim state is sent from program A to B .
2. Program B receives contact information, transforms each contact on the aircraft into its own coordinate system.
3. Program B fires an AG (above ground) raycast from each aircraft contact point to the DEM surface to calculate distances above ground level.
4. Program B replies to JSBSim with an array of contact heights above the ground.
5. (Where I'm stuck) How to map this list of AG heights from program B into program A's JSBsim instance.

It summary, it seems I could approach this from two directions:

• Program B calculates AG heights which are sent back program A. (What I ideally want to achieve, and which I described above)
• Program A waits for JSBSim to invoke the AG callback which inturn queries the DEM in program A for heights (What you seem to describe)

I want to avoid the latter option because it neccecetates N query-and-response message between program A and B for N aircraft contact points for each FDM iteration. This is more expensive (according to my spider-sense) than the former option which sends one response message (containing N contact points) per iteration.

Perhaps I'm overthinking this all, interested to hear your thoughts.

Thanks again for your time.

[seanmcleod]

@sr71684 I pretty much have the exact same setup, i.e. I have a slightly modified JSBSim program (used for test pilot training) which I've then interfaced with Prepar3D for the external visuals and I use Prepar3D to retrieve DEM data.

So I retrieve the ground elevation from Prepar3D based on the aircraft's cg latitude, longitude (which comes from JSBSim) with the following code:

    // Define AIRCRAFT_INFO_DATA_DEFINITION
    hr = SimConnect_AddToDataDefinition(hSimConnect, AIRCRAFT_INFO_DATA_DEFINITION, "GROUND ALTITUDE", "meters", SIMCONNECT_DATATYPE_FLOAT64);
.....
.....

  case SIMCONNECT_RECV_ID_SIMOBJECT_DATA:
  {
    SIMCONNECT_RECV_SIMOBJECT_DATA* pObjData = (SIMCONNECT_RECV_SIMOBJECT_DATA*)pData;

    if (pObjData->dwRequestID == AIRCRAFT_INFO_REQUEST)
    {
      AIRCRAFT_INFO_DATA* pInfoData = (AIRCRAFT_INFO_DATA*)&pObjData->dwData;
      AircraftInfoData.GroundElevation = pInfoData->GroundElevation * 3.28083989;

Then pass this ground elevation into JSBSim.

void copy_to_JSBSim()
{
  // Set ground elevation
  std::shared_ptr<JSBSim::FGPropagate> Propagate = FDMExec->GetPropagate();
  Propagate->SetTerrainElevation(AircraftInfoData.GroundElevation);
....

The default implementation of FGDefaultGroundCallback::GetAGLevel uses this ground elevation to calculate an AGL for each gear.

So in my implementation there is a single ground elevation value for each time step based on the aircraft's cg at that time step. So in effect this implies a level portion of terrain under all the landing gears.

So my first question is whether this isn't good enough for your setup? Or do you need finer grained elevation and do you have a DEM that has a resolution finer than the distance between the landing gears?

In what sort of environment is your setup being used?

[sr71684]

So my first question is whether this isn't good enough for your setup?
I did consider building what you described. However, I feel like we could do better - especially given I have the AG height array. We're limited only by how this data it's plugged into jsbsim. So no, this would not be good enough.

Or do you need finer-grained elevation and do you have a DEM that has a resolution finer than the distance between the landing gears?
For me it's highly desirable to simulate flight over a non-uniform runway. One that is laterally and longitudinally uneven, perhaps even riddled with small undulations. Yes, I have access to a DEM with a resolution larger than the distance between some of the distances between my gear and contact units.

Further, the terrain surface in program B can have custom 3d geometry placed on top of the DEM, potentially making its "resolution" approach an infinite value.

[sr71684]

It seems the feature I'm looking for is not currently possible with JSBSim. I've been thinking about how I might implement this:

Option 1: Create a property for each contact that a user can write to which set terrain elevation under each contact. For instance,

Exec->SetPropertyValue("gear[0]/mTerrainElevation", x)

Option 2: Add a new method argument to the AG callback that has a reference to the gear / contact unit which invoked it.

double JSBSim::GetAGLevel(int contactIndex, const FGLocation& location,
                                    FGLocation& contact,
                                    FGColumnVector3& normal,
                                    FGColumnVector3& vel,
                                    FGColumnVector3& angularVel) ~~const~~ {

mTerrainElevation = contactAGLookupTableFromExternalProgram[contactIndex]
...

}

[CarloBlanch1967]

Hello,
I have the same configuration.
I'm using Xplane as visual generator and I 'm probing the elevation of the mesh for nose and rear gear (so for now 2 points are enough for me)
And I need to modify the aircraft pitch to follow the terrain slope.

[seanmcleod]

For me it's highly desirable to simulate flight over a non-uniform runway. One that is laterally and longitudinally uneven, perhaps even riddled with small undulations.

Yes, I have access to a DEM with a resolution larger than the distance between some of the distances between my gear and contact units.

Okay thanks for confirming your requirements and what input data you have available.

So given your very high resolution DEM then on each call to GetAGLLevel you can lookup the terrain elevation for the given gear's position and use that to calculate the AGL. But you're concerned that for N gears that means you have to make N IPCs from program A to program B to retrieve the terrain elevation for a given gear's position? Have you measure how costly the N IPCs are?

Do you not have direct access to the high resolution DEM such that you can perform the DEM lookup yourself in program A instead of having to perform an IPC to program B to get it to perform the DEM lookup?

What coordinate system are you using in program B to perform the DEM lookup? On the JSBSim side the gear location that is passed into the AGL method includes ECEF coordinates as well as geographic coordinates. So on each time step you could make a single IPC from program A to program B which as you mentioned has enough state information to re-calculate the coordinates of all N gear and then perform the DEM lookups, and program B could then return a list of gear coordinates with associated AGL values which program A stores with the associated simulation time. Note the time argument t.

double FGDefaultGroundCallback::GetAGLevel(double t, const FGLocation& loc,
                                    FGLocation& contact, FGColumnVector3& normal,
                                    FGColumnVector3& vel, FGColumnVector3& angularVel) const

So on subsequent (N-1) calls to GetAGLevel program A can check whether it has pre-cached values for this time step and then do a coordinate match to find the matching gear within some epsilon.

But I'd measure the time for N IPCs versus the extra work in terms of duplicating the N gear transformations, caching code etc. to see whether it's worth it. Especially if N is only on the order of 3.

[sr71684]

What coordinate system are you using in program B to perform the DEM lookup?

ECEF

Have you measure how costly the N IPCs are?

No. I should.

Do you not have direct access to the high resolution DEM such that you can perform the DEM lookup yourself in program A instead of having to perform an IPC to program B to get it to perform the DEM lookup?

Technically yes, but a design goal of mine is to build program A without any DEM dependencies.

So on subsequent (N-1) calls to GetAGLevel program A can check whether it has pre-cached values for this time step and then do a coordinate match to find the matching gear within some epsilon.

I too considered this. I'd be classifying what gear AGL value goes to which gear coordinate by finding the closest one. What you're describing is very similar to the k-nearest-neighbours. This would work, but I'm concerned precision differences in ECEF gear coordinates between JSBSim and program B will make picking epsilon difficult, or, if epsilon would even be a constant.

But I'd measure the time for N IPCs versus the extra work in terms of duplicating the N gear transformations, caching code etc. to see whether it's worth it. Especially if N is only on the order of 3.

This is where I'll focus my efforts. Thanks for your help.

[dpculp]

If I recall correctly the ability to add per-gear elevation was added at the same time FlightGear added aircraft carriers.  This made it possible to push an airplane back to a parking spot on the edge of the deck, and if the main wheels passed the edge the airplane would fall (rather than hover). It's also used in FlightGear for different wheel drag effects, i.e. one main wheel on the runway and one in the mud. It's also used for slanted runways, i.e. runways that have a bit of "roll angle".

…

On 6/28/22 13:11, sr71 wrote: It seems the feature I'm looking for is not currently possible with JSBSim. I've been thinking about how I might implement this: Option 1: Create properties that a user can write to that set terrain elevation under each gear. For instance, |Exec->SetPropertyValue("gear[0]/mTerrainElevation", x)| Option 2: Add a new method argument to the AG callback that has a reference to the gear / contact unit which invoked it. double JSBSim::GetAGLevel(int contactIndex,const FGLocation& location, FGLocation& contact, FGColumnVector3&normal, FGColumnVector3& vel, FGColumnVector3& angularVel)const { mTerrainElevation = contactLookupTable[contactIndex] ... } — Reply to this email directly, view it on GitHub <#648 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFDBF2LFXZLRAYBZTC3CYTTVRNMAHANCNFSM5YDZRQ7A>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[sr71684]

Interesting. Could you point me to the relevant flightgear source code?

[dpculp]

Sorry, it's been too many years ago for me. The code might be located in SimGear, which is the codebase which provides the low-level simulation routines. In any case it's probably best to inquire at the FlightGear forum: https://forum.flightgear.org/

[seanmcleod]

@sr71684 out of interest is your project a personal hobby project or is it for research or being used in a commercial company? Can you share any more details on the overall project/application?