Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “sequencing commanding operations”

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 199 records · Page 11

Antenna Controller Replacement Software

The Antenna Controller Replacement (ACR) software accurately points and monitors the Deep Space Network (DSN) 70-m and 34-m high-efficiency (HEF) ground-based antennas that are used to track primarily spacecraft and, periodically, celestial targets. To track a spacecraft, or other targets, the antenna must be accurately pointed at the spacecraft, which can be very far away with very weak signals. ACR s conical scanning capability collects the signal in a circular pattern around the target, calculates the location of the strongest signal, and adjusts the antenna pointing to point directly at the spacecraft. A real-time, closed-loop servo control algorithm performed every 0.02 second allows accurate positioning of the antenna in order to track these distant spacecraft. Additionally, this advanced servo control algorithm provides better antenna pointing performance in windy conditions. The ACR software provides high-level commands that provide a very easy user interface for the DSN operator. The operator only needs to enter two commands to start the antenna and subreflector, and Master Equatorial tracking. The most accurate antenna pointing is accomplished by aligning the antenna to the Master Equatorial, which because of its small size and sheltered location, has the most stable pointing. The antenna has hundreds of digital and analog monitor points. The ACR software provides compact displays to summarize the status of the antenna, subreflector, and the Master Equatorial. The ACR software has two major functions. First, it performs all of the steps required to accurately point the antenna (and subreflector and Master Equatorial) at the spacecraft (or celestial target). This involves controlling the antenna/ subreflector/Master-Equatorial hardware, initiating and monitoring the correct sequence of operations, calculating the position of the spacecraft relative to the antenna, executing the real-time servo control algorithm to maintain the correct position, and monitoring tracking performance.

Chao, Roger Y.↗

Implementing Distributed Operations: A Comparison of Two Deep Space Missions

Two very different deep space exploration missions--Mars Exploration Rover and Cassini--have made use of distributed operations for their science teams. In the case of MER, the distributed operations capability was implemented only after the prime mission was completed, as the rovers continued to operate well in excess of their expected mission lifetimes; Cassini, designed for a mission of more than ten years, had planned for distributed operations from its inception. The rapid command turnaround timeline of MER, as well as many of the operations features implemented to support it, have proven to be conducive to distributed operations. These features include: a single science team leader during the tactical operations timeline, highly integrated science and engineering teams, processes and file structures designed to permit multiple team members to work in parallel to deliver sequencing products, web-based spacecraft status and planning reports for team-wide access, and near-elimination of paper products from the operations process. Additionally, MER has benefited from the initial co-location of its entire operations team, and from having a single Principal Investigator, while Cassini operations have had to reconcile multiple science teams distributed from before launch. Cassini has faced greater challenges in implementing effective distributed operations. Because extensive early planning is required to capture science opportunities on its tour and because sequence development takes significantly longer than sequence execution, multiple teams are contributing to multiple sequences concurrently. The complexity of integrating inputs from multiple teams is exacerbated by spacecraft operability issues and resource contention among the teams, each of which has their own Principal Investigator. Finally, much of the technology that MER has exploited to facilitate distributed operations was not available when the Cassini ground system was designed, although later adoption of web-based and telecommunication tools has been critical to the success of Cassini operations.

Cassini Mission↗

From Prime to Extended Mission: Evolution of the MER Tactical Uplink Process

To support a 90-day surface mission for two robotic rovers, the Mars Exploration Rover mission designed and implemented an intensive tactical operations process, enabling daily commanding of each rover. Using a combination of new processes, custom software tools, a Mars-time staffing schedule, and seven-day-a-week operations, the MER team was able to compress the traditional weeks-long command-turnaround for a deep space robotic mission to about 18 hours. However, there was never an intention of maintaining the pace of this process indefinitely. Even before the end of the three-month prime mission, MER operations began evolving towards greater sustainability. A combination of continued software tool development, increasing team experience, and availability of reusable sequences first reduced the mean process duration to approximately 11 hours. The number of workshifts required to perform the process dropped, and the team returned to a modified 'Earth-time' schedule. Additional process and tool adaptation eventually provided the option of planning multiple Martian days of activity within a single workshift, making 5- day-a-week operations possible. The vast majority of the science team returned to their home institutions, continuing to participate fully in the tactical operations process remotely. MER has continued to operate for over two Earth-years as many of its key personnel have moved on to other projects, the operations team and budget have shrunk, and the rovers have begun to exhibit symptoms of aging.

Mars exploration↗

Implementing distributed operations : a comparison of two Deep Space Missions

Two very different deep space exploration missions—Mars Exploration Rover and Cassini—have made use of distributed operations for their science teams. In the case of MER, the distributed operations capability was implemented only after the prime mission was completed, as the rovers continued to operate well in excess of their expected mission lifetimes; Cassini, designed for a prime mission of four years, had planned for distributed operations from its inception. The rapid command turnaround timeline of MER, as well as many of the operations features implemented to support it, have proven to be conducive to distributed operations. These features include: a single science team leader during the tactical operations timeline, highly integrated science and engineering teams, processes and file structures designed to permit multiple team members to work in parallel to deliver sequencing products, web-based spacecraft status and planning reports for team-wide access, and near-elimination of paper products from the operations process.

Larsen, Barbara↗

CloudSat Anomaly Recovery and Operational Lessons Learned

In April 2011, NASA's pioneering cloud profiling radar satellite, CloudSat, experienced a battery anomaly that placed it into emergency mode and rendered it operations incapable. All initial attempts to recover the spacecraft failed as the resultant power limitations could not support even the lowest power mode. Originally part of a six-satellite constellation known as the "A-Train", CloudSat was unable to stay within its assigned control box, posing a threat to other A-Train satellites. CloudSat needed to exit the constellation, but with the tenuous power profile, conducting maneuvers was very risky. The team was able to execute a complex sequence of operations which recovered control, conducted an orbit lower maneuver, and returned the satellite to safe mode, within one 65 minute sunlit period. During the course of the anomaly recovery, the team developed several bold, innovative operational strategies. Details of the investigation into the root-cause and the multiple approaches to revive CloudSat are examined. Satellite communication and commanding during the anomaly are presented. A radical new system of "Daylight Only Operations" (DO-OP) was developed, which cycles the payload and subsystem components off in tune with earth eclipse entry and exit in order to maintain positive power and thermal profiles. The scientific methodology and operational results behind the graduated testing and ramp-up to DO-OP are analyzed. In November 2011, the CloudSat team successfully restored the vehicle to consistent operational collection of cloud radar data during sunlit portions of the orbit. Lessons learned throughout the six-month return-to-operations recovery effort are discussed and offered for application to other R&D satellites, in the context of on-orbit anomaly resolution efforts.

cloud profiling radar satellite↗

UMI - An interactive supervisory and shared control system for telerobotics

An interactive user interface, User-Macro-Interface (UMI), and its complete task execution system are developed and implemented for utilization by an operator to describe, simulate and execute tasks on a multiarm telerobot. The sequences or primitives can be executed on a graphics simulator or on the JPL Telerobot which incorporates two task execution manipulators, one manipulation used for positioning cameras, and two 6-degree-of-freedom force-reflecting hand controllers employed for shared and teleoperation modes of execution. The UMI interface is to be used as the operator interface at a local command site to prepare and send commands to a remote space telerobot.

Backes, Paul G.↗

Failure Investigation of an Intra-Manifold Explosion in a Horizontally-Mounted 870 lbf Reaction Control Thruster

In June 2010, an 870 lbf Space Shuttle Orbiter Reaction Control System Primary Thruster experienced an unintended shutdown during a test being performed at the NASA White Sands Test Facility. Subsequent removal and inspection of the thruster revealed permanent deformation and misalignment of the thruster valve mounting plate. Destructive evaluation determined that after three nominal firing sequences, the thruster had experienced an energetic event within the fuel (monomethylhydrazine) manifold at the start of the fourth firing sequence. The current understanding of the phenomenon of intra-manifold explosions in hypergolic bipropellant thrusters is documented in literature where it is colloquially referred to as a ZOT. The typical ZOT scenario involves operation of a thruster in a gravitational field with environmental pressures above the triple point pressure of the propellants. Post-firing, when the thruster valves are commanded closed, there remains a residual quantity of propellant in both the fuel and oxidizer (nitrogen tetroxide) injector manifolds known as the "dribble volume". In an ambient ground test configuration, these propellant volumes will drain from the injector manifolds but are impeded by the local atmospheric pressure. The evacuation of propellants from the thruster injector manifolds relies on the fluids vapor pressure to expel the liquid. The higher vapor pressure oxidizer will evacuate from the manifold before the lower vapor pressure fuel. The localized cooling resulting from the oxidizer boiling during manifold draining can result in fuel vapor migration and condensation in the oxidizer passage. The liquid fuel will then react with the oxidizer that enters the manifold during the next firing and may produce a localized high pressure reaction or explosion within the confines of the oxidizer injector manifold. The typical ZOT scenario was considered during this failure investigation, but was ultimately ruled out as a cause of the explosion. Converse to the typical ZOT failure mechanism, the failure of this particular thruster was determined to be the result of liquid oxidizer being present within the fuel manifold.

Durning, Joseph G., III↗

MPST Software: grl_pef_check

This innovation is a tool used to verify and validate spacecraft sequences at the predicted events file (PEF) level for the GRAIL (Gravity Recovery and Interior Laboratory, see http://www.nasa. gov/mission_pages/grail/main/index. html) mission as part of the Multi-Mission Planning and Sequencing Team (MPST) operations process to reduce the possibility for errors. This tool is used to catch any sequence related errors or issues immediately after the seqgen modeling to streamline downstream processes. This script verifies and validates the seqgen modeling for the GRAIL MPST process. A PEF is provided as input, and dozens of checks are performed on it to verify and validate the command products including command content, command ordering, flight-rule violations, modeling boundary consistency, resource limits, and ground commanding consistency. By performing as many checks as early in the process as possible, grl_pef_check streamlines the MPST task of generating GRAIL command and modeled products on an aggressive schedule. By enumerating each check being performed, and clearly stating the criteria and assumptions made at each step, grl_pef_check can be used as a manual checklist as well as an automated tool. This helper script was written with a focus on enabling the user with the information they need in order to evaluate a sequence quickly and efficiently, while still keeping them informed and active in the overall sequencing process. grl_pef_check verifies and validates the modeling and sequence content prior to investing any more effort into the build. There are dozens of various items in the modeling run that need to be checked, which is a time-consuming and errorprone task. Currently, no software exists that provides this functionality. Compared to a manual process, this script reduces human error and saves considerable man-hours by automating and streamlining the mission planning and sequencing task for the GRAIL mission.

Call, Jared A.↗

APGEN Version 5.0

Activity Plan Generator (APGEN), now at version 5.0, is a computer program that assists in generating an integrated plan of activities for a spacecraft mission that does not oversubscribe spacecraft and ground resources. APGEN generates an interactive display, through which the user can easily create or modify the plan. The display summarizes the plan by means of a time line, whereon each activity is represented by a bar stretched between its beginning and ending times. Activities can be added, deleted, and modified via simple mouse and keyboard actions. The use of resources can be viewed on resource graphs. Resource and activity constraints can be checked. Types of activities, resources, and constraints are defined by simple text files, which the user can modify. In one of two modes of operation, APGEN acts as a planning expert assistant, displaying the plan and identifying problems in the plan. The user is in charge of creating and modifying the plan. In the other mode, APGEN automatically creates a plan that does not oversubscribe resources. The user can then manually modify the plan. APGEN is designed to interact with other software that generates sequences of timed commands for implementing details of planned activities.

Maldague, Pierre↗

Advanced Communications Technology Satellite high burst rate link evaluation terminal experiment control and monitor software maintenance manual, version 1.0

The Experiment Control and Monitor (EC&M) software was developed at NASA Lewis Research Center to support the Advanced Communications Technology Satellite (ACTS) High Burst Rate Link Evaluation Terminal (HBR-LET). The HBR-LET is an experimenter's terminal to communicate with the ACTS for various investigations by government agencies, universities, and industry. The EC&M software is one segment of the Control and Performance Monitoring (C&PM) software system of the HBR-LET. The EC&M software allows users to initialize, control, and monitor the instrumentation within the HBR-LET using a predefined sequence of commands. Besides instrument control, the C&PM software system is also responsible for computer communication between the HBR-LET and the ACTS NASA Ground Station and for uplink power control of the HBR-LET to demonstrate power augmentation during rain fade events. The EC&M Software User's Guide, Version 1.0 (NASA-CR-189160) outlines the commands required to install and operate the EC&M software. Input and output file descriptions, operator commands, and error recovery procedures are discussed in the document. The EC&M Software Maintenance Manual, Version 1.0 (NASA-CR-189161) is a programmer's guide that describes current implementation of the EC&M software from a technical perspective. An overview of the EC&M software, computer algorithms, format representation, and computer hardware configuration are included in the manual.

Reinhart, Richard C.↗

Advanced communications technology satellite high burst rate link evaluation terminal experiment control and monitor software user's guide, version 1.0

The Experiment Control and Monitor (EC&M) software was developed at NASA Lewis Research Center to support the Advanced Communications Technology Satellite (ACTS) High Burst Rate Link Evaluation Terminal (HBR-LET). The HBR-LET is an experimenter's terminal to communicate with the ACTS for various investigations by government agencies, universities, and industry. The EC&M software is one segment of the Control and Performance Monitoring (C&PM) software system of the HBR-LET. The EC&M software allows users to initialize, control, and monitor the instrumentation within the HBR-LET using a predefined sequence of commands. Besides instrument control, the C&PM software system is also responsible for computer communication between the HBR-LET and the ACTS NASA Ground Station and for uplink power control of the HBR-LET to demonstrate power augmentation during rain fade events. The EC&M Software User's Guide, Version 1.0 (NASA-CR-189160) outlines the commands required to install and operate the EC&M software. Input and output file descriptions, operator commands, and error recovery procedures are discussed in the document.

Reinhart, Richard C.↗

A vision architecture for the extravehicular activity retriever

The Extravehicular Activity Retriever (EVAR) is a robotic device currently being developed by the Automation and Robotics Division at the NASA Johnson Space Center to support activities in the neighborhood of the Space Shuttle or Space Station Freedom. As the name implies, the Retriever's primary function will be to provide the capability to retrieve tools, equipment or other objects which have become detached from the spacecraft, but it will also be able to rescue a crew member who may have become inadvertently de-tethered. Later goals will include cooperative operations between a crew member and the Retriever such as fetching a tool that is required for servicing or maintenance operations. This report documents a preliminary design for a Vision System Planner (VSP) for the EVAR that is capable of achieving visual objectives provided to it by a high level task planner. Typical commands which the task planner might issue to the VSP relate to object recognition, object location determination, and obstacle detection. Upon receiving a command from the task planner, the VSP then plans a sequence of actions to achieve the specified objective using a model-based reasoning approach. This sequence may involve choosing an appropriate sensor, selecting an algorithm to process the data, reorienting the sensor, adjusting the effective resolution of the image using lens zooming capability, and/or requesting the task planner to reposition the EVAR to obtain a different view of the object. An initial version of the Vision System Planner which realizes the above capabilities using simulated images has been implemented and tested. The remaining sections describe the architecture and capabilities of the VSP and its relationship to the high level task planner. In addition, typical plans that are generated to achieve visual goals for various scenarios will be discussed. Specific topics to be addressed will include object search strategies, repositioning of the EVAR to improve the quality of information obtained from the sensors, complementary usage of the sensors and redundant capabilities.

Magee, Michael↗

A vision system planner for increasing the autonomy of the Extravehicular Activity Helper/Retriever

The Extravehicular Activity Retriever (EVAR) is a robotic device currently being developed by the Automation and Robotics Division at the NASA Johnson Space Center to support activities in the neighborhood of the Space Shuttle or Space Station Freedom. As the name implies, the Retriever's primary function will be to provide the capability to retrieve tools and equipment or other objects which have become detached from the spacecraft, but it will also be able to rescue a crew member who may have become inadvertently de-tethered. Later goals will include cooperative operations between a crew member and the Retriever such as fetching a tool that is required for servicing or maintenance operations. This paper documents a preliminary design for a Vision System Planner (VSP) for the EVAR that is capable of achieving visual objectives provided to it by a high level task planner. Typical commands which the task planner might issue to the VSP relate to object recognition, object location determination, and obstacle detection. Upon receiving a command from the task planner, the VSP then plans a sequence of actions to achieve the specified objective using a model-based reasoning approach. This sequence may involve choosing an appropriate sensor, selecting an algorithm to process the data, reorienting the sensor, adjusting the effective resolution of the image using lens zooming capability, and/or requesting the task planner to reposition the EVAR to obtain a different view of the object. An initial version of the Vision System Planner which realizes the above capabilities using simulated images has been implemented and tested. The remaining sections describe the architecture and capabilities of the VSP and its relationship to the high level task planner. In addition, typical plans that are generated to achieve visual goals for various scenarios are discussed. Specific topics to be addressed will include object search strategies, repositioning of the EVAR to improve the quality of information obtained from the sensors, and complementary usage of the sensors and redundant capabilities.

Magee, Michael↗

STS-41 Space Shuttle mission report

The STS-41 Space Shuttle Program Mission Report contains a summary of the vehicle subsystem activities on this thirty-sixth flight of the Space Shuttle and the eleventh flight of the Orbiter vehicle, Discovery (OV-103). In addition to the Discovery vehicle, the flight vehicle consisted of an External Tank (ET) (designated as ET-39/LWT-32), three Space Shuttle main engines (SSME's) (serial numbers 2011, 2031, and 2107), and two Solid Rocket Boosters (SRB's), designated as BI-040. The primary objective of the STS-41 mission was to successfully deploy the Ulysses/inertial upper stage (IUS)/payload assist module (PAM-S) spacecraft. The secondary objectives were to perform all operations necessary to support the requirements of the Shuttle Backscatter Ultraviolet (SSBUV) Spectrometer, Solid Surface Combustion Experiment (SSCE), Space Life Sciences Training Program Chromosome and Plant Cell Division in Space (CHROMEX), Voice Command System (VCS), Physiological Systems Experiment (PSE), Radiation Monitoring Experiment - 3 (RME-3), Investigations into Polymer Membrane Processing (IPMP), Air Force Maui Optical Calibration Test (AMOS), and Intelsat Solar Array Coupon (ISAC) payloads. The sequence of events for this mission is shown in tabular form. Summarized are the significant problems that occurred in the Orbiter subsystems during the mission. The official problem tracking list is presented. In addition, each Orbiter problem is cited in the subsystem discussion.

Camp, David W.↗

Learning reference governor for cycle-to-cycle combustion control with misfire avoidance in spark-ignition engines at high exhaust gas recirculation–diluted conditions

Cycle-to-cycle feedback control is employed to achieve optimal combustion phasing while maintaining high levels of exhaust gas recirculation by adjusting the spark advance and the exhaust gas recirculation valve position. The control development is based on a control-oriented model that captures the effects of throttle position, exhaust gas recirculation valve position, and spark timing on the combustion phasing. Under the assumption that in-cylinder pressure information is available, an adaptive extended Kalman filter approach is used to estimate the exhaust gas recirculation rate into the intake manifold based on combustion phasing measurements. The estimation algorithm is adaptive since the cycle-to-cycle combustion variability (output covariance) is not known a priori and changes with operating conditions. A linear quadratic regulator controller is designed to maintain optimal combustion phasing while maximizing exhaust gas recirculation levels during load transients coming from throttle tip-in and tip-out commands from the driver. During throttle tip-outs, however, a combination of a high exhaust gas recirculation rate and an overly advanced spark, product of the dynamic response of the system, generates a sequence of misfire events. In this work, an explicit reference governor is used as an add-on scheme to the closed-loop system in order to avoid the violation of the misfire limit. The reference governor is enhanced with model-free learning which enables it to avoid misfires after a learning phase. Experimental results are reported which illustrate the potential of the proposed control strategy for achieving an optimal combustion process during highly diluted conditions for improving fuel efficiency.

42 ENGINEERING↗

Power system interface and umbilical system study

System requirements and basic design criteria were defined for berthing or docking a payload to the 25 kW power module which will provide electrical power and attitude control, cooling, data transfer, and communication services to free-flying and Orbiter sortie payloads. The selected umbilical system concept consists of four assemblies and command and display equipment to be installed at the Orbiter payload specialist station: (1) a movable platen assembly which is attached to the power system with EVA operable devices; (2) a slave platen assembly which is attached to the payload with EVA operable devices; (3) a fixed secondary platen permanently installed in the power system; and (4) a fixed secondary platen permanently installed on the payload. Operating modes and sequences are described.

Source record↗

Integrated Planning for Telepresence with Time Delays

Teleoperation of remote robotic systems over time delays in the range of 2-10 seconds poses a unique set of challenges. In the context of a supervisory control system for the JSC Robonaut humanoid robot, we have developed an 'intelligent assistant' that integrates an Artificial Intelligence planner (JSHOP2) with execution monitoring of the state of both the human supervisor and the remote robot. The assistant reasons simultaneously about the world state on both sides of the time delay, which represents a novel application of this technology. The purpose of the assistant is to provide advice to the human supervisor about current and future activities, derived from a sequence of high-level goals to be achieved. To do this, the assistant must simultaneously monitor and react to various data sources, including actions taken by the supervisor who is issuing commands to the robot (e.g. with a data glove), actions taken by the robot, and the environment of the robot, both as currently perceived over the time delay, along with the current sequence of goals. We have developed a 'leader/follower' software architecture to handle the dual time-shifted streams of execution feedback. In this paper we describe the integrated planner and its executive, and how it operates in normal and anomaly situations.

remote robotic systems↗

Injecting Errors for Testing Built-In Test Software

Two algorithms have been conceived to enable automated, thorough testing of Built-in test (BIT) software. The first algorithm applies to BIT routines that define pass/fail criteria based on values of data read from such hardware devices as memories, input ports, or registers. This algorithm simulates effects of errors in a device under test by (1) intercepting data from the device and (2) performing AND operations between the data and the data mask specific to the device. This operation yields values not expected by the BIT routine. This algorithm entails very small, permanent instrumentation of the software under test (SUT) for performing the AND operations. The second algorithm applies to BIT programs that provide services to users application programs via commands or callable interfaces and requires a capability for test-driver software to read and write the memory used in execution of the SUT. This algorithm identifies all SUT code execution addresses where errors are to be injected, then temporarily replaces the code at those addresses with small test code sequences to inject latent severe errors, then determines whether, as desired, the SUT detects the errors and recovers

Gender, Thomas K.↗