Spirit Sol 229

Amazingly, it worked. I don't know if we're better than I think we are or if we just dodged a bullet this time, but it worked. There's no word yet on whether the MIs were in focus -- we've just got the thumbnails, not the full images -- but there's no IDD fault.

Phew.

So we worked around the terrain mesh problem yestersol, but the problem is still there. Indeed, if anything, we've taken a step backward: Chris is going to have to redo his analysis of it, because his previous analysis was performed using a version of RSVP that incorrectly transformed site to rover coordinates[1]. So not only do we still have the problem, we know even less about it than we thought we did.

I've come in early to check on yestersol's success and also to meet with a couple of reporters from Aviation Week. Aviation Week is going to run a story on MER, and they want to include a wealth of 3-D images illustrating what we've found and how we run the mission. In particular, they're interested in RSVP.

Frank's the artist of the group, and as such he's the best person for them to meet with. But he's leaving on vacation and hasn't packed yet, so he asks me to take care of them. They're just going to need to understand what RSVP is, and what its capabilities are, he tells me. I can handle that.

Only it turns out they've already met with people and they know all that already. What they need is cool screen shots illustrating how we've used RSVP, particularly in the second half of the mission. Preferably artsy stuff.

I can't handle that.

Not that I don't try. What we settle on, after half an hour of fumbling around, is taking a series of screen shots that communicate a sense of what they're after, without actually being what they're after. We email these to Frank, who will make versions of them that actually look cool. When he gets back from vacation. I just hope I haven't wasted their time and put them off the whole idea.

Sigh. Some days I feel useless.

As they're leaving, they catch sight of what Chris is working on. He's looking up at the rover from in front and below, as it reaches out its arm to explore the world before it. "That's perfect!" one of the reporters exclaims. "Can we get a shot of that? Wow, the longer I hang around here, the more cool stuff I see." He should try working here.

Thisol, of course, we continue prodding Ebenezer. I miss out on a lot when I'm not working as RP-1 -- stuff like, why are we at this particular rock instead of another? In this case, I happen to overhear Steve Squyres explaining it to someone: Ebenezer is the unaltered rock they're comparing Clovis to. But Steve's way of putting it is more entertaining: "Ebenezer is whatever Clovis was before whatever happened to it happened to it."

Thisol's exploration turns out to be fairly simple, at least as compared to yestersol, and they don't change their minds about what they want at the last minute, which always helps. This leaves me with time to follow up with Jim Erickson -- who, in case I haven't mentioned this, is now the project manager (Richard Cook moved on). Yesterday he asked me if I had a minute, and I told him no -- I really didn't. "When you have the time," he said. I have the time today, so when I spot him I ask what he wanted.

"You need to come to my office," he says. We head out to the elevator, and he turns around and says, "It's a good thing." He punches the "up" button. While we wait for the elevator, he muses, "Nobody ever got fired 'when you have the time.'"

So we go up to his office and close the door and sit down. I'm getting an award -- it's a JPL thing called a SPOT award, which is basically a pat on the back plus a small amount of money (minus taxes). This one is for "outstanding performance as a Rover Planner ... and in the continuous improvement of the sequence generation and validation software ...."

It was initiated by Arthur Amador ("and I heartily endorsed it and sent it on," Jim adds). Andy Mishkin and Brian Cooper were the ones who hired me onto the project in the first place, and Arthur was the one who (albeit under pressure from Brian) selected me as a rover driver. He was taking a chance on me when he did it, so it's been particularly important to me that I not let him down.

Jim makes me a photocopy of the award form. "This must be one of the best parts of your job," I say to kill time as he navigates the photocopier's needlessly complex menus. "Yeah," he says. "As project manager, you're always having to tell people, 'Cut your budget, do it faster.' You rarely get to say 'Good job.'" He hands me the photocopy and the check. "Good job," he says.

The award's not much, in itself. But then, it doesn't need to be, especially when it comes at the right time.

Some days I feel useless. But not today.

---

Footnotes:

[1] It took me a while to wrap my head around the plethora of coordinate frames on MER. Some things as seemingly simple as locating a point in the world -- just asking a question like "where am I?" -- turn out to be more subtle and complex than I'd previously considered.

So. As we all remember from high-school geometry, you can designate any point with three numbers -- say, one representing how far north/south the point is, one representing how far east/west the point is, and one representing how far up/down the point is. But those numbers have to be measured relative to some starting point, and for different purposes you want to use a different starting point.

For most purposes, on MER, we designate points in the world -- for example, drive targets, or science targets of interest -- relative to a "site frame," which we periodically reset. Resetting it makes all your old targets useless because it restarts the numbering at zero in a new place, but this is a more useful thing to do than you might think: when you've driven far enough (usually tens or hundreds of meters) from the last place you reset the site frame, all the numbers for designating a new point become annoyingly large, and the points you might have designated before have been left behind anyway.

For some purposes, though, we use another coordinate system called "rover frame," which is centered on a certain point on the rover body. As the rover moves around in the world, it sort of carries that "rover frame" with it. So, for example, in rover frame, the numbers (1, 0, 0) might designate the point exactly one meter in front of the rover, wherever the rover happens to be.

Coordinate frames are also oriented differently: site frame is oriented so that it aims north, while rover frame is oriented so that it pokes out the front of the rover, no matter how the rover is aimed or tilted.

Now, you sometimes need to refer to the same point using two different coordinate frames -- for example, to satisfy two different pieces of software that have different needs -- and transforming between them takes a bit of matrix math. Here, the problem was that the points Chris was looking at were picked out in site frame (which is the usual way to do it) but what mattered in this case was how the IDD flight software referred to them, which was in rover frame. Chris was using RSVP to transform one set of numbers into the other, but at the time there was a bug in how RSVP did this, which spoiled his work.

Driving a rover on Mars can be complicated.