This is new: Ashitey's RP-1 thisol.
This is also new: there's no RP-1 scheduled for nextersol. But that's a scheduling snafu, one I fix by volunteering to do it myself. (Oh, twist my arm.)
I'll need to be a little late, but Arthur says that won't be a problem. "Tomorrow will just be a simple tool change," he reassures me -- little realizing, I think, that he's disappointing me instead. Hey, if I'm going to be RP-1 again for the first time in what seems like months, I want a damn challenge. But I'll take what I can get.
Thisol is the kind of complicated sol I'm lusting for. We're RATting a spot that we'll then investigate with the MB. But there's another issue: the sol-212 MI images we took appear to be out of focus, so we want to redo them thisol. Now, stay with me. The lowest -- that is, closest-to-rock -- MI images appeared to be most nearly in focus. And Ashitey's plan for thisol is to redo the stacks[1] using a technique that will start farther away from the rock. Which will make their focus worse, not better. Which is a complete waste of time, energy, and downlink data volume. I can't seem to communicate this concept to Ashitey to save my life, so it goes up like that.[2] Oy.
But Ashitey and I have worse problems. Thisol's IDD work requires that we move the IDD away from its current position a few times. But because sol 213's sequences haven't executed yet, we don't know exactly where the IDD contacted, so we have to pull some tricks to command the IDD back to its current position during thisol's business. The IDD automatically remembers a single location, so the only way to do this is to use a special command that tells the IDD to put a different tool on the last saved location. And that command doesn't seem to be working, at least not in the simulation. Neither Ashitey nor I can understand why not. It doesn't make sense: we're putting the IDD in the configuration it would have after the change-tool command would execute, then issuing the change-tool command, and the simulation says the command fails. We can't figure out why we would get an error at all, and the message itself isn't very useful.
This is where certain personality differences between me and Ashitey start to be a problem. We like each other a lot, but, well, we're very different. Most relevant, Ashitey's cool with being late, and I'm just not. Ashitey is the epitome of Type B, and I am Type A. No, make that Type A+. Type A+++. You get the picture.
We're not ready for the activity plan approval meeting. "Got an animation for me?" Saina asks. "Just a few minutes," Ashitey reassures her, but the minutes pass and we've made no progress. Saina and the scientists are clearly growing more and more concerned as Ashitey keeps putting them off, "just a few minutes" at a time. An hour passes this way, and I am starting to go insane. We're slipping later and later, and I'm not in control of the situation: Ashitey's sitting in front of the keyboard, not I, and he naturally wants to argue about every idea I have for fixing the situation (not that his -- or, for that matter, my -- ideas are working anyway).
I heroically summon every ounce of self-control I possess, and smile grandly at Ashitey. By itself, that act calms me down a lot.
But not for long. (Long enough to sign a small poster for Arthur C. Clarke, but not much longer.) Another hour goes by, and we're as stuck as we were to start with. At this point I decide to believe that my problem is that I'm not in front of the keyboard, so under the pretense of checking something, I log into the other RP workstation and start working out my ideas directly, rather than arguing over them with Ashitey one at a time. They're still not panning out, but at least I can explore them faster; and I'm driving, which makes me feel better for no good reason.
What we need is a fresh pair of eyes, and luckily we get one. John was working on Opportunity today, and when he moseys downstairs to say howdy I rope him into helping out. He and I look at it a while, and eventually we realize that we're helping the IDD too much. Remember that we're moving the IDD away and then back to where it started, then using the tool-change command to fix up its position more precisely. When we moved the IDD back in, we put it in approximately the configuration it would put itself in after the tool change, thinking that would simplify things for it, but the software can't handle that; it wants to compute its own path to the post-tool-change position, and gets upset if we do the work for it. When we make things "harder" by using the pre-change configuration instead (helped along by another trick with the amusing name of "the guarded move to nowhere"), it works like a charm.
We're three and a half hours late, I've probably destroyed my relationship with Ashitey, the new MIs are going to be in worse focus than the old ones, and hell if I know whether this hacked-up sequence is even going to work.
Did I say I like a challenge?
Can I just have a simple tool change?
Please?
Footnotes:
[1] When you look at something under a microscope on Earth, you look through the eyepiece and twiddle the focus knob until the subject is focused. We can't do that on the rovers because light-time delays would make the knob-twiddling take forever. Instead, our sequence takes a whole "stack" of images -- some above, one at, and some below where we think the right focus distance is. We're pretty good at nailing the best-focus position, but when we miss it, the images taken above and below that position are our record of what happened when we twiddled the focus knob; one of the images is almost always well-focused.
[2] A serious mistake. Yes, we were busy and stressed and running late. There was still no excuse for uplinking a sequence that I really didn't think would correctly implement the science observation. Since Ashitey and I clearly weren't communicating well here, a smarter move would have been to politely involve else in the conversation, someone who might have been better at explaining things to Ashitey (or to me, if I actually was in the wrong).
No comments:
Post a Comment