Spirit Sol 502

At the SOWG meeting, there's a controversy about the RAT. Fortunately, I've been warned about this in email from Ashitey: he says we're still worried about the badly worn RAT causing the IDD to damage itself through vibration, even when just brushing (everyone agrees grinding is out) and that the Honeybee guys are wrongly suggesting there's no problem.

Which is exactly what happens at the SOWG: when Steve asks about it, the Honeybee guy says there's no problem. "We've seen lots of lost-contact events even back to the beginning of the mission," he argues, suggesting that the events we see now don't imply the arm is actually vibrating dangerously. Steve doesn't just take the RAT guy's word for it, though; he wants more imaging as part of a diagnostic that will eliminate all doubt. Since that's exactly what Ashitey asked me to ask for, I spot my cue and pipe up. "Yeah, Steve, we'd like HAZCAM, PANCAM, and NAVCAM of the RAT brush and teeth before we stow at this location." I've already looked through past sols and found the last time we did this (sol 426), which will make it easy to do again, tomorrow or whenever.

"Sounds like we're pretty much on the same page, then," Steve replies.

The RAT guy tries to tell Steve that the instrument is safe to use, but Steve says, "I'm worried about the whole rover, not just the RAT." This is why Steve is so awesome[1]: lots of science team leaders would have thought it's their job to stand up for the science side, no matter what (or so I'm told). Not many would realize that the science team is best served by preserving the goddamned vehicle. Or so I'm told. Anyway, we're damned fortunate that Steve's not of that stripe.

Chris had to take his dog to the vet this morning (she's got bad allergies), so I've swapped with him: reversing the official plan, I'm RP-1, and he'll be in later as RP-2. But it hardly matters; the two-sol plan is so simple that I'm already done when he arrives. Or rather, I should have been done. At the activity plan approval meeting, it turns out I've sequenced the wrong thing, moving the IDD to the wrong target at one point. This is not really my fault, as the official plan had it wrong, and that's what I was following. But I should have seen it coming because of the Curse of the Premature Animation. (Your line: "I used to have a problem with premature animation, but now I just think about baseball.")

That curse is this. Whenever I'm so confident that I've finished early that I go ahead and build the uplink report and/or the official MPEG animation before the walkthrough -- much less before the APAM, as I did today -- something will have to change in the sequence that invalidates that work. This happens every time, and today was no exception.

Fortunately, it's easy to fix: almost before they can finish describing the problem, I've already fixed the sequence and have redone the on-the-fly animation. But you'd think I'd know by now that I'm cursed. Cursed. Cursed!

Maybe next time I can avert the curse by thinking about baseball. It's worth a try.

---

Footnotes:

[1] I mean, of course, that it's one of the reasons. One of many, many, many.