Daniel Limonadi's trying to scare up a scientist to give the science lecture Friday, but nobody's around; they're all at their home institutions. ("You should see the end-of-sol science discussion upstairs right now," one of the few remaining scientists commiserates. "It's the saddest thing I ever saw.") So it falls to Matt Golombek -- thisol's SOWG chair -- to be a good sport and volunteer.
"What do I have to do, exactly?" Matt asks.
"Anything," says Daniel.
Matt thinks about it. "Okay."
Thisol's drive is short, about 1.5m, but tricky. We want to get a particular rock (Coba) in the IDD workspace, but the rock's kind of narrow -- at least along the axis from which we're approaching it. We also want to be turned to a heading of 90 degrees for comm, and we want to ensure that we avoid a particular direction (160 degrees) that's extremely bad for comm, in case the drive faults out in the middle.
Luckily for us -- if you want to think of it that way -- it looks like we're going to get some extra time to work on it. This is because of a problem in the Planner, the software that helps automate the construction of a valid activity plan. The problem turns out to be due to a hard-coded limit in the Planner. Essentially, the developers chose a hard-coded time -- 150,000,000 seconds since the "epoch," 2000 Jan 01 -- to represent "infinity," the time beyond which nobody would ever conceivably want to plan. The software won't let you make plans that extend past the point where the clock runs out.
Guess when the clock runs out.
If you guessed "during today's plan," give yourself five points. You are correct.
It transpires, during the resulting conference call, that the Planner's developers knew about the limitation but hadn't bothered to figure out exactly what it converted to in terms of the real-world calendar. ("Sometime in October" was apparently as far as they went.) They also hadn't bothered to tell the project.
The good news is that they know what the fix is, and will start working on fixing and delivering it now. (Start working on it now? It makes me want to scream. They knew about this problem and couldn't alert the project, fix it, and redeliver the month before it failed? I understand that the rovers have lasted longer than anyone expected them to at the start of the project, but the Planner's developers should have handled this situation better. End soapbox.) And they have a workaround: you can lie to the Planner about what sol it's planning for, although this makes coordination with other uplink tools difficult, slowing the process.
The other good news is that, as Ashitey points out, we rover planners are, for once, not the ones holding up the uplink process. We even have time to sample the free root beer floats given away by the company that designed JPL's Rose Bowl float this year. It's a nice reminder of the long-gone days of free ice cream.
Ashitey's planned a very careful drive that avoids nearby rocks that might cause us to slip, and that also avoids driving over Coba. As I'm hacking on his sequence, though, I realize that there's a much simpler, more direct, faster, and safer drive -- but it'll cause us to drive one of the wheels over Coba, which the scientists often don't want us to do. In fact, if the drive goes exactly as planned, Spirit would drive her left front wheel onto Coba, turn the wheel, and then drive off as she turned in place, leaving Coba directly in front of her. This would be likely to scuff the rock, at least a bit.
I think about it and decide to ask Matt if we can drive over Coba. He asks the rest of the team and comes back with, "Sure, scuff it up all you want. Fresh surface would be great. Hell, if you can break it, that'd be even better. Stomp on it."
And to think I almost didn't ask. Naturally, we change the drive.
As I'm working out the details, Daniel Limonadi (our TDL thisol) starts waffling on the comm direction -- turns out that 70 degrees might be better than 90. We've just gotten the drive sequence worked out, and this would change it again. Ashitey somehow manages to talk him out of it, and the drive remains intact. Good on ya, Ashitey!
Daniel also proves a tough critic at the walkthrough, asking several difficult questions and in the process uncovering a couple of minor, but real, problems. It makes me realize that while this sort of probing questioning used to be a daily (solly?) occurrence at our reviews, it's now virtually absent. I don't know why the change occurred -- everyone just assumes everyone else knows what they're doing, I guess. Maybe that'll be how we lose the rover.
In any case, the problems Daniel points out are readily fixed, and in the end I go home feeling more confident in the sequence than I would have otherwise. Good on ya, Daniel.