Search NASA⌕ Search

SEARCH · Search NASA

Results for “spacecraft commanding”

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 181 records · Page 10
All sourcesNASA NTRSDOE OSTI
NASA NTRS2012

Rapid Diagnostics of Onboard Sequences

Keeping track of sequences onboard a spacecraft is challenging. When reviewing Event Verification Records (EVRs) of sequence executions on the Mars Exploration Rover (MER), operators often found themselves wondering which version of a named sequence the EVR corresponded to. The lack of this information drastically impacts the operators diagnostic capabilities as well as their situational awareness with respect to the commands the spacecraft has executed, since the EVRs do not provide argument values or explanatory comments. Having this information immediately available can be instrumental in diagnosing critical events and can significantly enhance the overall safety of the spacecraft. This software provides auditing capability that can eliminate that uncertainty while diagnosing critical conditions. Furthermore, the Restful interface provides a simple way for sequencing tools to automatically retrieve binary compiled sequence SCMFs (Space Command Message Files) on demand. It also enables developers to change the underlying database, while maintaining the same interface to the existing applications. The logging capabilities are also beneficial to operators when they are trying to recall how they solved a similar problem many days ago: this software enables automatic recovery of SCMF and RML (Robot Markup Language) sequence files directly from the command EVRs, eliminating the need for people to find and validate the corresponding sequences. To address the lack of auditing capability for sequences onboard a spacecraft during earlier missions, extensive logging support was added on the Mars Science Laboratory (MSL) sequencing server. This server is responsible for generating all MSL binary SCMFs from RML input sequences. The sequencing server logs every SCMF it generates into a MySQL database, as well as the high-level RML file and dictionary name inputs used to create the SCMF. The SCMF is then indexed by a hash value that is automatically included in all command EVRs by the onboard flight software. Second, both the binary SCMF result and the RML input file can be retrieved simply by specifying the hash to a Restful web interface. This interface enables command line tools as well as large sophisticated programs to download the SCMF and RMLs on-demand from the database, enabling a vast array of tools to be built on top of it. One such command line tool can retrieve and display RML files, or annotate a list of EVRs by interleaving them with the original sequence commands. This software has been integrated with the MSL sequencing pipeline where it will serve sequences useful in diagnostics, debugging, and situational awareness throughout the mission.

Starbird, Thomas W.↗
NASA NTRS2006

Lessons Learned from Daily Uplink Operations during the Deep Impact Mission

The Deep Impact mission to comet Tempel-1 produced some of the more spectacular science results ever collected by a spacecraft. On July 4, 2005 the Deep Impact Flyby vehicle observed the Deep Impact Impactor vehicle's collision with the comet. 24 hours earlier the Flyby vehicle released the Impactor vehicle into the path of comet Tempel-1. The process to command the spacecraft was a challenge to the entire flight operations team. This paper presents an overview of the process used prepare command products for uplink and the lessons that were learned from this process.

mission operations↗
NASA NTRS1965

The Relay spacecraft

Structure, power, communications, telemetry, tracking, and command for Relay I spacecraft

COMMAND SYSTEM↗
NASA NTRS2005

Data visualization for effective rover sequencing

The Rover Sequencing and Visualization Program is a suite of toos for the commanding of planetary rovers which are subject to significant light time delay and thus are unsuitable for tele-operation.

surface operations↗
NASA NTRS1972

Apollo experience report: Thermal protection from engine-plume environments

Portions of the combined Apollo spacecraft (the command and service module and the lunar module) are subjected to the impingement of hot exhaust gases from the various propulsion systems of the modules. The configurations of the vehicles and the sources of impinging engine plumes are described. A typical Apollo mission is outlined. Protection and design-verification methods are discussed. Finally, recommendations are made for future spacecraft programs.

Taylor, J. T.↗
NASA NTRS1972

Application of an onboard processor to the OAO C spacecraft

The design of a stored program computer for spacecraft use and its application on the fourth Orbiting Astronomical Observatory (OAO) is reported. The computer is a medium scale, parallel machine with a memory capacity of 16384 words of 18 bits each. It possesses a comprehensive instruction repertoire and operates on 45 W of power (including the dc-to-dc converter). The machine operates at a 500-kHz rate and executes an add instruction in 10 microseconds. Its primary functions on OAO C will be auxiliary command storage, spacecraft monitoring and malfunction reporting, data compression and status summary, and possible performance of emergency corrective action for certain anomalous situations.

Stewart, W. N.↗
NASA NTRSDate not supplied

TECHEDSAT-7 and 10: The Little Spacecraft That Could

The NOW (Nanosatellite Orbital Workshop) of NASA Ames Research Center (ARC) has two cubesats in orbit at this time: 6 U TechEdSat-10 (T-10) and the 3U TechEdSat-7 (T-7). T10 was jettisoned from the ISS via the NANORACKS system 7/13/2020, and T-7 was launched via Virgin Orbit 1/17/2021. Both were built by the Nano-satellite Orbital Workshop (NOW) at NASA ARC, and designed and fabricated by interns and students in collaboration with educational institutions. Prototyping novel technologies for non-powered re-entry and communications from orbit are primary research interests, however all subsystems including power generation and distribution, subsystem control, navigation, positioning, heat management etc. extend current technologies. Use of distributed processors using open software platforms and standards other based technologies and software is integral to all segments of spacecraft design. Here, we will present an overview of the spacecraft, experiments, and accomplishments – as well as the next three flight experiments. Some of these experiments include: The exo-brake re-entry system is being developed to enable sample return and end of life disposal; Internal communications for sensors, inter-subsystem and experiments uses both a Zigbee based PAN and internal Wi-Fi for high-speed inter-device communications; The Iridium small message LEO system (Short Burst Data) is used to both command the spacecraft and send data to the ground; Experimental use of the Global-Star system for L-band system comparison and back-up; Collaborative NOAA an experiment to communicate from LEO to the GOES geostationary satellite using the DCS (Data Collection System) with on-board Doppler correction; Mars and Lunar experimental communication systems for future cis-lunar and interplanetary nano-satellites; First demonstration of the NASA Near Earth Network systems with nano-satellites at NASA/Wallops Island; Solar array design and implementation for unique future flexible structures; Power distribution using Tardigrade rad-hard processor omni-board (designed by the team); Distributed processors with internal Wi-Fi connectivity; and Initial experiments with AI/Machine Learning.

M Murbach↗
NASA NTRS1998

Mission Operations with an Autonomous Agent

The Remote Agent (RA) is an Artificial Intelligence (AI) system which automates some of the tasks normally reserved for human mission operators and performs these tasks autonomously on-board the spacecraft. These tasks include activity generation, sequencing, spacecraft analysis, and failure recovery. The RA will be demonstrated as a flight experiment on Deep Space One (DSI), the first deep space mission of the NASA's New Millennium Program (NMP). As we moved from prototyping into actual flight code development and teamed with ground operators, we made several major extensions to the RA architecture to address the broader operational context in which PA would be used. These extensions support ground operators and the RA sharing a long-range mission profile with facilities for asynchronous ground updates; support ground operators monitoring and commanding the spacecraft at multiple levels of detail simultaneously; and enable ground operators to provide additional knowledge to the RA, such as parameter updates, model updates, and diagnostic information, without interfering with the activities of the RA or leaving the system in an inconsistent state. The resulting architecture supports incremental autonomy, in which a basic agent can be delivered early and then used in an increasingly autonomous manner over the lifetime of the mission. It also supports variable autonomy, as it enables ground operators to benefit from autonomy when L'@ey want it, but does not inhibit them from obtaining a detailed understanding and exercising tighter control when necessary. These issues are critical to the successful development and operation of autonomous spacecraft.

Pell, Barney↗
NASA NTRS2005

Multi-Mission System Architecture Platform: Design and Verification of the Remote Engineering Unit

The Multi-Mission System Architecture Platform (MSAP) represents an effort to bolster efficiency in the spacecraft design process. By incorporating essential spacecraft functionality into a modular, expandable system, the MSAP provides a foundation on which future spacecraft missions can be developed. Once completed, the MSAP will provide support for missions with varying objectives, while maintaining a level of standardization that will minimize redesign of general system components. One subsystem of the MSAP, the Remote Engineering Unit (REU), functions by gathering engineering telemetry from strategic points on the spacecraft and providing these measurements to the spacecraft's Command and Data Handling (C&DH) subsystem. Before the MSAP Project reaches completion, all hardware, including the REU, must be verified. However, the speed and complexity of the REU circuitry rules out the possibility of physical prototyping. Instead, the MSAP hardware is designed and verified using the Verilog Hardware Definition Language (HDL). An increasingly popular means of digital design, HDL programming provides a level of abstraction, which allows the designer to focus on functionality while logic synthesis tools take care of gate-level design and optimization. As verification of the REU proceeds, errors are quickly remedied, preventing costly changes during hardware validation. After undergoing the careful, iterative processes of verification and validation, the REU and MSAP will prove their readiness for use in a multitude of spacecraft missions.

Sartori, John↗
NASA NTRS2008

NASA Tech Briefs, August 2008

Customizable Digital Receivers for Radar Two-Camera Acquisition and Tracking of a Flying Target Visual Data Analysis for Satellites A Data Type for Efficient Representation of Other Data Types Hand-Held Ultrasonic Instrument for Reading Matrix Symbols Broadband Microstrip-to-Coplanar Strip Double-Y Balun A Topographical Lidar System for Terrain-Relative Navigation Programmable Low-Voltage Circuit Breaker and Tester Electronic Switch Arrays for Managing Microbattery Arrays Topics covered include: Lower-Dark-Current, Higher-Blue-Response CMOS Imagers; Fabricating Large-Area Sheets of Single-Layer Graphene by CVD; Support for Diagnosis of Custom Computer Hardware; Providing Goal-Based Autonomy for Commanding a Spacecraft; Dynamic Method for Identifying Collected Sample Mass; Optimal Planning and Problem-Solving; Attitude-Control Algorithm for Minimizing Maneuver Execution Errors; Grants Document-Generation System; Heat-Storage Modules Containing LiNO3 3H2O and Graphite Foam; Precipitation-Strengthened, High-Temperature, High-Force Shape Memory Alloys; Improved Relief Valve Would Be Less Susceptible to Failure; Safety Modification of Cam-and-Groove Hose Coupling; Using Composite Materials in a Cryogenic Pump; Using Electronic Noses to Detect Tumors During Neurosurgery; Producing Newborn Synchronous Mammalian Cells; Smaller, Lower-Power Fast-Neutron Scintillation Detectors; Rotationally Vibrating Electric-Field Mill; Estimating Hardness from the USDC Tool-Bit Temperature Rise; Particle-Charge Spectrometer; Automated Production of Movies on a Cluster of Computers; FIDO-Class Development Rover; and Tone-Based Command of Deep Space Probes Using Ground Antennas.

Source record↗
NASA NTRS1995

Mode Transitions in Glass Cockpit Aircraft: Results of a Field Study

One consequence of increased levels of automation in complex control systems is the presence of modes. A mode is a particular configuration of a control system that defines how human command inputs are interpreted. In complex systems, modes also often determine a specific allocation of control authority between the human and automated systems. Even in simple static devices (e.g., electronic watches, word processors), the presence of modes has been found to cause problems in either-the acquisition or production of skilled performance. Many of these problems arise due to the fact that the selection of a mode causes device behavior to be mediated by hidden internal state information. For these simple systems, many of these interaction problems can be solved by the design of appropriate feedback to communicate internal state information to the human operator. In complex dynamic systems, however, the design issues associated with modes seem to trancend the problem of merely communicating internal state information via displayed feedback. In complex supervisory control systems (e.g., aircraft, spacecraft, military command and control), a key function of modes is the selection of a particular configuration of control authority between the human operator and automated control systems. One mode may result in full manual control, another may result in a mix of manual and automatic control, while a third may result in full automatic control over the entire system. The human operator selects an appropriate mode as a function of current goals, operating conditions, and operating procedures. Thus, the operator is put in a position of essentially trying to control two coupled dynamic systems: the target system itself, and also a highly complex suite of automation controlling the target system. From a historical perspective, it should probably not come as a surprise that very little information is available to guide the design of mode-oriented control systems. The topic of function allocation (i.e., the proper division of control authority among human and computer) has a long history in human-machine systems research. Although this research has produced some relevant guidelines, a design approach capable of defining appropriate allocations of control function between the human and automation is not yet available. As a result, the function allocation decision itself has been allocated to the operator, to be performed in real-time, in the operation of mode-oriented control systems. A variety of documented aircraft accidents and incidents suggest that the real-time selection and monitoring of control modes is a weak link in the effective operation of complex supervisory control systems. Research in human-machine systems and human-computer interaction has barely scraped the surface of the problem of understanding how operators manage this task.The purpose of this paper is to present the results of a field study which examined how operators manage mode selection in a complex supervisory control system. Data on mode engagements using the Boeing B757/767 auto-flight system were collected during approach and descent into four major airports in the East Coast of the United States. Protocols documenting mode selection, automatic mode changes, pilot actions, quantitative records of flight-path variables, and verbal reports during and after mode engagements were collected by an observer from the jumpseat. Observations were conducted on two typical trips between three airports. Each trip was be replicated 11 times, which yielded a total of 22 trips and 66 legs on which data were collected. All data collected concerned the same flight numbers, and therefore, the same time of day, same type of aircraft, and identical operational environments (e.g., ATC facilities, weather patterns, traffic flow etc.)

Degani, Asaf↗
NASA NTRS2011

Cassini Attitude Control Operations - Guidelines Levied on Science to Extend Reaction Wheel Life

The Cassini spacecraft was launched on October 15, 1997 and arrived at Saturn on June 30, 2004. It has performed detailed observations and remote sensing of Saturn, its rings, and its satellites since that time. Cassini deployed the European-built Huygens probe, which descended through the Titan atmosphere (Saturn's largest moon) and landed on its surface on January 14, 2005. The Cassini mission has recently been approved by NASA to continue through September of 2017. This 7-year extension is called the Solstice mission and it presents challenges to the spacecraft operations team and its ability to maintain the health of the spacecraft. To keep the spacecraft healthy for 7 more years, the spacecraft team must carefully manage hydrazine use (about 48% of the 132 kg launch load remains as of January 2011). A vital part of conserving hydrazine is to use the reaction wheel assembly (RWA) control system for precise pointing and slews wherever possible. In any given week, the Cassini spacecraft is commanded to use RWA control about 99% of the time, with about 1% of the time requiring reaction control system (RCS) thruster control (to perform Delta V course corrections or to bias the RWA momentum). Such extensive use of the RWA hardware throughout the mission requires that the RWAs be operated in a way that minimizes degradation in the RWA electronics, DC motor, and spin bearing for each reaction wheel. Three consumables in particular have been identified for the RWAs: (1) Total number of revolutions for each RWA. (2) Time spent at very low wheel speeds. At these low speeds, good elasto-hydrodynamic (EHD) film lubrication may be compromised. (3) Total number of on/off power cycles. The second of these consumables, minimizing the time spent at very low wheel speeds, is especially important to keep the spin bearing healthy and well-lubricated. These consumables are actively managed by the attitude control operations team throughout the mission. One vital management technique is to predict individual RWA momentum (given the pointing and slews that are needed to collect the best science) and to bias the RWA momentum in a way that reduces both the total number of revolutions as well as the time spent below EHD wheel speed. Another strategy to protect RWA health is to alter the planned pointing of the spacecraft (which can affect science collection) so that the RWA consumables are conserved. This paper focuses on why this second technique is needed, and discusses how guidelines have been developed by the attitude control team which affects the planned science pointing, so that science data can be most optimally collected while still minimizing RWA consumable usage.

interplanetary trajectory↗
NASA NTRS2021

Reducing Risk of InSight Surface Operations Through High-Fidelity Command Sequence Modeling

Simulating spacecraft behavior is crucial for the success of deep space missions, and failure to do so may result in damages to or the loss of the spacecraft. Many previous deep space missions have made use of ground-simulation of sequenced commanding, at speeds far greater than real time, to predict spacecraft state over time through the execution of onboard sequences. This type of modeling can be done at any fidelity, and most missions have opted to decrease fidelity to reduce cost and complexity. However, NASA’s Interior Exploration using Seismic Investigations, Geodesy and Heat Transport (InSight) mission expanded the scope of ground modeling considerably, which has led to numerous benefits over past implementations. This paper will discuss the process and products that InSight created, as well as the lessons learned from successfully operating the spacecraft on Mars. InSight is the first JPL mission to expand the scope of ground modeling to include the uplink of files from Earth to the spacecraft, rather than making the simplification that any command sequences already exist onboard the spacecraft. The advantages of modeling the uplink of files are numerous. First, it allows for accurate modeling of the onboard filesystem of the spacecraft at all points in time, meaning that all file loads and deletions throughout the mission are modeled at the exact moment they are predicted to actually happen. Second, operators can be more certain that dependencies between sequences are not broken due to the dynamic nature of the filesystem as files are deleted, copied, and uplinked. Lastly, spacecraft filesystem tracking allows for management of sequences prior to uplink, limiting the uplink to only new sequences. The onboard filesystem model became crucial to mission success, emphasizing the importance of investing in accurate models before the need for them arises. During daily tactical operations of a spacecraft on Mars, a model is only useful if the results can be interpreted quickly. In this fast-paced environment, it is essential that command products are modeled and reviewed, errors are found and diagnosed, and new command products are redelivered, remodeled, re-reviewed in a timely manner. It is impossible to review the entire model and therefore the results of the model must be condensed and presented in a fashion that is intuitive, easy-to-navigate, complete, and trustworthy. InSight developed a number of innovative sequence review products that are designed to provide operators with the information required to quickly assess the validity of command products and diagnose potential issues. Together, these products provide a complete, yet succinct picture of the command and sequence model to the operators and facilitate a quick assessment of all sequence command products. This paper will cover planning and sequencing innovations made during InSight surface operations, and will compare the tools, processes, and results to those on other missions. Additionally, the paper will cover the flexible, yet robust nature of the planning and sequencing system architecture and how that flexibility allowed for rapid development and response to the unpredictability of Mars.

Cloutier, Kyle↗
NASA NTRS1973

Atmosphere Explorer control system software (version 2.0)

The Atmosphere Explorer Control System (AECS) was developed to provide automatic computer control of the Atmosphere Explorer spacecraft and experiments. The software performs several vital functions, such as issuing commands to the spacecraft and experiments, receiving and processing telemetry data, and allowing for extensive data processing by experiment analysis programs. The AECS was written for a 48K XEROX Data System Sigma 5 computer, and coexists in core with the XDS Real-time Batch Monitor (RBM) executive system. RBM is a flexible operating system designed for a real-time foreground/background environment, and hence is ideally suited for this application. Existing capabilities of RBM have been used as much as possible by AECS to minimize programming redundancy. The most important functions of the AECS are to send commands to the spacecraft and experiments, and to receive, process, and display telemetry data.

Mocarsky, W.↗
NASA NTRS1969

An on-board processor for OAO-C.

Spaceborne stored program computer design for OAO-C, noting auxiliary command storage, spacecraft monitoring and malfunction reporting, etc

Hartenstein, R.↗
NASA NTRS1972

An On Board Processor (OBP) for OAO C

A stored program computer and its application on OAO is considered. The parallel computer has a memory capacity of 16,384 words of 18 bits each, one central processor unit, two 4096 word memory units, and one input/output unit. The I/O has no direct data connection with the CPU so that all data flow between these two units must pass through memory by way of the memory data bus. The primary functions of the onboard computer are auxiliary command storage, spacecraft monitoring and malfunction reporting, data compression and status summary, and possible performance of emergency corrective action.

Hartenstein, R. G.↗