Opportunity Sol 541 (Spirit Sol 562)

"It's way too early to be driving rovers," mutters Jeff Favretto. I must agree. It's 07:00, and it's a tight sol -- meaning our uplink is just a few hours away -- so we have to get a lot done, with little room for error.

Fortunately, Mars is kind to us thisol. The previous drive didn't go quite where it was meant to, but it made good progress and left us at the entry of a fairly wide trough that extends for another 25m or so. At that point, it's hard to tell what happens; there are ripples blocking our path, but they're not too scary-looking. Still, we don't want to try to cross them thisol. So this will be a simple, straight drive, about 24m down the trench. We'll stop after a few meters to PCAM an outcrop ("Zurich") just in front of us, but otherwise there's not much special about it.

I'm pretty well done with the sequence in maybe four hours, leaving me time to handle another of Susan Kurtik's tour groups. This one I take up into the SOWG room, since there's a moderate-fidelity full-scale rover model in there now. This model is named "Bubba." I am not making this up.

Just before Cooper delivers the sequence, I realize we've been making a mistake. The new-style driving, where we punctuate the drives with 40cm slip checks every 5m or so, has a flaw: if the lowest-level visodom-update sequence doesn't make it on board, our sequence won't detect that. Instead, it will blithely believe that the slip test passed and keep driving. Murphy's Law says this will happen on a sol where we really do get stuck, so I persuade Cooper to make the easy fix, inserting a single call to that helper sequence in our drive backbone. The command that invokes that helper is told that it should abort the backbone sequence if the target sequence isn't on board, which will mean that we'll cancel the drive if the helper is missing. That's the safe and logical thing to do, and that's the end of that.

Or so you'd think. Speaking of Murphy's Law ....

At the point where the backbone calls the helper, no special visodom pointing has yet been set up. This means that that call to the helper will do visodom using the HAZCAMs. None of this matters in itself; the result isn't used anyway, we're just invoking the helper for the side effect of canceling the drive if the helper is missing. The rest of the drive properly sets up to do visodom using the NCAMs instead. But it's this switch from one set of cameras to the other that worries me. That's supposed to work, and I think it's even been tried, but I don't really know that it works. So just out of an abundance of caution, I call Mark Maimone's voice mail, describe the situation, and ask him to call me back if there's a problem with this.

I don't hear back from him. Until -- just as the CAM ends, my phone rings. It's Mark. And it's bad news. I'm right that what I describe is supposed to work. It's even been done a few times, and worked. But once, it didn't work -- subsequent NCAM updates in the same drive started failing for no apparent reason. Mark was never able to track down the bug, and he isn't sure it's because of the camera switching. But just in case, he recommends we fix it.

Oh, lovely. I really, really hate to do this; we had such an early start, and everybody thought they were just about to leave. And this is going to delay us for, like, an hour. I only have to make a minor change, but then Cindy has to spend an hour turning all the cranks that need to be turned in order to produce the uplink.

But it has to be done.

So we do it.

Oh, but the fun's not over yet. After we've rebundled and reviewed the changes, another thought occurs to me. In the backbone sequence, we're turning visodom off (it's turned on as needed during the slip checks). This means that the first time the helper is called, it's called with visodom off. It will still do a nav map update -- and will have the side effect of checking for the sequence's existence -- but not a visodom update. If we need it to do a visodom update, we have to turn visodom on. Which is going to mean another minor change to my sequence, followed by another hour's delay for the entire team ....

The sinking feeling starts, I turn to say something, and -- wait a minute. If the first call to the helper is being performed with visodom disabled, so that it isn't doing a visodom update, then we have no reason to think it will interfere with the actual visodom updates during the drive. Not only do we not need to rebundle again, we didn't need to rebundle the first time.

I think about whether to say anything about this. Either version of the sequence, I now realize, will do the same thing, so it makes no difference to the rover. However, all else being equal, we should go with the simpler thing -- that is, revert to the first version. But there's another consideration. Doing this job is exhausting any time, but it's worse when we start at 07:00. Right now the team is tired, but proud of themselves for sticking to their posts and doing the right thing.

I'll tell them tomorrow.