Spirit Sol 278

I'm a little worried about yestersol's drive. It was in two legs, meant to position us with a rock named "Uchben" in the IDD work volume. But I think we went about it the wrong way. When we're doing drives in multiple parts, we really need to ensure that the first leg of the drive gets where it's supposed to go before starting the second leg of the drive. And we didn't do that. We left the first leg of the drive with maybe 50cm uncertainty, enough to mess up our placement at the end of the second leg. And it wouldn't have been that hard to fix -- heck, I've fixed such drives before, by adding fine-positioning commands at the end of the first leg. I resolve not to repeat the mistake.

As it turns out, it's moot. "The [dynamic brake] relay freaked out again," Chris says. "We drove only two meters or so. We didn't even complete the first leg."

So that's bad. Especially because it suggests that Spirit really does have a hardware failure of some kind, not the one-time software failure we were all hoping for. This is something we're going to have to diagnose and, likely, deal with for the rest of the mission.

We're planning a drive anyway, to complete the one that was interrupted thisol. Since the failure -- whatever causes it -- shows up at the start of a drive command, Chris is working on a way to do it with as few commands as possible. Which means leaving out fine-positioning commands at the end of the first leg, which means I'm going to repeat the mistake I just vowed not to repeat. But at least it's for a good reason.

Or maybe I'm not going to have to repeat that mistake. There's a meeting going on to decide what we're going to do about the anomaly, and it turns out they've decided we're not going to drive thisol after all, to reduce the risk of unintentionally damaging the vehicle. So the uplink team switches to plan B -- an all-remote-sensing sol, requiring no RP work -- and I shrug quietly and go hang out in the anomaly meeting.

The upshot of which is, we'll likely be sitting still for the next few days. Jeff Biesiadecki is working on a diagnostic program to run on the rover, but it won't be ready until Friday, a couple of days away. "I don't want to run a new test on the flight vehicle for the first time on a Friday," Erickson says, which means it won't run until Monday. Meanwhile, we might IDD, but no driving.

I look through Rick's meeting notes, which are projected on the big screen, seeking something hopeful. One of them says something about one of the fuses -- they seem to have a known failure mode that could be causing the brakes to respond more slowly. If that's all it is, it seems to me, a simple patch to Jeff's mobility flight software code could fix the problem -- just increase the amount of time it waits for the brakes to respond.

The rest of the failure scenarios I have time to read look grim. I'm rooting for the fuse.