SEARCH · Search NASA

Results for “Command Script”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 37 records · Page 2

All sources NASA NTRS DOE OSTI

NASA NTRS1992

IGGy: An interactive environment for surface grid generation

A graphically interactive derivative of the EAGLE boundary code is presented. This code allows the user to interactively build and execute commands and immediately see the results. Strong ties with a batch oriented script language are maintained. A generalized treatment of grid definition parameters allows a more generic definition of the grid generation process and allows the generation of command scripts which can be applied to topologically similar configurations. The use of the graphical user interface is outlined and example applications are presented.

Prewitt, Nathan C.↗

NASA NTRS2004

Software for Automated Testing of Mission-Control Displays

MCC Display Cert Tool is a set of software tools for automated testing of computerterminal displays in spacecraft mission-control centers, including those of the space shuttle and the International Space Station. This software makes it possible to perform tests that are more thorough, take less time, and are less likely to lead to erroneous results, relative to tests performed manually. This software enables comparison of two sets of displays to report command and telemetry differences, generates test scripts for verifying telemetry and commands, and generates a documentary record containing display information, including version and corrective-maintenance data. At the time of reporting the information for this article, work was continuing to add a capability for validation of display parameters against a reconfiguration file.

OHagan, Brian↗

NASA NTRS1992

Interactive Scene Analysis Module - A sensor-database fusion system for telerobotic environments

Accomplishing a task with telerobotics typically involves a combination of operator control/supervision and a 'script' of preprogrammed commands. These commands usually assume that the location of various objects in the task space conform to some internal representation (database) of that task space. The ability to quickly and accurately verify the task environment against the internal database would improve the robustness of these preprogrammed commands. In addition, the on-line initialization and maintenance of a task space database is difficult for operators using Cartesian coordinates alone. This paper describes the Interactive Scene' Analysis Module (ISAM) developed to provide taskspace database initialization and verification utilizing 3-D graphic overlay modelling, video imaging, and laser radar based range imaging. Through the fusion of taskspace database information and image sensor data, a verifiable taskspace model is generated providing location and orientation data for objects in a task space. This paper also describes applications of the ISAM in the Intelligent Systems Research Laboratory (ISRL) at NASA Langley Research Center, and discusses its performance relative to representation accuracy and operator interface efficiency.

Cooper, Eric G.↗

NASA NTRS1998

Second Flight of the Zeno Experiment on USMP-3

The second flight of the Zeno experiment in the USMP-3 flight has shown successful control of density perturbations near the window surfaces. These density changes were demonstrated to be arising from the rate of temperature change in the sample cell during the flight. These effects could be controlled by using decreasing ramp rates as Tc was approached. The cell window interference was carefully recorded to provide data about the phase of the interference close to the critical point and the effective window reflectivity. Correlograms were recorded from 500 mili K down to 2 mili K at 24 temperatures, 383 correlograms in all. The efforts to get closer were prevented by a long (greater than two week time constant) decay of a 1.3% density error caused by local heating from the 17 micro W laser beam. The phase boundary was located with unprecedented precision of +/- 2O micro K. The complete experiment sequence was done with ground commanding and uploaded script files, bypassing the original autonomous-mode program sequence.

Gammon, Robert W.↗

NASA NTRS2017

Interactive Exploration Robots: Human-Robotic Collaboration and Interactions

For decades, NASA has employed different operational approaches for human and robotic missions. Human spaceflight missions to the Moon and in low Earth orbit have relied upon near-continuous communication with minimal time delays. During these missions, astronauts and mission control communicate interactively to perform tasks and resolve problems in real-time. In contrast, deep-space robotic missions are designed for operations in the presence of significant communication delay - from tens of minutes to hours. Consequently, robotic missions typically employ meticulously scripted and validated command sequences that are intermittently uplinked to the robot for independent execution over long periods. Over the next few years, however, we will see increasing use of robots that blend these two operational approaches. These interactive exploration robots will be remotely operated by humans on Earth or from a spacecraft. These robots will be used to support astronauts on the International Space Station (ISS), to conduct new missions to the Moon, and potentially to enable remote exploration of planetary surfaces in real-time. In this talk, I will discuss the technical challenges associated with building and operating robots in this manner, along with lessons learned from research conducted with the ISS and in the field.

Fong, Terry↗

NASA NTRS2007

MatLab Script and Functional Programming

MatLab Script and Functional Programming: MatLab is one of the most widely used very high level programming languages for scientific and engineering computations. It is very user-friendly and needs practically no formal programming knowledge. Presented here are MatLab programming aspects and not just the MatLab commands for scientists and engineers who do not have formal programming training and also have no significant time to spare for learning programming to solve their real world problems. Specifically provided are programs for visualization. The MatLab seminar covers the functional and script programming aspect of MatLab language. Specific expectations are: a) Recognize MatLab commands, script and function. b) Create, and run a MatLab function. c) Read, recognize, and describe MatLab syntax. d) Recognize decisions, loops and matrix operators. e) Evaluate scope among multiple files, and multiple functions within a file. f) Declare, define and use scalar variables, vectors and matrices.

Shaykhian, Gholam Ali↗

NASA NTRS2008

Automatic Testcase Generation for Flight Software

The TacSat3 project is applying Integrated Systems Health Management (ISHM) technologies to an Air Force spacecraft for operational evaluation in space. The experiment will demonstrate the effectiveness and cost of ISHM and vehicle systems management (VSM) technologies through onboard operation for extended periods. We present two approaches to automatic testcase generation for ISHM: 1) A blackbox approach that views the system as a blackbox, and uses a grammar-based specification of the system's inputs to automatically generate *all* inputs that satisfy the specifications (up to prespecified limits); these inputs are then used to exercise the system. 2) A whitebox approach that performs analysis and testcase generation directly on a representation of the internal behaviour of the system under test. The enabling technologies for both these approaches are model checking and symbolic execution, as implemented in the Ames' Java PathFinder (JPF) tool suite. Model checking is an automated technique for software verification. Unlike simulation and testing which check only some of the system executions and therefore may miss errors, model checking exhaustively explores all possible executions. Symbolic execution evaluates programs with symbolic rather than concrete values and represents variable values as symbolic expressions. We are applying the blackbox approach to generating input scripts for the Spacecraft Command Language (SCL) from Interface and Control Systems. SCL is an embedded interpreter for controlling spacecraft systems. TacSat3 will be using SCL as the controller for its ISHM systems. We translated the SCL grammar into a program that outputs scripts conforming to the grammars. Running JPF on this program generates all legal input scripts up to a prespecified size. Script generation can also be targeted to specific parts of the grammar of interest to the developers. These scripts are then fed to the SCL Executive. ICS's in-house coverage tools will be run to measure code coverage. Because the scripts exercise all parts of the grammar, we expect them to provide high code coverage. This blackbox approach is suitable for systems for which we do not have access to the source code. We are applying whitebox test generation to the Spacecraft Health INference Engine (SHINE) that is part of the ISHM system. In TacSat3, SHINE will execute an on-board knowledge base for fault detection and diagnosis. SHINE converts its knowledge base into optimized C code which runs onboard TacSat3. SHINE can translate its rules into an intermediate representation (Java) suitable for analysis with JPF. JPF will analyze SHINE's Java output using symbolic execution, producing testcases that can provide either complete or directed coverage of the code. Automatically generated test suites can provide full code coverage and be quickly regenerated when code changes. Because our tools analyze executable code, they fully cover the delivered code, not just models of the code. This approach also provides a way to generate tests that exercise specific sections of code under specific preconditions. This capability gives us more focused testing of specific sections of code.

Bushnell, David Henry↗

NASA NTRS1992

A new programming metaphor for image processing procedures

Most image processing systems, besides an Application Program Interface (API) which lets users write their own image processing programs, also feature a higher level of programmability. Traditionally, this is a command or macro language, which can be used to build large procedures (scripts) out of simple programs or commands. This approach, a legacy of the teletypewriter has serious drawbacks. A command language is clumsy when (and if! it attempts to utilize the capabilities of a multitasking or multiprocessor environment, it is but adequate for real-time data acquisition and processing, it has a fairly steep learning curve, and the user interface is very inefficient,. especially when compared to a graphical user interface (GUI) that systems running under Xll or Windows should otherwise be able to provide. ll these difficulties stem from one basic problem: a command language is not a natural metaphor for an image processing procedure. A more natural metaphor - an image processing factory is described in detail. A factory is a set of programs (applications) that execute separate operations on images, connected by pipes that carry data (images and parameters) between them. The programs function concurrently, processing images as they arrive along pipes, and querying the user for whatever other input they need. From the user's point of view, programming (constructing) factories is a lot like playing with LEGO blocks - much more intuitive than writing scripts. Focus is on some of the difficulties of implementing factory support, most notably the design of an appropriate API. It also shows that factories retain all the functionality of a command language (including loops and conditional branches), while suffering from none of the drawbacks outlined above. Other benefits of factory programming include self-tuning factories and the process of encapsulation, which lets a factory take the shape of a standard application both from the system and the user's point of view, and thus be used as a component of other factories. A bare-bones prototype of factory programming was implemented under the PcIPS image processing system, and a complete version (on a multitasking platform) is under development.

Smirnov, O. M.↗

NASA NTRS2004

James Webb Space Telescope: Supporting Multiple Ground System Transitions in One Year

Ideas, requirements, and concepts developed during the very early phases of the mission design often conflict with the reality of a situation once the prime contractors are awarded. This happened for the James Webb Space Telescope (JWST) as well. The high level requirement of a common real-time ground system for both the Integration and Test (I&T), as well as the Operation phase of the mission is meant to reduce the cost and time needed later in the mission development for re-certification of databases, command and control systems, scripts, display pages, etc. In the case of JWST, the early Phase A flight software development needed a real-time ground system and database prior to the spacecraft prime contractor being selected. To compound the situation, the very low level requirements for the real-time ground system were not well defined. These two situations caused the initial real-time ground system to be switched out for a system that was previously used by the Bight software development team. To meet the high-!evel requirement, a third ground system was selected based on the prime spacecraft contractor needs and JWST Project decisions. The JWST ground system team has responded to each of these changes successfully. The lessons learned from each transition have not only made each transition smoother, but have also resolved issues earlier in the mission development than what would normally occur.

Detter, Ryan↗

NASA NTRS2010

Time-Tag Generation Script

Time-Tag Generation Script (TTaGS) is an application program, written in the AWK scripting language, for generating commands for aiming one Ku-band antenna and two S-band antennas for communicating with spacecraft. TTaGS saves between 2 and 4 person-hours per every 24 hours by automating the repetitious process of building between 150 and 180 antenna-control commands. TTaGS reads a text database of communication satellite schedules and a text database of satellite rise and set times and cross-references items in the two databases. It then compares the scheduled start and stop with the geometric rise and set to compute the times to execute antenna control commands. While so doing, TTaGS determines whether to generate commands for guidance, navigation, and control computers to tell them which satellites to track. To help prevent Ku-band irradiation of the Earth, TTaGS accepts input from the user about horizon tolerance and accordingly restricts activation and effects deactivation of the transmitter. TTaGS can be modified easily to enable tracking of additional satellites and for such other tasks as reading Sun-rise/set tables to generate commands to point the solar photovoltaic arrays of the International Space Station at the Sun.

Jackson, Dan E.↗

NASA NTRS1992

AXAF user interfaces for heterogeneous analysis environments

The AXAF Science Center (ASC) will develop software to support all facets of data center activities and user research for the AXAF X-ray Observatory, scheduled for launch in 1999. The goal is to provide astronomers with the ability to utilize heterogeneous data analysis packages, that is, to allow astronomers to pick the best packages for doing their scientific analysis. For example, ASC software will be based on IRAF, but non-IRAF programs will be incorporated into the data system where appropriate. Additionally, it is desired to allow AXAF users to mix ASC software with their own local software. The need to support heterogeneous analysis environments is not special to the AXAF project, and therefore finding mechanisms for coordinating heterogeneous programs is an important problem for astronomical software today. The approach to solving this problem has been to develop two interfaces that allow the scientific user to run heterogeneous programs together. The first is an IRAF-compatible parameter interface that provides non-IRAF programs with IRAF's parameter handling capabilities. Included in the interface is an application programming interface to manipulate parameters from within programs, and also a set of host programs to manipulate parameters at the command line or from within scripts. The parameter interface has been implemented to support parameter storage formats other than IRAF parameter files, allowing one, for example, to access parameters that are stored in data bases. An X Windows graphical user interface called 'agcl' has been developed, layered on top of the IRAF-compatible parameter interface, that provides a standard graphical mechanism for interacting with IRAF and non-IRAF programs. Users can edit parameters and run programs for both non-IRAF programs and IRAF tasks. The agcl interface allows one to communicate with any command line environment in a transparent manner and without any changes to the original environment. For example, the authors routinely layer the GUI on top of IRAF, ksh, SMongo, and IDL. The agcl, based on the facilities of a system called Answer Garden, also has sophisticated support for examining documentation and help files, asking questions of experts, and developing a knowledge base of frequently required information. Thus, the GUI becomes a total environment for running programs, accessing information, examining documents, and finding human assistance. Because the agcl can communicate with any command-line environment, most projects can make use of it easily. New applications are continually being found for these interfaces. It is the authors' intention to evolve the GUI and its underlying parameter interface in response to these needs - from users as well as developers - throughout the astronomy community. This presentation describes the capabilities and technology of the above user interface mechanisms and tools. It also discusses the design philosophies guiding the work, as well as hopes for the future.

Mandel, Eric↗

NASA NTRS1996

Tools for automating spacecraft ground systems: The Intelligent Command and Control (ICC) approach

The practical application of scripting languages and World Wide Web tools to the support of spacecraft ground system automation, is reported on. The mission activities and the automation tools used at the Goddard Space Flight Center (MD) are reviewed. The use of the Tool Command Language (TCL) and the Practical Extraction and Report Language (PERL) scripting tools for automating mission operations is discussed together with the application of different tools for the Compton Gamma Ray Observatory ground system.

Stoffel, A. William↗

NASA NTRS1995

A High Efficiency System for Science Instrument Commanding for the Mars Global Surveyor Mission

The Mars Global Surveyor (MGS) mission will return to Mars to re- cover most of the science lost when the ill fated Mars Observer space- craft suffered a catastrophic anomaly in its propulsion system and did not go into orbit. Described in detail are the methods employed by the MGS Sequence Team to accelerate science command processing by using standard command generation process and standard UNIX control scripts.

mars global surveyor mission science instrument co↗

NASA NTRS2005

Solar-System Ephemeris Toolbox

NASA s Jet Propulsion Laboratory (JPL) generates planetary and lunar ephemeris data and FORTRAN routines that allow users to obtain state data for the Sun, the moon, and the planets. The JPL Solar System Ephemeris Toolbox, developed at Kennedy Space Center, is a set of functions that provides the same functionality in the MATLAB computing environment along with some additional capabilities. The toolbox can be used interactively via a graphical user interface (GUI), or individual functions can be called from the MATLAB command prompt or other MATLAB scripts and functions. The toolbox also includes utility functions to define and perform coordinate transformation (e.g., mean-of-date, true-of-date, J2000) that are common in the use of these ephemerides. An attached README file guides the user through the process of constructing binary ephemeris files, verifying correct installation, and using functions to extract state data. This process also can be performed using the GUI. Help from each toolbox function is available through MATLAB s "help" function. Many of the functions in the toolbox are MATLAB equivalents of the JPL-written FORTRAN programs and subroutines used for the same purposes. A novice can use the GUI to extract state data, while a more experienced user can use the functions directly, as needed, in his/her applications. The toolbox has been tested using MATLAB Releases 13 an

Walker, Charles F.↗

NASA NTRS2008

Mars Reconnaissance Orbiter Wrapper Script

The MRO OLVM wrapper script software allows Mars Reconnaissance Orbiter (MRO) sequence and spacecraft engineers to rapidly simulate a spacecraft command product through a tool that simulates the onboard sequence management software (OLVM). This script parses sequence files to determine the appropriate time boundaries for the sequence, and constructs the script file to be executed by OLVM to span the entirety of the designated sequence. It then constructs script files to be executed by OLVM, constructs the appropriate file directories, populates these directories with needed input files, initiates OLVM to simulate the actual command product that will be sent to the spacecraft, and captures the results of the simulation run to an external file for later review. Additionally, the tool allows a user to manually construct the script, if desired, and then execute the script with a simple command line.

Gladden, Roy↗

NASA NTRS2007

Improve Problem Solving Skills through Adapting Programming Tools

There are numerous ways for engineers and students to become better problem-solvers. The use of command line and visual programming tools can help to model a problem and formulate a solution through visualization. The analysis of problem attributes and constraints provide insight into the scope and complexity of the problem. The visualization aspect of the problem-solving approach tends to make students and engineers more systematic in their thought process and help them catch errors before proceeding too far in the wrong direction. The problem-solver identifies and defines important terms, variables, rules, and procedures required for solving a problem. Every step required to construct the problem solution can be defined in program commands that produce intermediate output. This paper advocates improved problem solving skills through using a programming tool. MatLab created by MathWorks, is an interactive numerical computing environment and programming language. It is a matrix-based system that easily lends itself to matrix manipulation, and plotting of functions and data. MatLab can be used as an interactive command line or a sequence of commands that can be saved in a file as a script or named functions. Prior programming experience is not required to use MatLab commands. The GNU Octave, part of the GNU project, a free computer program for performing numerical computations, is comparable to MatLab. MatLab visual and command programming are presented here.

Shaykhian, Linda H.↗

NASA NTRSDate not supplied

Distributed Spacecraft Autonomy - Development of Swarm Autonomy Capability and Scalability for Spacecraft

The Distributed Spacecraft Autonomy project is developing a suite of software tools that enable an operator to command and receive data from a swarm as a single entity, enable a swarm to autonomously coordinate its actions via distributed decision making and reactive closed-loop control, and model swarm behavior in the presence of anomalies or failures. Our use case is the mapping of the electron density of the ionosphere using radio tomography by coordinating the selection of appropriate GPS channels, and by recording Total Electron Count (TEC) measurements. DSA will be demonstrated onboard the NASA Ames Starling mission – a swarm of four small, LEO spacecraft, scheduled to launch in 2021. We will also perform a ground demonstration with simulated and hardware-in-the-loop elements, to validate the tools for controlling swarms of up to 100 assets. The capability to communicate autonomously between the swarm satellites is demonstrated via a sophisticated simulation architecture. Historical Plasmasphere TEC data obtained via dual-band Novatel GPS Receivers are utilized as a representative input dataset for the swarm. The representative TEC data and GPS satellite observability information is fed to the autonomous software package in place of a true real-time ground data collection process. The swarm satellites actively share status updates amongst one another and utilize multi-agent decision making to optimally identify regions of interest in the TEC distribution. The software, aware of the bandwidth limitations of the swarm satellites, prioritizes explorative measurements, which define the range of observability for the satellites, as well as exploitative measurements, which focus on maximizing the observance potential of regions with prolonged, elevated TEC density. The science of this study can ultimately be used to determine the dynamics and coupling of Earth’s magnetosphere, ionosphere, and atmosphere and their response to solar and terrestrial inputs. The findings can be applied to the imaging of critical, transient phenomena in the magnetosphere in later missions. Meanwhile, the swarm autonomy capabilities have far reaching potential in future satellite missions. As an experimental demonstration of the autonomous capabilities of the network, a message is first printed within a core Flight Executive (cFE) application. Two cFE applications that communicate with one another within the same core Flight System (cFS) are shown. Communication between mission applications on the internal cFE bus is extended to utilize Data Distribution Service (DDS) for vehicle-to-vehicle networking. The DDS middleware provides reliable delivery, routing, and topic subscription features over User Datagram Protocol (UDP). Leveraging Linux containerization, a networked set of satellite instances are generated by script to simulate swarm behavior. Swarm commanding and synchronization through the network is demonstrated under various topologies and data-loss conditions. Finally, autonomous swarm scalability from 2 satellites to 100 satellites is shown.

Distributed Autonomy↗

NASA NTRS2020

Distributed Spacecraft Autonomy (DSA): Development of Swarm Autonomy Capability and Scalability for Spacecraft

The Distributed Spacecraft Autonomy project is developing a suite of software tools that enable an operator to command and receive data from a swarm as a single entity, enable a swarm to autonomously coordinate its actions via distributed decision making and reactive closed-loop control, and model swarm behavior in the presence of anomalies or failures. Our use case is the mapping of the electron density of the ionosphere using radio tomography by coordinating the selection of appropriate GPS channels, and by recording Total Electron Count (TEC)measurements. DSA will be demonstrated on board the NASA Ames Starling mission a swarm of four small, LEO spacecraft, scheduled to launch in 2021. We will also perform a ground demonstration with simulated and hardware-in-the-loop elements, to validate the tools for controlling swarms of up to 100 assets.The capability to communicate autonomously between the swarm satellites is demonstrated via a sophisticated simulation architecture. Historical Plasma sphere TEC data obtained via dual-band Novatel GPS Receivers are utilized as a representative input data set for the swarm. The representative TEC data and GPS satellite observability information is fed to the autonomous software package in place of a true real-time ground data collection process. The swarm satellites actively share status updates amongst one another and utilize multi-agent decision making to optimally identify regions of interest in the TEC distribution. The software,aware of the bandwidth limitations of the swarm satellites, prioritizes explorative measurements,which define the range of observability for the satellites, as well as exploitative measurements,which focus on maximizing the observance potential of regions with prolonged, elevated TEC density. The science of this study can ultimately be used to determine the dynamics and coupling of Earth's magnetosphere, ionosphere, and atmosphere and their response to solar and terrestrial inputs. The findings can be applied to the imaging of critical, transient phenomena in the magnetosphere in later missions. Meanwhile, the swarm autonomy capabilities have far reaching potential in future satellite missions.As an experimental demonstration of the autonomous capabilities of the network, a message is first printed within a core Flight Executive (cFE) application. Two cFE applications that communicate with one another within the same core Flight System (cFS) are shown.Communication between mission applications on the internal cFE bus is extended to utilize Data Distribution Service (DDS) for vehicle-to-vehicle networking. The DDS middle ware provides reliable delivery, routing, and topic subscription features over User Data gram Protocol (UDP).Leveraging Linux containerization, a networked set of satellite instances are generated by script to simulate swarm behavior. Swarm commanding and synchronization through the network is demonstrated under various topologies and data-loss conditions. Finally, autonomous swarms calability from 2 satellites to 100 satellites is shown.

Fugate, Jason↗