Catch 22 with SPICE

[chris]

Nice to know that spkmerge works as expected. I had been meaning to try it myself but hadn't gotten around to it.

I wrote a short C program using the SPICE library that prints out rotation parameters for an object. I had the program load the Eros bpc kernel and show give me the orientation of Eros on the day NEAR touched down. Here are the values:

Obliquity 78.6590
EquatorAscendingNode 107.2166
RotationOffset 193.3778
RotationEpoch "2001 2 12"

The obliquity and equator ascending node are almost the same as before, but the rotation offset is different (roughly 30 degrees different; it looks like more here, but that's because I've used a different rotation epoch.) With this adjustment, the landing site is right on, though the probe touches the surface of the asteroid about three minutes early (or possibly a two minutes early depending on what time scale the ending time is specified in.) At that time, NEAR was moving at 1.9 m/sec, so this is an error of 100-150 meters. Not bad, really. It's possible also that there's a slight error in the size of Eros in the ssc file.

I think I know what may be causing the problems with your NEAR mission add-on. I had to make some modifications to Celestia to make mine work--I'll let you know more soon.

--Chris

[cartrite]

I tried changing the rotation offset myself thru trial an error and came up with this. I also made the radius a little smaller. I tried spkmerge again. This time I downloaded another eros file from NAIF and used beginning and ending dates to "wrap" it around the main eros file. But eros still disappears after 19:44:30 . I can"t understand that. It doesn't really disappear but it's orbit changes. Anyhow

Code: Select all

Replace "Eros" "Sol"
{
    Class "asteroid"
    Mesh   "eros-360.cmod"
    Color [ 1.000 0.878 0.853 ]
    BlendTexture true
    Radius 15.955 # maximum semi-axis
    MeshCenter [ -1.262 0.168 -0.164 ]
 
    SpiceOrbit
    {
        Kernel "near-eros.bsp"
        Target "2000433"
        Origin "Sun"
            BoundingRadius 2
            Period 1.761
 
        Beginning "1997 1 1 00:00:00"
        Ending "2005 1 1 00:00:00"
    }
 
    RotationPeriod         5.270
    Obliquity             78.70
    EquatorAscendingNode 107.23
    RotationOffset       278.165
 
    Albedo 0.16
}

This is a close as I can get. The model is just disappearing at 19:44:11







The image that shows the actual landing site http://near.jhuapl.edu/iod/20010212a/20010212afull.jpg
The other image http://near.jhuapl.edu/iod/20010202/index.html was posted 10 days before landing so I guess that was a guesstimate.
I did some digging at the Near web site and found the actually landing time was 3:01:52 p.m est so that would be 20:01:52 utc
Too bad the Eros model changes orbit at 19:44:15 and disappears from veiw. I think the file near_eroslanded_nav_v1.bsp is the cause of this because of this text I see in the file..

Code: Select all

This file was created using PINPOINT Utility Program. The input to the program was the landed spacecraft location Cartesian vector in with
respect to the Eros center in the EROSFIXED frame (see Appendix 1 for PINPOINT inputs.) Since EROSFIXED frame is not one of the frames built into SPICE,
the definition for this frame consisting of the following keywords:         
 \begindata         
FRAME_EROSFIXED  =  2000433         
FRAME_2000433_NAME  = 'EROSFIXED'         
FRAME_2000433_CLASS  =  2         
FRAME_2000433_CLASS_ID =  2000433         
FRAME_2000433_CENTER   =  2000433         
OBJECT_2000433_FRAME   = 'EROSFIXED'         
\begintext       
should be made available to the SPICE system by cut-n-pasting these keywords into a text and loading it using FURNSH routine

I was thinking about how that last sentence could be aomplished. After the orbit changes for eros I get multible error msgs stating something like the ID "2000433" is not a valid ID and the orbit goes back to normal.

[cartrite]

This section of the the mkspk user guide seems to suggest that a new spk file could be created with data from a pck file so mabey the file erosephem_1999004_2002181.bsp could be "fixed" to contain the proper orientation for the entire mission.

Usage
--------------------------------------------------------

Program usage:

> mkspk [-setup <setup file name>]
[-input <input data file name>]
[-output <output SPK file name>]
[-append]
[-u|-usage]
[-h|-help]
[-t|-template] [<input data type> <output spk type>]

Required Assignments

The following assignments must be present in a setup file:

INPUT_DATA_TYPE = 'STATES' or 'ELEMENTS' or 'EQ_ELEMENTS'
or 'TL_ELEMENTS'
OUTPUT_SPK_TYPE = 5 or 8 or 9 or 10 or 12 or 13 or 15 or 17

OBJECT_ID = Numeric code assigned to the object, or
NORAD s/c code ('TL_ELEMENTS'/SPK 10 only)
or
OBJECT_NAME = 'NAIF supported object name'

CENTER_ID = Numeric code assigned to the body which
is the center of the motion for the object
or
CENTER_NAME = 'NAIF supported body name'

REF_FRAME_NAME = 'reference frame name'
PRODUCER_ID = 'producer identifier'
DATA_ORDER = 'ordered list of input parameter names'
DATA_DELIMITER = 'delimiter separating input data items'
LEAPSECONDS_FILE = 'leapseconds file name'

The following assignments are required in the setup file if their values
are not provided on the command line:

INPUT_DATA_FILE = 'input data file name'
OUTPUT_SPK_FILE = 'output SPK file name'


Conditional Assignments

One or more of the following assignments may be needed depending on the
kind of input data being used and other conditions. See the definitions
that follow for details.

PCK_FILE = ( 'PCK_1 file name'
'PCK_2 file name'
...
'PCK_n file name' )

[chris]

You should use my values for the rotation of Eros (RotationOffset, RotationEpoch, EquatorAscendingNode, and Obliquity) since they were computed from the SPICE kernel with Eros's orientation.

As for the position of NEAR after touchdown . . . You can either load the erosatt bpc file (from the fk subdirectory on the NEAR SPICE kernel repository) or defined a constant rotation for Eros. I haven't tried this yet, but I'll hopefully have the chance to do so tonight.

--Chris

[cartrite]

Chris,
I used your settings and changed the radius to 12.875 and the Near model enters the eros model at 19.44.15, an instant before the eros model changes orbit and disappears from veiw. Since touchdown is at 20:01:52 ? that is still
ways to go so it seems to be right on target. I question the touchdown time because the file near_eroslanded_nav_v1.bsp reports 19:45:20.000 as the touhdown time. The start time for the file. I got the 20:01:52 ( 3:01:52 PM EST ) time from this page:
http://near.jhuapl.edu/news/flash/01feb14_1.html
I wonder if the 3 PM EST time took light speed travel time into account ???





If the eros model can be fixed to hold it's orbit till after touhdown then radius will have to be even smaller

[chris]

Chris,
I used your settings and changed the radius to 12.875 and the Near model enters the eros model at 19.44.15, an instant before the eros model changes orbit and disappears from veiw. Since touchdown is at 20:01:52 ? that is still
ways to go so it seems to be right on target. I question the touchdown time because the file near_eroslanded_nav_v1.bsp reports 19:45:20.000 as the touhdown time. The start time for the file. I got the 20:01:52 ( 3:01:52 PM EST ) time from this page:
http://near.jhuapl.edu/news/flash/01feb14_1.html
I wonder if the 3 PM EST time took light speed travel time into account ???
If the eros model can be fixed to hold it's orbit till after touhdown then radius will have to be even smaller

I'm pretty certain that time doesn't include light time delay, which is close to 16 minutes at the time of the landing. So that accounts for most of the difference. There's also a 64.184 second difference between UTC and the TDB time scale used by SPICE (there's a 32.184 second difference between TAI and UTC, and 32 leap seconds in 2001.) The UTC time displayed by Celestia is actually 64.184 seconds ahead of the time in the SPICE kernel, so we should actually expect touchdown at 19:44:15.816 assuming the SPICE kernel is correct.

--Chris

[chris]

Where did you get the value of 12.875 for the radius?

--Chris

[cartrite]

Trial and Error. I kept at it till Near entered Eros at the last possible second.

[cartrite]

Well I kindof got it. Eros almost stays put after 19:44:15. Problems though. There is a difference between Near's landing at 19:44:15 and where Near is located after 19:44:15. NEAR also orbits a center somehere inside Eros after 19:44:15.. Eros shifts orbit slightly after 19:44:15.

SSC FILE

Code: Select all

Replace "Eros" "Sol"
{
    Class "asteroid"
    Mesh   "eros-360.cmod"
    Color [ 1.000 0.878 0.853 ]
    BlendTexture true
   #Radius 24.135 # everything commented out
   #Radius 14.085 # no mesh center
   #Radius 13.475 mode b rotation offset
   Radius 14.929
    #Radius 12.875 # use with mode b
    #Radius 15.935 # use with mode a
    MeshCenter [ -1.262 0.168 -0.164 ]
 
    SpiceOrbit
    {
        Kernel "near-kernels.txt"
        Target "2000433"
        Origin "Sun"
            BoundingRadius 2
            Period 1.761
 
        Beginning "1997 1 1 00:00:00"
        Ending "2005 1 1 00:00:00"
    }
 
#   Obliquity 78.6590 # mode b
   EquatorAscendingNode 107.2166 # mode b
#   RotationOffset 193.3778 # mode b
   RotationEpoch "2001 2 12"  # mode b
   RotationPeriod         5.270 # mode a
   Obliquity             78.70 # mode a
#   EquatorAscendingNode 107.23 # mode a
#   RotationOffset       278.165 # mode a
   RotationOffset       298.165
 
   Albedo 0.16
}

"NEAR Shoemaker" "Sol"
{
    Class "spacecraft"
    Mesh "near.3ds"        # substitute "near.3ds" if you have the NEAR
                 # model installed in Celestia
    Radius 0.002
    #RotationOffset 270
 
    Beginning "1996 5 31"
    Ending "2010 1 1 00:00:00"
 
    SpiceOrbit
    {
        Kernel "near-kernels.txt"
        Target "NEAR"
            Origin "Sun"
        BoundingRadius 1e100
 
        Beginning "1996 5 31"
        Ending "2010 1 1 00:00:00"
    }
}

NEAR-KERNEL.txt Notice the 2 files on top.

Code: Select all

\begindata

PATH_VALUES = ( 'extras/near/data' )
PATH_SYMBOLS = ( 'P' )

KERNELS_TO_LOAD = (
          '$P/erosatt_1999304_2001151.bpc',
          '$P/eros_fixed.tf',
                    '$P/de403s.bsp',
                    '$P/erosephem_1999004_2002181.bsp',
           '$P/math9749.bsp',
                    '$P/near_cruise_nav_v1.bsp',
           '$P/near_erosorbit_nav_v1.bsp',
           '$P/near_eroslanded_nav_v1.bsp'
                   )

Edit: After I found a mistake in my deep impact file di-kernerls.txt, I double checked to see if this file was being used and it was. The top 2 kernels are needed to keep eros in the same position after landing.

FINAL POSITION AFTER 19:44:15



Getting There

[cartrite]

Using Jestr's Deep Impact addon for the models and textures, I reconstructed the Deep Impact mission to comet Tempel1 with Spice.
di-kernerls.txt

Code: Select all

PATH_VALUES = ( 'extras/near/data' )
PATH_SYMBOLS = ( 'P' )

KERNELS_TO_LOAD = (
         '$P/di_tempel1_v01.tpc',
         '$P/di_v17.tf',
         '$P/deep-impact.bsp'
         )


Edit: This file was never being used because the line "\begindata" was missing. When I added the missing line, the addon was broken. The top 2 kernels of that file were not doing a thing except break the addon.

I used spkmerge on these files.

leapseconds_kernel = /home/cartrite/bin/09202006/cspice/exe/naif0008.tls
spk_kernel = /home/cartrite/bin/09202006/cspice/exe/deep-impact.bsp
source_spk_kernel = /home/cartrite/bin/09202006/cspice/exe/dii_preenc174_nav_v1.bsp
source_spk_kernel = /home/cartrite/bin/09202006/cspice/exe/dif_preenc174_nav_v1.bsp
source_spk_kernel = /home/cartrite/bin/09202006/cspice/exe/di_tempel1_ssd_v1.bsp
source_spk_kernel = /home/cartrite/bin/09202006/cspice/exe/di_finalenc_nav_v3_to2006048.bsp

SSC File

Code: Select all

"Tempel 1" "Sol"
{
   Class "comet"
   Mesh "tempel1.3ds"
   Texture "comet2.jpg"
   Radius 200.5
   #Beginning  Beginning "2005 1 12 19:23:32.068"
   #Ending  "2006 1 20 00:00:00"
   Albedo 0.7
    SpiceOrbit
    {
        Kernel "deep-impact.bsp"
        Target "1000093"
        Origin "10"
            BoundingRadius 2
            Period 5.51615
 
        Beginning "2005 1 12 19:23:32.068"
        Ending "2006 1 20 00:00:00"
    }
}

"Deep-Impact" "Sol"
{
   Class "spacecraft"
   Mesh "DeepImpact3.3ds"
   Radius 0.001
   #Beginning "2005 1 12 19:23:32.068"
   #Ending "2009 1 15 00:05:00.000"
   Albedo 0.7
   SpiceOrbit
    {
        Kernel "deep-impact.bsp"
        Target "-140"
        Origin "10"
            BoundingRadius 2
            #Period 5.51615
 
        Beginning "2005 1 12 19:23:32.068"
        Ending "2009 1 15 00:05:00.000"
    }
   #Orientation [ 270 1 0 0 ]
   Obliquity  180
   #SampledOrbit "DeepImpact.xyz"
}

"Impactor" "Sol"
{
   Mesh "DI-Impactor.3ds"
   Radius 0.001
   #Beginning "2005 7 3 06:16:04.184" #06:00:00 UTC Jul 03 2005
   #Ending "2005 7 5 05:46:38.183" #06:01:04 UTC Jul 04 2005
   Albedo 0.7
   SpiceOrbit
    {
        Kernel "di-kernels.txt"
        Target "-70"
        Origin "10"
            BoundingRadius 2
            #Period 5.51615
 
        Beginning "2005 7 3 06:16:04.184"
        Ending "2005 7 5 05:46:38.183"
    }
   #SampledOrbit "DeepImpact-Impactor.xyz"
   #Orientation [ 270 1 0 1 ]
   Obliquity  90
   RotationPeriod 0.0166667
}

A few shots after seperation and just before impact.







I still got to get some kinks out and fine tune some parameters like radius , etc, but it's getting easier to do Spice orbits.

cartrite

[symaski62]

http://www.celestiaproject.net/forum/viewtopic ... 2&start=30

spice_MRO <=

[cartrite]

Chris,
After spiceorbit.cpp was updated for more error checking after 9/20 , how did you load metakernels ( kernel.txt ) ???
With cvs version 9/28 I got this error reported by Spice on the command line of my terminal used to start Celestia running the DI addon ( http://celestiaproject.net/forum/viewtopic.php?p=78353#78353 ) .

Toolkit version: N0060

SPICE(INVALIDARCHTYPE) --

Input file extras/DI/data/di-kernels.txt has architecture ?. The file must be a
binary SPK file to be readable by this routine. Binary SPK files have DAF
architecture. If you expected the file to be a binary SPK file, the problem may
be due to the file being an old non-native file lacking binary file format
information. It's also possible the file has been corrupted.

A traceback follows. The name of the highest level module is first.
spkcov_c --> SPKCOV

This may be why the spacerafts are not being processed. This same addon works with the 9/20 version.

[chris]

Chris,
After spiceorbit.cpp was updated for more error checking after 9/20 , how did you load metakernels ( kernel.txt ) ???
With cvs version 9/28 I got this error reported by Spice on the command line of my terminal used to start Celestia running the DI addon ( http://celestiaproject.net/forum/viewtopic.php?p=78353#78353 ) .

Toolkit version: N0060

SPICE(INVALIDARCHTYPE) --

Input file extras/DI/data/di-kernels.txt has architecture ?. The file must be a
binary SPK file to be readable by this routine. Binary SPK files have DAF
architecture. If you expected the file to be a binary SPK file, the problem may
be due to the file being an old non-native file lacking binary file format
information. It's also possible the file has been corrupted.

A traceback follows. The name of the highest level module is first.
spkcov_c --> SPKCOV

This may be why the spacerafts are not being processed. This same addon works with the 9/20 version.

Metakernels work for me because I've made some further changes to SpiceOrbit that I haven't yet checked in. With the change, you'll need to specify the beginning and ending times for the SPICE trajectory. If I have time, I'll also check in a change that lets you specify a list of SPICE kernels in the SSC file so that you don't have to use a metakernel.

--Chris

[cartrite]

10/4. I suppose you put in a flag to stop spkcov_c checking metakernels.

[chris]

10/4. I suppose you put in a flag to stop spkcov_c checking metakernels.

I didn't do that. Like the name of the function suggests, spkcov_c only deals with SPK files. Metakernels are quite first-class citizens in SPICE. The fact that spkcov_c doesn't work for them is one of the reasons that I added explcit beginning and ending fields for SPICE kernels.

--Chris

[cartrite]

OK. It seems that I need to correct my understanding of what the code is actually doing. I thought that

Code: Select all

 if kernelfile has ext = .txt don't treat it as spk file. only let furnish_c read

There are files that Spice needs to read that are not spk files like

di_v17.tf
di_tempel1_v01.tpc
eros_fixed.tf
erosatt_1999304_2001151.bpc

It seems that without the error checking these files are being used by Spice in my cvs 9/20 version.

Edit: The top 2 files were never used because of a mistake in the file that was loading them. The bottom 2 for near-eros addon were being used and are needed to get eros to keep the same position after the near landing.


On another note, Do you see this same rotation when Near is in a "fixed" position after landing on Eros?. A couple of screenshots showing the rotation of Impactor while it's attached to the fly by craft. This is what Near does after it lands on Eros. It orbits around a center inside Eros just like Impactor is orbiting around a center in the Fly-By craft.









cartrite

[cartrite]

I finally got Impactor to stop rotating.

Code: Select all

RotationPeriod 0.00000000000000000000001

in the ssc file
If I just put zero, that didn't work. Near has a different problem though. Probally because it's on a rotating body after landing.
Next stop, Jupiter via Galileo.

[cartrite]

Using the addon Galileo from Jack Higgins - add-on editing by F. Gregorio and the spice orbit data from jpl, I took these sreenshots of Galileo just before the crash in 03 and the it's probe just before it's crash in 95.





cartrite

[cartrite]

I found this to be interesting. I ran the Galileo addon with a spice Jupiter and didn't replace the standard Jupiter. So I had 2 Jupiter's to see which 1 was closer. It seems that they are sharing the same space. Notice the distortions in the center of the planet. Chalk 1 up for Spice orbits. Vsop87 and Spice are pretty close. I wonder if this has something to do with the new Sun barycenter.



cartrite

[symaski62]

http://www2.jpl.nasa.gov/galileo/

video

RealPlayer
http://realserver1.jpl.nasa.gov:8080/ramgen/Video-Galileo-AVC-2003-182.rm

Quicktime
http://www.jpl.nasa.gov/videos/quicktime/galileo.qtl