HST Robotic Servicing Assessment
In January 2004, NASA Administrator Sean O’Keefe made the decision not to continue planning to use the space shuttle for servicing mission 4 (SM-4) to extend the life of the Hubble Space Telescope (HST). In early March, O’Keefe and the associate administrator for space sciences directed the Goddard Space Flight Center (GSFC) HST project to investigate the feasibility of extending the life of HST by servicing it robotically. NASA developed a set of Level-1 requirements for this purpose, shown in Box 5.1. These requirements have guided the agency in its evaluation of options for robotically extending the life of HST.
The HST project team, which includes the Space Telescope Science Institute, concluded that in order to extend the life of HST, as well as continue its high level of scientific return, on-orbit robotic servicing was needed in order to install a subset of the components originally planned for the space shuttle-based SM-4. Specifically it was considered necessary to install new spacecraft batteries, gyroscopes, and two new instruments, the Wide-field Camera 3 (WFC3) and the Cosmic Origins Spectrograph (COS).
The HST project solicited input from industry on how to perform robotic servicing as well as provide the capability to safely de-orbit the telescope. Based on the responses to this request for information (RFI), the project selected and evaluated key elements of the robotic technology required to change out the batteries and gyroscopes and to install the new instruments. The HST project also developed a mission operations concept, defined the system architecture, and allocated top-level requirements to the ground system and four major flight elements: the de-orbit module (DM), the ejection module (EM), the grapple arm (GA), and the dexterous robot (DR). The project then initiated sole source actions for the GA and DR and a competitive procurement for the DM and EM.
The baseline HST robotic servicing mission program as presented to the committee by the HST project has a development schedule of approximately 39 months. The spacecraft and instrument hardware that the project has baselined to be installed by robotic servicing are essentially those items that were developed for SM-4. The baseline HST robotic servicing mission is to launch the DM and EM as
a package on an expendable launch vehicle, rendezvous with HST, and perform autonomous proximity and docking operations to mate the two modules to HST. The GA and DR will be contained in the EM, as will the replacement spacecraft hardware with the exception of the spacecraft batteries. The DM will contain the de-orbit motor and the replacement set of spacecraft batteries. Once the robotic servicing operations have been completed, the EM containing the removed spacecraft and instrument hardware will separate from HST and de-orbit. At the time of this writing, although the HST project has performed the high-level up-front systems engineering to establish the baseline architecture, the detailed systems engineering and analysis to understand and define how these elements and the ground system will all operate together as a system remain to be accomplished.
The committee assessed both the program and the technical plans as presented by the project as well as the project’s assessment of the readiness of the technology needed to robotically extend the life of HST. The committee’s assessment is provided below.
ASSESSMENT OF THE TECHNICAL APPROACH
This section provides an assessment of both the mission-level risks and the technology risks associated with robotic servicing of HST.
Mission Description and Risks
The robotic servicing mission has a number of phases that involve relatively independent technical challenges and relatively independent risks, an assessment of which is provided below. It should be noted that risks are discussed in several different parts of this report. In Chapter 7 the different types of risks considered are defined and include health and safety risk, programmatic risk, and mission risk. Of course, technology risks are embedded in the programmatic risks. Mission risks are discussed below and qualitatively assessed in Chapter 7. Health and safety risks are discussed in Chapter 6, and programmatic risks are discussed in several places in the report, including Chapter 7. It is important to realize that the discussions of risk are abbreviated and qualitative and do not have the benefit of the full-scope risk assessment that was recently under development by NASA.
As summarized above, the DM will be a competitive procurement; the GA, essentially the shuttle remote manipulator system (RMS), and the DR, based on the existing but not yet flown International Space Station (ISS) special-purpose dexterous manipulator system (SPDM), will be procured from a sole source, MD Robotics of Canada. The EM will be built in-house at GSFC. The Hubble Rescue Vehicle (HRV) will thus consist of four major subsystems that will be developed by three separate organizations—GSFC, Lockheed-Martin (recently selected), and MD Robotics. GSFC also will perform the systems-level integration and testing in-house and will develop the ground control system based on the RMS and SPDM control station designs, modified to interface with HST hardware.
Risks—There is a major risk in the integration of these different elements into a single payload to be operated by the overall system software, as well as for physical integration of the four elements in the payload fairing and their deployment from the launch vehicle. A very high level of system integration is required because the initial sequence of events, from the launch through the deployment and subsequent stabilization of the spacecraft, is done automatically. Sufficient time and resources will have to be allocated to the program development schedule to integrate and test this payload successfully, especially because it is so difficult to simulate these complex operations on the ground.
There is always the very real risk of a launch vehicle failure, especially in the case of a relatively new launch system such as the Atlas V or the Delta IV. Historical data on U.S. spaceflights suggests that the probability of failure should be estimated at around 5 percent. Regardless of the launch vehicle, if the failure occurs with the HST payload on board, the entire servicing mission is lost and cannot be attempted again. If the launch vehicle fails (or a serious anomaly occurs) on an earlier mission, there will be a delay of 6 months to 1 year in order to perform the failure analysis and implement the corrective measures. Given the Hubble servicing schedule constraints (see Chapter 4), this could have a major impact on the probability of success of the servicing mission.
The launch vehicle’s ascent performance must be near nominal and the spacecraft must separate cleanly within the allowable tip-off limits. After separation from the launch vehicle, the HRV must rely on its star trackers and the onboard propulsion system to cancel the spacecraft rotation, deploy the solar arrays toward the sun, and lock the high-gain communications antenna on the Tracking and Data Relay Satellite.
Risks—Although ascent activities present a low and acceptable level of risk, the inability to reach the desired orbit or correctly deploy a functional spacecraft at the desired altitude and orientation will result in the failure of the mission.
The rendezvous process consists of a sequence of precisely timed thrusting maneuvers that bring the two spacecraft (the HRV and the HST) close together. This requires precise tracking of the relative states of the respective vehicles. Then, coordination and exact timing of the burns of the HRV must be accomplished to ensure that the vehicles’ orbital planes are appropriately aligned and that the closure rate and angles are precisely controlled. As the distance between the two spacecraft diminishes, the
onboard instruments of the HRV (usually star trackers and/or optical cameras) are required to provide precise angular measurements to improve on ground tracking of the target.
Risk—Although the technology is well developed and understood, the short development time presents a risk to being able to fully perform the verification and testing required to validate the mission-critical systems integration and operations that are unique to the HRV. In some respects, there is no 100 percent effective way to test and verify all these systems operations short of on-orbit testing of the planned HST operational modes, which is not planned. The hardware and software of the guidance, navigation, and control (GN&C) systems must integrate across the many subsystems of the spacecraft, including those for propulsion, sensing, avionics, grapple, communication, thermal regulation, and power. This requires a very-high-fidelity ground simulator to adequately validate all the procedures that may have to be used. Any significant problem that precludes a successful rendezvous with HST will result in failure of the mission.
Proximity operations begin when the chasing spacecraft comes into close proximity to the target, acquires the target with a ranging device (radar, camera, or lidar), and settles in on a trajectory to fly in close formation with the target. Once the full relative position and velocity estimation has converged and is producing reliable results, the HRV will have to initiate controlled burns to match rates with HST and then move down the capture axis to close in on HST.
Risks—Because of the 2-second communications delay for man-in-the-loop ground control, the HRV must have the onboard capability for autonomous execution when it is in close proximity to HST. In addition, wave-off and abort decisions will be required for mission success under certain predicted failure conditions. These procedures will have to be developed, validated, and practiced on the ground. The biggest potential problems concern the inability of the near-field sensor suite to acquire HST; any limits on the fine-guidance control could preclude the ability of the HRV to fly in close formation with HST and could even result in a collision of the two vehicles. The technologies for near-field sensors and for matching vehicle rates for robotic missions have yet to be demonstrated in flight. Failure to correctly accomplish controlled proximity operations will result in loss of the mission.
Robotic systems checkout must be accomplished prior to the final approach. There is a risk at this point that the systems will fail to deploy and/or fail checkout. In such an instance, time for a workaround will be needed before initiating the final approach. It is also possible that the system could fail in such a way that a workaround would not be possible, resulting in failure of the mission.
Approach and Capture
In the approach and capture phase of flight, the chasing spacecraft must maneuver to within capture distance and eventually dock with the target spacecraft. During this phase, the navigation system must provide precise relative orientation between the two spacecraft, which at a minimum requires sensors that can provide relative attitude measurements. A series of safe pause points will also be needed to hold relative position, proceed with capture, or terminate the approach. In addition, the spacecraft architecture must accommodate full simultaneous six-degree-of-freedom precise control capability in a manner that avoids plume impingement on the target vehicle (which could make capture impossible or could possibly damage HST).
Use of the grapple system to perform the final capture of HST is a significant challenge, and this is one of the key technical aspects of the mission that has never been accomplished in the history of the space program. Some of the required technologies are expected to be demonstrated by an experimental system called the Orbital Express (a DARPA program), but given its timing (late 2006) the opportunity for feedback and incorporation of lessons learned into the HST robotic servicing mission may not occur.
Risks—The capture of HST by the HRV is one of the highest-risk portions of a robotic servicing mission. The sequence involves having the two vehicles fly close enough together to enable the GA (which cannot be safely teleoperated, due to the 2-second communications delay) to place its end effector over the pin of the HST grapple fixture, engage the snares, and stiffen the connection. At some point HST’s control system must be disabled so that the combined vehicle will be under the control of the HRV. The GA then has to maneuver the HRV down to the aft end of HST and dock it to the HST towel bars, after which the GA can release the grapple fixture pin.
This type of complicated maneuver has never been done autonomously or teleoperated with time delays. It is very difficult to accurately simulate the event on the ground since it involves two vehicles with almost equal inertia operating in zero gravity. There is some experience in dealing with similar problems on the Space Transportation System (STS), where the shuttle arm has been used to grapple a large payload such as the ISS. But this case has relied on an accurate simulation of the shuttle/arm/ station stack and a clear understanding and detailed modeling of the capture envelope of the station/ shuttle docking mechanism. The approach to and capture of the ISS have been successful because of the advantage of having astronauts who are operating directly in the loop (with a better vantage point than would be available from the GA ground telemetry for the HRV) and who are operating with practiced skill and caution, and with no time delay.
When a robotic system is teleoperated with a time delay, such as would be the case for an HST robotic mission system, there is always the risk that the situation will have changed between the last data sample and the time the command is executed. For slowly moving, non-dynamic situations this may be acceptable, but for situations where there is some inherent motion, a time delay could impose a significant mission risk.
The failure of the HRV to successfully grapple or dock with HST will result in loss of the mission.
Robotic System Integration
The execution of the actual servicing tasks can be broken down into a number of challenging but simpler sub-elements. The details of each scenario have not yet been completely defined, but they can be characterized by a set of generic capabilities that are applied to the desired objectives through the use of special-purpose tools or end effectors and careful adjustment of various parameters.
Assuming that the robotic grapple and dexterous systems have docked successfully with HST using the grapple arm and the rendezvous/proximity sensor suite, the next challenge will be the integration and checkout of the two robotic systems. The grapple arm must de-mate from HST and then grapple the dexterous system, and in so doing must make the necessary electrical and data connections to ensure continuity of command and control. The objective is to optimally operate both robotic systems as one single integrated system. Should that prove to be too challenging in system design and engineering, then the ability to operate the systems independently but harmoniously is required.
Risks—The simple act of decoupling the grapple arm from HST involves two independent risks: the risk of failure to ungrapple and the risk of failure to successfully grapple the dexterous system. The ability to
recover from a failure to ungrapple is built into the systems designed for extravehicular activity (EVA) servicing; there is always a method for overriding the end effectors to release the spacecraft from the grapple manually. As with the shuttle RMS, there is also a secondary remotely commanded capability for release using a backup system. It is not clear whether this backup release capability will be present in the HST robotic system design. The likelihood of a failure to successfully grapple the dexterous system at this point in the mission is reduced, given the assumed earlier success of the initial capture of HST by the grapple arm. A third risk is that of failure to successfully make all the electrical and data/ command connections. Again, such failures during a shuttle mission would be mitigated by manual EVA overrides. A fourth area of risk involves the software development necessary to support the teleoperation or autonomous operations of either or both robotic systems. Historically, complex systems such as those planned for the HST robotic servicing elements have had difficulty in having sufficient testing of the software under all operational modes before being flown. In HST servicing, the need to successfully integrate the two robotic systems adds complexity and increases the risk and challenge of the mission.
Thermal and Illumination Constraints
The tasks in many of the past servicing missions occasionally were made more challenging because of the limitations imposed on allowable intrusion of sunlight on HST or by the HST thermal environment. While the assumption for robotic servicing is that there will be no such constraints because there are no time limitations for any specific task, consideration nevertheless will have to be given to real-world limitations imposed by HST orientation on each step of each operation. In fact, there may well be some tasks in which timing or thermal issues must be considered.
Risks—Some HST servicing tasks may be much more difficult if time limitations are imposed. In such an instance, the ability to stop and assess the situation in the event of any particular anomaly will be reduced, and the risk of failure will increase.
Disassembly and Assembly Tasks
The robotic systems will require task-specific end effectors or tools for each step in a given servicing task, including de-mating and mating of connectors. Each assembly or disassembly operation requires the appropriate end effector to be grappled, including the proper positioning and orienting of the end effector, before the part to be manipulated is grasped. This must be followed by the actual assembly or disassembly operation. This operation is particularly complicated in the case of mating and de-mating of connectors. The connector must be grasped, pulled out, docked to a temporary fixture, and then released. At some future point, the same or a different connector will have to be grasped, de-mated from its storage location, manipulated in a carefully controlled fashion, and successfully mated.
Risks—Any time a tool or end effector is grappled there is a risk of losing the tool and not being able to successfully grasp the tool. There is also a risk that the tool may not work. A further risk is that the tool cannot be successfully released after the operation.
Similarly, when a connector is grasped there is a risk of unsuccessfully de-mating the connector, failing to maintain it with adequate control, bending one or more pins in the connector, and failing to successfully mate it. The ability to successfully de-mate a connector is a direct function of the grip the robotic system has on it. The ability to get into position to get a good grasp and apply the torque in
exactly the right direction presents a mission risk for every connector. Each scenario will require demonstration preflight using real-world geometry and metrology for every single case.
Bent connector pins have occurred in shuttle servicing missions and have been worked around by utilizing spare jumper cables. There is no reason to think that a robotic system might not encounter bent pins. The ability to recognize that this has occurred will be dependent on the vision system being used (versus the EVA crew member’s direct eyesight). Further, the ability to react to such a case will depend on the spare parts that are carried aboard the robotic servicing spacecraft. Every high-priority, mission-critical task using connectors subject to failure will require fallback options for recovery, and the vision system will have to be adequate to detect any such problems when they occur.
Loss of control of a connector or cable could also involve risk, as re-grapple of a free-floating cable (even if tethered at one end) could be a challenge for a robotic system.
Some tasks will involve opening and closing access doors. Depending on the case, this opening or closing may be relatively easy or quite difficult. The task for opening the servicing bay doors is a matter of placing a servicing tool on a J-hook bolt, applying the necessary torque for the necessary number of turns, and then actuating the hook to rotate it 90 degrees out of the way. Opening the door is a little more challenging because the door opens outward and away, and so the robotic operator will have to pull slowly and carefully and move outward with the dexterous manipulator simultaneously. More difficulty can occur with the requirement to keep the access doors open to accomplish the servicing task. Shuttle EVA crews tether doors open to keep them out of the way during a servicing task. The plan for this will require development. The axial bay doors are much larger than the servicing bay doors and can therefore be balkier. The particular axial doors that the first shuttle servicing mission crew had difficulty with are not candidates for the robotic mission. However, another set of axial bay doors must be operated in the robotic mission, and there is expected to be considerable challenge in successfully opening and closing them. These doors have several bolts that are accessed with a special interface and the bolts are driven by a standard power tool. There has been some concern in the past about the state of the bolts and the possibility of degradation of the lubricant used on these bolts, but that has not proved to be a significant issue in the past. Again, the doors must be opened outward and away from the centerline, and so coordinated movement by the robotic system will be necessary. Also, a tether or door stay of some type will be necessary to keep the doors open and not allow them to drift back into the work space.
Risks—Inability to open a set of servicing bay doors implies inability to service what lies behind the door, but nothing more. Inability to close the axial bay doors would lead to loss of the telescope’s functionality, a much higher risk consideration.
The details of any particular instrument change-out have not been finalized, but the tasks can be characterized generically. The old instrument must have all connectors de-mated (see above) and moved out of the way, the instrument must be positively controlled, all bolts or other connections holding the instrument in place must be released, and the instrument must be withdrawn and temporarily stowed in a holding fixture of some type. The new instrument must go through the same process to remove it from its stowage location and then install it in HST. Depending on the instrument, one of the most difficult tasks might be determining proper alignment of the new instrument during installation. Taking snapshot
data readings of the old instrument upon removal can be helpful in ensuring that the new instrument is properly installed, but this is not an absolutely foolproof approach unless the position accuracy of the integrated grapple/dexterous robotic system is kept within very fine tolerance constraints based on allowable misalignment for the respective instrument. These allowable boundary conditions are well understood by the Hubble GSFC personnel for each case. Relying on the data alone is much riskier, however, than having the ability to verify with direct viewing the guide rails and insertion process. Thus the robotic camera pointing, lighting, and viewing angles will become critical factors in ensuring task success. Force feedback to the teleoperator will be a valuable secondary cue, but it is also not sufficient alone to provide the necessary assurance that no binding has occurred during installation.
Risks—The most significant risks are associated with unintentional misalignment of an instrument and any damage that might result from this. For example, the fine-guidance sensor (a radial bay instrument) has a pickoff mirror at the front end (the center of the pie slice) that is extremely delicate and could easily be damaged by inadvertent contact. Other risks include loss of situational awareness of the extrusion or insertion because of poor lighting or sunlight impact on cameras, poor viewing angles, or unanticipated interference such as sagging multilayer insulation.
Physical Location of the Robotic System
The robotic system will have to be properly oriented so that it can reach all targeted subsystems and instruments for change-out. This simple geometry can be worked out well in advance. However, the integrated robotic system is not able to reach all sides and all elements of HST. This is a particularly important point if it becomes necessary to replace the FGS that is on the side opposite the Wide Field Planetary Camera. In this case, the robotic system would have to move to the other side of HST, which will be an extremely complicated and time-consuming maneuver.
Risks—Failure to properly align the robotic system will alter all task geometries and could lead to an inability to accomplish certain mission objectives.
Each sub-element of each robotic task may require its own unique robotic interface or end effector. This could lead to dozens, perhaps even hundreds, of different tools, each with a unique application. The failure of any one of these tools could have a significant impact on mission success. Adequate redundancy of functionality will be a major consideration in allocating mission weight and stowage resources.
Risks—Loss of a critical tool or capability could lead to loss of a particular instrument and, in the worst case, could lead to a loss of HST (in the case of the tools used to close the axial bay doors, for example). Similarly, loss of one of the robotic system elements, such as loss of one of the two dexterous robotic arms, for example, or loss of a key television camera, could lead to loss of the mission.
FINDING: The technology required for the proposed HST robotic servicing mission involves a level of complexity, sophistication, and maturity that requires significant development, integration, and demonstration to reach flight readiness and has inherent risks that are inconsistent with the need to service Hubble as soon as possible.
Technology Readiness Assessment
HST was not designed for autonomous rendezvous and docking, and to achieve this through robotic operations presents a number of technology development challenges. The GSFC HST project has done a good job of identifying the technology challenges that have been recognized to date. The project has made an assessment of the technology risks, and these were provided to the committee in the document entitled “Hubble Robotic Servicing and Disposal Mission (HRSDM) Risk Identification for the National Academies of Sciences, July 9, 2004.” In the project’s analysis, most of the technical readiness levels (TRLs) were given as 8 or 9, with several lower than TRL 5.1
The committee is concerned about the overall TRLs that the project has estimated for many of the robotic servicing tasks. As discussed above, the Hubble robotic servicing and disposal mission is a complex robotic mission with a compressed schedule for testing, development, and evaluation. The robotic missions planned by other agencies before or at approximately the same time as the HRSDM will include specific technology demonstrations and evaluations of several aspects of the technology challenges faced in an HST robotic mission, but these demonstrations will provide only limited, if any, opportunity to incorporate lessons learned.
The individual hardware elements (GA, DR, and DM) have been or will be tested on several different missions (STS, ISS, and Orbital Express), but there will be no in-flight experience with an integrated RMS/SPDM system. Similarly, the vision and control software required for the HRSDM will not be tested with the hardware in flight.
The committee concludes that several of the required robotic servicing technologies are at considerably lower TRL than estimated by the project, and are also mission critical without a significantly better alternative technology available. For example, relative attitude control during servicing and relative attitude determination fall into this category. Other technologies, such as the lidar required for near-field relative navigation acquisition, although considered by the project to be at TRL 6, have not been demonstrated in space. The XSS-11, a U.S. Air Force mission, is scheduled to demonstrate some technologies such as the lidar and autonomous proximity operations by March 2005. DARPA’s Orbital Express program, scheduled for flight in 2006, provides a second opportunity to validate some autonomous grappling technology. Because of the time schedule of these demonstrations relative to the HST robotic service planning, it will be difficult to incorporate lessons learned into an HST robotic mission.
The systems-level operations, interfaces, and software still remain to be designed and tested. The GSFC project team has indicated that it is waiting until the prime contractor is selected, and as a result the interfaces and functionality between elements, as well as an overall systems design implementation plan, have not yet been developed in sufficient detail. Therefore, additional schedule and technology challenges are likely to be identified as the next level of design development gets underway.
The committee believes that there are many substantial differences between the proposed robotic HST mission and the previous robotic experience base. Therefore the readiness assessment based on the TRL of the proposed hardware is almost certainly misleading.
Critical Technology Readiness
The committee assessed the readiness for critical enabling technology for the rendezvous, capture, and robotic operations, as discussed below.
Rendezvous and Capture
There are very few examples of field-tested operations involving robotic manipulation and assembly with either supervised or non-supervised autonomy, and there are only two examples involving space operations. In 1970, the Soviet Union’s space program performed rendezvous and capture with a non-cooperative target2 with a human operator in control and with no communication time delays. (A non-cooperative target is one without transponders or active sensors to provide other space vehicles with its location, identification, and/or relative position.) In 1998, collaboration between the European Space Agency and National Space Development Agency of Japan produced a moderately successful demonstration using the Japanese Engineering Test Satellite (ETS) VII. This involved a 2-meter-long, six-degree-of-freedom manipulator arm attached to a 2500 kg satellite. Coordinated control of the manipulator and the base was used to minimize reaction forces/moments and disturbances. The ETS VII mission demonstrated autonomous rendezvous and capture of a non-cooperative target. However, in this demonstration,3 the target was less than 10 cm from the firmly docked position, and it was specially designed for non-cooperative capture. In other words, it was specifically designed for robotic operations and was equipped with fiduciaries for relative positioning and orientation, and included appropriate fixtures for capture.
The proximity operations, autonomous rendezvous and capture, and robotic servicing of HST require unique sensors, end effector capabilities, capture mechanisms, and guidance and control algorithms for spacecraft maneuvers relative to a target spacecraft. In particular, proximity operations (from approximately 500 m to 3 m) will require the ability to use lidar and/or cameras to control range and bearing. Such a capability has not been flight-tested before. In particular, autonomous non-cooperative and non-interactive relative navigation has never been accomplished. Based on the HST project’s assessment provided to the committee, relative-attitude sensor technology is still at TRL 3. Finally, the lidar and cameras will have to be used to get to within 3 m of the HST with very near zero relative velocity, requiring the control of all of the relative velocities, including attitude rates. While the committee assesses that this level of control is feasible, it notes that the fact that this has never been flight-tested or even accomplished on a similar scale on the ground is reason for concern.
FINDING: Technologies needed for proximity operations and autonomous rendezvous and capture have not been demonstrated in a space environment.
The above procedures will also be required even for a mission that only attaches a de-orbit module to Hubble. This attachment will be required should NASA conclude after the planned mid-2005 critical design review that robotic servicing of HST is not a feasible option and that the original shuttle-based servicing mission should be pursued. The risk in attaching a robotic de-orbit module could be significantly reduced if astronauts would install appropriate hardware (such as targets, fiduciaries, and precision latches) at the time of a shuttle servicing. These items would enable HST to become a cooperative target for the subsequent robotic de-orbit mission. This hardware would provide the best margin of success for docking the de-boost module and for ensuring a more accurate alignment for the center of thrust with HST’s center of gravity for the de-orbit rocket firing.
FINDING: The addition to HST of targets and fiduciaries and a better latching system by the astronauts on the SM-4 mission would enhance the ability of the subsequently launched de-orbit module to dock with HST and provide a more precise alignment for de-orbit.
Control Algorithms and Software
Relative position (via lidar and cameras) will have to be used to grapple and secure HST. Image-processing algorithms must accurately detect features (including fiduciaries) from camera/lidar imagery and match these features with a CAD model of HST. The software must be able to use information about the detected features to automatically register the end effector with respect to the features and then control the end effector of the grapple arm to maintain relative positioning with errors less than 10 cm and relative orientation with errors within 1-2 degrees. This level of final position accuracy is critical for successful instrument change-out where clearances can be as small as 1/2 cm. It may not be feasible to accomplish this on HST because it was not designed for robotic operation and does not have the fiduciaries that a target for robotic capture should have. Further, because of the deterioration of the insulation and of the exterior of HST in general, there could be noticeable differences between HST’s actual condition and the CAD model of HST that is used in the software development. Finally there is a risk associated with the docking procedure during which the HRV and HST must be brought closer by the grapple arm so that the HRV can dock with the HST towel bars. The rates of the combined system will have to be regulated by the propulsion system on the HRV, and the dynamics of the large HST payload at the end of a long arm will excite low-frequency modes in the structure and the control algorithm. Most importantly, while there have been several proof-of-concept demonstrations of autonomy in similar tasks (but on a much smaller scale) in research laboratories, nothing on a system of this size has been demonstrated or tested, on Earth or in space.
It should be noted that some of the technology risk will be alleviated because human operators can be involved in the command-and-control loop. Autonomous operations can be limited to several seconds of operation at a time, allowing the human operator to monitor the progress of the task and to intervene as necessary. However, the performance of such human-in-the-loop teleoperated control systems will be significantly degraded by the communication time delays of up to 2 seconds.4 Extensive testing will be required to reduce the technology risk associated with grappling and securing HST.
FINDING: The control algorithms and software for lidar- and camera-based control of the grapple arm are mission-critical technologies that have not been flight-tested.
The servicing mission includes the installation of batteries, the gyroscopes, and the WFC3 package, and the COSTAR/COS change out. This requires opening and closing shroud doors, the manipulation of HST SA3 DBA2 connectors to tap SA3 power feeds to recharge the new batteries, and de-mating and remating connectors. All of these tasks will be performed by the dexterous robot (DR) equipped with
special-purpose tools and end effectors. The committee concludes that the hardware solutions proposed for the tasks are relatively low risk, that the software and control algorithms for the Dexterous Robot/ Orbital Express Dexterous Manipulator System (DR/OEDMS) are medium risk, and that the vision-based closed-loop control is high risk.
Again, because human operators can be involved in command and control, autonomous operations can be limited to several seconds of operation at a time, significantly mitigating the level of risk involved. But because of the time delays, the operation of the robotic system will not be like the human-in-the-loop systems that NASA has deployed on the shuttle or the ISS. The force feedback information may be difficult to interpret and react to. In principle, punctuating short, scripted, guarded moves with human monitoring and control at every step, although very tedious, is feasible. However, no systematic tests have been done at the scale envisioned in this mission over an extended time line of weeks or months. Further, the software architecture requires complex distribution and integration of sensory data processing and control arbitration across computers that are in orbit and on the ground.
FINDING: Technologies needed for autonomous manipulation, disassembly, and assembly, and for control of manipulators based on vision and force feedback, have not been demonstrated in space.
This section provides the committee’s assessment of NASA’s Project Technical and Programmatic Management Plan for Hubble servicing.
The Goddard Space Flight Center is responsible for the overall management of the HST program, including normal operations and periodic servicing missions. The GSFC has supported the HST robotic servicing mission by providing resources as needed to the project team, composed of Civil Service and contractor personnel with long Hubble experience, augmented by technology experts in the areas of guidance, navigation, and robotics. Throughout their interaction with this committee, it was clear to the committee that project personnel are dedicated to successfully carrying out an HST robotic servicing mission. The committee notes, however, that the Goddard experience base in robotics is limited, with no on-orbit experience, and that the Goddard team has virtually no flight experience with autonomous rendezvous and docking.
Although the situation may change as a result of the NASA administrator’s commitment to proceed with the development of the robotic servicing capability, it was not evident during the committee’s discussions with the project team that the HST robotic servicing project has requested or received the commitment it needs for success. Application of the full breadth of NASA technical expertise is vital to this project, yet as of this writing the committee has seen no evidence that this support has been provided by either the Johnson Space Center or the Jet Propulsion Laboratory, which are organizations with directly applicable mission operations and robotic technology expertise.
FINDING: The Goddard Space Flight Center HST project has a long history of HST shuttle servicing experience but has little experience with autonomous rendezvous and docking or robotic technology development, or with the operations required for the baseline HST robotic servicing mission.
Program Development Plan
The committee evaluated the state of the HST robotic servicing mission system design, program definition, and development plan as provided by the project, as discussed below.
Although the GSFC HST project has developed the initial architecture for the top-level systems engineering, the detailed systems engineering, analysis, and requirements flow down to understand and define how the flight elements and the ground system will operate together as a single system remains to be accomplished. A robotic mission of this complexity requires a significant amount of up-front systems engineering and trade studies based on thorough analyses and simulations just to arrive at a starting point for the system design. This level of design definition is normally done before commitment to hardware procurements, especially for a mission as technically complex5 as the HST robotic servicing mission. Historically, in the experience of the committee members, inadequate upfront systems engineering has been the primary cause of significant program schedule delays and cost overruns. Furthermore, the committee believes that initiating the hardware procurements before completing the system-level analysis may lead to an unnecessarily complex mission implementation. Specifically, the present mission approach focuses on de-orbit prematurely and has selected a complex mission design that requires three modules, the de-orbit module, the ejection module, and the robotic module, and four separate procurements, the DM, the EM, the grapple arm, and the dexterous robot. Further, GSFC will provide all the as-yet-undefined element-to-element and operational interfaces.
The system engineering during the development phase will present a significant challenge because of the complexity of the design approach. As one example, there are a large number of program elements that must be integrated into a single operational system, with an overarching set of system software that will not be defined until after the element prime contractors have begun their design phases. The committee points out that the present plan to develop the various elements of the robotic program in parallel, in various parts of industry and government, will require a strong, central system engineering and integration function that must be extremely active in its oversight of the program.
NASA management has indicated that the integration will be accomplished in-house at GSFC. The committee is concerned that this approach requires a significant broadening of the GSFC HST project responsibilities beyond their previous experience base. Not only will the project oversee the development of the replacement scientific instruments (already completed) and the development of the necessary tooling and implementation of the on-orbit robotic operations, but the project will also be asked to oversee the development and integration of two major spacecraft modules (the DM and the EM) and two different robotic systems (the GA and the DR). This approach could work if there is assurance that there will be an adequate number of highly experienced and capable personnel assigned to accomplish these demanding tasks. Even in this case, there may be insufficient time to carry every task to a satisfactory completion.
FINDING: The GSFC HST project has accomplished a great amount since January 2004. However, there remain significant technology challenges and major systems engineering and development challenges to successfully extend the lifetime of HST through robotic servicing.
Appendix D provides an overview of the state of the art in robotics technology for the reader not familiar with robotics.
The proposed HST robotic servicing mission development schedule of 39 months presents a very difficult challenge in terms of the acquisition and program management strategy. In the briefings presented by the project to the committee it was clear that most of the constituent elements of the mission are well understood by NASA and its supporting industrial partners, with perhaps a few exceptions (such as relative navigation and guidance technology). As individual elements these present no special development problems, provided adequate time is available. However, the schedule allocated for the system-level design integration and validation is extremely aggressive and therefore carries high risk.
The committee believes that the technology development and design integration challenges for the HST robotic servicing mission are being seriously underestimated by the project. Given the state of the current system design, for example, it is unrealistic to expect to have a reasonably thorough preliminary design review (PDR) less than 3 months and a critical design review (CDR) 9 months after contract award, as is currently envisioned by the project. This is especially true given that this effort (1) has not had detailed pre-award, system definition studies; (2) requires critical in-line technology developments; (3) involves multiple contractors; and (4) currently has an undefined set of system-level operational and software interfaces. Further, because of the lack of maturity of the program plan, the project was unable to identify for the committee a data-based critical path in the schedule, further undermining the credibility of the current schedule.
The Aerospace Corporation’s historical database of different space missions of various levels of complexity versus development time is shown in Figure 5.1. The analysis to determine where the HST robotic servicing mission elements fit, as shown in the figure, was developed by the Aerospace Corporation for NASA as part of an assessment of the risks of being able to meet the objectives of the baseline HST robotic servicing mission, and to evaluate any potential reductions in risk that might be offered by less ambitious HST servicing alternatives. Figure 5.1 compares the complexity of the DM, EM, and EM plus RM, each with a baseline development of approximately 39 months, with a large set of other missions contained in the historical database. The committee concludes that all three of the HST robotic servicing subsystem developments have significant schedule shortfalls, ranging from 18 months for the DM to 39 months for the EM plus RM, when compared with successful missions of similar complexity. The committee notes that even more significant is the fact that all of the 39-month HST robotic servicing mission options (even the DM alone) fall very close to the statistical sample of failed or partially failed missions.
The committee not only evaluated the HST project’s schedule plan, but also reviewed the findings of both the Aerospace Corporation’s “Hubble Space Telescope Servicing Analyses of Alternatives”6 and NASA’s Independent Program Assessment Office (IPAO) report prepared for NASA, as presented to the committee.7 The committee concurs with the findings of both of these groups that there is no precedent for a 39-month development schedule for a mission as complex as the baseline HST robotic servicing mission. In fact, the committee agrees with the Aerospace Corporation findings, which suggest that a successful mission of this level of complexity would require a nominal development time of the order of 65 months.
FINDING: The proposed HST robotic servicing mission involves a level of complexity that is inconsistent with the current 39-month development schedule and would require an unprecedented improvement in development performance compared with that of space missions of similar complexity. The likelihood of successful development of the HST robotic servicing mission within the baseline 39-month schedule is remote.
System-Level Test and Validation
In addition to issues with the overarching system engineering and the lack of adequate development schedule time, another critical dimension for ensuring mission success is performing sub-element, element, and integrated systems testing. It is not clear that there is time in the current schedule to accomplish the necessary systems testing, particularly at the more complex integrated level. Nor is it clear that the end-to-end mission scenarios can be replicated in ground testing to validate the operations plans, which in turn requires that the program development plan build quality into all elements of the program at the subsystem and component level. The committee was shown a laboratory demonstration of the elements of the HST servicing mission at GSFC. This demonstration was at a TRL of 4: “component and/or breadboard validation in a laboratory environment.” Although some of the hardware for the proposed mission is at TRL 9, other components are not. Further, the committee found no evidence of systems integration beyond TRL 4.
The current 39-month schedule, as presented to the committee, has no real margin. As a minimum, this will preclude resolution of any serious problems that are discovered in final system test or will have major schedule and cost impacts, or will require a reduction of testing, which in turn likely will increase mission risk.
To improve the chances for success under these circumstances, the program manager would require considerable latitude in authority and budget support from NASA headquarters. Parallel developments and alternative sourcing of critical components would have to be considered. For those critical components where alternative sourcing is impractical, increased management focus would have to be maintained to ensure success. Clearly if the project has adequately performed the upfront system engineering prior to committing to a design implementation and has thus identified all of the risk items along with mitigation strategies, those considered high risk and without an acceptable mitigation strategy would be cause for pursing a completely different implementation solution. The servicing schedule baselined by the project has led it to commit to hardware development without yet completing the development of a complete risk analysis and mitigation plan, and at a minimum the schedule for component development and sourcing would require acceleration to allow for thorough system testing and validation.
The program would require an adequate budget to accomplish this project, including a substantial management reserve to be used at the program manager’s discretion. The project informed the committee that its cost estimates indicated a requirement of close to $1 billion for this effort. The committee learned subsequently that NASA completed an independent cost estimate and is predicting costs of more than $2 billion. Although the committee does not have insight into the composition of these latest cost estimates, the inclusion of a robust management reserve will be critical to achieving a successful outcome. The committee points out that the Defense Science Board, led by Thomas Young, recently completed a 2-year review of national security space programs.8 One of the findings of the Young panel
was that the lack of budget flexibility was one of the chief reasons that complex space development programs were unsuccessful.
The HST robotic servicing technical plan involves significant risks. The initial risk relates to development of the capabilities needed in the program to enable conduct of a mission to service Hubble on a schedule that would preclude a significant interruption of the science program. The second risk relates to effecting a successful vehicle launch to the desired orbit, and to conducting a successful rendezvous. The third risk involves proximity operations and grapple by the robotic spacecraft. A fourth risk relates to successful execution of the combination of complex autonomous and robotic activities required to actually accomplish HST revitalization and instrument replacement. Finally, the fifth risk is that the robotic mission lacks the flexibility to accommodate unforeseen Hubble equipment failures that may occur before the mission is executed and without significantly adding complexity and schedule delay to an already high-risk robotic servicing technical and program plan.
There is some human intervention in the proposed robotic plan through teleoperation, and there may even be the potential for some reprogramming of robotic systems during flight as has been carried out with Mars landers and rovers. However, in general the robotic mission will of necessity be rigid in its design and in its ability to cope with unplanned anomalies such as those that have been encountered during each of the four previous shuttle servicing missions.
CONCLUSION: The very aggressive schedule for development of a viable robotic servicing mission, the commitment to development of individual elements with incomplete systems engineering, the complexity of the mission design, the current low level of technology maturity, the magnitude of the risk-reduction efforts required, and the inability of a robotic servicing mission to respond to unforeseen failures that may well occur on Hubble between now and the mission, together make it unlikely that NASA will be able to extend the science life of HST through robotic servicing.
RELEVANCE TO NASA’S SPACE EXPLORATION INITIATIVE
A robotic serving mission would provide GSFC with experience that could help NASA move toward robotic space exploration. Many technologies that are currently at TRL 7 or lower will be tested, potentially resulting in TRL 9 ratings by the time of mission execution. However, the algorithms, software, and much of the hardware that would be used in this proposed HST mission will have to be tailored to the specific needs of capturing and grappling a non-cooperative target. Further, assembly and disassembly tasks will have to be performed on a premier scientific spacecraft that was never designed for robotic servicing. Future robotic missions will presumably be designed for robotic deployment and servicing from the outset, and will therefore require a different set of robotic technologies.
The space exploration initiative will require the ability to robotically perform satellite servicing in deep space. In such an initiative, the target and the robotic spacecraft would both be designed to common interfaces with the necessary targets, fiduciaries, and other elements to enable the robotic activities. Since Hubble was designed for astronaut servicing, there are no such common interfaces. As such, it is unlikely that there will be significant engineering commonalities between the robotic servicing of Hubble and the essential robotic elements that would be specifically incorporated in a space exploration program.
A more detailed discussion of the comparative risk between a robotic servicing mission and a shuttle mission to HST is presented in Chapter 7.
FINDING: Many of the concerns raised by the committee regarding the risk of attempting to robotically service the Hubble Space Telescope could be mitigated for future programs through planning for robotic servicing in the initial spacecraft design.