Pointing Definition and Simulation#

System overview#

../_images/mos_sc_attitude_simulation_if.png

Spacecraft pointing definition#

CK baseline#

Using dynamic FK#

Simulated using ODF#

  • “Simulated frame” geometry definitions are required in an ODF file to be able to “dynamically” simulate the spacecraft and/or MAJIS scanner pointing (superseding CK baseline).

  • Spacecraft pointing directions are specified using pointing-independent Direction Geometry classes.

  • Direction classes handle frames rotation transformations depending on a singleton Simulator object’s state (outside the scope of SPICE pxform-type functions).

../_images/gfinder_ptsimu_model.png

In the following ODF geometry definition example, Target_Position and SC_Velocity are Direction geometry classes defining the two vectors of the simulated frame:

{
  "name": "Simulated_SC_Frame",
  "parameters": {
    "primary_axis": "Z",
    "primary_vector": {
      "name": "Target_Position",
      "parameters": {
        "target": "@target"
      }
    },
    "secondary_axis": "Y",
    "secondary_vector": {
      "name": "SC_Velocity",
      "parameters": {
        "target": "@target"
      }
    },
    "power_optimised": true,
    "offset_rotations": "SC_Slew_Angles"
  }

MAPPS Pointing Request (PTR)#

Spacecraft pointing definition and simulation in MAPPS or JUICE Pointing Tool are based on PTR syntax and conventions. It can not be used as input to MOS-GFINDER simulation, but it is intended to generate PTR files as output.

Note on spacecraft offset rotations definition:

The offset-x-axis is defined such that offset-x-axis, offset-y-axis and boresight form a right handed orthogonal frame.

  • xAngle: Rotation angle of the boresight towards the offset-x-axis (rotation around plus offset-y- axis)

  • yAngle: Rotation angle of the boresight towards the offset-y-axis (rotation around minus offset-x- axis)

../_images/mapps_ptr_convention.png

Scanner motion compensation#

../_images/majis_mc_angles.png
../_images/majis_mc_method.png

Former notes on implementation#

Notes on simulating JUICE S/C and MAJIS pointing different than the baseline pointing scenario (loaded via CKs).

  1. The first way of simulating spacecraft pointing is to make use dynamic frames defined to perform JUICE instruments attitude dependent science opportunity identification. However, these frames are limited to three pointing types:

  • Nadir orbit-aligned pointing

  • Nadir power-optimized pointing

  • Ramming direction pointing

This has been used to deal with Callisto flyby 21C13 and Ganymede GCO500 (see use_cases):

Uncomment line ``spice.furnsh(Config().kernelsDir()+'fk/juice_sc_gan_noa_v01.tf')``in ``cli.py`` to simulate Ganymede NOA pointing.

  1. The other way to implement a spacecraft pointing definition mechanism based on direction vectors that are computed and used by GFINDER.

Computation of detector pointing vectors (using gfinder.geometry.Frustrum for example) is currently done based on loaded kernels, namely using baseline pointing scenario. These vectors result from the direct transformation from the detector to the target frame (using spice.pxform).

We can simulate any spacecraft pointing/frame based on two direction vectors (wrt target frame) instead, or in addition of using a pre-defined dynamic frame. We do so by performing two successive transformations, assuming that the simulated-SC frame corresponds to the spacecraft reference frame (JUICE_SPACECRAFT):

  1. from the detector frame to S/C frame (no need to know S/C attitude wrt target)

  2. from the simulated-SC frame to the target frame (using directory vectors and spice.twovec))

We can apply the same method to the MAJIS scanner (JUICE_MAJIS_SCAN frame), limiting its degree of freedom to rotations around the JUICE_MAJIS_BASE frame X-axis of +/- 4 degrees.

../_images/sc_pointing_simulation.png

The definition and computation of these two direction vectors, defining a simulated-SC frame, could be done using dedicated GFINDER “pointing” Geometry classes and new ODF syntax (eg: "pointing": ["", "Target_Velocity", "Target_Position"] would simulate a Nadir orbit-aligned pointing).

This approach would also easily enable the generation of JUICE S/C and/or MAJIS CKs from the same “pointing” Geometry data computed to simulate the spacecraft and/or MAJIS pointing .

Note that spacecraft pointing request and validation is done via the AGM/PTR interfaces: https://juicept.esac.esa.int. PTR definition syntax is pretty complex (see example below). We shall try to reduce redundancy and duplication of work as much as possible.

    <block ref="OBS">
  <attitude ref="track">
    <boresight ref="SC_Zaxis" />
    <target ref="Callisto" />
    <offsetRefAxis frame="SC">
      <x>1.0</x>
      <y>0.0</y>
      <z>0.0</z>
    </offsetRefAxis>
    <offsetAngles ref="scan">
              <numberOfScansPerLine> 1 </numberOfScansPerLine>
              <numberOfLines> 1 </numberOfLines>
              <xStart units="deg"> -2.0 </xStart>
      <yStart units="deg"> 5.0 </yStart>
              <scanDelta units="deg"> -9.0 </scanDelta>
              <startTime units="min"> 2.2 </startTime>
              <scanTime units="min"> 25.0 </scanTime>
              <borderSlewTime units="min"> 2.0 </borderSlewTime>
    </offsetAngles>
    <phaseAngle ref="powerOptimised">
      <yDir>false </yDir>
    </phaseAngle>
  </attitude>
</block>