Higher order fit for LROC NAC

[meganhenriksen]

Stereo images taken post 2018 are taken without the MIMU and have movement in the CK that doesn't seem to be quite accounted for in the CSM (though it is much better than the generic pushbroom model (RMS 0.55 vs 1.078). Jesse mentioned that you might be able to do a higher order fit for (something??) that might help us. If we could try that, I would be very grateful.

We've been currently testing this with this NAC pair: M1371324649, M1371331677

Here are the plots of the CK motion. We're also working on some residual plots.
https://drive.google.com/drive/folders/1cK0IpCfJNdXIyweC_0bs0htzvZiCIG6a?usp=sharing

Here's a brief history of our attempts to work with this pair.
Added a bunch of tie points (including ¾-ways to seams) to the project.
Solved 0.78, saved. Ran NGATE DTMs at 3.0m GSD
Weird terrain correlated with high tie point residuals at 19.8N. (~ halfway between top/bottom)
Left side had some usable terrain, right was unusable.
Edited out weird terrain, registered remaining terrain of left side.
Removed high residual points.
Tried making more DTMs to register with LOLA, none of which has been usable
Most recent solve: (RMS: 0.55, X: 5.26, Y: 9.09, Z: 0.58), saved.

I realize this is somewhat vague, so please let me know what questions I can try to answer.

[jessemapel]

Looking at those plots, that's a lot of rough motion to model with polynomials. It may be better to try a more fluid technique such as checkline or piecewise methods.

I'm curious to see the residual plots too as the pointing adjustments are added into the original data, so even extremely rough apriori data can be corrected. The issue is when the corrections are also extremely rough.

[AaronBoyd]

Looking at those plots, that's a lot of rough motion to model with polynomials. It may be better to try a more fluid technique such as checkline or piecewise methods.

I'm curious to see the residual plots too as the pointing adjustments are added into the original data, so even extremely rough apriori data can be corrected. The issue is when the corrections are also extremely rough.

In the past, we have had a lot of success with periodic functions, such as Fourier, sum of sines, or sum of cosines. That is what we based the HiRISE jitter detection and modeling on as well, so it has some precedence.

[meganhenriksen]

I've updated the folder linked above with the residual plots. The points with the highest residuals have unfortunately been removed in a narrow latitude band, but I think they are still pretty informative. We could also put some points back in if you think it would be helpful.
Plot of the point locations: JitterTest_Test2_Mar2021_GXP3_point_locations.png
Plot of point residuals (vs. latitude): JitterTest_Test2_Mar2021_GXP3_residuals.png

For fun, here's a a couple of slides showing the plot of the residuals from the same pair made in SOCET SET 5.5.0 w/ the generic pushbroom sensor model: PointResidualPlots_Socetset

[jessemapel]

It is good to see that it's definitely doing a better job compared to socet set and the old model. I don't think that just adding higher order terms will solve this. Something more localized is probably a better solution.

What parameters are you solving for?

[Tom-Tyburczy]

Here are the parameters we are solving for, and their accuracies:

IT Pos. Bias - 100.0
CT Pos. Bias - 100.0
Rad Pos. Bias - 10.0
IT Vel. Bias - 13.0
CT Vel. Bias - 13.0
Rad Vel. Bias - 1.3
Kappa Bias - 0.1

This is the setup we normally use in SOCET SET.

[jessemapel]

Is there a reason why you are solving for only a Kappa angle offset and no other angles?

[meganhenriksen]

Thanks for the feedback on the higher order terms. It's definitely not our area of expertise. However, if there's another method you think might be better for fitting that motion, we'd be interested in trying it out.

As for the kappa only value, the short answer is not really. Those values are primarily from the bundle-adjustment in SocetSet, so that's where we started in GXP, especially since we wanted to compare the two. We'll play around with adding the additional angles and get back to you with new plots if something seems promising. We've played around with the omega and phi biases in the past for SocetSet, with some small success. That was a completely different sensor model though! If you have any suggestions for new parameters or parameter values, we'd be happy to take them. Or I can move this conversation over to the usgscsm discussion area.

[jessemapel]

Sorry it's taken a while to get down to this issue. I'm fine with just keeping this discussion going as "how do we better adjust these images?"

I would try adding the angle bias for the other angles at around the same accuracy and see what that gets you.

[Kelvinrr]

@meganhenriksen I am struggling to replicate this in a way similar to the examples you provided.

I think I tracked down the same image you are using in the archives and opened up the CKs to plot the orientations. I am seeing a little bit of jitter in the orientations but not to the same magnitude you are seeing in your visualizations.

You can see what I did to get try to match your plots here: https://gist.github.com/Kelvinrr/614a876321b470fd87a2fb735fc7b529

There is a lot of jitter in one dimension of rotation, so maybe it's simply a different representation of the same issue.

Im using a library that is syntax sugar on top of cspice calls to search for the kernels, so I believe these are the values stored directly on the CK's segments.

[AustinSanders]

I updated Kelvin's visualization notebook using the new reference frame (LRO_REFERENCE), which seems to have reproduced the results described in the provided plots.

The updated notebook can be found at https://gist.github.com/AustinSanders/3138a954178d9bd63a5afad202c68f1c