Spirit Sol 193

Yestersol's drive was a bullseye -- we ended up just where we'd aimed for. "Welcome to the outcrop," says an excited Larry Soderblom. The only problem is that we picked up a little south-facing tilt, meaning the rover is aimed away from the sun. So before we spend a lot of energy investigating the outcrop, we're going to move to a slightly different spot where we can pick up more solar energy.

That makes thisol a touch-and-go sol -- we'll poke at the rock underneath us, then drive to a new location. Our destination is just a couple of meters away, but we'll be north-facing instead, and the difference in tilt will give us dozens of additional Watt-hours per sol. Especially since we'll want to RAT the rock -- an energy-intensive operation -- this is a critical move. It's a bit of a weird drive, too -- they've already picked out the spot they want to RAT, so we're going to drive the rover right on top of that location, then turn around and back away from it.

"Everybody knows we fataled this morning on Spirit?" asks Rick Welch. I'd heard something about this already, but it gets my attention. Rick's exposition is larded with acronyms I'm not familiar with, but what I think happened was this. Possibly because of the weaker solar energy resulting from our south-facing tilt, the sun woke the rover a little later than expected, so Spirit started executing the morning's commands a little late. One of the first commands would have shut it back down for a nap -- sooner after wakeup than we thought when we sent the command, since the rover woke later than expected -- and its wakeup behavior and shutdown behavior got into a fight. They both won, sort of: the rover first decided to ignore the shutdown command because it was too close to the shutdown time, then another part of the software realized it was ignoring the shutdown command and signaled a fatal error, causing a reboot.

Now, normally, the rover records the presence of a fatal error in flash memory, which will cause it to enter fault-protection mode when it reboots. This mode ignores the on-board sequences and basically just tries to call home for help, which would have caused us to lose the sol. But because the rover was still in its wakeup mode when the fatal error was signaled, it wasn't allowing itself to write to flash yet. So it rebooted, but forgot about the fatal, and proceeded normally with the sol's activities. The rover was confused, but this happened to work out in our favor.

They want to write a new flight rule to prevent a recurrence of this, but apparently nobody left on the project knows how to add rules to the flight rule database. The rover's not the only thing that's confused around here.

[Next post: sol 198, July 24.]

1 comment:

Anonymous said...

I've heard of a "bus factor" that's directly related to how many people on a project can be hit by a bus before all useful knowledge of a certain system or subsystem is lost.

Sounds like your bus factor got pretty bad there.