Opportunity Sol 263 (Spirit Sol 284)

We didn't make it.

Yestersol's drive was supposed to back away from Wopmay, turning uphill as it went. Then if it got far enough, it was to turn to face uphill. Then if it was still reasonably close to our goal for it (it could slip downhill during the turn), it would drive on.

The way it worked out, the backup went reasonably well, not gaining as much uphill distance as we'd hoped but still OK. So it went on to do the turn, and the turn took it out of the goal region, so the second leg of the drive didn't execute.

This was a good thing, in the sense that the conditionals we put in protected the rover exactly as they were supposed to -- if the rover had executed the drive's second leg, it would likely have tracked across the slope and whacked into Wopmay, which, since Wopmay is big enough to damage the solar panels, would be bad.

"Is this what driving in this area has been like?" I ask Frank.

"Yeah," he says resignedly, "pretty much."

So we're trying again. Frank suggests I drive today, and I don't need to be asked twice. There are a few scary moments at first when I realize I haven't planned a drive for months -- been RP-2 too long. But then it all comes back to me, and I come up with a structure for the drive.

I decide to do this one a little differently. Since our real goal is to get away from Wopmay, let's try telling the rover that. I define a point on Wopmay (calling it "WopmayEdge") and structure the drive in terms of getting away from that point. We command the rover to drive six meters uphill, using visodom to see how far it actually gets. Then it'll check to see if it's reasonably far away from WopmayEdge, and if not, drive a little farther. Then, if it's far enough from WopmayEdge, it'll start driving cross-slope.

All of this would be easier if we just went downhill. But then we'd have another problem; we'd have to get even farther uphill later. So we might as well pay the price now ....

So I hack out this drive, and Frank and I go over it and make some changes he suggests, and that's about it. Somehow this seems wrong.

"I don't know how to put this," I say, "but what went wrong with the decision-making process that put me in charge of a four-hundred-million-dollar piece of equipment on another planet? Isn't there supposed to be a government body or something that decides what you can do with these vehicles?"

"There is," Frank points out. "We're it."

"True, but what I mean is ... well, isn't somebody else supposed to do this?"

"You mean, adults?" Frank says.

"Exactly!"

"I get that feeling all the time, dude."

The rest of the sol mostly goes smoothly. In the end, the drive sequence ends up taking longer to execute (or so our model predicts) than we'd originally projected, but since the drive is a high priority, Cindy obligingly makes time for us. There's just one problem, and it shows up very late. It has to do with our use of visual odometry.

Visodom is an application of parallax. That is, it works by comparing two pictures (really, two stereo pairs of images) taken a short distance apart. It computes how far common features have moved between the two images, then figures out how the rover must have actually moved (vs. how far it was commanded to move, an important distinction in such slippery terrain) in order to cause that apparent change. Hence, in order for visodom to work, there has to be a certain amount of overlap between successive images. This places limits on the kind of moves we can make between visodom steps, and given the camera pointing we're using on Opportunity, one of those limits is that we need to keep turns under about 15 degrees. If we want to turn farther than that, we have to break up the turn into multiple smaller turns, with visodom updates after each part.

Walking through the sequence at the CAM, I notice that I inadvertently exceeded this limit during the sequence. One of the turns I thought was 15 degrees is in fact 20 degrees, which isn't much over the line, but ....

The turn is right at the end of the sequence, meaning it won't affect the drive itself, but it might affect our ability to image Wopmay after the drive. If visodom fails to update, the rover isn't where it thinks it is, so it won't aim the cameras where it should, so we won't get the pictures we need in order to decide whether to explore the other side of Wopmay before driving farther away.

Since that makes this a science concern, Squyres, teleconferenced in, pipes up. "Is this going to make us miss our post-drive PANCAM?" he asks.

I think about it. We've already had to ask for more time for the drive, and I don't want to add more time to do another visodom update. Besides, we're running late, as usual, and I know people just want to leave. And it'll probably be OK .... "Nah," I answer at last, "I think the visodom update will work."

"OK," he says. He doesn't sound completely convinced, but what can he do but trust the rover driver?

That might have ended the matter, but it doesn't. The more I think about my answer, the less I like it. It's a matter of pride to make these things work, and besides, people are trusting me. The visodom update probably will work, but what's the point of taking the risk? Sure, we save three minutes by not doing it, but if it causes us to blow the PANCAM image, we could end up having to spend another sol here just to get the imaging. That's a heck of a downside. And it'll be all my fault, because I was too lazy to do the right thing.

The CAM is coming to an end. I make my choice.

"Hey, I hate to be a pain about this, but I want to change my answer. I really think we should break up that turn and add a visodom update."

Squyres sounds relieved: "I think we'll all sleep better." And, as happens every time, the uplink team springs into action. I make my changes and deliver, and Rich rebundles, and Cindy and Rich and Andy and I double-check the changed sequence. Fifteen minutes after I spoke up, we're done, and that's all it took to do the right thing.

Maybe this spacecraft is in the hands of adults, after all.