Flexible Motion Model

The primary coordinate system in DIRSIG is the East-North-Up (ENU), where the ENU axes correlate to X, Y and Z, respectively.

The reference frame for motion models in DIRSIG is as follows:

How do roll, pitch and yaw relate to this motion frame?

The Flexible motion model configuration is supplied to DIRSIG through an XML description file (like other DIRSIG components). The recommended extension for these files is .motion.

The XML description for the Flexible motion model is composed of two top level elements that define the location and orientation engine used:

The Fixed location engine let’s the used supply the location as a fixed location as either Scene ENU, Geodetic Lat/Long, UTM or ECEF coordinates. The object does not move as a function of time, with the exception of motion due to jitter. The configuration is very simple, with the location using the <location> schema defined in the coordinates document.

The example below defines an object statically located at 0,0,12500 in the Scene ENU coordinate system:

The Waypoints location engine lets the user supply a set of waypoints that the object appears at as a function of time.

The Straight location engine defines a platform flying at a "straight line" (constant altitude, at a constant speed and in a constant direction). The user configures this engine using the following variables.

The example below shows an object starting at 0,0,12500 in Scene ENU coordinate system, heading at 20 degrees East of North (+CW) and traveling at 200 meters/second:

The Circling engine supports a platform that circles about a supplied center location (Scene ENU, Geodetic Lat/Long, UTM and ECEF coordinates are supported) at a supplied radius (meters) and linear velocity (meters/second).

The example below is for an object circling around 0,0,12500 in the Scene ENU coordinate system, with a radius of 1000 meters at 500 meters/second:

The SGP4 location engine provides access to a "simplified general perturbations" (SGP) model implementation, which performs a direct location calculation for an earth orbiting object from a Two-Line Element (TLE) set. Specifically, DIRSIG utilizes the SGP4 implementation written by David Vallado (the version referred to by Vallado as "SGP4 Version 2008-11-03"), which is available on the Celestak website.

Currently, the user must supply the TLE within the engine description. However, at a future date it is expected that extracting the TLE from a local file or remote (HTTP accessible) file will be added.

The Euler Angles orientation engine lets the user specify the orientation using an Euler angle rotation sequence.

The Spin orientation engine allows the orientation to be driven by a set of rotation rates. The rates are specified at a series of relative times and the units are radians/second. The rates change at the supplied times and are not interpolated. The axis attribute defines the axis of rotation.

The Quaternion orientation engine allows the user to define the orientation using quaternions, which have the following form:

Q = W + X i + Y j + Z k

The Velocity orientation engine allows the orientation to be driven by the current velocity supplied from the location engine. This engine is useful for when an object is always oriented to point along the current velocity direction (for example, a vehicle generally points in the direction it is headed). This engine assumes the object that it is associated with is oriented in its local coordinate system such that the "front" is along the +Y axis.

However, the current velocity vector is not enough to fully constrain the orientation because the coordinate system can rotate about the velocity heading. Therefore, a second vector is needed to constrain the orientation. The default constraint vector for the Velocity engine is the Scene ENU +Z vector. If the user wishes to override the constraint vector, they can do so via the optional <constraint> element. This element has three attributes:

The following XML configuration shows the setup of this engine with the Scene ENU +Z axis explicitly defined as the constraint vector:

The Look At orientation engine provides a great deal of flexibility because it lets the user specify the orientation by forcing the object to "look at" another location from whatever it’s current location is. This makes it easy to configuration scenarios combining static (stationary) and dynamic (moving) pointing and tracking scenarios. For example:

The Look At engine requires the user to specify the location to "look at" by configuring a location engine.

Any of the previously described location engines can be used to define the location to "look at". That location engine can be static (stationary) or dynamic (moving) with time.

This engine works by dynamically computing a line-of-sight (LOS) vector between the current location and the location being "looked at". This LOS vector is then used to define the -Z axis of the object (vehicle) since the default for DIRSIG’s sensor plugins is for camera models to look down from the vehicle. However, this LOS vector is not enough to fully constrain the orientation because the coordinate system can rotate about that LOS vector. Therefore, the user must specify an additional vector that is not parallel to the LOS vector to constrain the orientation. In general, this additional vector is aligned with the "heading" or +Y axis of the object or vehicle. This is additional vector is supplied via the <constraint> element, which has three attributes:

The scenario is a platform fixed at some location in space and using Euler angles to define the orientation. In this case, the angles are all zero so the vehicle is the default orientation

The scenario is a platform at a fixed location in space and looking at another fixed location.

When using the "look at" orientation, the orientation around the line-of-sight (LOS) vector is defined by the <constraint> configuration. The two simulations below show two possible options. In the first (see configuration above) the +Y axis is used, which aligns the "heading" axis of the vehicle with the +Y axis of the scene (corresponds to North in the Scene ENU coordinate system):

In the following alternative configuration, the +X axis is used (e.g., the vector attribute was set to "1,0,0"), which aligns the "heading" axis of the vehicle with the +X axis (corresponds to East in the Scene ENU coordinate system):

The scenario is a simple flight line at some altitude, speed and heading. This can be accomplished with the following engine pairing:

In this case, the velocity is horizontal so we set the constraint vector to the scene ENU +Z direction to lock in the orientation.

In this scenario the platform flies a straight line while staring at a fixed point. This can be accomplished with the following engine pairing:

In this scenario has the vehicle flying along the +Y axis (heading is 0) start point offset from the origin, but looking at the origin. The velocity is the constraint but the velocity and the LOS to the origin are not necessarily orthogonal. However, the constraint simply needs to not be parallel to the LOS.

The scenario is that the object flies in circle around a center point, with the orientation such that it stares at the center point. This can be accomplished with the following engine pairing:

In this scenario, we wanted the "top" of the image frame to be aligned with "up" in the scene coordinate system. Hence, the <constraint> vector was not set use the velocity option, but rather to be constant with the Scene ENU +Z.

If the <constraint> was set to the velocity, the vehicle would rotate to point at the origin but be heading along the arc of the circular path (see below):

The addition of STK I/O handlers to the appropriate engines streamlines the process of importing these STK scenarios into DIRSIG and eliminates the need to perform external conversions from the STK reports to something like the DIRSIG PPD file format. This can be accomplished with the following engine pairing:

Landsat is in a fixed orbit and the orientation is such that the platform is always pointed down towards the center of the earth. This can be accomplished using the following engine combination:

In this scenario, we have a ground based imaging platform that is tracking an orbiting object. The location of the ground platform is known and the TLE for the orbiting object is used to tell the platform where to point.

In this scenario, we have an orbiting imaging platform that is tracking another orbiting object. The location of the imaging platform is defined by the TLE for that objects orbit. A second TLE (for the orbiting object) is used to tell the imaging platform where to point.

In the following example, we are using the TLE for the Anik-F1 communications satellite (in a geo-synchronous orbit) to track the Landsat-7 satellite in a low-earth orbit (LEO).