In fact, Chris has the drive pretty well complete by the time I arrive. I sit down with him and watch him work, occasionally pitching in suggestions but mainly letting him finish what he started. We successfully ended up on Missoula Crater's rim on the last drive, and though the rim ended up being broader than we thought (so that we can't see as much of the crater's inside as we thought), the scientists are happy with what they got and we're moving on. As usual, we present his version of the drive at the activity plan approval meeting, then Chris leaves and I take over.
There are some features of this drive I'm not completely comfortable with, but I decide I don't have time to replan it. Instead I spend my time going through what's there, checking out all the little details, making sure the fault-response logic works. While I'm trying to concentrate on this, I get interrupted to deal with a reported RoSE problem. Part of the routine maintenance of the spacecraft is setting up comm windows, telling the spacecraft when it should try to communicate with Earth and through which path (via one of the orbiters or direct to Earth). As with all spacecraft commanding, they use RoSE for this, and one of the people responsible, Bill Nelson, seems to be having a problem with it; Theresa Kowalski has brought him by to talk to me about it. I ask a couple of questions. He's not doing anything obviously wrong. But I don't have time to deal with it right now, so I explain that I'm on the clock, in the middle of planning thisol's sequences, and can this wait until later? Sure, they say, and then they keep pestering me anyway.
Something they say leads me to an idea. Bill runs RoSE by remotely logging into one particular system, but it's a strange one to be using -- it's one of the systems that's still configured for launch/cruise ops, not for surface. "Why don't you try it on one of the surface ops machines?" I ask, and that solves the problem. They've been using the wrong machine all along, and noticed now only because someone apparently deleted a file on the old systems. I hadn't thought about it before, since I don't use those machines, but it seems like a mistake to leave them up -- it's asking for trouble like this. Unless there's some reason for keeping them that I don't know about, they should reconfigure them for surface ops or take them off the net.
At least I can get back to work.
Driving away from here is a little tricky because, being on a crater rim, we have to deal with the ejecta blanket -- that is, big rocks. We also have to avoid a smaller secondary impact crater to the east; there's some concern from the project management -- though none from us -- that if we got into that smaller crater, we wouldn't be able to get back out.
An unusual feature of this drive is that we're using autonav to send the rover into a region we can't see, and this turns out to be the big issue of the day. Previously, even when we've used autonav, we've been able to see the region the rover was entering. We couldn't see it well enough to plan a blind drive through the terrain, but we could at least see the general lay of the land. In this case, we can't even see that; the terrain is completely blocked from our current viewpoint as well as from previous days' images.
I'm usually more paranoid about these things than anyone, and I'm not the least bit concerned about this. I've seen the performance of autonav over this mission, and I strongly believe that if there's dangerous terrain, the rover will correctly avoid it. But the mission managers manage to work themselves into a tizzy about it, so I have to go stare at an orbital map of the terrain with them as they argue about it. Occasionally I make reassuring noises, but mainly I quietly watch to see how it's going to go before I jump in. As it happens, they basically talk themselves into believing that the rover will be safe. If uke throws himself, you don't have to throw him.[1] I get back to work.
So far we've driven 913m, so our next target is to hit 1km. We aren't likely to get that far tomorrow -- though we might; the best case for the drive is that we'd cover 100m tomorrow, which would set a new Spirit record and also take us over the 1km line. But we don't really expect that. If autonav has to deal with hazards, as we expect it will, it runs more slowly. 80m is more likely, and would still be a new record.
During the CAM, it becomes clear that the mission managers need a little reassurance from Mark Maimone, so I volunteer to run upstairs to fetch him. On the way back down, Mark raises the subject of our turn-to-rock command. The rover has the ability to scan the terrain immediately around it for something that looks like a rock, then turn to face the nearest rock it can see. The idea was that we'd just drive it to wherever -- maybe over the horizon -- and have it autonomously face any nearby rock; the next day, we'd have the option of IDDing that rock without spending an extra sol on an approach drive. We've never done this on the surface, because we've always either had a particular rock we were supposed to face, or we've had a particular heading we were supposed to turn to in order to maximize comm. But Mark would like to try it out. His idea is to drive to a chosen spot, tell the rover to turn to a rock, take an image to see what happened, and then turn wherever we really wanted to go and drive on. This way we'd achieve the real driving objectives while still exercising the rock-finding capability. He already knows it's too late to work this into thisol's drive, but I tell him I'm up for it. "Don't let anyone else do it before me, though," I add.
The nervousness about the drive seems to have mostly abated, but there's a fresh concern about the next sol's planning. Tomorrow is a "Mars weekend," one of the days where the planning cycle flops over. As a consequence, we have nothing to do that day, but the uplink team needs to be in extra early -- starting at 6AM -- the next day. (It's a weird feature of the Earth-time schedule: occasionally we go from being way, way early for one sol to being time-crunched for the next, with an Earth day in between.) And they have to be uplinking the commands at 3PM. The reason they're nervous about this is not just the suddenly tight schedule, but also that John's RP-1 solo for the first time that day, and Ashitey is RP-2 solo for the first time as well. So Arthur asks me to come in, just in case.
Sigh. Well, I was going to come in later that day anyway, because it's Lug Your Spoiled Brats To Work Day and I promised to show Tracy Clark's and Trish Santos's sons around the MER area. So I'll come in a little earlier, verify that everything is working perfectly fine without me, and the kids will give me a good excuse to blow out later.
Nagin Cox[2] is moving on. Apparently -- this is the first I've heard of it -- she's been very unhappy about her role on the project. She thought she'd get to do a lot more technical stuff, but it's all been budgets and schedules. (And there's a lot of this going around, she tells me: a lot of the cruise people didn't feel welcome any more when surface ops started.) So she's been looking for other opportunities for a while. One of them, being part of the President's team looking into the Lunar/Martian manned missions, was looking very likely for a while, then fell through for reasons she doesn't elaborate on. So now she's going to work for this upcoming telescope mission, looking for planets around other stars.
Well, it was nice working with her again.
Courtesy NASA/JPL-Caltech. In the push for the Columbia Hills: just making tracks, grinding our way a little closer every sol.
Footnotes:
[1] Aikido lingo: "uke" is your attacker.
[2] I worked with Nagin in my very first job at JPL. She is one of the smartest, most competent people I've ever met. If you were mowing lawns with her, you'd find it a rewarding experience.
No comments:
Post a Comment