The responsibility of his next actions was not lost on Hawley. I remember, throughout the mission, but in particular on deploy day, thinking about all of the people and all the years of effort that had led up to this moment. To some extent, what I was doing was just representing the community of scientists and engineers who had taken [Lyman] Spitzers idea for an optical telescope on-orbit and made it a reality. So I really did not want to mess this up. I did feel, particularly as a professional astronomer, the weight of the astronomical community. They had done all their jobs, and its up to me to finish it off. I remember thinking about that quite a lot.
Looking out the overhead aft flight deck windows [left to right] Bruce McCandless, Steve Hawley and Loren Shriver.
Unwanted motions and collision avoidance
Hawley, an astronaut for 12 years, was on his third flight into space, fully proficient and experienced in operating the Remote Manipulator System (RMS). Although he had operated the arm in simulators and had gained insights from colleagues who had already operated it in space, he had yet to fly the arm in space. But the task was daunting. Hubble was by far the largest mass that the arm had been required to hoist out of the payload bay to date, and the tolerances were tight, so the trick was to recognize the momentum of movement and be able to react quickly enough to do something about it.
Hawley explained this as the worse failure you can have, when you are trying to unberth Hubble and it is very near the orbiter structure [where] tolerances are very small. With a run-away motor you can have your first hypothetical failure. As there was no collision avoidance software available, the collision avoidance is the RMS operator and you can make [all kinds] of estimates as to how long it would take the operator to recognize a run-away and take [the appropriate corrective] action. Obviously, when the telescope is that low in the bay, and that happens, you have a concern that it is going to take longer to recognize and stop it than the [time and distance] you have. In order to protect for that failure, what they did was, through the software, to limit the amount of current that you can send to the motors and that way, if a motor failed on for some reason it would drive slowly enough that the operator, in principle at least, would be able to recognize that and take action before there was an impact.
That is what was planned for STS-31. Hawley could control the rate of motion, or drive, through the software. As he unberthed Hubble, the software load would be changed so that when he had lifted the payload high enough, greater current was sent to the motors slowing the rate down. But what happened on-orbit was that these loads became lost in the general noise of the system, to the extent that the signal noise that Hawley was sending from the controller to the arm was not that much bigger than the noise in the system. This combined noise then acted like a command, as far as the motors were concerned, confusing the system. Normally the ground simulators did not model this effect, and the crew didnt notice it until they were actually deploying Hubble. As Hawley explained, The consensus was, when I would command pure up motion, it wouldnt move purely up, it would wallow around. I remember that it was really confusing when it was doing that, because it wasnt the way it behaved in the sims and made the deployment task [about] 50 percent longer, because we kept having it stop and take out the commands that we werent requesting and the different axis [that the arm was heading in].
Once we came back after STS-31, Hawley continued, we went over to the Shuttle Engineering Simulator and we modeled the noise, and my recollection is that we very accurately reproduced what we saw in deployment. Ultimately, what we did was develop a control mode for the arm called POHS [pronounced POSH] for Position Orientation Hold Submode [in which] you could select that mode, then command in the minus Z orbiter axis, purely straight up out of the bay, with the software only allowing motion in that one axis. It would cancel out the noise in the system that we had on STS-31 that was trying to rotate the telescope in pitch and yaw, and send opposite commands. That made it quite a bit easier.
Hubble on the arm
The training for the mission had rehearsed a number of contingency and backup modes, including two worse-case scenarios that involved deploying the telescope in the backup mode and the total loss of the RMS. A failure of the orbiters Main Bus A or Manipulator Controller Interface Unit (MCIU) could disable all the modes reliant on software. It had also been found that in the event of a failure of the systems management general purpose computer this could be replaced by a guidance navigation and control computer in order to support the operation of the arm. Should it be required, the crew had trained to remove and replace a MCIU with a spare. The individual joint motors could be driven in the backup mode, but without computer support or information displays. Reflecting on these contingency procedures, Hawley wrote in 2014 that had such a failure occurred, it would have been preferable to have delayed the deployment of Hubble until the MCIU backup unit had been installed.
Although the Earth return mode for servicing needs had been abandoned in 1985 owing to the cost and the risk to the integrity of the telescope, the option for a contingency return was discussed in the event that Discovery was unable to attain the minimum deployment altitude. The overriding concerns which fuelled the decision to pursue orbital servicing remained, and as a result the team developed a means of deploying the telescope even if the RMS was not functional. This concept, which became known as backaway deploy, would have involved turning the orbiter to the tail-to-Sun attitude to allow the telescopes Sun sensors to lock onto the Sun after its release. The disconnection of the umbilical would then have been followed by the opening of the four payload retention latch assemblies. With Hubble essentially free of the orbiter, Discovery would then have flown out from under the telescope. During flight techniques meetings in 1989, the question of providing the procedures in the STS-31 flight plan were discussed several times. There were many issues to be resolved with this proposal, and of course if anything had gone wrong in the post-deployment period, such as the failure of solar array or high gain antenna deployment, there would have been very little the crew could have done without an operational RMS. In 2014 Hawley recalled that some standalone training was done in the shuttle mission simulator for this mode, but they did not progress to the integrated simulation level. The backaway deployment procedures were available on the checklists for the mission, but fortunately neither this nor any other contingency plans were needed in deploying the telescope.