Opportunity Sol 649 (Spirit Sol 668)

Meanwhile, on the other side of the planet ... Opportunity is still skirting the rim of Erebus Crater, making her way to the potential entry point we can see from orbital data. Thisol's plan is to finish up a little IDD work, then drive about 50m -- mostly along outcrop -- toward a flat patch of outcrop we can see in the distance.

This plan is complicated by the fact that the flat patch of outcrop isn't so flat. Looking at it in stereo, we realize that it's actually a somewhat steep face, rising about 50cm over less than 2m. (The fact that the outcrop seems to have some delta-Z makes me think the science team might be interested in it, as it might provide some layered rock to examine. Cooper, ever eager to get moving, is comically reluctant to point this out to them, but I do it anyway.) The ends of the patch are still relatively flat, though, so we decide to aim toward those instead.

Our drive sequence is further complicated by the fact that we're heading at about 180, but need to turn for comm to about 115 -- a large counterclockwise turn, problematic on this vehicle because of the stuck right-front steering actuator. If we knew in advance what our heading would be for the comm turn, that would make it a lot easier to sequence. But we don't, because toward the end there's a slight change in direction: we'll be headed either about 175 or 185 when the time-of-day limit hits. And the only tool we have to make the sequence conditional on the vehicle's yaw gives awkward results around 180, because it gives its answers in the range of -180 to +180 (actually -pi to +pi, since it's in radians) -- nothing we can't sequence around, it's just one more damn thing.

All this still wouldn't be too bad, if Cooper or I were driving. But we decided to let Paolo do it, since he needs the experience. He actually handles it really well, making good decisions and so on. The only problem is that he's still somewhat new, and therefore somewhat slow, and this is a complicated sol, and, well ... it takes a long time. I sit with him pretty much the whole time and strive to stay cheerful and positive. Add that to the list of challenges.

Oh, but we're not through yet. Because I'd been sitting with Paolo, I hadn't had a chance to closely examine Brian's IDD sequence. During the CAM, I discover that the MI poker gets awfully close to a rock during a lateral move. There's less than 1cm of clearance in the prediction, which is within our error budget. Luckily for me, Ken Herkenhoff -- the MI PI, basically the designer and builder and owner of the instrument -- is sitting in the room. (He's normally one of the remote scientists, but is out here to participate in training the new crop.) So I put the CAM on hold, show Ken the situation, and ask his advice.

Now, the MI poker has a bit of spring steel near its base, allowing it to flex safely in just such circumstances as these. And the simulation does show that we have clearance, albeit not much clearance. What's more, we're first touching the surface near the potential contact point, so any error about the location of that point will likely be accounted for -- if our imagery is misleading about that, it should be misleading in the same way about the nearby spot we'll touch, and the sequencing is relative to the touched location, so the error will effectively magically disappear. All this taken into account, Ken's comfortable with proceeding as planned, so we go ahead. (What occurs to me later, as well, is that the simulation we're looking at is actually relative to the 1cm overdrive position -- which aleady accounts for our uncertainty about the terrain -- which means we'll likely have 1cm more clearance than shown. Even better.)

We also realize another place where there's a potential problem. We're in that phase where the Earth-Mars time difference requires us to plan several sols ahead, so we don't yet know the true state of the IDD at the beginning of this sol's sequences -- for the very good reason that that stuff simply hasn't happened yet. And since we're starting (we hope) with the MB in contact with the CCT, we have to disable self-collision checking at the beginning of the sequence in order to allow ourselves to retract the IDD into free space. The problem is, if the planned IDD sequences don't go as predicted, the IDD could start off sol 649 someplace unexpected, and disabling self-collision checking is not what you want to do under those circumstances.

Our solution is to remove the IDD sequence from the bundle -- we'll call in Sunday morning, after we've looked at the data, and we'll send this IDD sequence to the spacecraft only after we know it's done what we expected it to do. This potentially means we'll have to drop the IDD sequence as well as the subsequent drive, since the rover won't drive when the IDD is unstowed -- and it also means we've all got some work to do Saturday night and Sunday morning -- but that's a lot better than risking the IDD.

At long last, we complete the CAM -- and not a moment too soon, as it's been a long and grueling day and we're all getting kind of punchy -- and I realize we've made yet another mistake.

"We're not going to change anything," I say carefully, "but we did screw something up." Normally, our drive sequences detect absent helper sequences, precluding further driving if a helper is missing. (This would mean, for instance, that we were unable to perform a slip check; without that, we don't know whether the vehicle is bogged down, so we don't want to keep trying to drive for tens of meters, making the situation worse.) Our predicted downlink is so poor thisol, however, that we wanted to be sure we'd turn for comm even if one of the helper sequences didn't make it on board. That's rare, but it happens, whether due to a human screw-up somewhere in the process, equipment problems at the DSN stations, or simply because of interference in the long journey of the radio waves from Earth to Mars.

So we pulled a clever trick: during the sequence, we abuse the OK-to-IDD flag -- if a helper is absent and we preclude driving for that reason, we also preclude IDDing. Later, the sequence checks whether we're OK to IDD, and if not, that means a helper must have been missing, so we re-enable driving (and IDDing) so that we can turn for comm.

"What we forgot," I conclude, "is that if you try to drive while driving is precluded -- which we would -- you also get a goal error. And we don't clear that goal error, so the turn for comm still wouldn't happen."

But this bites us only if a helper doesn't make it onto the vehicle -- a rare event -- and it doesn't truly hurt us, it just fails to help us. And at this point on this sol, nobody wants to go back and fix it. So we don't.

[Next post: sol 676, November 27.]