[X] My Assistant

[Toma B]

So it's hardware problem this time...

OPPORTUNITY UPDATE: Stalled Motor, Stowed Arm - sol 649-660, Dec 01, 2005:
"...This time, a shoulder-joint motor that is needed for unstowing the arm stalled, and the arm stayed stowed. In subsequent sols, engineers worked to narrow the range of possibilities for the cause of the stall. Among the remaining possibilities is that, after working more than seven times longer than originally planned, the lubrication is degrading...."

I continue to be impressed (depressed?) by how unnecessarily complex and cryptic the jpl MER site is.  I tried several times to find this update starting with http://marsrovers.jpl.nasa.gov/home/index.html, and failed each time.

I had that same problem yesterday...finaly I find updates (The Mission>Rover Update) but I had to go to sitemap to do it....
It's that "*"Spirit and Opportunity One Martian Year Anniversary"*" part of MER home page that's just a little bit on the wrong place...earlier there was direct link to the updates...
Sorry about my english...

[CosmicRocker]

Thank you, Toma B. I finally found the lost updates with your help. I suspected it was a problem caused by the "One Martian Year Anniversary."

http://marsrovers.jpl.nasa.gov/mission/status.html

I noticed two more "unexpected sequences," recently. I wonder what that means. I think they should move the rover to jostle the arm, and then try again.

[Tesheiner]

Imho, those "unexpected sequences" mean just that an actually executed sequence ID could not be found on a file containing the list of all planned sequences.

6. What unexpected sequences ran?  (that is, sequences we did not enter in the SSF
list file /home/mersci/pan/B/ops/Sol_all_seq_list.txt)

Sol  Seq.Ver
--- ---------
659 p1157.01
659 p2900.03

I remember seeing that same thing for a navcam post-drive panorama (<...searching on my notes...>, here! Oppy, sol 630), and my conclusion is that the sequence was actually planned but missed on the "description file".

Edited: More troubleshooting sequences planned for sol 600...
---
660 p1157.02 2 2 0 0 0 4 idd_hazcam_LOCO_512x1024_SF_pri27
660 p1157.02 2 2 0 0 0 4 idd_hazcam_LOCO_512x1024_SF_pri27
660 p1157.02 2 2 0 0 0 4 idd_hazcam_LOCO_512x1024_SF_pri27
...
660 p2900.03 1 0 0 1 1 3 microscopic_imager_health_check_image
660 p2900.03 1 0 0 1 1 3 microscopic_imager_health_check_image
660 p2900.03 1 0 0 1 1 3 microscopic_imager_health_check_image

This post has been edited by Tesheiner: Dec 2 2005, 09:57 AM

[Bill Harris]

I suspected that the IDD problem was a balky motor. Heck, at my age, my shoulder joint actuator is getting creaky, so I can sympathize. They'll work up a solution, though: after all, they've got a three-legged dog climbing mountains over at Gusev...

--Bill

[Tesheiner]

Sol 660 MI's are available.
No movement again...

Sol 659: http://nasa.exploratorium.edu/mars/opportu...KCP2900M1M1.JPG
Sol 660: http://nasa.exploratorium.edu/mars/opportu...KCP2900M1M1.JPG

[Vladimorka]

There is some slight movement, but enough just to confirm the inability of the motor to move :-(

[Tesheiner]

An animation with the five MI pics taken until now.

(98k)

[odave]

I'm not up on lubricants - is the suspected degradation a function of use or age or both? Has Oppy done more IDD work than Spirt, thus putting more "wear" on the lubricant?

[djellison]

I imagine it's much like the Spirit FR wheel issue - just one of those things that happens after some use, but isnt predictable. Unfortunately, there's no 'backwards' to running a joint, so perhaps some higher watermarks for current limits on the motor will help the problem, as perhaps will heating the hell out of it to redistribute grease hopefully (didnt work with Spirit's wheel) , but as with all the actuators and motors on the rovers, they're getting old.

Doug

[tfisher]

Playing "what if" with the worst case scenario: if the instrument depolyment arm is permanently stuck, what does that mean for Oppy? First, the mission would continue to operate, for at least as long as Spirit stays largely functional, or as long as the rovers stay mobile, whichever lasts longer. Squires said as much in his interview. For workable instruments, however, they would be down to cameras and Mini-TES.

I wonder what it would mean for power consumption. Do they have a way of killing power to the full arm, and would that be a significant savings when it isn't in use anyway? Suddenly if the Mini-TES is the only instrument besides optical cameras, preserving it from the threat of deep sleep becomes more important, I would think.

I hope our amazingly durable martian friend finds a way to bounce back from this problem, like it has from all others so far!

[odave]

I guess if we do lose the IDD, it's better to lose it stowed than deployed.

[odave]

Hmmm...if they can't free the arm with higher motor current limits, could they spin the RAT brushes while stowed to give the IDD some jiggling? Sounds risky, but it might help in a last-resort situation...

[Redstone]

I guess if we do lose the IDD, it's better to lose it stowed than deployed. 

Yes, which is another reason why the engineers will be extremely cautious with this problem. You wouldn't want to deploy the arm without knowing whether you will be able to stow it again.

[tasp]

Is it confirmed the fault is not with the protection circuit?

If the rover can be programmed to disregard the fault indication, could it verify the fault is in fact in the deployment motor/gear train?

[odave]

Doug's suggestion of opening up the current limits is probably safer. If there really is a mechanical problem, you wouldn't want keep running the motor regardless, as it might burn up. It's a tough problem to debug at a considerable distance...