Yup, just CCD bloom I think.

Regarding the sun images that have CCD blooming.

The purpose of the images is to measure atmosphere opacity, and to precisely locate the sun in the sky <relative to rover pancam mast camera coordinate system angles>

The exposures are commanded, not "auto-exposed". If they calculate wrong, or if the atmosphere is clearer than expected, the camera saturates pixels in the bright areas and the electrical charge in the saturated areas overflow into the non-saturated adjacent pixels.

I believe that this particular CCD <correct me if I've got this mixed with another planetary mission camera> can actually still give pretty good atmosphere opacity data from the overexposed images since the electrical charge is pretty much all there, just spread out.

I've a little question about software while we wait...

How in-synch do they keep Oppy and Spirit's software? I know there have been pauses for code updates in both rovers, but in general, do the tweaks made for Spirit's driving challenges remain separate from Oppy's?

I don't know what their architecture is. I'd assume that the code base for both rovers is the same, but the driving parameters/decision variables for each are different - so the slip tweaks done for Spirit are made in a "data file", which is different for Oppy. But the code that makes the decision for shutting off on a slip of X% would be the same for both. I did a quick Google and didn't find anything specific on the guts of the software.

Hopefully they don't have to manage two (slightly) different code bases for each rover. Even with the cool code management tools available now, that kind of environment can let unexpected bugs slip in.

It is my understanding that the flight software on both rovers are identical. The differences are going to be in settings and instructions.

Such things as "disable steering on right, front wheel" is a setting. Both rovers have the setting. On one it is on and the other it is off. The types of automated drives and manuvers that are allowed would be instructions. They have extended the types and cababilities of drives through software updates. There have only been two software updates that I am aware of. They are lengthy to upload (two or three days) and a tad bit risky. So they don't do it very often.

The operating system for the rovers is VxWorks. The flight software is custom written for the rovers. The "buy-off" for a software update is not going to be trivial. The chances of a bug slipping through are small though not negligable. The brain freeze early in the spirit mission was caused by a bug in VxWorks. It was not detected until spirit was near death. The amazing thing is that the software was designed well enough that they were able to recover the vehical and fix the problem. Having some experience with remotely maintaining and debugging machine control problems, I can say that such a recovery is a tribute to the software design. Truly well done.

ed

I think we might be over thinking this. It could be simply that the riover got high centered and the new more aggressive software (for longer drives) caused it to dig itsself in. Can the wheels tell if there is slip if all 6 are slipping the same amount? Dosen't it take differences in travel to account for slip? Or maybe the rover dosen't account for slip right before it makes a turn. Was the rover making a turn when it got stuck? If it had not tried to make the turn would it be stuck right now?

scott

I have a similar question.

When djellison explained current wheel directions, he wrote:
"The wheels will be pointing in funny directions because at the end of a drive they turn the rover in place to put it in the best position for the UHF passes that afternoon and the following morning."

Does rover make turn in place at the end of drive automatically, even when it encounters an obstacle? Oppy went a half of planned day distance and sensed unexpected resistance. What instruction does she have for this issue? Is it "make turn in place for good communication"?

On the contrary, if they turn a rover by a command: did they send this command because they haven't got information about the problem yet, or did they decide to take close look at the problem after the turn?

Id love to see what's going on at JPL with the test rover. They must be building lots of sand dunes Hopefully they'll post some pics.

http://www.pasadenastarnews.com/Stories/0,...2848411,00.html

He said the earliest Opportunity would be instructed to try a maneuver that was successful in the test-bed would be Thursday for Friday

Does that mean they have tested a maneuver in the testbed that got the rover out of a dune?

Um....I think so. If they did not succeed in the testbed, this statement would be premature I guess.

Thanks for the explanations, Ed. They take much of the "black box mystique" out of the Rover software.

I wonder if one of the tweaks made to Oppy's obstacle avoidance algorithms for travel in the dunes could have made it "ignore" the dune it was on when it tried to make an end-of-drive turn in place. I imagine that the obstacle avoidance algorithm reads the hazcam/navcam images and detects shapes to avoid. A sea of dunes would present a sea of potential obstacles to avoid and the likely put less weight to avoid the dune-shapes.

She'll get out and on the road again...

--Bill

Yes, the fact that the rover was able to first figure out that its constant rebooting wasn't doing anything, and then know to start sending diagnostic info - essentially asking for help - shows some really good design. Except for that bug that let it screw up in the first place.

I cite from the JPL MER site: "We planned a drive of about 90 meters (295 feet). After driving about 40 meters (131 feet), Opportunity dug into soft dune material"

Ergo it can't be a regular end-of-drive turn, unless the software will try doing one even when the drive ends prematurely, if so I think this is more of a bug than a feature.

tty

From the above-referenced article:

"The rover stopped driving when its remote sensing capabilities noticed it had not been able to make sufficient progress on a planned turn while it was driving backward."

That would seem to suggest that it still attempted a turn to help align the antenna after it had prematurely terminated the drive.

I took the sentence less optimistically to mean that they didn't necessarily have an approach that worked (it does note that they've been working on getting the consistency of their surface material right). I thought it meant only that if they came up with a maneuver that worked in the test bed, Thursday or Friday would be the earliest that they could send the commands. On the other hand, I assume that they wouldn't rush off to try the first thing that works, either, so this may just mean that they won't be sufficiently satisfied with the option until later this week. Guess we'll find out when we're all of a sudden peering back at those skid marks.

I also thought Oppy had tried to do the normal turn at the end of a drive, irrespective of a full drive or prematurely cut short drive. You can bet your bottom dollar that they have a manouvere that will get Oppy out of the dune