Opportunity Sol 368 (Spirit Sol 389)

Thanks to the frenzy of yesterday, the pressure is somewhat reduced today. Today's uplink was done yesterday, so today (Friday) we just have to do Saturday's and Sunday's uplinks. It's just as much work, but we can run late if we have to.

Our downlink must be poor. We've only gotten one MI so far, but it looks spectacular. Unfortunately, it doesn't quite cover the area the scientists wanted. RSVP showed we should expect to just see over the top of the trench, which is exactly what they asked for, but it seems the image we got is somewhat farther down the trench wall than that. It's not clear we've got enough room in the plan to reshoot them today, but we'll have to reshoot them before leaving because they're probably the highest-priority scientific target in the trench. Between that, and the MB team's deciding that they want additional integration time in the trench for better statistics, they decide to change the plan. We won't bump to the scuff on Monday, we'll continue our trench work.

This sucks for two reasons. First, it means we need to redo a large chunk of the plan, which in turn means not only that we wasted a whole bunch of time yesterday but also that we're going to have that much less time for sequencing today. Far more important to me, though, is that this means I won't get a chance for a long drive in this cycle of shifts. I'm on only until Tuesday, and then I'm off shift again for about a week. I was really pushing to get all of the trench work finished by Monday, but with the decision to spend an extra day at the trench, we'll finish Tuesday instead. So I'll have spent this entire shift cycle screwing around with the trench, and the RPs who come in after me will be doing the fun record-setting drives, while I spend that time slogging through some decidedly dull MSL-related work.

Worst of all, I have nobody to blame for it but myself. MB notwithstanding, I doubt we'd spend the extra time here if the MIs had covered the desired area. And guess who took the MIs.

Intellectually, I can see that I'm being churlish about this. (Oh, woe is me. I get paid to play with a Mars rover, but I'm not driving it very long distances right at the moment. My life is such a misery.) But knowing that doesn't seem to improve my attitude -- to the contrary, it's making it worse. I might need to take a couple of days off.

So might Matt Golombek. He's having a hard time wrangling the scientists, so the SOWG meeting is going slowly. He turns around to face the engineering team (us), which sits along the row behind him. "Damn scientists!" he blurts out -- only half-kidding, if I'm reading him right. "Welcome to the back row," replies fellow engineer Geoff Lake.

As expected, today's another long day. Jeff and I improve our process -- we develop the two sols in parallel, as we did yesterday, but we exchange sequences earlier in the day, which I think makes a lot of difference. Once again, the TULs and TAP/SIEs have to work through a variety of software problems, but at least we've figured out why this keeps happening.

It's happening because we're improving things. Sharon Laubach has been developing a bunch of scripts for automating the ground system. Mostly, she develops these in her home directory, and then at some point she informally delivers them to the team by putting them in a semipublic location. At the same time, she starts the process of delivering them to Configuration Management, who's responsible for installing them officially on all the systems. CM just officially installed her new stuff, so Sharon duly removed her semipublic copies.

The only problem is, CM installed her new stuff on the Suns only, not on the Linux systems. Most of our work gets done on the Linux systems. So a lot of stuff broke.

The team's collective opinion is that CM needs to take a few days off, too. And not come back.

[Next post: sol 392 (Opportunity sol 371), February 8.]


Vi-king said...

I am quite amazed you don't use proper revision control to manage those scripts...

Scott Maxwell said...

The scripts were subject to both revision control and (as described) configuration management. The problem was that CM screwed up the "promotion" of those scripts from our beta-testing area into our official delivery area.

Vi-king said...

Okay, thank you for that clarification.

Keep up the good work!