Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Scenario planning”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS2016

Overview and Status of the Laser Communication Relay Demonstration

NASA is presently developing first all optical high data rate satellite relay system, LCRD. To be flown on commercial geosynchronous satellite, it will communicate at DPSK and PPM modulation formats up to 1.244 Gbps. LCRD flight payload is being developed by NASA's Goddard Space Flight Center. The two ground stations, one on Table Mountain in CA, developed by NASA's Jet Propulsion Laboratory and another on Hawaiian island will enable bi-directional relay operation and ground sites diversity experiments. In this paper we will report on the current state of LCRD system development, planned operational scenarios and expected system performance.

free space optical communication↗
NASA NTRS2024

Lunar Terrain Vehicle (LTV) Remote Teleoperation Studies Under Four Lunar Communication Latencies

Remotely operating a lunar rover from Earth while subject to an Earth-Moon time delay of multiple seconds could result in a dangerous state where the roving vehicle is either damaged or lost, thereby potentially compromising an entire mission or series of missions. Providing the right capabilities to the remote operator to manage inherent communication latencies will be important for remote driving to be successful. NASA conducted two studies to investigate the average speed and number of kilometers per day that an operator on Earth could teleoperate a notional Artemis unpressurized rover with minimal remote operator capabilities under 0- and 4-second communication delays (April 2023 study) and 6- and 8-second delays (August 2023 study). A primary goal of these studies was to understand if an Artemis Lunar Terrain Vehicle (LTV) could cover 6 kilometers (km) in 24 hours when operated remotely. During the April 2023 evaluation, eight test operators used an in-house simulation of the lunar surface South Pole to teleoperate a NASA government reference LTV. Each operator received approximately 30 minutes of remote driving familiarization/training prior to their test run. Operators viewed the surrounding terrain via a single, rover mast-mounted, high-resolution camera with pan/tilt/zoom capabilities; continuous communication was provided throughout all testing. In the August 2023 evaluation, remote operators received approximately 3 hours of familiarization training in each latency, and the simulation environment provided remote operators with an operator-selected rate limiter to enable finer sensitivity in the hand controller and a predictive circle function to better assist operators with predicting the path the vehicle could take. All test operators were able to successfully navigate and drive through six different types of terrain and five planned traverse scenarios using natural lighting under all communication delays. Results for average speeds for each communication delay, computed by averaging the data from all test conditions for that latency and all operators, are shown in the table below. The average speed data was then used to derive the total time needed to cover 6 km, 8 km, and 20 km (distances relevant to LTV-SYS071 and -029 requirements). Remote operators drove slower and used the brake more frequently when subject to a communication latency as opposed to no communication latency. Subjective workload assessments revealed that while operating in a latency the overall workload significantly increased when compared to a 0-s delay with mental demand, frustration, and performance being the primary contributing factors. Driving strategies in the 0-s delay did not vary significantly among subjects; however, in the 4-s delay condition, three different driving strategies were identified. In the 6-s and 8-s latency conditions the operator’s use of the cruise control to maintain speed was more apparent. Additionally, over the course of the August study, the operator took advantage of the predictive circle indicator on the navigation display and over 95% of the operator’s navigation used the mast camera 180-degree panning function for ground truthing in terms of boulders and craters. Operators started to define more specific parameters in driving strategies for general operations. This consisted of setting the vehicle into a low-speed cruise mode of approximately 11.5 kph and noticing driving performance of the vehicle seemed to be much harder at slower speeds 0.4–0.8 kph; however, the vehicle was more responsive at speeds of 2.9–3.6 kph. Regardless of communication delay, operators used both the horizontal translation rails and the vehicle fenders as guides to predict a path for the vehicle through heavily concentrated terrain features. Test operators acknowledged that the teleoperations training for this study was substantially less than what an actual LTV remote operator will ultimately receive. They estimated a minimum of 20 to 100 hours spread across multiple days and weeks (e.g., strategies included immersion training over a 3-day period, to a short 8-week starter program) would be needed to get an operator ~ 60% proficient (i.e., able to complete a subset of remote driving tasks), to a yearlong program for full proficiency in remote driving tasks under all terrain types and natural lighting conditions. Remotely operating a vehicle on another planetary body while subject to communication latency is a complex task. Speed, distance covered, time spent driving, time spent navigating, brake usage and rock contacts are all affected by operator workload, driving strategies, workstation ergonomics and training. These studies provided a “first-look” answer to a potential system requirement (namely if a remote operator could cover a given distance in a given amount of time); however, considerable general knowledge was gained to begin to understand what it will take to make a successful lunar rover teleoperator.

LTV↗
NASA NTRS2025

Lunar Terrain Vehicle (LTV) Remote Teleoperation Studies Under Four Lunar Communication Latencies

Remotely operating a lunar rover from Earth while subject to an Earth-Moon time delay of multiple seconds could result in a dangerous state where the roving vehicle is either damaged or lost, thereby potentially compromising an entire mission or series of missions. Providing the right capabilities to the remote operator to manage inherent communication latencies will be important for remote driving to be successful. The National Aeronautics and Space Administration (NASA) conducted two studies to investigate the average speed and number of kilometers per day that an operator on Earth could teleoperate a notional Artemis unpressurized rover with minimal remote operator capabilities under 0- and 4-second communication delays (April 2023 study) and 6- and 8-second delays (August 2023 study). A primary goal of these studies was to understand if an Artemis Lunar Terrain Vehicle (LTV) could cover 6 kilometers (km) in 24 hours when operated remotely. During the April 2023 evaluation, eight test operators used an in-house simulation of the lunar surface South Pole to teleoperate a NASA government reference LTV. Each operator received approximately 30 minutes of remote driving familiarization/training prior to their test run. Operators viewed the surrounding terrain via a single, rover mast-mounted, high-resolution camera with pan/tilt/zoom capabilities; continuous communication was provided throughout all testing. In the August 2023 evaluation, remote operators received approximately 3 hours of familiarization training in each latency, and the simulation environment provided remote operators with an operator-selected rate limiter to enable finer sensitivity in the hand controller and a predictive circle function to better assist operators with predicting the path the vehicle could take. All test operators were able to successfully navigate and drive through six different types of terrain and five planned traverse scenarios using natural lighting under all communication delays. Results for average speeds for each communication delay, computed by averaging the data from all test conditions for that latency and all operators, are shown in the table below. The average speed data was then used to derive the total time needed to cover 6 km, 8 km, and 20 km. Remote operators drove slower and used the brake more frequently when subject to a communication latency as opposed to no communication latency. Subjective workload assessments revealed that while operating in a latency the overall workload significantly increased when compared to a 0-s delay with mental demand, frustration, and performance being the primary contributing factors. Driving strategies in the 0-s delay did not vary significantly among subjects; however, in the 4-s delay condition, three different driving strategies were identified. In the 6-s and 8-s latency conditions the operator’s use of the cruise control to maintain speed was more apparent. Additionally, over the course of the August study, the operator took advantage of the predictive circle indicator on the navigation display and over 95% of the operator’s navigation used the mast camera 180-degree panning function for ground truthing in terms of boulders and craters. Operators started to define more specific parameters in driving strategies for general operations. This consisted of setting the vehicle into a low-speed cruise mode of approximately 1–1.5 kph and noticing driving performance of the vehicle seemed to be much harder at slower speeds 0.4–0.8 kph; however, the vehicle was more responsive at speeds of 2.9–3.6 kph. Regardless of communication delay, operators used both the horizontal translation rails and the vehicle fenders as guides to predict a path for the vehicle through heavily concentrated terrain features. Test operators acknowledged that the teleoperations training for this study was substantially less than what an actual LTV remote operator will ultimately receive. They estimated a minimum of 20 to 100 hours spread across multiple days and weeks (e.g., strategies included immersion training over a 3-day period, to a short 8-week starter program) would be needed to get an operator ~ 60% proficient (i.e., able to complete a subset of remote driving tasks), to a yearlong program for full proficiency in remote driving tasks under all terrain types and natural lighting conditions. Remotely operating a vehicle on another planetary body while subject to communication latency is a complex task. Speed, distance covered, time spent driving, time spent navigating, brake usage and rock contacts are all affected by operator workload, driving strategies, workstation ergonomics and training. These studies provided a “firstlook” answer to a potential system requirement (namely if a remote operator could cover a given distance in a given amount of time); however, considerable general knowledge was gained to begin to understand what it will take to make a successful lunar rover teleoperator.

LTV↗
NASA NTRS2015

Planning for Crew Exercise for Deep Space Mission Scenarios

Exercise which is necessary for maintaining crew health on-orbit and preparing the crew for return to 1G can be challenging to incorporate into spaceflight vehicles. Deep space missions will require further understanding of the physiological response to microgravity, understanding appropriate mitigations, and designing the exercise systems to effectively provide mitigations, and integrating effectively into vehicle design with a focus to support planned mission scenarios. Recognizing and addressing the constraints and challenges can facilitate improved vehicle design and exercise system incorporation.

Moore, E. Cherice↗
NASA NTRS2018

Cassini's Grand Finale: A Mission Planning Retrospective

On September 15, 2017, Cassini plunged deep into Saturn, down to where the atmosphere was sufficiently dense to destroy the spacecraft, making it part of Saturn forever. In the five months leading up to its destruction, Cassini flew between Saturn and its rings 22 times, collecting data from the never before-explored region of the Kronian system. These orbits, the Grand Finale of Cassini, were the culmination of years of planning by the Cassini flight team. This paper looks back upon the mission planning effort in particular, comparing the baseline operational scenarios and contingency plans to the as flown Grand Finale. The bulk of the Grand Finale mission planning effort was focused on the environmental hazards present in the region between Saturn and its rings: the dust and the atmosphere. Dust hazard and atmospheric transit contingency plans were in place to help ensure spacecraft health and maximize science data return. The dust hazard plan gave the operations team the option to turn the spacecraft to a safe attitude during ring-plane crossings had the dust environment proved more threatening than anticipated. The atmospheric transit plan would have made use of an orbital trim maneuver in order to raise or lower periapsis depending on the density of the atmosphere. The proximal environment did have its surprises, though they were good surprises. The dust was significantly less hazardous than predicted. So much so that elements of the contingency plan were leveraged in order to remove a dust hazard protection from the baseline plan, rather than add one to it. While the atmosphere was substantially denser than predicted, it was not dense enough to warrant a periapsis-raise maneuver and actually meant that better in-situ data was gathered. Ultimately, from a mission planning perspective, the Grand Finale went better than expected.

Sturm II, Erick J.↗
NASA NTRS1988

NASA telerobot testbed development and core technology demonstration

In 1985, NASA initiated a major program of technology development and demonstration for robotics applications to space servicing, assembly, repair, and remote exploration. A ground-based telerobot testbed at the Jet Propulsion Laboratory has been the focal point within this program. Designed to prove technology concepts for supervised automation of increasingly unstructured and complex tasks, the testbed has reached an initial stage of integration. Several significant testbed experiments have been performed, including visual tracking and grapple of a satellite, dual-arm spatial coordination and manipulator control, force-reflecting teleoperations, and simulated task planning for a satellite servicing scenario. The current NASA plans for continuing testbed development and demonstration are also described.

Schenker, Paul S.↗
NASA NTRS1991

MisTec: A software application for supporting space exploration scenario options and technology development analysis and planning

The structure and composition of a new, emerging software application, which models and analyzes space exploration scenario options for feasibility based on technology development projections is presented. The software application consists of four main components: a scenario generator for designing and inputting scenario options and constraints; a processor which performs algorithmic coupling and options analyses of mission activity requirements and technology capabilities; a results display which graphically and textually shows coupling and options analysis results; and a data/knowledge base which contains information on a variety of mission activities and (power and propulsion) technology system capabilities. The general long-range study process used by NASA to support recent studies is briefly introduced to provide the primary basis for comparison for discussing the potential advantages to be gained from developing and applying this king of application. A hypothetical example of a scenario option to facilitate the best conceptual understanding of what the application is, how it works, or the operating methodology, and when it might be applied is presented.

Horsham, Gary A. P.↗
NASA NTRS1992

MisTec - A software application for supporting space exploration scenario options and technology development analysis and planning

This structure and composition of a new, emerging software application, which models and analyzes space exploration scenario options for feasibility based on technology development projections is presented. The software application consists of four main components: a scenario generator for designing and inputting scenario options and constraints; a processor which performs algorithmic coupling and options analyses of mission activity requirements and technology capabilities; a results display which graphically and textually shows coupling and options analysis results; and a data/knowledge base which contains information on a variety of mission activities and (power and propulsion) technology system capabilities. The general long-range study process used by NASA to support recent studies is briefly introduced to provide the primary basis for comparison for discussing the potential advantages to be gained from developing and applying this kind of application. A hypothetical example of a scenario option to facilitate the best conceptual understanding of what the application is, how it works, or the operating methodology, and when it might be applied is presented.

Horsham, Gary A. P.↗
NASA NTRSDate not supplied

BioSentinel: To the Moon or Beyond?

BioSentinel, an Artemis-1 secondary spacecraft, will carry a biology experiment into deep space for the first time in 50 years. A 6U CubeSat form factor was utilized for the spacecraft and included technologies newly developed or adapted for operations beyond Earth orbit. This is the maiden deep-space voyage for the radio, propulsion system, electrical power system, and BioSensor payload. The spacecraft carries onboard budding yeast, Saccharomyces cerevisiae, as an analog to human cells to test the biological response to deep space radiation. Flying a secondary payload beyond LEO comes with unique challenges with respect to trajectory uncertainty and mission operations planning. BioSentinel does not carry propulsion for trajectory maneuvers, so plans for Comms and Power need to be developed for all trajectories. The nominal plan is a lunar flyby followed by an insertion into Heliocentric orbit. However, some possible scenarios include lunar eclipses that could severely impact the power budget during that phase of the mission, while others could result in a “Retrograde” hyperbola at swingby resulting in the spacecraft traveling inward toward Earth or even towards a collision with the lunar surface. BioSentinel’s final trajectory will not be known until after launch and deployment so possible scenarios need to be planned for ahead of time. This paper discusses the operational scenarios that were planned for as well as the actual execution of the mission operations including: command pass scheduling with the Deep Space Network, selecting bandwidth limits, medium gain antenna versus low gain antenna usage, and conserving power prior to a lunar eclipse. Note: Artemis-1 is planned to launch in the Spring of 2022

BioSentinel↗
NASA NTRSDate not supplied

Development of Space Mission Integrated Operations Scenarios

Integrated Operations Scenarios (IOS) describe nominal operations planned for a space mission. Operational scenarios are key to an operations concept, as they help identify issues and drivers on the operations system. This paper covers the tools, processes, and inputs that feed into an IOS product, and how IOS iterations during a mission lifecycle can buy down operational risks. A case used for this paper is nominal operations for an initial crewed Artemis mission that includes cross-program sequence of tasks required to accomplish end to end functions from launch through transit, on-orbit operations, to safely return to Earth. An IOS product serves as a reference for discussions during requirements development, task and risk analyses, concept of operations development, and as foundation to prepare space mission flight plans.

integrated operations scenarios↗
NASA NTRS2017

Participatory Technology Assessment for Mars Mission Planning: Public Values and Rationales

Public support and interest are needed to design an ambitious human spaceflight program. However, it is difficult to understand what the public values and would support. And it is even more challenging and rare to consider public views prior to actually developing a mission. Participatory technology assessment (pTA) is a method that aims to understand public preferences and values in order to inform upstream government decision-making. We assess a recently completed experiment in pTA, the "Informing NASA's Asteroid Initiative" project. Through a cooperative agreement with NASA, the Expert and Citizen Assessment of Science and Technology (ECAST) network conducted a pTA-based forum on NASA's Asteroid Initiative and the Journey to Mars. ECAST organized two citizen forums in Phoenix, Arizona and Boston, Massachusetts in November 2014, with a total of 183 citizens selected so as to minimize self-selection biases. This paper focuses on the "Journey to Mars" session, which had the primary goal of soliciting citizen perceptions about different Mars exploration scenarios and mission planning approaches. Citizens were given background information about three potential Mars exploration scenarios that NASA could carry out: 1) Crewed orbital mission to direct robots on the surface of Mars; 2) Short exploratory crewed mission to the surface of Mars; and 3) establishing a permanent settlement. Citizens then engaged in structured facilitated discussions about their preferences among the scenarios and NASA's mission planning approach. Using a grounded theory coding approach, we analyzed participants' written rationales and dialogue about Mars exploration. In general, participants did not show a strong preference for any particular mission profile, but there was a slight preference for the crewed orbital robotics scenario. Participants who supported this approach saw it as the quickest, safest, and least costly road to a successful mission. However, many participants were interested in seeing "boots on the ground," as they believed this would propel scientific advancement, increase excitement about space exploration, and make humans a "two-planet species."

Bertrand, Pierre↗
NASA NTRS2015

Planning for Crew Exercise for Future Deep Space Mission Scenarios

Providing the necessary exercise capability to protect crew health for deep space missions will bring new sets of engineering and research challenges. Exercise has been found to be a necessary mitigation for maintaining crew health on‐orbit and preparing the crew for return to earth's gravity. Health and exercise data from Apollo, Space Lab, Shuttle, and International Space Station missions have provided insight into crew deconditioning and the types of activities that can minimize the impacts of microgravity on the physiological systems. The hardware systems required to implement exercise can be challenging to incorporate into spaceflight vehicles. Exercise system design requires encompassing the hardware required to provide mission specific anthropometrical movement ranges, desired loads, and frequencies of desired movements as well as the supporting control and monitoring systems, crew and vehicle interfaces, and vibration isolation and stabilization subsystems. The number of crew and operational constraints also contribute to defining the what exercise systems will be needed. All of these features require flight vehicle mass and volume integrated with multiple vehicle systems. The International Space Station exercise hardware requires over 1,800 kg of equipment and over 24 m3 of volume for hardware and crew operational space. Improvements towards providing equivalent or better capabilities with a smaller vehicle impact will facilitate future deep space missions. Deep space missions will require more understanding of the physiological responses to microgravity, understanding appropriate mitigations, designing the exercise systems to provide needed mitigations, and integrating effectively into vehicle design with a focus to support planned mission scenarios. Recognizing and addressing the constraints and challenges can facilitate improved vehicle design and exercise system incorporation.

Moore, Cherice↗
NASA NTRSDate not supplied

An Impedance-Based Complexity Metric for Unmanned Aircraft System Traffic Scenario Classification

This paper introduces an impedance-based metric to capture the complexity of a given unmanned aircraft system traffic scenario. The metric accounts for both the number of aircraft and the traffic flow pattern. The work presented here extends an earlier approach that introduced another scenario complexity metric based on the number of potential conflicts weighted by the conflict resolution cost associated. Complexity measurements for randomly-generated scenarios were produced through high-fidelity fast-time simulations and treated as baseline. Then the impedance based metric was evaluated, for the same scenarios, without the need for an actual flight simulation and a conflict resolution method. The results show that the impedance-based metric has a strong correlation to the baseline data and performs marginally better than the weighted conflict-based complexity metric introduced in the earlier work. The metric computation generates impedance maps which are useful for identifying high complexity regions in a scenario, where flight plan changes might be necessitated. This metric can therefore be used, in conjunction with other complexity metrics, to inform adequate traffic management strategies and classify a traffic scenario as acceptable, unacceptable or acceptable with changes made to flight plans that pass through the high complexity regions. The metric can also be used as a guidance metric for strategic conflict management methods.

Complexity↗
NASA NTRS2003

Software for Planning Scientific Activities on Mars

Mixed-Initiative Activity Plan Generator (MAPGEN) is a ground-based computer program for planning and scheduling the scientific activities of instrumented exploratory robotic vehicles, within the limitations of available resources onboard the vehicle. MAPGEN is a combination of two prior software systems: (1) an activity-planning program, APGEN, developed at NASA s Jet Propulsion Laboratory and (2) the Europa planner/scheduler from NASA Ames Research Center. MAPGEN performs all of the following functions: Automatic generation of plans and schedules for scientific and engineering activities; Testing of hypotheses (or what-if analyses of various scenarios); Editing of plans; Computation and analysis of resources; and Enforcement and maintenance of constraints, including resolution of temporal and resource conflicts among planned activities. MAPGEN can be used in either of two modes: one in which the planner/scheduler is turned off and only the basic APGEN functionality is utilized, or one in which both component programs are used to obtain the full planning, scheduling, and constraint-maintenance functionality.

Ai-Chang, Mitchell↗
NASA NTRS1991

Space Shuttle launch pad rescue plan

The final preparation of the Space Shuttle Orbiter for flight involves the loading of large quantities of hazardous propellants. Additionally, many pyrotechnially operated mechanical joints are armed and ready for flight. The personnel manning at the pad is minimized during these operations to reduce the risk. Upon completion of propellant loading, the flight crew must be boarded onto the vehicle which at this point has tremendous potential energy. Plans have been made to safely and quickly evacuate the crew should some unforeseen contigency occur. Both aided and unaided egress scenarios have been planned. Personnel protective equipment is an important consideration to assure the highest chance for survival. Rapid movement of personnel is enhanced by the use of the slidewire system and specially prepared armored personnel carriers. The end result is a system that provides a reasonable chance of survival should an emergency occur during late countdown at the pad.

Doerr, Donald F.↗
NASA NTRS2019

Scenario Complexity for Unmanned Aircraft System Traffic

This work introduces an approach to estimate the complexity of a low-altitude air traffic scenario involving multiple UASs using mathematical programming. Given a set of multi-point UAS flight trajectories, vehicle dynamics, and a conflict resolution algorithm, an abstract model is developed such that it can be solved quickly using a mathematical programming optimization software without running high-fidelity simulations that can be computationally expensive and may not suit real-time apA quick and accurate assessment of complexity for a given traffic scenario can help plan and schedule flights to alleviate traffic bottleneck and mitigate operation risks, especially for unmanned aerial system traffic management where high traffic density or complexity is expected. This work introduces a traffic scenario complexity metric that was constructed based on the number of potential conflicts weighted by the conflict resolution cost associated. The cost associated with a conflict is calculated based on the corresponding conflict resolution maneuvers. To obtain the conflict resolution maneuvers, a MILP-based optimization was formulated with the vehicle model and conflict management parameters incorporated. To evaluate the complexity metrics, an approach of using measurements from high-fidelity simulations was proposed. The scenario complexity measurements for 920 random-generated scenarios were obtained through high-fidelity simulations and treated as the ground truth. Two statistics methods: Pearson and Alternative Conditional Expectations were applied for analysis. The results showed that the number of flights has low correlation with the scenario complexity according to the correlation coefficients calculated by both methods. The Alternative Conditional Expectations method shows that the proposed scenario complexity metric has better correlation with the ground truth than the number of potential conflicts.plications. In the abstract model, each vehicle is represented by a time-varied vector associated with position, speed, and heading information. The total extra distance that aircraft need to divert from their original routes to avoid collisions is computed and used to setup a quadratic programming formula. The metrics including the number of conflicts and extra distances travelled by all vehicles are then utilized to estimate the complexity of a given UAS flight scenario. Results and verification against high-fidelity simulations will be provided in the final draft.

traffic complexity↗
NASA NTRS2005

A Model-based Approach to Controlling the ST-5 Constellation Lights-Out Using the GMSEC Message Bus and Simulink

Space Technology 5 (ST-5) is a three-satellite constellation, technology validation mission under the New Millennium Program at NASA to be launched in March 2006. One of the key technologies to be validated is a lights-out, model-based operations approach to be used for one week to control the ST-5 constellation with no manual intervention. The ground architecture features the GSFC Mission Services Evolution Center (GMSEC) middleware, which allows easy plugging in of software components and a standardized messaging protocol over a software bus. A predictive modeling tool built on MatLab's Simulink software package makes use of the GMSEC standard messaging protocol to interface to the Advanced Mission Planning System (AMPS) Scenario Scheduler which controls all activities, resource allocation and real-time re-profiling of constellation resources when non-nominal events occur. The key features of this system, which we refer to as the ST-5 Simulink system, are as follows: Original daily plan is checked to make sure that predicted resources needed are available by comparing the plan against the model. As the plan is run in real-time, the system re-profiles future activities in real-time if planned activities do not occur in the predicted timeframe or fashion. Alert messages are sent out on the GMSEC bus by the system if future predicted problems are detected. This will allow the Scenario Scheduler to correct the situation before the problem happens. The predictive model is evolved automatically over time via telemetry updates thus reducing the cost of implementing and maintaining the models by an order of magnitude from previous efforts at GSFC such as the model-based system built for MAP in the mid-1990's. This paper will describe the key features, lessons learned and implications for future missions once this system is successfully validated on-orbit in 2006.

Witt, Kenneth J.↗