Extra OSIRIS-REx kernels

[jessemapel]

I don't know whether to reopen this issue or create a new one, but I am downloading all of the ISIS4+ data area (isisdist.astrogeology.usgs.gov::isisdata) and am seeing some things that may need to be addressed or at least documented.

There is a significant increase in the number of OREX CK and SPK kernels that don't appear to be used or needed in ISIS.

The OLA CKs, of the form orx_ola_YYMMDD_scil2idNNNNN.bc, are instrument specific (i.e., scan mirror adjustments) and there is no support for OLA in ISIS so they are not needed. There are lots of these.

The S/C gimble CKs are also not used. These kernels are of the form orx_sa_rel_YYMMDD_YYMMDD_vXX.bc. These should be removed.

There are also a number of expressly named kernels that I have no idea where they came from. They are not in the PDS archive and the IPWG did not use these kernels. Some examples of these kernels are Equatorial_Stations_1.bc, Plume_Search_1.bc, etc... The point is that these kernels are likely redundant that are also contained in the S/C REL kernels. Anybody know where they came from and their fidelity? Currently, some appear to be tagged as Predict types in the kernel DB file, but I don't think they are necessary.

Currently there are only two types of CK kernels that need to included in the ISIS release - S/C orientation (orx_sc_rel_YYMMDD_YYMMDD_vXX.bc ) and payload structure kernels (orx_struct_mapcam_v01.bc and orx_struct_polycam_v01.bc).

I am also seeing additional SPK kernels that are not in the PDS archive. Some of the examples of these SPK kernels are ORX_Recon_225mSortie_Case02.bsp, OrbitalA_600s_20181203T230000_20190109T000000.bsp, etc... Again, these could be redundant with the standard general coverage kernels (of the form orx_YYMMDD_YYMMDD_YYMMDD_odNNN_vX.bsp) but we have not used them. Anybody know where they came from? Some of these also appear to be tagged as Predict in the DB, which I don't think are needed.

There are s/c SPKs in the TSPK directory that should not be there. In fact, they appear to be a copy what is in the SPK directory. All the kernels in $ISISDATA/osirisrex/kernels/tspk of the form orx_YYMMDD_YYMMDD_YYMMDD_odNNN_vX.bsp should be removed.

There appears to be some residual files that I think are remnants of MacOSX tar file extraction that should be removed. There are some in the IAK directory (e.g., iak/._orex_ocams_addendum_v04.ti).

Unless there are compelling reasons to include these additional kernels, they should be removed so as to try to keep it clean and limit the size of the ISIS DATA download.

Thanks...

Originally posted by @KrisBecker in #4060 (comment)

[Kelvinrr]

All the extraneous kernels have been deleted but I am struggling with getting a passing test from the mapcam.

The problem image is 20190303T100344S990_map_iofL2pan_V001.fits (ingested and spiceinited cube: 20190303T100344S990_map_iofL2pan_V001-spiceinit.cub.zip). Spiceinit goes fine, but fails to get surface intersection despite bennu clearly being in view.

relevant label info:

  Group = Kernels
    NaifFrameCode             = -64361
    LeapSecond                = $base/kernels/lsk/naif0012.tls
    TargetAttitudeShape       = $osirisrex/kernels/pck/bennu_v16.tpc
    TargetPosition            = (Table, $osirisrex/kernels/tspk/de421.bsp,
                                 $osirisrex/kernels/tspk/sb-101955-76.bsp)
    InstrumentPointing        = (Table,
                                 $osirisrex/kernels/ck/orx_sc_rel_190225_19030-
                                 3_v01.bc, $osirisrex/kernels/fk/orx_v14.tf)
    Instrument                = ($osirisrex/kernels/ik/orx_ocams_v07.ti,
                                 $osirisrex/kernels/fk/orx_struct_mapcam_v01.b-
                                 c)
    SpacecraftClock           = $osirisrex/kernels/sclk/SCLK.tsc
    InstrumentPosition        = (Table,
                                 $osirisrex/kernels/spk/orx_190301_190424_1904-
                                 12_od125_v1.bsp)
    InstrumentAddendum        = $osirisrex/kernels/iak/orex_ocams_addendum_v1-
                                0.ti
    ShapeModel                = Null
    InstrumentPositionQuality = Reconstructed
    InstrumentPointingQuality = Reconstructed
    Extra                     = $osirisrex/kernels/pck/bennu_v10.tpc
    CameraVersion             = 1
    Source                    = isis
  End_Group

  Object = NaifKeywords
    BODY_CODE                                = 2101955
    BODY2101955_RADII                        = (0.2825, 0.2675, 0.254)
    BODY_FRAME_CODE                          = 10106
    INS-64361_SWAP_OBSERVER_TARGET           = TRUE
    INS-64361_LIGHTTIME_CORRECTION           = LT+S
    INS-64361_LT_SURFACE_CORRECT             = FALSE
    INS-64361_FOCAL_LENGTH                   = 125.2
    INS-64361_PIXEL_SIZE                     = 8.5
    CLOCK_ET_-64_1/0604879429.64881_COMPUTED = 14741643dd06c241
    INS-64361_TRANSX                         = (0.0, 0.0, 0.0085)
    INS-64361_TRANSY                         = (0.0, 0.0085, 0.0)
    INS-64361_ITRANSS                        = (0.0, 0.0, 117.64705882353)
    INS-64361_ITRANSL                        = (0.0, 117.64705882353, 0.0)
    INS-64361_CCD_CENTER                     = (511.5, 511.5)
    INS-64361_OD_K_PAN                       = (2.21e-05, 1.71e-04, 5.96e-05, 0.0, 0.0)
    INS-64361_OD_CENTER_PAN                  = (486.2, 450.3)
  End_Object

Target clearly in view:

@KrisBecker Do you have any insight on what might be happening? From doing a table dump, the positions seem to be off by quite a bit compared to the original predicted kernels which makes me think there is a missing component somewhere for resolving positions (couldn't find any special SPK dependencies mentioned in the docs) or maybe there needs to be a change to the camera model?

type	J2000X	J2000Y	J2000Z	J2000XV	J2000YV,	2000ZV	ET
recon	6.3178847398239	-0.19755582748185	-1.9764321501022	-1.58578076328421e-05	5.79081522012822e-06	-2.25223441440034e-05	604879494.18542
predict	2.6866146323862	-3.838785574107	-1.7459032425953	8.541737303657e-07	2.03718454278916e-05	-4.01607310654445e-05	604879494.18542

[KrisBecker]

Hi @Kelvinrr...

There appears to be at least two issue in the Kernels (group) configuration.

The SpacecraftClock kernel is incorrect. I traced its selection to the kernel DB file that is in the current ISIS4+ distribution. The SCLK.tsc kernel looks to be very old (8 years!, yikes!) and will not contain any of the updates made to account for s/c clock drift. This will lead to timing errors and result in incorrect ephemeris data extracted from the NAIF kernels, such as the CK and SPK. I think this is responsible for most of the s/c ephemeris errors. To select the proper SCLK, add a new kernel DB configuration:

Object = SpacecraftClock
  Group = Selection
    File  = ("osirisrex", "kernels/sclk/orx_sclkscet_?????.tsc")
  EndGroup
EndObject
End

Second, the Extra kernel specifies a different/old PCK specification. This should be removed unless there is some specific need for it. Outdated versions (bennu_v10.tpc) of the PCK generally have different Bennu rotation rates, prime meridian, pole position and radii specs that conflict with newer (bennu_v16.tpc) PCKs, of which both are contained in the Kernels group. Kernels specified in the spiceinit EXTRA parameter take precedence over all others.

These two mods should provide better OREX ephemeris.

In the kernel management package I provided, a fundamental OREX kernel (directory) configuration was included. That configuration is designed to completely replace/obsolete any previous ISIS OREX kernel configurations.

[Kelvinrr]

Hi @KrisBecker

ugh, I forgot to mention this detail about the SCLK. I wasn't able to spiceinit this image with the newer SCLKs.

  Error                     = "An unknown NAIF error has been encountered. The
                               short explanation provided by NAIF is
                               [SPICE(NOTINPART)]. The Naif error is [SCLK
                               count 1/0604879429.64881 does not fall in the
                               boundaries of partition number 1.]"

Didn't think too much about this because the ET between the predicted and recon are exactly the same, it seems obvious to not mix the old SCLK with newer time dependent kernels in hindsight. So, now my question is, can this image even be inited with the newer SCLKs as clock string doesn't even seem compatible?

[KrisBecker]

@Kelvinrr, yeah there is a lot going on here. Its starting to make sense.

I looked at the image you linked and it has slightly different kernels than what you posted. I tested this in my ISIS5 development system and get the same error. So I went searching for this image in the archive. It doesn't exist. This is a simulated image that was probably generated before launch (2016-09-08) and it does not contain a valid label, particularly the SpacecraftClockStartCount.

So, no, it cannot be inited.

The closest image to this time is 20190303T105940S279_map_iofL2pan.fits and it worked fine using ISIS5 and our UA OREX kernel configuration:

  Group = Instrument
    MissionName                = OSIRIS-REx
    SpacecraftName             = OSIRIS-REX
    InstrumentId               = MapCam
    TargetName                 = Bennu
    StartTime                  = 2019-03-03T10:59:40.279
    ExposureDuration           = 5.285275 <Millisec>
    SpacecraftClockStartCount  = 3/0604882742.23115
    FocusPosition              = 270
    PolyCamFocusPositionNaifId = None
  End_Group

  Group = BandBin
    FilterName = PAN
    Center     = 650
  End_Group

  Group = Kernels
    NaifFrameCode             = -64361
    LeapSecond                = $base/kernels/lsk/naif0012.tls
    TargetAttitudeShape       = $osirisrex/kernels/pck/bennu_v15.tpc
    TargetPosition            = (Table, $osirisrex/kernels/tspk/de424.bsp,
                                 $osirisrex/kernels/tspk/bennu_refdrmc_v1.bsp,
                                 $osirisrex/kernels/tspk/sb-101955-76.bsp,
                                 $osirisrex/kernels/pck/pck00010.tpc)
    InstrumentPointing        = (Table,
                                 $osirisrex/kernels/ck/orx_sc_rel_190225_19030-
                                 3_v01.bc, $osirisrex/kernels/fk/orx_v14.tf)
    Instrument                = ($osirisrex/kernels/ik/orx_ocams_v07.ti,
                                 $osirisrex/kernels/fk/orx_struct_mapcam_v01.b-
                                 c)
    SpacecraftClock           = $osirisrex/kernels/sclk/ORX_SCLKSCET.00071.tsc
    InstrumentPosition        = (Table,
                                 $osirisrex/kernels/spk/orx_190301_190424_1904-
                                 12_od125-N-M13D-L-M15D_v1.bsp)
    InstrumentAddendum        = $osirisrex/kernels/iak/orex_ocams_addendum_v1-
                                0.ti
    ShapeModel                = Null
    InstrumentPositionQuality = Reconstructed
    InstrumentPointingQuality = Reconstructed
    CameraVersion             = 1
    Source                    = isis
  End_Group

Note that the partition number in the SpacecraftClock is 3 not 1 as is in your test image labels. More evidence this is a simulated image. You might be inclined to just change the 1 to a 3 in your image label, but the mission kernels don't match up so your geometry will be invalid. I would not recommend trying to add any additional kernels just to support old, invalid tests, in particular those using simulated images.

Here are the two images with the real image (right) showing good coordinates.

I suggest you update your test with a real image and correct the OREX ISIS kernel configuration.

[Kelvinrr]

@KrisBecker I figured this is what was going on so thanks for the clarification, wanted to make sure the issue was not the configuration before just swapping the image. Updating tests with a new image should be easy enough, thanks for the help.

[Kelvinrr]

@KrisBecker All the extraneous kernels are removed and existing tests are passing. At some point we need to probably do some more rigorous tests on other instruments (they seem to have been disabled at some point).

[KrisBecker]

@Kelvinrr sounds good. Let me know once the kernels become available and I will have a look.

Also, could you please add OSIRIS-REx kernel download instructions to the ISIS3 README instruction set on the main ISIS3 webpage?

Thanks...

[jessemapel]

Looks like this was caused by us not using the --delete flag in the data upload step. I'm going to re-push the O-REx kernel area with the delete flag but not other missions.

[jessemapel]

@KrisBecker This should be resolved now, can you double check?

[KrisBecker]

Looks good!

Thanks.