Curiosity Image Retrieval Tools, scripts and software Options

[mcaplinger]

see if it was OK to post the url...

How could it be not OK to post a public URL? Hopefully they weren't relying on security by obscurity to hide this information.

BTW, for those wanting to develop software and not familiar with SPICE, once you have all the right kernels loaded, a single call to pxform will produce a rotation matrix that will transform a vector from one frame (say, MSL_MASTCAM_LEFT) to another (say, MSL_LANDING_SITE). See http://naif.jpl.nasa.gov/pub/naif/toolkit_docs/C/index.html (though I like to use pyspice -- https://github.com/rca/PySPICE )

[jmknapp]

Hopefully they weren't relying on security by obscurity to hide this information.

Myself, I rarely get through a day without some security through obscurity. Not like everything is nuclear secrets!

a single call to pxform will produce a rotation matrix that will transform a vector from one frame (say, MSL_MASTCAM_LEFT) to another (say, MSL_LANDING_SITE).

True enough, or MSL_MASTCAM_LEFT to MSL_TOPO anyway--here's a C program that I used:

http://curiositymsl.com/campoint.c

[mhoward]

Well, it's public info for the moment anyway. But even in plain sight it's probably still pretty obscure.

Thanks for the example, Joe. Guess I know what I'll be doing today.

[elakdawalla]

I just exchanged email with Michelle Viotti. She said that they are running a couple of test projects, one of them with Ames (which explains the Google Mars part), with the goal of putting the metadata out via JPL's website publicly in the future. No time frame given.

[jmknapp]

the goal of putting the metadata out via JPL's website publicly in the future.

Got this from Boris Semenov:

I don't see any problem letting them know about these kernels; feel free to do that. Again, these kernels are not as good and they (should) be are but probably good enough for many applications. Their release destination will eventually (in a couple of months) change to the main directory (MSL/kernels).

[mhoward]

Yep - that'll work.

Attached thumbnail(s)

 

[jmknapp]

Yep - that'll work.

Nice... So are you getting reasonable results for the NAVCAM images too? I'm getting somewhat random pointing data for them.

[mhoward]

I'm getting good pointing data for Navcam as far as I've seen so far, but I'm taking a slightly different approach. What I need is the rover-relative camera mast az,el, and the rover orientation quaternion; that's what I've got for MER and it makes sense for what I'm doing. So, my approach so far is:

1) Calculate the ephemeris time from the UTC time stamp from the raw images page using str2et_c.
2) Calculate the encoded SCLK from the ephemeris time using sce2c_c.
3) Get the camera mast az,el in two steps using ckgp_c:

// FRAME_MSL_RSM_AZ = -76202
ckgp_c(-76202, esclk, 0, "MSL_RSM_ZERO_AZ", cmat, &clkout, &found);
// ... pull out the azimuth in a way similar to your code example ...
// then get the elevation
// FRAME_MSL_RSM_EL = -76204
ckgp_c(-76204, esclk, 0, "MSL_RSM_ZERO_EL", cmat, &clkout, &found);
// ... pull out the elevation, and there you go.

There's probably a simpler way to do it, but I don't know how, I just started learning CSPICE yesterday.

I'm getting those rover az,el values from msl_surf_rsm_tlmenc_spanned.bc. I have no idea if that's the correct file, but it seems to be working for the moment. (Edit: some time later, it turned out that msl_surf_rsm_tlmres_spanned.bc is better for what I'm doing. msl_surf_rsm_tlmenc_spanned.bc does not seem to be accurate enough when it comes to exact placement of M-100 images.)

Actually the problem I'm having is with ChemCam. I get wrong values there, and no idea why. For starters, the time stamps on ChemCam images on the raw images page don't seem to match up with the rover clock value in the filenames, so... who knows. That's a problem for another day. Now I need to figure out how to pull out the orientation and position information.

Sorry if that doesn't help, but at least it indicates that there is good data along the line somewhere.

[mcaplinger]

There's probably a simpler way to do it, but I don't know how, I just started learning CSPICE yesterday.

Do you separately account for the slight pointing differences between the cameras on the RSM and the RSM itself? If not, that will cause small errors, though maybe not enough to matter for your application.

pxform with the appropriate frames should give you what you want without the need to compute the SCLK (ckgp is an older, lower-level routine) but if ckgp works, no reason not to use it.

[mhoward]

Do you separately account for the slight pointing differences between the cameras on the RSM and the RSM itself?

I haven't gotten quite that far yet, but I hope to. I was having problems with the values I was getting from pxform, but it's entirely possible I just haven't figured out how to use it yet.

[jmknapp]

I'm getting those rover az,el values from msl_surf_rsm_tlmenc_spanned.bc. I have no idea if that's the correct file, but it seems to be working for the moment.

Just figuring these MSL files myself, but as I understand it, the "spanned" version fills in the gaps between actual telemetry (TLM) data with interpolated values. The other version has the gaps, so SPICE calls will throw an error for those times.

The "runout" files are intriguing because according to the description they project 10 years (!) into the future, to be "used for predicted applications." They don't appear to have any future data at this point though, they just leave the rover at the last position for 10 years. Wouldn't it be nice to see where they're planning to go!

They do have the rover's position up to the current location, updated twice daily, so that allows a track to be made:


http://curiositymsl.com/track.jpg

That link updates every hour or so to show the current position.

[fredk]

Oh man, that's cool, Joe! Does this mean you've put our resident map makers out of work?

Edit: comparing with Phil's map, there are obvious offsets, though maybe those are due to translating rover location coordinates into positions on the orbital image. That would mean understanding the image projection.

Still, you've really outdone yourself here!

[jmknapp]

Edit: comparing with Phil's map, there are obvious offsets, though maybe those are due to translating rover location coordinates into positions on the orbital image. That would mean understanding the image projection.

Looks pretty close to the NASA map and Phil's. As I understand it, the HiRISE map-projected image is an equirectangular projection, where lines of longitude and latitude have equal spacing. The SPICE MARS_TOPO frame is cartesian, with the origin at the landing site, Z up (zenith), X to the local north and Y local west. MARS_TOPO is more practical than lat/lon IMO because the coordinates can be in meters (as in Y meters east and X meters south of the landing site). I think (could be wrong) that while these aren't exactly similar projections, at the scale of the area so far and so close to the equator, they're within maybe a meter at any given point when they're registered to a best fit.

It's lacking the placenames and waypoints of a proper map, but I was thinking of incorporating something like it in the raw images listing, just to provide a context for a given image--an icon to click on or maybe hover over to bring up the map.

[jmknapp]

OK, another feature update related to mapping--the image listing on http://curiositymsl.com now has a "map it" link associated with each image. Clicking on it brings up a page with a map showing the rover position on the left hand side, and the associated image on the right. If camera pointing information is available (currently only for MASCAM and HAZCAM images), an arrow on the map indicates the direction.

Here's an example of the "map it" page for an image without pointing info, NLA_408954917EDR_S0051576NCAM00535M_

...and with pointing info, 0106ML0681003000E1_DXXX

[elakdawalla]

Wow. That is awesome.