Yesterday we planned sols 402 and 403 (which executes today); today we plan the weekend sols, 404 and 405. Khaled could use the experience, so I have him do the bulk of the RP-1 work today.
Which is easy, since he already did most of it yesterday. I spend most of the day struggling with a tricky m4 problem. Don't get me started. But he calls me over to help out with something weird: the INCONs file ("INCONs" is short for "initial conditions" -- it specifies the rover's last known position, which is how it will start the day) shows the rover with the APXS in the wrong position. Instead of being directly on the target, the instrument is laterally offset by about 3.4cm.
On comparing the numbers from that file to the numbers we expected, we find it's offset by the right amount to be an MI poker offset. This term takes some explanation. When we're trying to get good MI images of a rock surface, often we first touch it with the MI's poker, a small, thin, steel rod affixed near the MI's lens. When it senses contact, we back off a known amount, and we can trust that the resulting images will be in good focus.
But the poker doesn't project directly out of the lens, obviously, which leads to a minor problem: when the rock surface is uneven, the poker might contact a position higher or lower than the area we're trying to image. This could lead to out-of-focus images or, in the worst case, we could smash the MI lens while the poker felt nothing.
So in these cases, we do the poker touch differently. First, we slide the instrument over by a known lateral offset, putting the poker where the lens was. Then we touch and retract. Then we slide back, putting the lens directly over the position the poker touched.
And the offset we're seeing in the APXS placement has just the right magnitude to have been introduced by this procedure -- if, for instance, we slid over but didn't slide back. Nothing else we normally do moves the IDD in this exact way, so it has to be some kind of poker-slide problem. And the scientists aren't going to like it: it would mean that some if not all of our instrument readings have been at the wrong location. Basically, we might have wasted one or more entire sols, and we'll have to do them over.
But there's still a puzzle. While the offset has exactly the right magnitude to have been caused by this error, it's not in the direction we would have used in this case. And when Khaled and I look carefully through all the sequences that have executed since the last known-good placement, we can't find the problem in any of them. So we look again, and we still can't find it.
But it has to be that. And I'm quite prepared to believe it is, since we very nearly made exactly this mistake in the last IDD sequence I built; I caught it in time (because I noticed the simulation looked wrong), but we know the problem could bite us.
So it has to be an MI poker-slide problem. But it isn't. What the hell is going on?
Grasping at straws, we reload the INCONs file -- and suddenly the IDD snaps into the right position. Turns out there was an error in the original file, and the Mobility/IDD team corrected it, probably right after we loaded the erroneous version. Everything's fine. We've just wasted half an hour chasing a ghost.
Well, I'll say this: it sure as hell could have been worse.
[Next post: sol 428 (Opportunity sol 407), March 17.]
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment