Search NASA⌕ Search

SEARCH · Search NASA

Results for “command process”

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 505 records · Page 28

Hierarchical control of intelligent machines applied to space station telerobots

A hierarchical architecture is described which supports space station telerobots in a variety of modes. The system is divided into three hierarchies: task decomposition, world model, and sensory processing. Goals at each level of the task decomposition hierarchy are divided both spatially and temporally into simpler commands for the next lower level. This decomposition is repeated until, at the lowest level, the drive signals to the robot actuators are generated. To accomplish its goals, task decomposition modules must often use information stored in the world model. The purpose of the sensory system is to update the world model as rapidly as possible to keep the model in registration with the physical world. The architecture of the entire control system hierarchy and how it can be applied to space telerobot applications are discussed.

Albus, J. S.↗

Neural-Network-Development Program

NETS, software tool for development and evaluation of neural networks, provides simulation of neural-network algorithms plus computing environment for development of such algorithms. Uses back-propagation learning method for all of networks it creates. Enables user to customize patterns of connections between layers of network. Also provides features for saving, during learning process, values of weights, providing more-precise control over learning process. Written in ANSI standard C language. Machine-independent version (MSC-21588) includes only code for command-line-interface version of NETS 3.0.

Phillips, Todd A.↗

The European Southern Observatory-MIDAS table file system

The new and substantially upgraded version of the Table File System in MIDAS is presented as a scientific database system. MIDAS applications for performing database operations on tables are discussed, for instance, the exchange of the data to and from the TFS, the selection of objects, the uncertainty joins across tables, and the graphical representation of data. This upgraded version of the TFS is a full implementation of the binary table extension of the FITS format; in addition, it also supports arrays of strings. Different storage strategies for optimal access of very large data sets are implemented and are addressed in detail. As a simple relational database, the TFS may be used for the management of personal data files. This opens the way to intelligent pipeline processing of large amounts of data. One of the key features of the Table File System is to provide also an extensive set of tools for the analysis of the final results of a reduction process. Column operations using standard and special mathematical functions as well as statistical distributions can be carried out; commands for linear regression and model fitting using nonlinear least square methods and user-defined functions are available. Finally, statistical tests of hypothesis and multivariate methods can also operate on tables.

Peron, M.↗

Detecting Phase Boundaries in Hard-Sphere Suspensions

A special image-data-processing technique has been developed for use in experiments that involve observation, via optical microscopes equipped with electronic cameras, of moving boundaries between the colloidal-solid and colloidal-liquid phases of colloidal suspensions of monodisperse hard spheres. During an experiment, it is necessary to adjust the position of a microscope to keep the phase boundary within view. A boundary typically moves at a speed of the order of microns per hour. Because an experiment can last days or even weeks, it is impractical to require human intervention to keep the phase boundary in view. The present image-data-processing technique yields results within a computation time short enough to enable generation of automated-microscope-positioning commands to track the moving phase boundary

McDowell, Mark↗

Support for User Interfaces for Distributed Systems

An extensible Java(TradeMark) software framework supports the construction and operation of graphical user interfaces (GUIs) for distributed computing systems typified by ground control systems that send commands to, and receive telemetric data from, spacecraft. Heretofore, such GUIs have been custom built for each new system at considerable expense. In contrast, the present framework affords generic capabilities that can be shared by different distributed systems. Dynamic class loading, reflection, and other run-time capabilities of the Java language and JavaBeans component architecture enable the creation of a GUI for each new distributed computing system with a minimum of custom effort. By use of this framework, GUI components in control panels and menus can send commands to a particular distributed system with a minimum of system-specific code. The framework receives, decodes, processes, and displays telemetry data; custom telemetry data handling can be added for a particular system. The framework supports saving and later restoration of users configurations of control panels and telemetry displays with a minimum of effort in writing system-specific code. GUIs constructed within this framework can be deployed in any operating system with a Java run-time environment, without recompilation or code changes.

Eychaner, Glenn↗

Development of a NASA 6-U Satellite

NASA/Wallops Flight Facility has focused on the development of new technologies for the advancement of 6 Unit (6U) small satellites. From the design of the structure and instrument support hardware to improvements in the deployer, NASA is concentrating on maximizing the potential of small satellites for the benefit of science. The telemetry system provides much higher data rates than typical I U UHF system. 6U provides up to several hundred kilobits per second and utilizes the existing NASA Ground Network for data reception. The guidance, navigation and control system keeps the satellite pointed within plus or minus 10 degrees of the sun and has knowledge of the sun vector within 1 degree. The 6U power design increased the options for different voltages and power switching capabilities and is capable of supporting instruments with higher power requirements. The Command & Data Handling (C&DH) system includes a low-power 520 MHz flight processor which provides more processing capability than existing I U processor technologies. These optimized technologies will offer the science community a greater opportunity for flying more sophisticated and complex instruments.

Thompson, Linda D.↗

Avionics System Architecture Tool

Avionics System Architecture Tool (ASAT) is a computer program intended for use during the avionics-system-architecture- design phase of the process of designing a spacecraft for a specific mission. ASAT enables simulation of the dynamics of the command-and-data-handling functions of the spacecraft avionics in the scenarios in which the spacecraft is expected to operate. ASAT is built upon I-Logix Statemate MAGNUM, providing a complement of dynamic system modeling tools, including a graphical user interface (GUI), modeling checking capabilities, and a simulation engine. ASAT augments this with a library of predefined avionics components and additional software to support building and analyzing avionics hardware architectures using these components.

Chau, Savio↗

Ground Autonomy for an Aging Spacecraft

As it approaches the sixteenth of a 5 year prime mission, NASA's Solar Radiation and Climate Experiment (SORCE) mission continues to meet and exceed all science requirements while operating with severely degraded batteries. By 2013, the batteries had degraded such that the On Board Computer (OBC) could not be powered through eclipse. This prevents science data collection in eclipse and erases over 99% of all stored science and engineering telemetry. To mitigate these problems, the Flight Operations Team (FOT) at the Laboratory for Atmospheric and Space Physics (LASP) adopted a new operations scheme. "Daylight Only Operations" (DO-OP) transitions the spacecraft from safemode to science mode every orbit. This involved heavily automating the transition process using ground autonomy to improve spacecraft recovery time to 6 minutes - down from 3 orbits of manual commanding. While highly successful, this method of operations poses daily challenges that must be overcome using increasingly complex ground software.

Autonomous Operations↗

Developing Urban Air Mobility Vehicle Models to Support Air Traffic Management Concept Development

To support Urban Air Mobility (UAM) research efforts at NASA, the Airspace Target Generator (ATG) software used in the FutureFlight Central (FFC) air traffic control tower simulator is undergoing updates to support physics-based UAM vehicle models. A process was developed to integrate UAM vertical takeoff and landing (VTOL) aircraft into the fixed-wing ATG modeling environment without significant change to the underlying equations of motion and vehicle model database. The VTOL aircraft models were converted from a six degrees-of-freedom (6-DOF) representation into a four degrees-of-freedom (4-DOF) representation for integration within ATG. Three vehicle designs from the NASA Revolutionary Vertical-Lift Technologies (RVLT) project were selected: a lift-plus-cruise (LPC) aircraft model and quadrotor, electric-powered (QEP) 1-seater and 6-seater models. With the LPC model comprised of a nonlinear force and moment build-up, and the QEP models comprised of linearized stability derivatives, two separate processes were developed to convert the lift, drag, and propulsion characteristics of each model into the ATG model database. Key aircraft performance characteristics including climb, cruise, and descent performance were preserved during the conversion process. Because ATG simulates fixed-wing aircraft through ground taxi and takeoff to approach and landing, acceleration command algorithms were developed to model the vertical takeoff and vertical landing phase of UAM operations. A strategy was then developed to transition the aircraft model to- and from- the new control mode.

urban air mobility↗

The Cassini Live Update Process

The Cassini orbiter is an international science mission to the Saturnian system with 12 science instruments onboard. The Cassini spacecraft lacks a scan platform, which means the entire spacecraft must be rotated to control pointing of any one instrument's boresight. The resulting complex sequences of commands are built beginning many months before execution onboard. Late ephemeris updates from improved navigation data (i.e. after an orbital trim maneuver) often result in pointing commands in the sequence no longer being accurate enough to obtain the desired science observation. This paper will provide an overview of how Cassini uses live updates to address this potential loss of data, including the software developed for this process.

Vandermey, Nancy↗

(abstract) Mission Operations and Control Assurance: Flight Operations Quality Improvements

Mission Operations and Command Assurance (MO&CA), a recent addition to flight operations teams at JPL. provides a system level function to instill quality in mission operations. MO&CA's primary goal at JPL is to help improve the operational reliability for projects during flight. MO&CA tasks include early detection and correction of process design and procedural deficiencies within projects. Early detection and correction are essential during development of operational procedures and training of operational teams. MO&CA's effort focuses directly on reducing the probability of radiating incorrect commands to a spacecraft. Over the last seven years at JPL, MO&CA has become a valuable asset to JPL flight projects. JPL flight projects have benefited significantly from MO&CA's efforts to contain risk and prevent rather than rework errors. MO&CA's ability to provide direct transfer of knowledge allows new projects to benefit directly from previous and ongoing experience. Since MO&CA, like Total Quality Management (TQM), focuses on continuous improvement of processes and elimination of rework, we recommend that this effort be continued on NASA flight projects.

mission operation flight operations error detectio↗

Using AUTORAD for Cassini File Uplinks: Incorporating Automated Commanding into Mission Operations

As the Cassini spacecraft embarked on the Solstice Mission in October 2010, the flight operations team faced a significant challenge in planning and executing the continuing tour of the Saturnian system. Faced with budget cuts that reduced the science and engineering staff by over a third in size, new and streamlined processes had to be developed to allow the Cassini mission to maintain a high level of science data return with a lower amount of available resources while still minimizing the risk. Automation was deemed an important key in enabling mission operations with reduced workforce and the Cassini flight team has made this goal a priority for the Solstice Mission. The operations team learned about a utility called AUTORAD which would give the flight operations team the ability to program selected command files for radiation up to seven days in advance and help minimize the need for off-shift support that could deplete available staffing during the prime shift hours. This paper will describe how AUTORAD is being utilized by the Cassini flight operations team and the processes that were developed or modified to ensure that proper oversight and verification is maintained in the generation and execution of radiated command files.

Goo, Sherwin↗

Assured Mission Support Space Architecture (AMSSA) study

The assured mission support space architecture (AMSSA) study was conducted with the overall goal of developing a long-term requirements-driven integrated space architecture to provide responsive and sustained space support to the combatant commands. Although derivation of an architecture was the focus of the study, there are three significant products from the effort. The first is a philosophy that defines the necessary attributes for the development and operation of space systems to ensure an integrated, interoperable architecture that, by design, provides a high degree of combat utility. The second is the architecture itself; based on an interoperable system-of-systems strategy, it reflects a long-range goal for space that will evolve as user requirements adapt to a changing world environment. The third product is the framework of a process that, when fully developed, will provide essential information to key decision makers for space systems acquisition in order to achieve the AMSSA goal. It is a categorical imperative that military space planners develop space systems that will act as true force multipliers. AMSSA provides the philosophy, process, and architecture that, when integrated with the DOD requirements and acquisition procedures, can yield an assured mission support capability from space to the combatant commanders. An important feature of the AMSSA initiative is the participation by every organization that has a role or interest in space systems development and operation. With continued community involvement, the concept of the AMSSA will become a reality. In summary, AMSSA offers a better way to think about space (philosophy) that can lead to the effective utilization of limited resources (process) with an infrastructure designed to meet the future space needs (architecture) of our combat forces.

Hamon, Rob↗

Characterization of Response Times based on Voice Communication and Traffic Surveillance Data

A barrier to the integration of remotely piloted aircraft operations in the U.S. National Airspace System is the latency of voice communications between the air traffic controller and the remote pilot, and the latency of communication between the aircraft and the remote pilot. The latency can be substantial especially when satellite-based beyond-radio-line-of-sight communication and relay through the aircraft are employed. This study uses voice recordings of controller-pilot communications and aircraft track data to establish a baseline of pilot readback latencies and maneuver detection delays in the current piloted operations. A machine learning pipeline was developed to parse the contents of the air traffic control clearances including the callsigns using natural language processing. After manually validating the results obtained using the pipeline, the average pilot readback latency was found to be about 0.6 seconds. The average latency between the end of maneuver (inferred from track data), initiated by the pilot in response to the clearance, and the end of clearance was found to be about 176 seconds for altitude change commands, 69 seconds for heading change commands, and 182 seconds for speed change commands. The average latency between the beginning of maneuver and the end of clearance was found to be about 17 seconds for altitude change commands, 17seconds for heading change commands, and 25 seconds for speed change commands.

controller-pilot communication, communication late↗

Characterization of Response Times Based on Voice Communication and Traffic Surveillance Data

A barrier to the integration of remotely piloted aircraft operations in the U.S. National Airspace System is the latency of voice communications between the air traffic controller and the remote pilot, and the latency of communication between the aircraft and the remote pilot. The latency can be substantial especially when satellite-based beyond-radio-line-of-sight communication and relay through the aircraft are employed. This study uses voice recordings of controller-pilot communications and aircraft track data to establish a baseline of pilot readback latencies and maneuver detection delays in the current piloted operations. A machine learning pipeline was developed to parse the contents of the air traffic control clearances including the callsigns using natural language processing. After manually validating the results obtained using the pipeline, the average pilot readback latency was found to be about 0.6 seconds. The average latency between the end of maneuver (inferred from track data), initiated by the pilot in response to the clearance, and the end of clearance was found to be about 176 seconds for altitude change commands, 69 seconds for heading change commands, and 182 seconds for speed change commands. The average latency between the beginning of maneuver and the end of clearance was found to be about 17 seconds for altitude change commands, 17seconds for heading change commands, and 25 seconds for speed change commands.

controller-pilot communication↗

Lessons Learned from Daily Uplink Operations during the Deep Impact Mission

The daily preparation of uplink products (commands and files) for Deep Impact was as problematic as the final encounter images were spectacular. The operations team was faced with many challenges during the six-month mission to comet Tempel One of the biggest difficulties was that the Deep Impact Flyby and Impactor vehicles necessitated a high volume of uplink products while also utilizing a new uplink file transfer capability. The Jet Propulsion Laboratory (JPL) Multi-Mission Ground Systems and Services (MGSS) Mission Planning and Sequence Team (MPST) had the responsibility of preparing the uplink products for use on the two spacecraft. These responsibilities included processing nearly 15,000 flight products, modeling the states of the spacecraft during all activities for subsystem review, and ensuring that the proper commands and files were uplinked to the spacecraft. To guarantee this transpired and the health and safety of the two spacecraft were not jeopardized several new ground scripts and procedures were developed while the Deep Impact Flyby and Impactor spacecraft were en route to their encounter with Tempel-1. These scripts underwent several adaptations throughout the entire mission up until three days before the separation of the Flyby and Impactor vehicles. The problems presented by Deep Impact's daily operations and the development of scripts and procedures to ease those challenges resulted in several valuable lessons learned. These lessons are now being integrated into the design of current and future MGSS missions at JPL.

uplink↗

MPST Software: MoonKommand

This software automatically processes Sally Ride Science (SRS) delivered MoonKAM camera control files (ccf) into uplink products for the GRAIL-A and GRAIL-B spacecraft as part of an education and public outreach (EPO) extension to the Grail Mission. Once properly validated and deemed safe for execution onboard the spacecraft, MoonKommand generates the command products via the Automated Sequence Processor (ASP) and generates uplink (.scmf) files for radiation to the Grail-A and/or Grail-B spacecraft. Any errors detected along the way are reported back to SRS via email. With Moon Kommand, SRS can control their EPO instrument as part of a fully automated process. Inputs are received from SRS as either image capture files (.ccficd) for new image requests, or downlink/delete files (.ccfdl) for requesting image downlink from the instrument and on-board memory management. The Moon - Kommand outputs are command and file-load (.scmf) files that will be uplinked by the Deep Space Network (DSN). Without MoonKommand software, uplink product generation for the MoonKAM instrument would be a manual process. The software is specific to the Moon - KAM instrument on the GRAIL mission. At the time of this writing, the GRAIL mission was making final preparations to begin the science phase, which was scheduled to continue until June 2012.

Kwok, John H.↗

Effects of errors on decoupled control systems

Various error sources in a decoupled control system are considered in connection with longitudinal control on a simulated externally blown jet-flap STOL aircraft. The system employed the throttle, horizontal tail, and flaps to decouple the forward velocity, pitch angle, and flight-path angle. The errors considered were: (1) imperfect knowledge of airplane aerodynamic and control characteristics; (2) imperfect measurements of airplane state variables; (3) change in flight conditions, and (4) lag in the airplane controls and in engine response. The effects of the various errors on the decoupling process were generally minor. Significant coupling in flight-path angle was caused by control lag during speed-command maneuvers. However, this coupling could be eliminated by including the control lag in the design of the decoupled system. Other error sources affected primarily the commanded response quantity.

Hamer, H. A.↗