Spirit Sol 72

I wake up a couple of hours early, in a near panic. I had completely forgotten that our previous drive had timed out, which means we would have had a goal-error flag set. Mark didn't mention this in his hastily written downlink report, so we didn't clear the flag in this drive sequence, which means the drive won't happen. I dislodge Zenobia, log in from home, and check the telemetry -- only to find that the goal-error flag wasn't set after all. (Which must be the actual reason Mark didn't mention it: there was nothing to mention.) I don't understand this, but I'm so relieved that for the moment I don't care. I actually manage to get a little more sleep before I have to get up.

(It turns out later that there's a good explanation why there was no goal error. At the end of our last drive, the rover timed out because it was back-and-forthing, trying to find a safe path. It happened to time out after a backward move, which left a little extra space in front of it. The sequence cleared the timeout error, enabling the rover to complete the final stutter-step into the small safe zone, without producing a goal error. If there had been such an error, Mark would have mentioned it and we would have cleared it as a routine matter; we do that all the time. So everything was fine. You'd think my subconscious would have recognized this pattern by now, instead of waking me up all the goddamn time.)

My badge is working again. I stuck around for hours yesterday, just to find out that Security couldn't help me at all. The project sent them a list of people whose access was supposed to be revoked and mistakenly included my name on it; apparently, this kind of thing happens all the time. And I'm far from being the only person it happened to this time: I keep having to open the door for other people whose access was mistakenly revoked along with mine and hasn't been restored yet.

Today's drive didn't quite complete, but we got a heck of a lot closer than I expected. We made it to the far side of Serpent and turned to face the bedform; that's the good news. The bad news is that the rover saw a 10cm rock with a depression behind it, and interpreted this as a 30cm obstacle. (Not unreasonably, actually; the rover could actually end up in trouble if it tried to drive over this in just the wrong way.) This exceeds the maximum obstacle size, so the rover refused to perform the final approach. We ended up 85cm short of our destination. Considering all the things that might have gone wrong, this is not bad at all. And there wasn't anything we could have done about it in advance; from our starting location, we couldn't see this terrain well enough to have avoided the problem. Just one of those things.

While we're looking at this, John Grant comes by to alert us to the day's likely plan. It's always something new. They want us to drive up partway onto Serpent, make a big scuff mark (not really a trench, just enough to scrub off the outer dust layer), back up so they can PANCAM/MTES/NAVCAM the scuffed area, and then drive forward again so that the area they just imaged is in the IDD work volume.

What makes this interesting is that we have no idea how much we'll slip in the process. So we can't accurately correct for slippage in advance. Mark suggests using visual odometry, a feature where the rover watches how objects in its visual field change position as it moves, and updates its own internal position estimates based on the result. This is really how humans work: when you're "navigating" as you walk, you trust your eyes more than you trust your feet. The rover normally trusts its feet (wheels), because it thinks so slowly. But when you need precision and can't correct on the ground, visual odometry is the only way to go. We haven't done this on Spirit before, but Opportunity has used it to good effect.

The big news in the downlink assessment meeting is that we've achieved mission success. We were waiting to rack up 60 sols of science ops. That was delayed by the Bad Thing[1], but we've now hit the goal. From here on out, we're gold. More good news: Lutz reports that yestersol's MI images (the ones we took after the gunslinging) look fabulous -- judging from the thumbnails, at least; we'll get the full frames in the overnight pass.

The plan shapes up to be pretty much what John Grant said it would, but there's a lot of debate over exactly what we want the rover to do to Serpent before we poke at it. Do we just want to drive onto it, then drive back off? Or should we wiggle the wheels, or run one of the wheels in a trench-like operation to scoop material out of it? Do we want to make one track or two? John suggests that everyone who cares about the details discuss the matter with me after the meeting, then ends the meeting itself. I accumulate a group of about a dozen scientists, who debate amongst themselves for a while before deciding that anything I do that scrapes away the upper layer is fine. Since we're already more or less lined up with Serpent, we should be able to just drive almost straight ahead onto it -- this will roll the left wheels over the top of the bedform -- and drive straight back off. In order to IDD the resulting scuff mark, we'll have to shift the rover to the left, which there's no very good way to do -- because the middle wheels don't articulate, we have to turn and drive and turn, and this accumulates uncertainty. (This maneuver later becomes known as "The Translation Dance.") But it should be OK.

This is starting to look like a nice, straightforward plan. So naturally it goes to hell. I'm building the sequence in the SOWG meeting when I realize that if we carry out that plan, we'll end up with the rover straddling Serpent. Which in itself is fine; Serpent isn't that tall where we are. The problem will be that we won't be able to use the APXS. To use the APXS, you first have to open its dust doors, which you do by pressing the instrument against a hard surface; this triggers a switch that pops the doors open. Soil isn't firm enough to cause this to happen (and we'd get the instrument dirty anyway, if we tried), so when using the APXS on a soil target, we instead bring it underneath the rover and press it up against the rover's "chin" (technically, a calibration target called the CCT). But when doing this, the IDD needs a lot of clearance under the rover. And Serpent is too tall. If we try to open the APXS on the CCT while straddling Serpent, we'll end up dragging the RAT (the instrument opposite the APXS) through the dirt, which is Very Bad.

We can't fix it by backing off farther, because there's a rock of about the same size at Serpent's tip. If we back off farther than that, we can't reach Serpent any more. The scientists consider whether we can open the APXS before driving and just leave it open overnight, but this violates a flight rule and nobody feels very comfortable with it. We'll have to find another answer.

Fortunately, I paid attention to the earlier discussion and I know what their general goals are, so I have an alternative to suggest: drive around to the side of Serpent and scuff it from there instead. I'd previously rejected this idea because it made things too complex (the drive itself is not complex, but the more driving we do here, the more uncertainty we have about the results), but I no longer see an alternative. We go down to the sequencing room and I start planning it.

Now there's another problem. The instrument reps need to know where to point the cameras to get images of the scuff marks. But we don't really know where those are going to be, because, again, we don't know how we're going to slip. We don't know exactly where the rover is going to intersect with Serpent, and we don't know how it will yaw when scuffing, and we don't know how it will slip afterward. All of these problems combined make it impossible to pick a precise target in advance.

This leads to an overly complicated discussion, made worse by the fact that every time we get all of the participants up to speed, someone else overhears the content of the discussion and wants in, and we have to start over. I start to get really frustrated: time is running out, and there are too many people offering too many suggestions (often ones we've already dealt with, before that person came into the conversation).

At last I see the answer. It's one of those things that's easier to see if you're a programmer. We've all been thinking in terms of absolute positioning -- predicting the spot where Spirit will cross Serpent -- but the answer is relative positioning. "We don't have to know in advance where the scuff mark is going to be," I point out. "We just make the scuff mark wherever we make it, shift the rover over and reorient it so that we're facing along the scuff, and take the images from there."

This won't eliminate all of the uncertainty, but it'll eliminate more than enough, leaving only whatever we pick up during the last little bit of the drive. They'll instruct the cameras to take images of a position 85cm in front of the rover (this length is determined by properties of the rover and its instruments) -- wherever that happens to be -- and it'll be my responsibility to ensure that there's a scuff mark there. That won't be easy, but it also won't be excessively difficult; the post-scuff driving takes place on relatively flat ground, and we can help our chances by making a really long scuff.

They aren't immediately convinced; they normally target the same spot for pre- and post-disturbance observations. But, as a couple of them point out, the drift is likely to be compositionally uniform over its length; it won't matter if the pre- and post-disturbance observations are a few cm apart. And if they can give up that constraint, my suggestion will solve all of the rest of the problem. Chris helps by taking over the job of convincing them and working out the targeting while John Wright and I work on the drive.

There are more distractions. There are currently no IDD activities scheduled for tomorrow, but there's an MI observation in purgatory. A couple of the scientists keep pestering me for the sequence ID of the IDD sequence (which they need in order to deliver their own), but I don't want to deal with that unless the observation makes it into the final plan; otherwise it's wasted work. (Maybe I should have just given them a sequence ID; then they could have wasted their own time instead of mine, and I wouldn't have come across as uncooperative. Confusingly, this seems both right and evil at the same time.) The IDD stuff ends up not making it into the plan, so I don't have to deal with it after all.

Part of the reason the IDD stuff gets pushed out is that Jeff is planning using my original resource estimates, which included the overhead of visual odometry. Now that we've decided on relative targeting for the images, we don't need visodom any more, and we need far less time and energy than we had expected. Instead of taking an hour, we'll be done in 20 minutes, even though the drive itself is now more complicated. But it's too late to go back and change things now. I feel awful about pushing some science out of the plan, yet I'm philosophical about it: if they want us to work on a compressed schedule, this kind of thing is going to happen. Haste makes waste, or so I've heard.

I get the drive into very rough shape and hand over to John; we continue working on it together. One of the changes we make, to help ourselves out, is to broaden the scuff. We'd originally planned to step down the bedform in 10cm intervals, wiggling the wheel as we go; this would leave a scuff about the width of a single wheel. We change this to perform a small turn-in-place at 10cm intervals instead, so we'll cut a significantly broader swath out of the bedform. We've arranged the drive so that only one wheel is on the bedform while we do this, so we shouldn't slip much, and having a broader scuff means we can accommodate more uncertainty in the rover's final position. We're going to scuff the hell out of this thing. When we show the animation of the intricate drive at the walkthrough, Kevin Talley asks, "So, do the other bees know where the honey is now?"

Why are they so interested in Serpent? The dark deposit at the other end of Bonneville -- which we decided not to drive to -- contains a "mystery feature." It's a spectral signature that's not in the scientists' library, meaning there's some unknown combination of elements over there. Serpent and its neighboring bedforms were likely formed from that material, blown by the wind across the crater to settle here. So, effectively, we might be able to examine the far end of the crater by poking at this thing.

I end up staying so late past the end of my shift that I decide to stick around for the Command Approval Meeting. I've never been to one, and I might as well take the opportunity to do it now. While waiting, I get into a discussion of SEQGEN with Kevin Talley and Richard Kornfeld, who are terribly frustrated with it. So is Celina Garcia, who says she badly wants to just rewrite it.

"I've been more frustrated with SEQGEN than you've ever been with anything in your lives," I tell them. All the same, I find myself gently defending SEQGEN. It's not meant for this kind of environment, it's meant for cruise and orbital ops, which work on a very different timescale. The fact that we can use it at all, in a way so far removed from its original intent, is remarkable. In the same way, its developers and adapters aren't used to the pace of development we've pushed them into, because of MER's own highly accelerated development schedule. We were asking them for a final adaptation in less time than they normally have to develop a prototype.

I don't bring up this point, but there's also an us-versus-them aspect to it. I see a tendency among project people to treat anyone outside the project as an enemy. (Shamefully, I'm as guilty of this as anyone; and having been the outsider in this situation myself, I should know better. I choose to construe this as evidence of the trap's perniciousness.) If you're having trouble with software developed by someone on the project, you go to them and tell them there's a problem, and since their goals are your goals, they work with you. When it's a tool developed outside the project, we feel ourselves to be under attack. It doesn't help that you have different bureaucracies to work with in the two cases, increasing the perceived separation. And it doesn't help that people outside the project legitimately have different goals: they're not just worrying about your mission, they're also worrying about Cassini, Voyager, and who knows what else.

I spend some time thinking about this problem and don't come up with any answers I like. But I'm happy I can at least see the problem from this side now.

John has an idea for the extended mission. Why doesn't he become an RP-1 and I'll become an RP-2? That way, he can go back to vanpooling (which saves him a lot of money, apparently) and I won't have to get here at 7:00 every morning. I've been thinking along the same lines, I tell him. "I'm not looking forward to going back to Earth time," I confess. "You know how enthusiastic I am about this mission, but getting here at 7:00 every morning will suck that out of me in no time."[2] I don't really want to give up being an RP-1, though, since I think I prefer it to being an RP-2. So I temporize: "I'll think about it."

I'm not there much longer before I give up on the idea of waiting for the CAM. If I do become an RP-2, I'll see plenty of them in person, and if I don't, it's not a tragic loss. So I hold the door for some unlucky soul whose badge access still hasn't been restored, and I leave.

---

Footnotes:

[1] By which I mean the Sol 18 Anomaly, when we got stuck at Adirondack -- making no progress toward our official mission goals -- for what seemed like forever.

[2] Five years later, I'm still no morning person. However, I fully recognize how lucky I am that my one and only complaint about my job is that it starts earlier in the morning than my brain does, so I don't bitch too much. Don't get me wrong, I bitch. But not too much.