Spirit Sol 101

Saina Ghandchi's father died. Saina's a TUL, one of the more high-pressure jobs on the uplink team, and she's here anyway. She won't be going home to Iran for the funeral and everything for three weeks. And I thought I pushed myself too hard. Marc Pack offers to pick up her mail or whatever while she's gone, which is another one of those damn things I'd think of myself if I weren't such a moron.

Today the schedule is such that the afternoon team is the first-shift team, so I'm here in the afternoon but I'm RP-1. Ashitey is shadowing me again. We're both in a couple of hours early, so we spend some time building sequences, getting him further up the learning curve. (During which, Jessica Collisson pops in to say she just read my Zipcode Mars entry.[1] "It was clever!" she laughs.)

I get interrupted to participate in a logistics meeting, which I normally try to avoid. But they need a RP's perspective to help work out the next few sols. Jennifer, Andy, and Ron (thisol's SOWG chair) are trying to figure out how to make Earth time work over the next few sols, when data is arriving really late in the day, leaving us very little time to sequence. The plan shapes up to be an alternating sequence of remote-sensing and drive sols: we'll sit still and take pictures for the first sol in each pair, and drive on the second sol. Since we're not moving the vehicle on the first sol, we have more time to plan the drive. (This is almost the reverse of the idea we came in with; Daniel Limonadi, who's recording the rapidly changing plan on the fly, starts humming circus music as he flips the presentation slides around. Doot doot doodle-doodle doot doot doo doo ....) In the meeting I reflect once more on how much difference it's made that we have the right management on this mission: "I'm just concerned that we're asking people to do too much in one day" is a common refrain in the meeting.

After the meeting, Daniel asks if I forgot to create the movie for yesterday's sequences. I sure did -- it's what I was starting on when I noticed the IDD collision problem, and I never finished up. "It's no big deal," he says, "I was just wondering." "No, no, I have to do it," I insist. "It goes to my pride."

So I do that. John had been making the movies using the complete-waste-of-money SGIs, and I couldn't stand it, so I wrote some software to build the movies on Linux. He and I have been genteelly competing over this, pretending that we're just cooperatively seeking the best solution, and I think I have now definitively won. My solution produces higher-quality movies with twice the frame rate and less than half the file size, so we're back to not needing the SGIs for anything at all. Linux rules.[2]

Shortly after I've finished building and uploading the movies, the data starts flowing. I go to the SMSA to see how thisol's drive went. We didn't really know how the new flight software was going to perform, so we're a little nervous.

It went pretty well, I guess: we covered 69m, a new single-sol Spirit record! Chris will be happy; this was really his (and John's) drive. The autonav was running at about 32m/hour, which is not as good as Mark was hoping for, but it beats the heck out of the 13m/hour we got with the old software. Autonav used to be five times slower than blind driving; now it's only half the speed of blind driving. Put another way, the rover now can find its own way around Mars at about half of the theoretical peak speed it could achieve if it didn't have to think at all, a really amazing accomplishment -- and this is using a CPU that's only one-hundredth as fast as the one in a current off-the-shelf PC.[3] (Mark promises to figure out why it's so slow, which makes the rest of us laugh.) Even better, the front HAZCAMs, and later the NAVCAMs, show a nice clear path in front of us, so we'll get to do it again nextersol.

I'm late for the downlink assessment meeting, so I just miss the drive-distance announcement. But I give them something else to applaud, introducing Ashitey as our new RP. Ashitey has worked with most of these scientists since the FIDO[4] field tests, so he's well-known and popular.

So it's time for Ashitey and me to plan nextersol's drive. Unfortunately, due to some kind of data management problem, we didn't get the PANCAMs. This means we can blind-drive only up to the edge of the NAVCAM range data, which limits us to about 20m. Then we'll have to switch to the slower autonav driving for the rest of the sol -- well, at least that's not the penalty it used to be. It's a real shame we didn't get the PANCAMs; in this terrain, we likely could have done a 40m blind drive, straight ahead. But we can't do that safely with the data we have. I almost do it anyway, but Ashitey talks me out of it. We probably won't set another record with this drive -- the best possible case is something like 78m, but I expect to get more like 50-70m.

We also have to do two back-to-back autonav segments, so that we can do mid-drive science at the right point. For complex reasons related to the handling of timeouts, back-to-back autonavs have been a problem for us before. Ashitey and I come up with an unconventional solution, making the same logic handle the error and success cases cleanly.

There's a strict limit of 22:00 for us to deliver, and we're only 5 minutes late, which I think is pretty good. Ashitey goes home, but I have a lot of email and documentation and stuff to do. (I end up staying until 01:00.)

The MTES PULs are usually here as late as the RPs, and today is no exception. One of them, Robin Fergason, asks why an old version of her sequence's name is still recorded in the RML file. I explain that this is the correct behavior; it's how RoSE ties the renamed sequence back to the name it had in the activity plan, part of a feature that links commands and sequences written in RSVP back to the high-level plans produced by SAP.

"Of course, we're not even using that feature in flight," I say. "But don't worry, it was a lot of work to implement ..." I add as she laughs. "Not that I'm bitter." (Andy commiserates. "I don't think you could find a single person on MER who's not bitter about something.")

I almost didn't notice that we're using the new version of RoSE -- they installed it already. Which is good; at least it didn't blow up the first time anyone clicked on it or something. A couple of the new features aren't working quite as well as I'd like, but one thing in particular is working beautifully. RoSE had been very slow in generating sequence reports, sometimes taking half an hour or even longer. (Late in the development cycle, I made it convert times in the report to LST, and for some reason the time conversion runs much slower on the flight LAN than on the development LAN.) We could never really afford that much time, but it's an even worse problem now that we're on an even tighter schedule, so it's one of the things I fixed in this release. Daniel Moyers says exactly what I was hoping someone would: "I thought maybe something was wrong -- I couldn't believe it was done so fast!" It now finishes in seconds.

Ah, that feels good.

---

Footnotes:

[1] Zipcode Mars was a really good idea from our outreach team: post pictures and bios of MER team members so the public can get a sense of the kind of real people who make a mission like this go. I was reading through other people's entries, trying to get a sense of what I should write, and I was just appalled. They were all, like, "Bill lives with his wife and four dogs in Temecula, California." Who cares?! So I wrote this. I never thought they'd publish it, but they did, without changing a word. Our outreach team rocks.

Readers of this blog will, however, perhaps find it surprising that (as I say in my Zipcode Mars entry) I hate writing about myself. :-)

[2] My distaste for the SGI boxes we were using should not be confused with my feelings about SGI as a company. They were very good to us, as they had been on Mars Pathfinder. I had just gotten annoyed by some technical issues involved in supporting our software on their systems, not to mention that the Linux boxes were way faster.

[3] The rovers use a 20MHz CPU whose design is a cousin of the PowerPC CPUs they used to use in Macs. That's right, 20MHz. It would have been mind-blowingly fast around, I guess, 1988.

For the computer hardware, we generally use old, slow parts, because (1) they're made with big fat transistors that are more resistant to radiation (on top of the radiation shielding they're given), and (2) they've been used before and are known quantities. There are places where you want to innovate and places where you don't; the rovers' CPUs are a single-point failure, not a good place to innovate.

[4] FIDO (Field Integrated Design and Operations) was a research rover on which the MER rovers were partly based. More details at JPL's site.