Spirit Sol 182

We're back on a tight schedule: when I arrive, it's around 2AM LST, leaving us only about 6 hours to get everything done and uplinked.

So naturally it's a complex sol. Yestersol's IDD sequence faulted out when the IDD flight software detected a pending self-collision, precluding the remainder of the IDD work and the subsequent drive. Which means we have both IDD and drive sequences to do thisol -- a touch-and-go -- on a tight schedule.

Fortunately, we're able to salvage a lot from yestersol's sequences, which makes the problem manageable. Which is good, because it leaves time for Andy to get paranoid about the drive's not completing. If it doesn't complete, we'll be facing in a particularly bad direction for comm. So I go back and make the sequence more robust; in the most likely cases, it will stop trying to drive and just skip ahead to the turn for comm. That, and some other last-minute changes that come up, should help me sleep tonight ....

Astonishingly, I voluntarily stay late for a meeting. This is a meeting Justin Maki called to discuss the problem we've been seeing in the terrain meshes. I've been interested in this problem ever since we noted it for the first time at Mazatzal. ("When this happened at Mazatzal, we said, 'Someday this will happen again, and then we'll have two data points to compare,'" I point out. We now have enough data that we should be able to solve it.)

Chris shows a preliminary graph of the error in MB placements since the start of the mission. There's no universal agreement on the trend of the graph, but it looks to me as if it took a sharp uptick around sol 140 or so: we go from having most placement errors under 1cm to having a lot of errors of 2-3cm or more.

The possible problems are these:

(a) Movement/flexure between cameras and rover/IMU since Earth calibration.

(b) Movement/flexure between cameras and IDD since Earth calibration.

(c) Movement/flexure between cameras and the left and right front hazcams since Earth calibration. Todd Litwin, who wrote most of the flight software for dealing with the cameras, thinks this is the leading candidate.

(d) Maybe the problem is with the IDD, not the cameras.

(e) Maybe the errors are due to ground processing of the images, not with the vehicle.

We need to explore all of these. As the meeting is wrapping up, I think of a way to help narrow down the options that we can do with the information we already have. Because the terrain meshes show the terrain as farther away from the rover than it really is, the rover seems to "float" a couple of centimeters above the terrain if you look closely. So I suggest taking a similar look at the rear hazcam meshes, and maybe at the navcam meshes. If the rover appears to be floating above those in the same way, then the problem almost certainly has nothing to do with the front hazcams themselves; alternatively, if only the front hazcam meshes are messed up, then the problem is almost certainly in the cameras. "Ooo, good idea," Justin says, and he assigns someone to look into it.

For now, we're not going to update the camera models on board. The only part of the flight software that uses them for on-board processing is visual odometry, and we can't usefully use visual odometry with the hazcams anyway. (Except for turns in place, and the visodom we can do with turn-in-place isn't affected by this hazcam problem.) But we're going to use updated camera models on the ground, for Spirit at least, which should reduce the appearance of this problem in the future.