Opportunity Sol 339 (Spirit Sol 360)

"Thank God the spacecraft is smarter than we are," Art says wryly. Our manual data product deletes failed yesterday, so Opportunity deleted some for us to keep flash from getting too full. It was so busy doing this that the sun-find timed out, which kept Opportunity from updating its attitude knowledge. So Opportunity decided it didn't know its current attitude, which causes it to mark itself unsafe for driving. Luckily, this problem was discovered last night, and Opportunity's already been manually reset to a better state of attitude knowledge.

But the autodeletes are a problem. You'll remember a few days back, when Jim Bell wanted to take some sky-flat images to help calibrate the PANCAM data, and he and Justin Maki got into a rather acrimonious argument about it? Well, the sky flats weren't taken that sol, but they were taken on a later sol. But they hadn't been downloaded yet. And guess what the autodelete logic just deleted?

So they're going to have to take those again.

Justin has something else to worry about today -- namely, me. There's something that's been annoying me through much of the extended mission. During the nominal mission, we built the post-drive NAVCAM sequences from scratch each sol; as a result, we could assign a sequence ID up front and worry about the pointing later, when we had the drive done and knew what we needed. But nowadays we're trying to use a "sequence library," which means we try to pick an already-built sequence. We still have to choose a sequence ID up front, but since sequences in the library are identified by sequence ID, this implies that we're choosing the post-drive imaging before the drive is built.

Obviously, this is screwed up. That decision was driven by another screwed-up decision made somewhere else, and, well, long story short, it's not going to get fixed today. Most of the time it doesn't matter; we image such a wide area that we have plenty of room for error. (Which is another gripe: why are we so wasteful? Maybe if we weren't so routinely wasteful, we wouldn't have needed autodelete, which killed the sky flats and ... ah, never mind.) But on this sol, we narrowed the post-drive imaging to save on downlink, and we're going to have to play with the drive to ensure we get onto the right approach vector for our final approach to the heat shield.

This combination of things -- an incompletely specified drive and a narrow field of view for the post-drive imaging -- is exactly the case where the sequence library approach is at its worst. Justin originally chooses a post-drive NAVCAM centered at 90 degrees, but after talking with the TPS folks, it becomes clear we should shoot for a very different orientation to the heat shield. (Which is bad news for Jeff, too, in a way. He couldn't sleep, so he came in early and built the drive. Now I have to rebuild it. That's fun for me, but he must feel he wasted a bit of his time.) So he has to redeliver with a new mosaic centered around 72 degrees.

Then I start looking at the situation more carefully in RSVP. Turns out that the new azimuth is fine, but I'm not as sanguine about the elevation. RSVP shows the NAVCAM pointing as being marginal -- we should get the whole heat shield, but about a third of the image is above the heat shield, and it's doubtful we'll see its bottom edge. Since the bottom edge is nearer to what we want to IDD, and more importantly what we'd smack the rover into in the event of a misjudgment, I'd feel safer about lowering the pointing a notch.

Justin argues against this change, and his is not a judgment to dismiss lightly. It's not just that he doesn't want to re-redeliver; he's sure we're going to image the heat shield whether we lower the elevation or not, and if we keep it the way it is, we're more likely to get distant features (namely, our own tracks) in the distance, which makes the images look cooler when MIPL converts them to overhead mosaics.

Justin knows this stuff like the back of his hand; it's hard to escape the feeling that arguing with him about it makes me a jerk. But in the end I decide to ask him to change it. Getting the tracks in the NAVCAMs would be cool, but getting the entire heat shield is critical. If we're aimed lower than necessary, then we'll just image more of the terrain leading up to the heat shield, which is perfectly fine with me; whatever we can't see well in the front HAZCAM view of this area, we'll pick up in the NAVCAMs.

So Justin redelivers again.

Note to self: if Justin was right and I was wrong, apologize profusely.

Second note to self: prepare to apologize profusely.

Worse yet, most of this work might be moot -- or, at least, delayed. Despite the space cleared out by autodelete, we won't have enough room in flash to do the entire planned sol unless we get confirmation of some additional manual deletes that were uplinked at the last second last night. The plan for the sol is, first, to drive up next to the heat shield, about 2m away, and take a whole bunch of pictures. Then we back off and drive around to its west side, where we take some more pictures. (Assuming this all goes well, we'll be able to approach to IDD range on the following sol.) But if we don't have room in flash, we won't be able to take all the pictures, which means we'll cut the sol in half. The work won't be entirely lost, but we'll have to defer most of it by a sol.

So we go ahead, hoping for the best. And our optimism is rewarded when Roger Klemm strolls into the room with a big grin on his face. "The deletes succeeded," he announces. "We have 361 megabits available." So we're good to go.

And "go" we do. If anything, we go too fast. When we finish the CAM, Emily complains about exactly that. "That went too fast," she said. "Did we miss something?" She's serious enough about it to bring up her checklist and go over it. But we didn't miss anything. Apparently, we're just getting better at this. Maybe we're smarter than Art thinks.

[Next post: sol 365 (Opportunity sol 344), January 11.]