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 397 records · Page 22
All sourcesNASA NTRSDOE OSTI
NASA NTRS2017

Key Differences in Operating a Rover on the Moon vs. Mars

The command and control model for spacecraft operations, as well as the distribution of tasks between ground assets and in space assets, whether with a crew or solely robotic, is fundamentally constrained by the round trip light time between the space asset and the control facility (presumably on Earth, though not required). For an asset on Mars, the round trip light time varies, from roughly fourteen minutes to up to forty minutes. For a Lunar asset the round-trip light time is measured in only a few seconds, but current communications systems may more than double the latency with system overhead. For a Lunar Asset the total command latency may range from six seconds to more than forty, depending on communications overhead and data rates. Further, these variables are not always predictable, thus complicating operations. There are several differentiating factors for Lunar vs. Mars operations, Round trip light time/Atmosphere/Lighting and ShadowsTerrain type and knowledge/Round trip light time has implications for the distribution of tasks between ground and in space assets. Even at Lunar Distances, the combination of round trip light time plus communications systems overhead does not enable joy stick driving of a rover. The best that can be done, if driving from Earth, is near real time command and control. By 2030, driving from in space may be possible. Productivity on Mars requires either long operational sequences of commands, as is done for current rovers such as Curiosity, significant autonomous capability or, as may be possible by 2030, command and control support from space. Another implication of the long round trip light time from Earth to Mars, is that flight software functions must be resident on the in space asset. On the Moon, there is considerably more flexibility, enabling processing functions, to be resident on Earth or in space. This provides the opportunity to take advantage of the considerable processing power available on the ground, but may be constrained by data rates. On the Moon, for practical operational purposes, there is no atmosphere. Hence there is no scattering of light in the shadows. This has implications for image interpretation and driving near the poles. The Moon has permanently shadowed regions (PSR), unique terrain with unknown surface properties. With no scattering of light in shadows, driving on the Moon, particularly at the poles, where we have strong evidence of water, may prove to be hazardous and complex, requiring non-optical sensors, such as LIDAR.

Trimble, Jay↗
NASA NTRS2002

Timekeeping for the Space Technology 5 (ST-5) Mission

Space Technology 5, or better known as ST-5, is a space technology development mission in the New Millennium Program (NMP) and NASA s first experiment in the design of miniaturized satellite constellations. The mission will design, integrate and launch multiple spacecraft into an orbit high above the Earth s protective magnetic field known as the magnetosphere. Each spacecraft incorporates innovative technology and constellation concepts which will be instrumental in future space science missions. A total of three ST-5 spacecraft will be launched as secondary payloads into a highly elliptical geo-synchronous transfer orbit, and will operate as a 3-element constellation for a minimum duration of 90 days. In order to correlate the time of science measurements with orbit position relative to the Earth, orbit position in space (with respect to other objects in space) and/or with events measured on Earth or other spacecraft, accurate knowledge of spacecraft and ground time is needed. Ground time as used in the USA (known as Universal Time Coordinated or UTC) is maintained by the U.S. Naval Observatory. Spacecraft time is maintained onboard within the Command and Data Handling (C&DH) system. The science requirements for ST-5 are that spacecraft time and ground time be correlatable to each other, with some degree of accuracy. Accurate knowledge of UTC time on a spacecraft is required so that science measurements can be correlated with orbit position relative to the Earth, orbit position in space and with events measured on Earth or other spacecraft. The most crucial parameter is not the clock oscillator frequency, but more importantly, how the clock oscillator frequency varies with time or temperature (clock oscillator drift). Even with an incorrect clock oscillator frequency, if there were no drift, the frequency could be assessed by comparing the spacecraft clock to a ground clock during a few correlation events. Once the frequency is accurately known, it is easy enough to make a regular adjustment to the spacecraft clock or to calculate the correct ground time for a given spacecraft clock time. The oscillator frequency, however, is temperature dependent, drifts with age and is affected by radiation; hence, repeated correlation measurements are required.

Raphael, Dave↗
NASA NTRS2012

Modular, Autonomous Command and Data Handling Software with Built-In Simulation and Test

The spacecraft system that plays the greatest role throughout the program lifecycle is the Command and Data Handling System (C&DH), along with the associated algorithms and software. The C&DH takes on this role as cost driver because it is the brains of the spacecraft and is the element of the system that is primarily responsible for the integration and interoperability of all spacecraft subsystems. During design and development, many activities associated with mission design, system engineering, and subsystem development result in products that are directly supported by the C&DH, such as interfaces, algorithms, flight software (FSW), and parameter sets. A modular system architecture has been developed that provides a means for rapid spacecraft assembly, test, and integration. This modular C&DH software architecture, which can be targeted and adapted to a wide variety of spacecraft architectures, payloads, and mission requirements, eliminates the current practice of rewriting the spacecraft software and test environment for every mission. This software allows missionspecific software and algorithms to be rapidly integrated and tested, significantly decreasing time involved in the software development cycle. Additionally, the FSW includes an Onboard Dynamic Simulation System (ODySSy) that allows the C&DH software to support rapid integration and test. With this solution, the C&DH software capabilities will encompass all phases of the spacecraft lifecycle. ODySSy is an on-board simulation capability built directly into the FSW that provides dynamic built-in test capabilities as soon as the FSW image is loaded onto the processor. It includes a six-degrees- of-freedom, high-fidelity simulation that allows complete closed-loop and hardware-in-the-loop testing of a spacecraft in a ground processing environment without any additional external stimuli. ODySSy can intercept and modify sensor inputs using mathematical sensor models, and can intercept and respond to actuator commands. ODySSy integration is unique in that it allows testing of actual mission sequences on the flight vehicle while the spacecraft is in various stages of assembly, test, and launch operations all without any external support equipment or simulators. The ODySSy component of the FSW significantly decreases the time required for integration and test by providing an automated, standardized, and modular approach to integrated avionics and component interface and functional verification. ODySSy further provides the capability for on-orbit support in the form of autonomous mission planning and fault protection.

Cuseo, John↗
NASA NTRS1977

Conceptual definition of Automated Power Systems Management

Automated Power Systems Management (APSM) is defined as the capability of a spacecraft power system to automatically perform monitoring, computational, command, and control functions without ground intervention. Power systems for future planetary spacecraft must have this capability because they must perform up to 10 years, and accommodate real-time changes in mission execution autonomously. Specific APSM functions include fault detection, isolation, and correction; system performance and load profile prediction; power system optimization; system checkout; and data storage and transmission control. This paper describes the basic method of implementing these specific functions. The APSM hardware includes a central power system computer and a processor dedicated to each major power system subassembly along with digital interface circuitry. The major payoffs anticipated are in enhancement of spacecraft reliability and life and reduction of overall spacecraft program cost.

Imamura, M. S.↗
NASA NTRS1998

An Object-Oriented Interface to the CCSDS Ground Telecommand Services

The Telecommand Data Routing and Channel Services defined by the Consultative Committee for Space Data Systems (CCSDS) are flexible enough to support a myriad of commanding models. Because the standard is so broad, the traditional approach has been to implement only the portion of the standard needed by the particular spacecraft being tested/operated. Tasked with providing Telecommand Services for an entire class of spacecraft, where each spacecraft may choose any valid CCSDS commanding model, NASA Code 584 designed a common architecture capable of handling the full CCSDS protocol. The solution uses another CCSDS standard - the Standard Formatted Data Unit (SFDU) as the interface to the Telecommand Services. SFDUs provide a consistent way of labelling data objects, as well as allowing data objects to encapsulate other data objects. The resulting interface is: - Flexible: The full Data Routing and Channel Services are available via a single interface. The client (i.e. the command source) may enter commands at any layer within the protocol stack, specify any of the data aggregation or segmentation methods, and dynamically set any configuration parameter defined in the standard. - Object-oriented: Each object specifies both the data and the actions to be performed with the data. An object may contain other objects. - Expandable: New capabilities are added by defining new objects. Objects pass thru the protocol layers until they reach the applicable layer. The resulting design is: - Modular: The logic for each protocol layer is contained in a separate Application Program Interface (API). The objects used for the external interface are also used for communication between layers. - Distributable: The design can be split along any layer boundary for distribution across multiple machines. The objects ensure data consistency across platforms. This paper describes the SFDU-based interface and the resulting protocol implementation. The implementation is currently used by NASA (National Aeronautics and Space Administration) for integration & test of the microwave Anisotropy Probe (MAP) and Earth observer-I (EO-l) spacecraft. It will be used for post-launch operations of these spacecraft as well as the Imager for Magnetopause to Aurora Global Exploration (IMAGE) spacecraft.

Ray, Timothy Joseph↗
NASA NTRS2012

Avoiding Human Error in Mission Operations: Cassini Flight Experience

Operating spacecraft is a never-ending challenge and the risk of human error is ever- present. Many missions have been significantly affected by human error on the part of ground controllers. The Cassini mission at Saturn has not been immune to human error, but Cassini operations engineers use tools and follow processes that find and correct most human errors before they reach the spacecraft. What is needed are skilled engineers with good technical knowledge, good interpersonal communications, quality ground software, regular peer reviews, up-to-date procedures, as well as careful attention to detail and the discipline to test and verify all commands that will be sent to the spacecraft. Two areas of special concern are changes to flight software and response to in-flight anomalies. The Cassini team has a lot of practical experience in all these areas and they have found that well-trained engineers with good tools who follow clear procedures can catch most errors before they get into command sequences to be sent to the spacecraft. Finally, having a robust and fault-tolerant spacecraft that allows ground controllers excellent visibility of its condition is the most important way to ensure human error does not compromise the mission.

guidance and control↗
NASA NTRS2020

A Flight Rule Checker for the LADEE Lunar Spacecraft

As part of the design of a space mission, an important part is the design of so-called flight rules. Flight rules express constraints on various parts and processes of the mission, that if followed, will reduce the risk of failure. One such set of flight rules constrain the format of command sequences regularly (e.g. daily) sent to the spacecraft to con- trol its next near term behavior. We present a high-level view of the automated flight rule checker Frc for checking command sequences sent to NASA’s LADEE Lunar mission spacecraft, used throughout its entire mission. A command sequence is in this case essentially a program (a sequence of commands) with no loops or conditionals, and it can there- fore be verified with a trace analysis tool. Frc is implemented using the TraceContract runtime verification tool, an internal Scala DSL for checking event sequences against “formal specifications”. The paper illustrates this untraditional use of runtime verification in a real con- text, with strong demands on the expressiveness and flexibility of the specification language, illustrating the advantages of an internal DSL.

Kurklu, Elif↗
NASA NTRS1974

Applications Technology Satellite ATS-6 in orbit checkout report

The activities of the ATS-6 spacecraft for the checkout period of approximately four weeks beginning May 30, 1974 are described, along with the results of a performance evaluation of its subsystems and components. The following specific items are discussed: (1) subsystem requirements/specifications and in-orbit performance summary; (2) flight chronology; (3) spacecraft description; (4) structural/deployment subsystems; (5) electrical power subsystem; (6) thermal control subsystem; (7) telemetry and command subsystems; (8) attitude control subsystem; (9) spacecraft propulsion subsystem; (10) communication subsystem; and (12) experiment subsystem.

Moore, W.↗
NASA NTRS1976

Tracking and data systems support for the Helios project. Volume 1: Project development through end of mission, phase 2

The overall evolution of the Helios Project is summarized from its conception through to the completion of the Helios-1 mission phase 2. Beginning with the project objectives and concluding with the Helios-1 spacecraft entering its first superior conjunction (end of mission phase 2), descriptions of the project, the mission and its phases, international management and interfaces, and Deep Space Network-spacecraft engineering development in telemetry, tracking, and command systems to ensure compatibility between the U.S. Deep Space Network and the German-built spacecraft are included.

Goodwin, P. S.↗
NASA NTRS2020

A Flight Rule Checker for the LADEE Lunar Spacecraft

As part of the design of a space mission, an important part is the design of so-called flight rules. Flight rules express constraints on various parts and processes of the mission, that if followed, will reduce the risk of failure. One such set of flight rules constrain the format of command sequences regularly (e.g. daily) sent to the spacecraft to con-trol its next near term behavior. We present a high-level view of the automated flight rule checker FRC for checking command sequences sent to NASA’s LADEE Lunar mission spacecraft, used throughout its entire mission. A command sequence is in this case essentially a program (a sequence of commands) with no loops or conditionals, and it can there-fore be verified with a trace analysis tool. FRC is implemented using the TraceContract runtime verification tool, an internal Scala DSL for checking event sequences against “formal specifications”. The paper illustrates this untraditional use of runtime verification in a real con-text, with strong demands on the expressiveness and flexibility of the specification language, illustrating the advantages of an internal DSL.

LADEE↗
NASA NTRS2012

Compact Autonomous Hemispheric Vision System

Solar System Exploration camera implementations to date have involved either single cameras with wide field-of-view (FOV) and consequently coarser spatial resolution, cameras on a movable mast, or single cameras necessitating rotation of the host vehicle to afford visibility outside a relatively narrow FOV. These cameras require detailed commanding from the ground or separate onboard computers to operate properly, and are incapable of making decisions based on image content that control pointing and downlink strategy. For color, a filter wheel having selectable positions was often added, which added moving parts, size, mass, power, and reduced reliability. A system was developed based on a general-purpose miniature visible-light camera using advanced CMOS (complementary metal oxide semiconductor) imager technology. The baseline camera has a 92 FOV and six cameras are arranged in an angled-up carousel fashion, with FOV overlaps such that the system has a 360 FOV (azimuth). A seventh camera, also with a FOV of 92 , is installed normal to the plane of the other 6 cameras giving the system a > 90 FOV in elevation and completing the hemispheric vision system. A central unit houses the common electronics box (CEB) controlling the system (power conversion, data processing, memory, and control software). Stereo is achieved by adding a second system on a baseline, and color is achieved by stacking two more systems (for a total of three, each system equipped with its own filter.) Two connectors on the bottom of the CEB provide a connection to a carrier (rover, spacecraft, balloon, etc.) for telemetry, commands, and power. This system has no moving parts. The system's onboard software (SW) supports autonomous operations such as pattern recognition and tracking.

Pingree, Paula J.↗
NASA NTRS2017

The Mars Reconnaissance Orbiter Mission: Continuing a Record of Exploration from Mars Orbit

The Mars Reconnaissance Orbiter (MRO) has been on station in its low altitude, sun-synchronous, primary science orbit since September 2006 performing both scientific and Mars programmatic support functions. The spacecraft is a very capable remote sensing science platform carrying six science payloads supporting seven investigations and a UHF telecommunications radio (Electra) for surface relay. Developed to support a mix of nadir mapping and targeted, highresolution surface observations, the spacecraft’s powerful telecommunications and command & data handling (C&DH) subsystems communicate an average of 16 hours a day with the Deep Space Network (DSN). To date, more than 300 TB of scientific data has been returned to Earth. All of the original science payloads are active with standard and new observing modes contributing to the advancement of Mars science through peer-reviewed paper publications and the timely dissemination of their data to the science community as a whole. Results from the science teams have revealed an amazing diversity of ancient aqueous environments and ongoing surface change is evident through gully formation, avalanches, and cratering. Extending the MRO-MGS climate record to a decade of Mars years is contributing to a better understanding of current atmospheric and polar processes. In addition to its fundamental scientific objectives, MRO is a critical element of NASA’s Mars Exploration Program (MEP) providing needed infrastructure support for landed and future missions. Using its Electra telecommunications payload, MRO provides landers and rovers critical event coverage during their entry, descent, and landing (EDL) phases and UHF relay support once they are on the Martian surface. MRO’s high-resolution imagers are used to scout potential landing sites and certify safe zones for landing. As MRO begins its Fourth Extended Mission, the spacecraft remains fully capable of carrying out an ambitious science observing plan and the programmatic tasks assigned to it. In addition to highlighting recent discoveries of the mission, this paper describes recent challenges the spacecraft engineers have faced in flight and the plans for extending spacecraft life well into the 2020’s.

Tamppari, Leslie K.↗
NASA NTRS1991

Nimbus-7

The DSN (Deep Space Network) mission support requirements for Nimbus 7 are summarized. The basic Nimbus series spacecraft is attitude-stabilized in three axes, with the yaw axis always pointing towards the center of the Earth. The spacecraft provides a stable platform, power, command, and data handling support for active and passive sensors for daily global surveillance of the atmosphere, and for mapping details of the atmospheric structure and Earth surface from satellite altitudes. The Nimbus 7 mission objectives are outlined and the DSN support requirements are defined through the presentation of tables and narratives describing the spacecraft flight profile; DSN support coverage; S-band frequency assignments; support parameters for telemetry, command and support systems; and tracking support responsibility.

Foreman, M.↗
NASA NTRS1967

Soil mechanics surface sampler - Lunar surface test and results

After the success of Surveyor I in meeting the objectives of the engineering flight series, selection from among candidate experiments led to the inclusion of the Soil Mechanics Surface Sampler (SMSS) on the payload. Though originally planned for later Surveyors, the SMSS design was modified to fit the reduced telemetry and commanding capability of the earlier spacecraft. These modifications included removal of the strain-, acceleration-, and position-measuring systems originally planned, and incorporation of a means for measuring current drawn by the motors during operation. A description of the modified device, its performance on Surveyor III, and some conclusions regarding the lunar surface material drawn from the experiment are presented.

Ground test↗