Search NASA⌕ Search

SEARCH · Search NASA

Results for “COMMAND MODULE”

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 523 records · Page 29
All sourcesNASA NTRSDOE OSTI
NASA NTRS1985

Experiences with a preliminary NICE/SPAR structural analysis system

Development of a new structural analysis system based on the original SPAR finite element code and the NICE system is described. The system is denoted NICE/SPAR. NICE was designed at Lockheed Palo Alto Research Laboratory and contains data management utilities, a command language interpreter, and a command language definition for integrating engineering computational modules. SPAR is a system of programs used for finite element structural analysis developed for NASA by Engineering Information Systems, Inc. It includes many complementary structural analysis and utility functions which communicate through a common database. The work on NICE/SPAR was motivated by requirements for a highly modular and flexible structural analysis system to use as a tool in carrying out research in computational methods and exploring new computer hardware. Analysis examples are presented which demonstrate the benefits gained from a combination of the NICE command language with the SPAR computational modules.

Lotts, C. G.↗
NASA NTRS1987

Introduction to the computational structural mechanics testbed

The Computational Structural Mechanics (CSM) testbed software system based on the SPAR finite element code and the NICE system is described. This software is denoted NICE/SPAR. NICE was developed at Lockheed Palo Alto Research Laboratory and contains data management utilities, a command language interpreter, and a command language definition for integrating engineering computational modules. SPAR is a system of programs used for finite element structural analysis developed for NASA by Lockheed and Engineering Information Systems, Inc. It includes many complementary structural analysis, thermal analysis, utility functions which communicate through a common database. The work on NICE/SPAR was motivated by requirements for a highly modular and flexible structural analysis system to use as a tool in carrying out research in computational methods and exploring computer hardware. Analysis examples are presented which demonstrate the benefits gained from a combination of the NICE command language with a SPAR computational modules.

Lotts, C. G.↗
NASA NTRS1973

VHF command system study

Solutions are provided to specific problems arising in the GSFC VHF-PSK and VHF-FSK Command Systems in support of establishment and maintenance of Data Systems Standards. Signal structures which incorporate transmission on the uplink of a clock along with the PSK or FSK data are considered. Strategies are developed for allocating power between the clock and data, and spectral analyses are performed. Bit error probability and other probabilities pertinent to correct transmission of command messages are calculated. Biphase PCM/PM and PCM/FM are considered as candidate modulation techniques on the telemetry downlink, with application to command verification. Comparative performance of PCM/PM and PSK systems is given special attention, including implementation considerations. Gain in bit error performance due to coding is also considered.

Gee, T. H.↗
NASA NTRS1971

Project: Apollo 15

The 12-day Apollo 15 mission, scheduled for launch on July 26 to carry out the fourth United States manned exploration of the Moon, will: Double the time and extend tenfold the range of lunar surface exploration as compared with earlier missions; Deploy the third in a network of automatic scientific stations; Conduct a new group of experiments in lunar orbit; and Return to Earth a variety of lunar rock and soil samples. Scientists expect the results will greatly increase man's knowledge both of the Moon's history and composition and of the evolution and dynamic interaction of the Sun-Earth system. This is so because the dry, airless, lifeless Moon still bears records of solar radiation and the early years of solar system history that have been erased from Earth. Observations of current lunar events also may increase understanding of similar processes on Earth, such as earthquakes. The Apollo 15 Lunar module will make its descent over the Apennine peaks, one of the highest mountain ranges on the Moon, to land near the rim of the canyon-like Hadley Rille. From this Hadley-Apennine lunar base, between the mountain range and the rille, Commander David R. Scott and Lunar Module Pilot James B. Irwin will explore several kilometers from the lunar module, driving an electric-powered lunar roving vehicle for the first time on the Moon. Scott and Irwin will leave the lunar module for three exploration periods to emplace scientific experiments on the lunar surface and to make detailed geologic investigations of formations in the Apennine foothills, along the Hadley Rille rim, and to other geologic structures. The three previous manned landings were made by Apollo 11 at Tranquillity Base, Apollo 12 in the Ocean of Storms and Apollo 14 at Fra Mauro.

Source record↗
NASA NTRS2005

Intersection-Controller Software Module

An important part of the emergency-vehicle traffic-light-preemption system summarized in the preceding article is a software module executed by a microcontroller in each intersection controller. This module monitors the broadcasts from all nearby participating emergency vehicles and intersections. It gathers the broadcast data pertaining to the positions and velocities of the vehicles and the timing of traffic and pedestrian lights and processes the data into predictions of the future positions of the vehicles. Analyzing the predictions by a combination of proximity tests, map-matching techniques, and statistical calculations designed to minimize the adverse effects of uncertainties in vehicle positions and headings, the module decides whether to preempt and issues the appropriate commands to the traffic lights, pedestrian lights, and electronic warning signs at the intersection. The module also broadcasts its state to all nearby vehicles and intersections. The module is designed to mitigate the effects of missing data and of unpredictable delays in the system. It has been intensively tested and refined so that it fails to warn in very few cases and issues very few false warnings.

Bachelder, Aaron↗
NASA NTRS2012

pyam: Python Implementation of YaM

pyam is a software development framework with tools for facilitating the rapid development of software in a concurrent software development environment. pyam provides solutions for development challenges associated with software reuse, managing multiple software configurations, developing software product lines, and multiple platform development and build management. pyam uses release-early, release-often development cycles to allow developers to integrate their changes incrementally into the system on a continual basis. It facilitates the creation and merging of branches to support the isolated development of immature software to avoid impacting the stability of the development effort. It uses modules and packages to organize and share software across multiple software products, and uses the concepts of link and work modules to reduce sandbox setup times even when the code-base is large. One sidebenefit is the enforcement of a strong module-level encapsulation of a module s functionality and interface. This increases design transparency, system stability, and software reuse. pyam is written in Python and is organized as a set of utilities on top of the open source SVN software version control package. All development software is organized into a collection of modules. pyam packages are defined as sub-collections of the available modules. Developers can set up private sandboxes for module/package development. All module/package development takes place on private SVN branches. High-level pyam commands support the setup, update, and release of modules and packages. Released and pre-built versions of modules are available to developers. Developers can tailor the source/link module mix for their sandboxes so that new sandboxes (even large ones) can be built up easily and quickly by pointing to pre-existing module releases. All inter-module interfaces are publicly exported via links. A minimal, but uniform, convention is used for building modules.

Myint, Steven↗
NASA NTRS1982

Space Shuttle autoland design

The Orbiter Autoland system is activated at 10,000 ft altitude and performs energy control through speedbrake modulation, vertical path tracking with acceleration commands to the pitch control system, lateral path tracking through bank angle commands to the roll control system, and brings the vehicle to main gear touchdown. A nominal 19 degree glide slope is flown down to 2000 ft, followed by a 1.5 deg path to flare and subsequent soft landing. The flight path is similar to that which a pilot would fly, a feature which increases safety factors should manual takeover be necessary during landing maneuvers. A block diagram of the autoland control interfaces is provided, and attention is given to the use of a reference trajectory, the guidance laws, lateral guidance, the speed control system, pitch rate control, and the rollout system. Conditions and instrument indications leading to pilot takeover are outlined.

Tsikalas, G. M.↗
NASA NTRS1987

Design of a reconfigurable modular manipulator system

Using manipulators with a fixed configuration for specific tasks is appropriate when the task requirements are known beforehand. However, in less predictable situations, such as an outdoor construction site or aboard a space station, a manipulator system requires a wide range of capabilities, probably beyond the limitations of a single, fixed-configuration manipulator. To fulfill this need, researchers have been working on a Reconfigurable Modular Manipulator System (RMMS). Researchers have designed and are constructing a prototype RMMS. The prototype currently consists of two joint modules and four link modules. The joints utilize a conventional harmonic drive and torque motor actuator, with a small servo amplifier included in the assembly. A brushless resolver is used to sense the joint position and velocity. For coupling the modules together, a standard electrical connector and V-band clamps for mechanical connection are used, although more sophisticated designs are under way for future versions. The joint design yields an output torque to 50 ft-lbf at joint speeds up to 1 radian/second. The resolver and associated electronics have resolutions of 0.0001 radians, and absolute accuracies of plus or minus 0.001 radians. Manipulators configured from these prototype modules will have maximum reaches in the 0.5 to 2 meter range. The real-time RMMS controller consists of a Motorola 68020 single-board computer which will perform real time servo control and path planning of the manipulator. This single board computer communicates via shared memory with a SUN3 workstation, which serves as a software development system and robot programming environment. Researchers have designed a bus communication network to provide multiplexed communication between the joint modules and the computer controller. The bus supports identification of modules, sensing of joint states, and commands to the joint actuator. This network has sufficient bandwidth to allow servo sampling rates in excess of 500 Hz.

Schmitz, D.↗
NASA NTRS1994

Project Freebird: An orbital transfer vehicle

Freebird is a space-based orbital transfer vehicle designed to repair and deorbit orbital assets. Freebird is based at International Space Station Alpha (ISSA) at an inclination of 51.6 deg and is capable of three types of missions: crewed and teleoperated LEO missions, and extended robotic missions. In a crewed local configuration, the vehicle can visit inclinations between 30.8 deg and 72.4 deg at altitudes close to 390 km. Adding extra fuel tanks extends this range of inclination up to 84.9 deg and down to 18.3 deg. Furthermore, removing the crew module, using the vehicle in a teleoperated manner, and operating with extra fuel tanks allows missions to polar and geosynchronous orbits. To allow for mission flexibility, the vehicle was designed in a semimodular configuration. The major system components include a crew module, a 'smart box' (which contains command, communications, guidance, and navigation equipment), a propulsion pack, extra fuel tanks, and a vehicle storage facility (VSF) for storage purposes. To minimize risk as well as development time and cost, the vehicle was designed using only proven technology or technology which is expected to be flight-qualified in time for the intended launch date of 2002. And, because Freebird carries crew and operates near the space station, it must meet or exceed the NASA reliability standard of 0.994, as well as other standard requirements for such vehicles. The Freebird program was conceived and designed as a way to provide important and currently unavailable satellite repair and replacement services of a value equal to or exceeding operational costs.

Aneses, Carlos A.↗
NASA NTRS2012

Fuel Cell/Electrochemical Cell Voltage Monitor

A concept has been developed for a new fuel cell individual-cell-voltage monitor that can be directly connected to a multi-cell fuel cell stack for direct substack power provisioning. It can also provide voltage isolation for applications in high-voltage fuel cell stacks. The technology consists of basic modules, each with an 8- to 16-cell input electrical measurement connection port. For each basic module, a power input connection would be provided for direct connection to a sub-stack of fuel cells in series within the larger stack. This power connection would allow for module power to be available in the range of 9-15 volts DC. The relatively low voltage differences that the module would encounter from the input electrical measurement connection port, coupled with the fact that the module's operating power is supplied by the same substack voltage input (and so will be at similar voltage), provides for elimination of high-commonmode voltage issues within each module. Within each module, there would be options for analog-to-digital conversion and data transfer schemes. Each module would also include a data-output/communication port. Each of these ports would be required to be either non-electrical (e.g., optically isolated) or electrically isolated. This is necessary to account for the fact that the plurality of modules attached to the stack will normally be at a range of voltages approaching the full range of the fuel cell stack operating voltages. A communications/ data bus could interface with the several basic modules. Options have been identified for command inputs from the spacecraft vehicle controller, and for output-status/data feeds to the vehicle.

Vasquez, Arturo↗
NASA NTRS2020

Artemis Sustained Translational Acceleration Limits: Human Tolerance Evidence from Apollo to ISS

The designers of the next generation of lunar landers may adopt novel, crew-body orientations outside of our flight history or applied to flight durations and environments outside of our experience. Current sustained translational acceleration requirements in NASA-STD-3001 are applicable only to crewmembers in a seated posture and are thus inadequate to address human tolerance in non-seated configurations. Initial designs for the Apollo Lunar Module (LM) included seats for both commander and pilot; however, these were subsequently removed from the vehicle due to mass constraints and a willingness to accept the unknown risks for short-duration missions given the limited human physiologic data at the time. In the years since Apollo, our evidence base has grown immensely. Initial Artemis mission timelines under consideration will be longer than the longest Apollo mission, by a significant margin, with timeframes more analogous to longer Space Shuttle missions. Given the incidence of postflight orthostatic intolerance following shuttle missions, a significant risk may exist for lander design(s) pursuing a standing crew configuration similar to Apollo LM. New sustained translational acceleration limits developed to address this risk are presented herein. These limits were derived from evaluations of Apollo biomedical and flight profile data during lunar descent and ascent operations, Soyuz and Space Shuttle flight profile and post-landing biomedical data, and analogue bed rest post-exposure data on orthostatic intolerance.

James M. Pattarini↗
NASA NTRS2021

Mars 2020 Perseverance Entry Controller Design and Flight Reconstruction

On February 18th, 2021, NASA landed Perseverance on the Jezero crater (on Mars). An entry Guidance, Navigation, and Control (GNC) system delivered the vehicle to the desired landing ellipse. The navigation filter propagated position and attitude states initialized from cruise using Inertial Measurement Unit (IMU) measurements. The entry guidance modulated the lift vector through bank commands to reach the parachute deploy conditions. The entry controller commanded the propulsive Reaction Control System (RCS) to track the bank commands while doing rate damping on angle-of-attack and sideslip. This paper describes the design and the as-flown performance of the entry controller.

Way, David W.↗
NASA NTRS1980

Spacelab's interface to payload experiments

The Spacelab Payload Standard Modular Electronics (SPSME) program has been designed to provide a standardized set of space-qualified low-power electronic modules from which an experimenter may economically implement a command and data management system. SPSME is based on the Computer Automated Measurement and Control (CAMAC) interface standards. To the system of CAMAC, SPSME adds Spacelab interface modules, a flight qualified system crate, and an efficient light-weight power supply to produce a system compatible with the Spacelab environments, the Spacelab Command and Data Management System interface, and any experiment.

Golemon, W. F.↗
NASA NTRS1993

Network command processing system overview

The Network Command Processing System (NCPS) developed for the National Aeronautics and Space Administration (NASA) Ground Network (GN) stations is a spacecraft command system utilizing a MULTIBUS I/68030 microprocessor. This system was developed and implemented at ground stations worldwide to provide a Project Operations Control Center (POCC) with command capability for support of spacecraft operations such as the LANDSAT, Shuttle, Tracking and Data Relay Satellite, and Nimbus-7. The NCPS consolidates multiple modulation schemes for supporting various manned/unmanned orbital platforms. The NCPS interacts with the POCC and a local operator to process configuration requests, generate modulated uplink sequences, and inform users of the ground command link status. This paper presents the system functional description, hardware description, and the software design.

Nam, Yon-Woo↗
NASA NTRS1994

FAST User Guide

The Flow Analysis Software Toolkit, FAST, is a software environment for visualizing data. FAST is a collection of separate programs (modules) that run simultaneously and allow the user to examine the results of numerical and experimental simulations. The user can load data files, perform calculations on the data, visualize the results of these calculations, construct scenes of 3D graphical objects, and plot, animate and record the scenes. Computational Fluid Dynamics (CFD) visualization is the primary intended use of FAST, but FAST can also assist in the analysis of other types of data. FAST combines the capabilities of such programs as PLOT3D, RIP, SURF, and GAS into one environment with modules that share data. Sharing data between modules eliminates the drudgery of transferring data between programs. All the modules in the FAST environment have a consistent, highly interactive graphical user interface. Most commands are entered by pointing and'clicking. The modular construction of FAST makes it flexible and extensible. The environment can be custom configured and new modules can be developed and added as needed. The following modules have been developed for FAST: VIEWER, FILE IO, CALCULATOR, SURFER, TOPOLOGY, PLOTTER, TITLER, TRACER, ARCGRAPH, GQ, SURFERU, SHOTET, and ISOLEVU. A utility is also included to make the inclusion of user defined modules in the FAST environment easy. The VIEWER module is the central control for the FAST environment. From VIEWER, the user can-change object attributes, interactively position objects in three-dimensional space, define and save scenes, create animations, spawn new FAST modules, add additional view windows, and save and execute command scripts. The FAST User Guide uses text and FAST MAPS (graphical representations of the entire user interface) to guide the user through the use of FAST. Chapters include: Maps, Overview, Tips, Getting Started Tutorial, a separate chapter for each module, file formats, and system administration.

Walatka, Pamela P.↗
NASA NTRS1974

Integrated source and channel encoded digital communications system design study

Studies on the digital communication system for the direct communication links from ground to space shuttle and the links involving the Tracking and Data Relay Satellite (TDRS). Three main tasks were performed:(1) Channel encoding/decoding parameter optimization for forward and reverse TDRS links,(2)integration of command encoding/decoding and channel encoding/decoding; and (3) modulation coding interface study. The general communication environment is presented to provide the necessary background for the tasks and to provide an understanding of the implications of the results of the studies.

Huth, G. K.↗
NASA NTRS2000

Autonomy Architectures for a Constellation of Spacecraft

Until the past few years, missions typically involved fairly large expensive spacecraft. Such missions have primarily favored using older proven technologies over more recently developed ones, and humans controlled spacecraft by manually generating detailed command sequences with low-level tools and then transmitting the sequences for subsequent execution on a spacecraft controller. This approach toward controlling a spacecraft has worked spectacularly on previous missions, but it has limitations deriving from communications restrictions - scheduling time to communicate with a particular spacecraft involves competing with other projects due to the limited number of deep space network antennae. This implies that a spacecraft can spend a long time just waiting whenever a command sequence fails. This is one reason why the New Millennium program has an objective to migrate parts of mission control tasks onboard a spacecraft to reduce wait time by making spacecraft more robust. The migrated software is called a "remote agent" and has 4 components: a mission manager to generate the high level goals, a planner/scheduler to turn goals into activities while reasoning about future expected situations, an executive/diagnostics engine to initiate and maintain activities while interpreting sensed events by reasoning about past and present situations, and a conventional real-time subsystem to interface with the spacecraft to implement an activity's primitive actions. In addition to needing remote planning and execution for isolated spacecraft, a trend toward multiple-spacecraft missions points to the need for remote distributed planning and execution. The past few years have seen missions with growing numbers of probes. Pathfinder has its rover (Sojourner), Cassini has its lander (Huygens), and the New Millenium Deep Space 3 (DS3) proposal involves a constellation of 3 spacecraft for interferometric mapping. This trend is expected to continue to progressively larger fleets. For example, one mission proposed to succeed DS3 would have 18 spacecraft flying in formation in order to detect earth-sized planets orbiting other stars. A proposed magnetospheric constellation would involve 5 to 500 spacecraft in Earth orbit to measure global phenomena within the magnetosphere. This work describes and compares three autonomy architectures for a system that continuously plans to control a fleet of spacecraft using collective mission goals instead of goals or command sequences for each spacecraft. A fleet of self-commanding spacecraft would autonomously coordinate itself to satisfy high level science and engineering goals in a changing partially-understood environment making feasible the operation of tens or even a hundred spacecraft (such as for interferometry or plasma physics missions). The easiest way to adapt autonomous spacecraft research to controlling constellations involves treating the constellation as a single spacecraft. Here one spacecraft directly controls the others as if they were connected. The controlling "master" spacecraft performs all autonomy reasoning, and the slaves only have real-time subsystems to execute the master's commands and transmit local telemetry/observations. The executive/diagnostics module starts actions and the master's real-time subsystem controls the action either locally or remotely through a slave. While the master/slave approach benefits from conceptual simplicity, it relies on an assumption that the master spacecraft's executive can continuously monitor the slaves' real-time subsystems, and this relies on high-bandwidth highly-reliable communications. Since unintended results occur fairly rarely, one way to relax the bandwidth requirements involves only monitoring unexpected events in spacecraft. Unfortunately, this disables the ability to monitor for unexpected events between spacecraft and leads to a host of coordination problems among the slaves. Also, failures in the communications system can result in losing slaves. The other two architectures improve robustness while reducing communications by progressively distributing more of the other three remote agent components across the constellation. In a teamwork architecture, all spacecraft have executives and real-time subsystems - only the leader has the planner/scheduler and mission manager. Finally, distributing all remote agent components leads to a peer-to-peer approach toward constellation control.

Barrett, Anthony↗