Voyager camera pointing information |
Voyager camera pointing information |
Jul 29 2016, 09:32 PM
Post
#1
|
|
Junior Member Group: Members Posts: 54 Joined: 7-July 16 From: Austin, Texas Member No.: 7991 |
Sorry if this has been discussed anywhere but I can't seem to find much information about it - why is it that Voyager's pointing is so haphazard, as in this video of all the RAW Jupiter images - https://www.youtube.com/watch?v=bf5QJ8iFxUs?
I came across this link which says that pointing information for the images exists - http://pds-rings.seti.org/voyager/ck.html, but have also read on this forum that it's not very accurate. Would the information be useful in automatically aligning composite images and mosaics, or is it too coarse? Would it at least be useful in getting general alignments that could be refined by hand? And does anyone know why the cameras could not be pointed more accurately, or why accurate information could not be returned with the images? I assume it was some technical limitation, but just curious what it might be. |
|
|
Aug 27 2016, 03:33 PM
Post
#2
|
|
Junior Member Group: Members Posts: 54 Joined: 7-July 16 From: Austin, Texas Member No.: 7991 |
I've been having trouble getting camera pointing information from SPICE - I've tried both the older C-kernels from NAIF and the newer versions from PDS, Voyager 1 and 2 data, run through all available image times, tried the scan platform vs cameras, set the time tolerance to increasingly larger values, but it still comes back with pointing information not found. I must be doing something obviously wrong - does anyone know what it is?
Here's the Python code using SpiceyPy (I also tried it in C to make sure there wasn't something wrong with the Python interface but got the same results) - Thanks for any pointers! CODE """ SPICE C-kernel (camera pointing) test Kernels from http://naif.jpl.nasa.gov/pub/naif/VOYAGER/kernels/ck/vgr1_super.bc http://naif.jpl.nasa.gov/pub/naif/VOYAGER/kernels/sclk/vg100019.tsc http://pds-rings.seti.org/voyager/ck/vg1_jup_version1_type1_iss_sedr.bc """ import spiceypy as spice # load SPICE kernels spice.furnsh('kernels/vgr1_super.bc') # voyager 1 pointing data (11mb) # spice.furnsh('kernels/vg1_jup_version1_type1_iss_sedr.bc') # pds version jupiter (700kb) spice.furnsh('kernels/vg100019.tsc') # voyager 1 clock data (76kb) spice.furnsh('kernels/naif0012.tls') # leap second data (5kb) # settings spacecraft = -31 # voyager 1 instrument = -31001 # narrow angle camera utcTime = "1979-01-05T15:14:10" # time of first jupiter image ephemerisTime = spice.str2et(utcTime) # seconds since J2000 sclkch = spice.sce2s(spacecraft, ephemerisTime) # spacecraft clock string sclkdp = spice.sce2c(spacecraft, ephemerisTime) # spacecraft clock double tolerance = spice.sctiks(spacecraft, "0:00:400") # time tolerance # tolerance = 1e12 # nowork frame = 'ECLIPB1950' # coordinate frame # frame = 'J2000' # coordinate frame # get camera pointing information cmat, clkout, found = spice.ckgp(instrument, sclkdp, tolerance, frame) # clean up the kernels spice.kclear() # print results print 'utc',utcTime print 'et',ephemerisTime print 'sclkch',sclkch print 'sclkdp',sclkdp print 'tolerance',tolerance print 'frame',frame print 'cmat',cmat print 'clkout',clkout print 'found',found """ => utc 1979-01-05T15:14:10 et -662330699.816 sclkch 2/14623:20:785 sclkdp 701344767.168 tolerance 399.0 frame ECLIPB1950 cmat [[ 0. 0. 0.] [ 0. 0. 0.] [ 0. 0. 0.]] clkout 0.0 found False """ and the example C code from https://naif.jpl.nasa.gov/pub/naif/toolkit_...ice/ckgp_c.html, slightly adapted CODE #include <stdio.h> #include "SpiceUsr.h" int main () { /* Constants for this program: -- The code for the Voyager 2 spacecraft clock is -32 -- The code for the narrow angle camera on the Voyager 2 spacecraft is -32001. -- Spacecraft clock times for successive Voyager images always differ by more than 0:0:400. This is an acceptable tolerance, and must be converted to "ticks" (units of encoded SCLK) for input to ckgp_c. -- The reference frame we want is FK4. -- The narrow angle camera boresight defines the third axis of the instrument-fixed reference frame. Therefore, the vector ( 0, 0, 1 ) represents the boresight direction in the camera-fixed frame. */ #define SC -32 #define INST -32001 #define REF "FK4" #define TOLVGR "0:0:400" #define NPICS 2 #define MAXCLK 30 #define CKCORR "voyager2_corrected.bc" #define SCLK "voyager2_sclk.tsc" #define FOO "naif0012.tls" SpiceBoolean found; SpiceChar sclkch [NPICS][MAXCLK] = { { "2/18473:46:768" }, { "2/18381:55:768" } }; SpiceChar clkch [MAXCLK]; SpiceDouble cmat [3][3]; SpiceDouble clkout; SpiceDouble sclkdp; SpiceDouble toltik; SpiceDouble vinert [3]; SpiceInt i; furnsh_c ( CKCORR ); /* Need to load a Voyager 2 SCLK kernel to convert from clock string to ticks. Although not required for the Voyager spacecraft clocks, most modern spacecraft clocks require a leapseconds kernel to be loaded in addition to an SCLK kernel. */ furnsh_c ( SCLK ); furnsh_c ( FOO ); /* Convert tolerance from VGR formatted character string SCLK to ticks, which are units of encoded SCLK. */ /* sctiks_c ( SC, TOLVGR, &toltik ); */ /* printf("toltik %f\n", toltik); */ /* toltik = 800.0; */ toltik = 1e10; for ( i = 0; i < NPICS; i++ ) { /* ckgp_c requires encoded spacecraft clock time. */ scencd_c ( SC, sclkch[ i ], &sclkdp ); ckgp_c ( INST, sclkdp, toltik, REF, cmat, &clkout, &found ); if ( found ) { /* The boresight vector, relative to inertial coordinates, is just the third row of the C-matrix. */ vequ_c ( cmat[2], vinert ); scdecd_c ( SC, clkout, MAXCLK, clkch ); printf ( "VGR 2 SCLK time: %s\n", clkch ); printf ( "VGR 2 NA ISS boresight pointing vector: " "%f %f %f\n", vinert[0], vinert[1], vinert[2] ); } else { printf ( "Pointing not found for time %s\n", sclkch[i] ); } } return ( 0 ); } |
|
|
Aug 27 2016, 04:53 PM
Post
#3
|
|
Senior Member Group: Members Posts: 2542 Joined: 13-September 05 Member No.: 497 |
I've been having trouble getting camera pointing information from SPICE - I've tried both the older C-kernels from NAIF and the newer versions from PDS, Voyager 1 and 2 data, run through all available image times, tried the scan platform vs cameras, set the time tolerance to increasingly larger values, but it still comes back with pointing information not found. If it's a type 1 kernel with no interpolation, then you will only get values at specific times no matter how you set the tolerance -- I think. Does it work for the exact time of an image as calculated using the clock strings instead of the ISO time? If it is a type 1 you could convert it to type 3 with ckspanit. http://naif.jpl.nasa.gov/naif/utilities_PC...dows_32bit.html -------------------- Disclaimer: This post is based on public information only. Any opinions are my own.
|
|
|
Aug 27 2016, 05:45 PM
Post
#4
|
|
Junior Member Group: Members Posts: 54 Joined: 7-July 16 From: Austin, Texas Member No.: 7991 |
If it's a type 1 kernel with no interpolation, then you will only get values at specific times no matter how you set the tolerance -- I think. Does it work for the exact time of an image as calculated using the clock strings instead of the ISO time? If it is a type 1 you could convert it to type 3 with ckspanit. http://naif.jpl.nasa.gov/naif/utilities_PC...dows_32bit.html Yes, they're type 1 kernels - they just have pointing information for when the images were taken. The first photo of Jupiter is C1462321 at 1979-01-05T15:14:10, so I tried this with both kernels but no luck - CODE sclkch = "2/14623:21" sclkdp = spice.scencd(spacecraft, sclkch) tolerance = spice.sctiks(spacecraft, "0:00:800") => sclkdp 701344783.0 found False also tried for a later picture, C1504804 at 1979-01-19T19:00:35, and tolerance=1600, but same result. And tried scanning clock ticks from 0 to a billion, but it didn't find anything - CODE tmin = 0 tmax = int(1e9) tstep = int(1e3) tolerance = int(1e3) for t in xrange(tmin,tmax,tstep): cmat, clkout, found = spice.ckgp(instrument, t, tolerance, frame) if found: print cmat And earlier I had tried scanning through the complete set of Voyager images and used their UTC times to look up pointing information but it didn't find anything. I've been able to use the position kernels without any problem, so there's something about the pointing kernels that isn't set up correctly. I know there's information in there somewhere! |
|
|
Aug 27 2016, 07:39 PM
Post
#5
|
|
Senior Member Group: Members Posts: 2542 Joined: 13-September 05 Member No.: 497 |
I know there's information in there somewhere! Maybe there's a mismatch between the SCLK-SCET file you're using and the one they used when they generated the C kernels -- this sometimes causes problems. Might be useful to dump the kernel to ASCII with toxfr. Can't look at this now (busy with other Jupiter images ) but maybe next week. -------------------- Disclaimer: This post is based on public information only. Any opinions are my own.
|
|
|
Aug 27 2016, 10:19 PM
Post
#6
|
|
Junior Member Group: Members Posts: 54 Joined: 7-July 16 From: Austin, Texas Member No.: 7991 |
I found the problem - somehow in all the permutations of inputs I missed one - it needed the scan platform instead of one of the cameras - Doh!
I had to dig into the kernel files with some SPICE command line tools to find it - some spacit output - CODE -------------------------------------------------------------------------------- Segment ID : /usr1/clove/P4/VGR-NEWPTG/V1/a11002.ptg Instrument Code: -31000 Spacecraft : Body -31, VOYAGER 1 Reference Frame: Frame 18, ECLIPB1950 CK Data Type : Type 3 Description : Continuous Pointing: Linear Interpolation Available Data : Pointing Only UTC Start Time : 1977 SEP 05 15:06:11.607 UTC Stop Time : 1977 SEP 05 16:48:35.613 SCLK Start Time: 1/00013:11:001 SCLK Stop Time : 1/00015:19:001 -------------------------------------------------------------------------------- There it is - Instrument Code: -31000. And it turned out the NAIF kernel was continuous and the PDS one was discrete - the continuous one works okay but not the discrete one, and I'm not sure why, but I can just use the continuous one. So, finally... CODE utc 1979-01-05T15:14:10 et -662330699.816 sclkch 2/14623:20:785 sclkdp 701344767.168 tolerance 799.0 frame ECLIPB1950 cmat [[-0.59495769 -0.46884094 -0.6528503 ] [-0.50325176 -0.41603515 0.75739846] [-0.62670808 0.7791681 0.01157828]] clkout 701344767.168 found True Now I can do some (approximate) camera pointing! Can't look at this now (busy with other Jupiter images ) but maybe next week. Can't wait to see what you guys get back! |
|
|
Aug 27 2016, 10:21 PM
Post
#7
|
|
Senior Member Group: Members Posts: 2542 Joined: 13-September 05 Member No.: 497 |
I found the problem - somehow in all the permutations of inputs I missed one - it needed the scan platform instead of one of the cameras - Doh! In the new way of doing things you could define a frames kernel with a constant offset between the scan platform frame and the camera frame and it would manage this for you, but the Voyager conversions probably predate that formalism. -------------------- Disclaimer: This post is based on public information only. Any opinions are my own.
|
|
|
Lo-Fi Version | Time is now: 22nd September 2024 - 01:15 AM |
RULES AND GUIDELINES Please read the Forum Rules and Guidelines before posting. IMAGE COPYRIGHT |
OPINIONS AND MODERATION Opinions expressed on UnmannedSpaceflight.com are those of the individual posters and do not necessarily reflect the opinions of UnmannedSpaceflight.com or The Planetary Society. The all-volunteer UnmannedSpaceflight.com moderation team is wholly independent of The Planetary Society. The Planetary Society has no influence over decisions made by the UnmannedSpaceflight.com moderators. |
SUPPORT THE FORUM Unmannedspaceflight.com is funded by the Planetary Society. Please consider supporting our work and many other projects by donating to the Society or becoming a member. |