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

Mathematical Simulation of Flight Maneuvers

Mathematical model simulates response of spin-stabilized spacecraft to commanded thruster pulses, using set of equations based on known inertial properties of vehicle and previously-determined thrustor performance. Model used to generate sequence of thrustor commands to accomplish specified maneuver.

Frauenholz, R. B.↗

Design considerations for the beamwaveguide retrofit of a ground antenna station

A primary requirement of the NASA Deep Space Network (DSN) is to provide for optimal reception of very low signal levels. This requirement necessitates optimizing the antenna gain to the total system operating noise level quotient. Low overall system noise levels of 16 to 20 K are achieved by using cryogenically cooled preamplifiers closely coupled with an appropriately balanced antenna gain/spillover design. Additionally, high-power transmitters (up to 400 kW CW) are required for spacecraft emergency command and planetary radar experiments. The frequency bands allocated for deep space telemetry are narrow bands near 2.1 and 2.3 GHz (Ka-band), 7.1 and 8.4 GHz (X-band), and 32 and 34.5 GHz (Ka-band). In addition, planned operations for the Search for Extraterrestrial Intelligence (SETI) program require continuous low-noise receive coverage over the 1 to 10 GHz band. To summarize, DSN antennas must operate efficiently with low receive noise and high-power uplink over the 1 to 35 GHz band.

Veruttipong, T.↗

Attitude analysis of the Earth Radiation Budget Satellite (ERBS) yaw turn anomaly

The July 2 Earth Radiation Budget Satellite (ERBS) hydrazine thruster-controlled yaw inversion maneuver resulted in a 2.1 deg/sec attitude spin. This mode continued for 150 minutes until the spacecraft was inertially despun using the hydrazine thrusters. The spacecraft remained in a low-rate Y-axis spin of .06 deg/sec for 3 hours until the B-DOT control mode was activated. After 5 hours in this mode, the spacecraft Y-axis was aligned to the orbit normal, and the spacecraft was commanded to the mission mode of attitude control. This work presents the experience of real-time attitude determination support following analysis using the playback telemetry tape recorded for 7 hours from the start of the attitude control anomaly.

Kronenwetter, J.↗

Magellan space flight operations

This paper describes the Magellan spacecraft designed to collect information from the surface of Venus while orbiting this planet. Special attention is given to the attitude and articulation control of the spacecraft; the command, data, and data storage; the thermal control; and instrumentation. The operations at Venus, which will include Venus orbit insertion and in-orbit checkout and to both routine and nonroutine (at a period when Venus will be in superior conjunction, and the solar plasma will drive Magellan's telecommunications signal-to-noise ratio to a very high value) mapping of the surface, are discussed. Also discussed are operations on earth, carried out by the new Space Flight Operations Control Center.

Doody, Dave↗

The Galileo Tape Recorder Rewind Operation Anomaly

On October 11, 1995, the Galileo spacecraft executed a sequence to record three approach images of Jupiter on the spacecraft's tape recorder, rewind the tape, and play back the images at the appropriate data rate consistent with the downlink performance. The recording of the images was performed and the spacecraft computer commanded the tape recorder to rewind the tape to the beginning of the first image. The rewind command was started at the proper time but the tape never got to the beginning of the image data. The analyses and tests that followed allowed a conclusive determination of the failure mechanism and indicated a strategy that could be used to prevent the untimely demise of the mission.

Johnson, Michael R.↗

Pros and Cons of Using Arrays of Small Antennas Versus Large Single Dish Antennas for the Deep Space Network

This paper briefly describes pros and cons of using arrays of small antennas instead of large single dish antennas for spacecraft telemetry, command, and tracking (TT and C) - communications and navigation (C and N) - and science support that the Deep Space Network (DSN) normally provides. It considers functionality and performance aspects, mainly for TT and C, though it also considers science. It only briefly comments on the cost aspects that seem to favor arrays of small antennas over large single antennas, at least for receiving (downlinks).

Deep Space Network↗

Commanding Constellations (Pipeline Architecture)

Providing ground command software for constellations of spacecraft is a challenging problem. Reliable command delivery requires a feedback loop; for a constellation there will likely be an independent feedback loop for each constellation member. Each command must be sent via the proper Ground Station, which may change from one contact to the next (and may be different for different members). Dynamic configuration of the ground command software is usually required (e.g. directives to configure each member's feedback loop and assign the appropriate Ground Station). For testing purposes, there must be a way to insert command data at any level in the protocol stack. The Pipeline architecture described in this paper can support all these capabilities with a sequence of software modules (the pipeline), and a single self-identifying message format (for all types of command data and configuration directives). The Pipeline architecture is quite simple, yet it can solve some complex problems. The resulting solutions are conceptually simple, and therefore, reliable. They are also modular, and therefore, easy to distribute and extend. We first used the Pipeline architecture to design a CCSDS (Consultative Committee for Space Data Systems) Ground Telecommand system (to command one spacecraft at a time with a fixed Ground Station interface). This pipeline was later extended to include gateways to any of several Ground Stations. The resulting pipeline was then extended to handle a small constellation of spacecraft. The use of the Pipeline architecture allowed us to easily handle the increasing complexity. This paper will describe the Pipeline architecture, show how it was used to solve each of the above commanding situations, and how it can easily be extended to handle larger constellations.

Tim Ray↗

The development and validation of command schedules for SeaWiFS

An automated method for developing and assessing spacecraft and instrument command schedules is presented for the Sea-viewing Wide Field-of-view Sensor (SeaWiFS) project. SeaWiFS is to be carried on the polar-orbiting SeaStar satellite in 1995. The primary goal of the SeaWiFS mission is to provide global ocean chlorophyll concentrations every four days by employing onboard recorders and a twice-a-day data downlink schedule. Global Area Coverage (GAC) data with about 4.5 km resolution will be used to produce the global coverage. Higher resolution (1.1 km resolution) Local Area Coverage (LAC) data will also be recorded to calibrate the sensor. In addition, LAC will be continuously transmitted from the satellite and received by High Resolution Picture Transmission (HRPT) stations. The methods used to generate commands for SeaWiFS employ numerous hierarchical checks as a means of maximizing coverage of the Earth's surface and fulfilling the LAC data requirements. The software code is modularized and written in Fortran with constructs to mirror the pre-defined mission rules. The overall method is specifically developed for low orbit Earth-observing satellites with finite onboard recording capabilities and regularly scheduled data downlinks. Two software packages using the Interactive Data Language (IDL) for graphically displaying and verifying the resultant command decisions are presented. Displays can be generated which show portions of the Earth viewed by the sensor and spacecraft sub-orbital locations during onboard calibration activities. An IDL-based interactive method of selecting and testing LAC targets and calibration activities for command generation is also discussed.

Woodward, Robert H.↗

Pattern Recognition Control Design

Spacecraft control algorithms must know the expected spacecraft response to any command to the available control effectors, such as reaction thrusters or torque devices. Spacecraft control system design approaches have traditionally relied on the estimated vehicle mass properties to determine the desired force and moment, as well as knowledge of the effector performance to efficiently control the spacecraft. A pattern recognition approach can be used to investigate the relationship between the control effector commands and the spacecraft responses. Instead of supplying the approximated vehicle properties and the effector performance characteristics, a database of information relating the effector commands and the desired vehicle response can be used for closed-loop control. A Monte Carlo simulation data set of the spacecraft dynamic response to effector commands can be analyzed to establish the influence a command has on the behavior of the spacecraft. A tool developed at NASA Johnson Space Center (Ref. 1) to analyze flight dynamics Monte Carlo data sets through pattern recognition methods can be used to perform this analysis. Once a comprehensive data set relating spacecraft responses with commands is established, it can be used in place of traditional control laws and gains set. This pattern recognition approach can be compared with traditional control algorithms to determine the potential benefits and uses.

Gambone, Elisabeth↗

Strategies for automatic planning: A collection of ideas

The main goal of the Jet Propulsion Laboratory (JPL) is to obtain science return from interplanetary probes. The uplink process is concerned with communicating commands to a spacecraft in order to achieve science objectives. There are two main parts to the development of the command file which is sent to a spacecraft. First, the activity planning process integrates the science requests for utilization of spacecraft time into a feasible sequence. Then the command generation process converts the sequence into a set of commands. The development of a feasible sequence plan is an expensive and labor intensive process requiring many months of effort. In order to save time and manpower in the uplink process, automation of parts of this process is desired. There is an ongoing effort to develop automatic planning systems. This has met with some success, but has also been informative about the nature of this effort. It is now clear that innovative techniques and state-of-the-art technology will be required in order to produce a system which can provide automatic sequence planning. As part of this effort to develop automatic planning systems, a survey of the literature, looking for known techniques which may be applicable to our work was conducted. Descriptions of and references for these methods are given, together with ideas for applying the techniques to automatic planning.

Collins, Carol↗

Command

The Command System provides the means by which a project controls the activities of its spacecraft from the Earth. An overview of the Multimission Command (MMC) System is presented. The major components within the MMC System are discussed, with emphasis on the telecommunications related implementations. Two versions of the spacecraft command detection system the Viking Heritage command detector and the NASA standard command detector are summarized. The former prevails in the existing flight projects and the latter will likely be adopted by the missions of the near future. The preparation of Design Control Tables for the control of command link performance between Deep Space Stations and the spacecraft is also discussed.

Burow, N. A.↗

Mission Operations Centers (MOCs): Integrating key spacecraft ground data system components

In an environment characterized by decreasing budgets, limited system development time, and user needs for increased capabilities, the Mission Operations Division (MOD) at the National Aeronautics and Space Administration Goddard Space Flight Center initiated a new, cost-effective concept in developing its spacecraft ground data systems: the Mission Operations Center (MOC). In the MOC approach, key components are integrated into a comprehensive and cohesive spacecraft planning, monitoring, command, and control system with a single, state-of-the-art graphical user interface. The MOD is currently implementing MOC's, which feature a common, reusable, and extendable system architecture, to support the X-Ray Timing Explorer (XTE), Tropical Rainfall Measuring Mission (TRMM), and Advanced Composition Explorer (ACE) missions. As a result of the MOC approach, mission operations are integrated, and users can, with a single system, perform real-time health and safety monitoring, real-time command and control, real-time attitude processing, real-time and predictive graphical spacecraft monitoring, trend analysis, mission planning and scheduling, command generation and management, network scheduling, guide star selection, and (using an expert system) spacecraft monitoring and fault isolation. The MOD is also implementing its test and training simulators under the new MOC management structure. This paper describes the MOC concept, the management approaches used in developing MOC systems, the technologies employed and the development process improvement initiatives applied in implementing MOC systems, and the expected benefits to both the user and the mission project in using the MOC approach.

Harbaugh, Randy↗