Platform

The Platform object describes the platform that an instrument is mounted to. Common examples used in atmospheric research are spacecraft, aircraft, balloons and ground-based sites. The primary purpose of the Platform object within this API is to eciposition and orient an instrument in space and simultaneously execute an observation policy to collect a set of data records suitable for retrieval or analysis. For example, this may include scanning through a range of limb altitudes for a limb scanning spectrograph, stepping through multiple filter ranges for an imaging tunable filter or collecting one exposure for a spatial heterodyne system.

The exact observation policy executed by an instrument is normally chosen and implemented by the user although helper classes and function may help lessen the burden for some commonly used scenarios. From this API’s perspective the observation policy provides a set of N platform positions, orientations and times. Radiance signals are calculated for each sample and are stored in each SpectralWindow in the Instrument. The end-user/observation policy is responsible for re-organizing the pixel signals if required.

Position and Orientation

The Platform class provides a flexible API system for specifying instrument position and orientation. Platform position is always provided in geographic geocentric coordinates, the ISKGeodetic object in the sasktran package provides various methods to convert from geodetic to geocentric and similar. Platform orientation is controlled by an instance of Platform_Pointing embedded within the Platform class. The Platform_Pointing object implements several rotation matrices that allow the instrument orientation to be specified in a combination of several convenient control frames and ultimately transformed to the geographic geocentric system for the radiative transfer calculations. Details on the various control frames is provided in Transformations and Control Frames.

Platform Pointing Scenarios

There are two broad platform pointing scenarios:

  1. Specify the orientation and eciposition of an actual platform. This might include setting the yaw, pitch and roll of an aircraft or balloon using local compass settings or setting satellite orientation using quaternions. This scenario also allows the instrument to be mounted in an arbitary direction relative to the platform coordinates.
  2. Specify the orientation and eciposition of an instrument on a simulated platform and use the observation policy to determine what location the instrument should look at at any given instant in time and space. In this scenario the platform can be queried to determine what yaw, pitch and roll are necessary to achieve the required observation policy.

Platform Pointing Guidelines

The platform pointing follows the general guidelines:

  • The orientations of individual Pixels of an Instrument are defined in the Instrument Control Frame. This is analogous to measuring fields of view with respect to the instrument’s primary optical axis.
  • The orientation of an Instrument is defined in the Platform Control Frame. This is analogous to bolting the instrument onto a real platform and measuring the orientation of the instrument’s optical axis with respect to the platform coordinates.
  • The orientation of the entire platform can be set in either local geodetic coordinates or global geographic geocentric coordinates but in either case it is implemented as a rotation of the entire platform at its current location.

Specifying roll around the look vector

It is straight-forward to get the Instrument to look at a specific location. However this is not sufficient to specify the full attitude of the platform as we must also specify the rotation, or roll, around the look vector. This consideration is not necessary for real platforms as they automatically provide the proper roll in their attitude solution. Platform simulations are a different matter and for this scenario we consider two cases

  1. In limb viewing mode the instrument \(\hat{z}_{ICF}\) unit vector is rolled around the primary look vector until it is as parallel to the local vertical as possible. This is an undefined operation if the instrument happens to be looking in the nadir.
  2. In nadir mode the \(\hat{z}_{ICF}\) unit vector is rolled around the primary look vector until it is as parallel as possible to a specified horizontal azimuth direction. The horizontal unit vectors are taken at the point the instrument is looking at. This can be an undefined operation if you are looking at a tangent point while requesting nadir mode.

Observation Policy

Inside each Platform object there is an ObservationPolicy which holds an array of platform states, one state for each sample in the current observation policy defined by the user. As far as the platform is concerned any observation policy implemented by the user is implemented as a sequence of platform positions, orientations and times.

The instrument model uses the current list of platform states in the platform’s ObservationPolicy as one of its inputs to the radiative transfer engine. The user must add at least one platform state to the ObservationPolicy for the radiative transfer to calculate anything.

Real observation policies for real instruments may be much more detailed than simply saving platform eciposition, orientation and time. For example, mirrors and filters may need to be adjusted, integration times and detector binning modes may need to be varied. These aspects are beyond the scope of the platform’s observation policy and are left for the user to manage and implement. API helper classes and functions may evolve with time as common scenarios are implemented.