The org.orekit.frames package provides classes to handle frames and transforms between them.
The Frame class represent a single frame. All frames are organized as a tree with a single root.
Each Frame is defined by a single transform linking it to one specific frame: its parent frame . This defining transform may be fixed or time-dependent, for example the Earth related frame ITRF2005 depends on time due to precession/nutation, Earth rotation and pole motion). The predefined root frame is the only one with no parent frames.
For each pair of frames, there is one single shortest path from one frame to the other one.
The Transform class represents a full transform between two frames. It manages combined rotation, translation and their first time derivatives to handle kinematics. Transforms can convert position, directions and velocities from one frame to another one, including velocity composition effects.
Transforms are used both:
The transform between any two frames is computed by merging individual transforms while walking the shortest past between them. The walking/merging operations are handled transparently by the library. Users only need to select the frames, provide the date and ask for the transform, without knowing how the frames are related to each-other.
Transformations are defined as operators which when applied to the coordinates of a vector expressed in the old frame provide the coordinates of the same vector expressed in the new frame. When we say a transform t is from frame A to frame B, we mean that if the coordinates of some absolute vector (say the direction of a distant star for example) are uA in frame A and uB in frame B, then uB =t.transformVector(uA ). Transforms provide specific methods for vectorial conversions, affine conversions, either with or without first derivatives (i.e. angular and linear velocities composition).
Several predefined reference frames are implemented in Orekit. The user can retrieve them using various static methods: getGCRF() , getEME2000() , getITRF2005() , getCIRF2000() , getTIRF2000() and getVeis1950() . One of these reference frames has been arbitrarily chosen as the root of the frames tree: the Geocentric Celestial Reference Frame (GCRF) which is an inertial reference defined by IERS.
One predefined set corresponds to the frames from the IERS conventions (2003) . This set defines the GCRF reference frame on the celestial (i.e. inertial) side, the ITRF (International Terrestrial Reference Frame) on the terrestrial side and several intermediate frames between them. Several version of ITRF have been defined. Orekit supports the last available version at time of writing (2008), which is ITRF 2005.
There are several different ways to compute transforms between GCRF and ITRF. Orekit uses the new paradigm promoted by IERS, i.e. it uses a single transform for both bias, precession and nutation, computed by the IAU-2000 precession-nutation model and the Earth Orientation Parameters (EOP) data published online by IERS. This single transform links the GCRF to a Celestial Intermediate Reference Frame (CIRF). The X axis of this frame is the Celestial Intermediate Origin (CIO) and its Z axis is the Celestial Intermediate Pole (CIP). The CIO is not linked to equinox any more . From CIRF, the Earth Rotation Angle is applied to define a Terrestrial Intermediate Reference Frame (TIRF) which is a pseudo Earth fixed frame. A last transform adds the pole motion with respect to Earth crust to reach the real Earth fixed frame: the International Terrestrial Reference Frame.
In summary, four frames are involved along this path: GCRF, CIRF, TIRF and ITRF.
The classical paradigm used prior to IERS conventions 2003 is equinox based and uses more intermediate frames. Only one of these frames is supported in Orekit.
Starting from GCRF, the first transform is a bias to convert to EME2OOO, which was the former reference. The EME2000 frame (which is also known as J2000) is defined using the mean equinox at epoch J2000.0, i.e. 2000-01-01T12:00:00 in Terrestrial Time (not UTC!). From this frame, applying precession evolution between J2000.0 and current date defines a Mean Of Date frame for current date and applying nutation defines a True Of Data frame. This frame is similar in spirit to the CIRF in the new paradigm, but is not identical. From this, the Greenwhich Apparent Sidereal Time is applied to reach the same Terrestrial Intermediate Reference Frame as with the new paradigm. The last transform (pole motion) is the same one already defined in the new paradigm.
In summary, six frames are involved along this path: GCRF, EME2000, MoD, ToD, TIRF and ITRF.
This paradigm is deprecated by IERS. It also involves additional complexity, first because of the larger number of frames and second because these frames are computed by mixed models with IAU-76 precession, correction terms to match IAU-2000, and a need to convert Earth Earth Orientation data from the published form to a form suitable for this model. Another drawback of this method is that the intermediate frames do not match the similar frames with the same names used prior to IERS conventions 2003 since a correction is added to the IAU-76 precession model and the IAU-80 nutation model is completely replaced by the nutation part extracted from IAU-2000 model. For these reasons, this paradigm is not completely supported in Orekit. Only the EME2000 frame, which can be computed by a single bias from GCRF is supported. This is an historically very important frame and lots of systems rely on it.
In summary, Orekit implements 5 frames from IERS 2003 convention: GCRF, EME2000, CIRF 2000, TIRF 2000, ITRF 2005.
Here is a schematic representation of the partial tree containing the supported IERS frames.
Since Orekit uses the new paradigm for IERS frames, the IAU-2000 precession-nutation model implemented is the complete model with thousands of luni-solar and planetary terms (1600 terms for the x components, 1275 components for the y component and 66 components for the s correction). Recomputing all these terms each time the CIRF frame is used would be really slow. Orekit therefore implements a caching/interpolation to improve efficiency. The shortest period for all the terms is about 5.5 days (it is related to one fifth of the moon revolution period). The pole motion is therefore quite smooth at the day or week scale. This implies that this motion can be computed accurately using a few reference points per day or week and interpolated between these points. The trade-off selected for Orekit implementation is to use 12 points separated by half a day (43200 seconds) each. The resulting maximal interpolation error on the frame is about 0.13 nanoarcseconds, as depicted in the following plot. The 12 reference points are cached so the computation cost is roughly to perform two complete evaluations of the luni-solar and planetary terms per simulation day, and one interpolation per simulation step, regardless of the step size. This represent huge savings for steps shorter than one half day, which is the rule in most application (step sizes are mostly of the range of a few tens of seconds)./p
For most purposes, the recommended frames to use are ITRF 2005 for terrestrial frame and GCRF for celestial frame. EME2000 could also be used for compatibility with other systems.
This frame model allows to define the frame associated to any position at the surface of a body shape, which itself is referenced to a frame, typically ITRF 2005 for Earth. The frame is defined with the following canonical axes:
In such a frame, the user can retrieve azimuth angle, elevation angle, range and range rate of any point given in any frame, at given date.
Local orbital frames are bound to an orbiting spacecraft. They move with the spacecraft so they are time-dependent. Two local orbital frames are provided: the (t, n, w) frame and the (q, s, w) frame.
The (t, n, w) frame has its X axis along velocity (tangential), its Z axis along orbital momentum and its Y axis completes the right-handed trihedra (it is roughly pointing towards the central body. The (q, s, w) frame has its X axis along position (radial), its Z axis along orbital momentum and its Y axis completes the right-handed trihedra (it is roughly along velocity).
All celestial bodies are linked to their own body-centered inertial frame, just like the Earth is linked to EME2000 and GCRF. Since Orekit provides implementations of the main solar system celestial bodies, it also provides body-centered frames for these bodies. The predefined ones are the Sun, the Moon, the eight planets and the Pluto dwarf planet. In addition to these real bodies, two points are supported for convenience as if they were real bodies: the solar system barycenter and the Earth-Moon barycenter.
The frames tree is can be extended by user which can add as many frames as he wants for specific needs. This is done by adding frames one at a time, attaching each frame to an already built one by specifying the transform from parent to child.
Transforms may be constant or varying. For simple fixed transforms, using directly the Frame class is sufficient. For varying transforms (time-dependent or telemetry-based for example), it may be useful to define specific subclasses that will implement updateFrame(AbsoluteDate) or that will add some specific updateFromTelemetry(telemetry) methods to recompute the transform and call internally the setTransform(Transform) method.
A basic example of such extension is to add a satellite frame representing the satellite motion and attitude. Such a frame would have an inertial frame as its parent frame (GCRF or EME2000) and the updateFrame(AbsoluteDate) method would update the translation and rotation from orbit and attitude data.
Frames are updated by resetting the transform from their parent frame to them. When such a transform is changed, it basically move not only the child frame but all the sub-tree starting at this frame with respect to the rest of the tree. This property can be used to update easily complex trees without bothering about combining transforms oneself. The following example explains a practical case.
This case is an improvement of the basic previous extension to manage orbit and attitude. In this case, we introduce several intermediate frames with elementary transforms and need to update the whole tree. We also want to take into account the offset between the GPS receiver antenna and the satellite center of mass. When a new GPS measurement is available, we want to update the complete left subtree. This is done by updating the Local Orbital Frame (near the root) with a single call to one of its updateTransform methods providing it a reference to the GCRF frame, a reference to the GPS receiver antenna frame and the desired translation and relative velocity between the two, i.e. the measurement itself. The method automatically locates the frames in the global tree, combines all transforms and updates the single transform between itself and its parent GCRF frame.