Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “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 991 records · Page 55
All sourcesNASA NTRSDOE OSTI
NASA NTRS1993

How well does voice interaction work in space?

The methods and results of an evaluation of the Voice Navigator software package are discussed. The first phase or ground phase of the study consisted of creating, or training, computer voice files of specific commands. This consisted of repeating each of six commands eight times. The files were then tested for recognition accuracy by the software aboard the microgravity aircraft. During the second phase, both voice training and testing were performed in microgravity. Inflight training was done due to problems encountered in phase one which were believed to be caused by ambient noise levels. Both quantitative and qualitative data were collected. Only one of the commands was found to offer consistently high recognition rates across subjects during the second phase.

Morris, Randy B.↗
NASA NTRS1991

Control algorithm implementation for a redundant degree of freedom manipulator

This project's purpose is to develop and implement control algorithms for a kinematically redundant robotic manipulator. The manipulator is being developed concurrently by Odetics Inc., under internal research and development funding. This SBIR contract supports algorithm conception, development, and simulation, as well as software implementation and integration with the manipulator hardware. The Odetics Dexterous Manipulator is a lightweight, high strength, modular manipulator being developed for space and commercial applications. It has seven fully active degrees of freedom, is electrically powered, and is fully operational in 1 G. The manipulator consists of five self-contained modules. These modules join via simple quick-disconnect couplings and self-mating connectors which allow rapid assembly/disassembly for reconfiguration, transport, or servicing. Each joint incorporates a unique drive train design which provides zero backlash operation, is insensitive to wear, and is single fault tolerant to motor or servo amplifier failure. The sensing system is also designed to be single fault tolerant. Although the initial prototype is not space qualified, the design is well-suited to meeting space qualification requirements. The control algorithm design approach is to develop a hierarchical system with well defined access and interfaces at each level. The high level endpoint/configuration control algorithm transforms manipulator endpoint position/orientation commands to joint angle commands, providing task space motion. At the same time, the kinematic redundancy is resolved by controlling the configuration (pose) of the manipulator, using several different optimizing criteria. The center level of the hierarchy servos the joints to their commanded trajectories using both linear feedback and model-based nonlinear control techniques. The lowest control level uses sensed joint torque to close torque servo loops, with the goal of improving the manipulator dynamic behavior. The control algorithms are subjected to a dynamic simulation before implementation.

Cohan, Steve↗
NASA NTRS1992

Database activity in the Italian Astronet: DIRA 2

The development and utilization of informational archives and databases started, in the Italian Astronet Project, in the middle of 1983. In that year, a small group of astronomers and some more technical people met together in an Astronet working group, with a common, painful experience in managing astronomical catalogues and archives with computers. Nowadays, some years later, some software packages and the contents of both, a relative general database and several local databases represent the work and the effort of the group. The systems have been conceived and developed keeping in mind the original goal of the group: to allow the single atronomer to make a free use of original data. The main package (DIRA) was rewritten, after some years of use, to fully take advantage of the several suggestions of the astronomer that used it and gathered experiences in the astronomical catalog's management. A more technical goal was to install the whole system, born and developed in the vms environment, on unix and unix-like systems. This new version, DIRA2, has a new user interface, a query language with SQL style commands supporting numerical and character functions also and a set of commands to create new catalogues from existing data. The graphics commands are also more powerful with respect to the previous version. DIRA (and DIRA2 of course) philosophy and design are very simple and proved to be very appreciated by astronomers, namely, to normalize and homogenize, at minimum, astronomical catalogues, to collect satisfactory astronomical documentation on their contents and, finally, to allow an astronomical approach to the dialogue with the database. DIRA2 is currently used in most Italian astronomical institutes to retrieve data from a still growing database of about 140 well documented and controlled astronomical catalogues, for the identification of objects and the preparation of a 'medium size' survey, in astrometry and in the creation of new catalogues.

Benacchio, L.↗
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 NTRS1992

XPI: The Xanadu Parameter Interface

XPI is a table driven parameter interface which greatly simplifies both command driven programs such as BROWSE and XIMAGE as well as stand alone single-task programs. It moves all of the syntax and semantic parsing of commands and parameters out of the users code into common code and externally defined tables. This allows the programmer to concentrate on writing the code unique to the application rather than reinventing the user interface and for external graphical interfaces to interface with no changes to the command driven program. XPI also includes a compatibility library which allows programs written using the IRAF host interface (Mandel and Roll) to use XPI in place of the IRAF host interface.

White, N.↗
NASA NTRS1993

Reliable transfer of data from ground to space

This paper describes the problems involved in uplink of data from control centers on the ground to spacecraft, and explores the solutions to those problems, past. present. and future. The evolution of this process, from simple commanding to transfer of large volumes of data and commands is traced. The need for reliable end-to-end protocols for commanding and file transfer is demonstrated, and the shortcomings of both existing telecommand protocols and commercial products to meet this need are discussed. Recent developments in commercial protocols that may be adaptable to the mentioned operations environment are surveyed, and current efforts to develop a suite of protocols for reliable transfer in this environment are presented.

Brosi, Fred↗
NASA NTRS1993

The EURECA telecommanding chain: Experience with packet telecommand and telemetry systems

The European Retrieval Carrier (EURECA) was launched on its first flight on the 31st July 1992 by the Space Shuttle Atlantis. EURECA is characterized by several new on-board features, most notable Packet Telemetry and a partial implementation of Packet Telecommanding using an early version of the Command Operation Procedure (COP-1) protocol. EURECA has also very low contact time with its Ground Station, with a consequent high number of out-of-visibility onboard operations. This paper concentrates on the implementation and operational experience with the COP-1 Protocol and the effect the short ground contact time has on the design of the Commanding System. Another interesting feature is that the COP-1 is implemented at the control center rather than at the ground station. The COP-1 protocol also successfully supported the mission during the launch where commands were sent via NASCOM and the Shuttle.

Mueller, C.↗
NASA NTRS1993

An intelligent planning and scheduling system for the HST servicing missions

A new, intelligent planning and scheduling system has been delivered to NASA-Goddard Space Flight Center (GSFC) to provide support for the up-coming Hubble Space Telescope (HST) Servicing Missions. This new system is the Servicing Mission Planning and Replanning Tool (SM/PART). SM/PART is written in C and runs on a UNlX-based workstation (IBM RS/6000) under Motif. SM/PART effectively automates the complex task of building or rebuilding integrated timelines and command plans which are required by HST Servicing Mission personnel at their consoles during the missions. SM/PART is able to quickly build or rebuild timelines based on information stored in a Knowledge Base (KB) by using an Artificial Intelligence (AI) tool called the Planning And Resource Reasoning (PARR) shell. After a timeline has been built in the batch mode, it can be displayed and edited in an interactive mode with help from the PARR shell. Finally a detailed command plan is generated. The capability to quickly build or rebuild timelines and command plans provides an additional safety factor for the HST, Shuttle and Crew.

Johnson, Jay↗
NASA NTRS1994

Development of a Power Electronics Unit for the Space Station Plasma Contactor

A hollow cathode plasma contactor has been baselined as a charge control device for the Space Station (SS) to prevent deleterious interactions of coated structural components with the ambient plasma. NASA LeRC Work Package 4 initiated the development of a plasma contactor system comprised of a Power Electronics Unit (PEU), an Expellant Management Unit (EMU), a command and data interface, and a Plasma Contactor Unit (PCU). A breadboard PEU was designed and fabricated. The breadboard PEU contains a cathode heater and discharge power supply, which were required to operate the PCU, a control and auxiliary power converter, an EMU interface, a command and telemetry interface, and a controller. The cathode heater and discharge supplies utilized a push-pull topology with a switching frequency of 20 kHz and pulse-width-modulated (PWM) control. A pulse ignition circuit derived from that used in arcjet power processors was incorporated in the discharge supply for discharge ignition. An 8088 based microcontroller was utilized in the breadboard model to provide a flexible platform for controller development with a simple command/data interface incorporating a direct connection to SS Mulitplexer/Demultiplexer (MDM) analog and digital I/O cards. Incorporating this in the flight model would eliminate the hardware and software overhead associated with a 1553 serial interface. The PEU autonomously operated the plasma contactor based on command inputs and was successfully integrated with a prototype plasma contactor unit demonstrating reliable ignition of the discharge and steady-state operation.

Hamley, John A.↗
NASA NTRS1994

Emergency medical services

When NASA was established in 1958, it was known that space flight would require efforts beyond those of NASA to ensure the health and safety of our astronauts. On 10 Aug. 1958, a Secretary of Defense memorandum was signed that assigned the first Department of Defense (DOD) Manager to provide support to NASA for Project Mercury. This established a chain of command through the Joint Chiefs of Staff to the Secretary of Defense. The current charter is dated 19 Mar. 1986 and assigns the DOD Manager responsibilities to the Commander and Chief, US Space Command. The DOD Managers charter has many support areas and among them are recovery of astronauts and medical support. Today these efforts support the Space Shuttle and Space Station Programs. Briefly, the program works with each organization tasking the other through a requirements document. Level of care, communications, and recovery requirements are established; NASA and the DOD provide the capability to meet them. NASA is also responsible for the specialized training and equipment needed to meet these requirements. A Shuttle launch a KSC requires an Emergency Medical Services (EMS) coordinator on console to facilitate communications, ensure proper coverage, and coordinate with area hospitals. A contingent of NASA medical personnel are assembled to provide triage and medical support capabilities. The DOD provides medical evacuation (MEDEVAC) helicopters with surgeons and pararescue specialists (PJ's) or emergency medical technicians (EMT's). Each helicopter is equipped with at least one doctor and one PJ/EMT per astronaut crew member. Transoceanic abort landing (TAL) sites and end of mission (EOM) sites have similar structures, with TAL sites utilizing fixed wingg aircraft for MEDEVAC. The DOD also supports contingency planning for the support and return of crew members from the Space Station Freedom. Much of this support has been directed at the recovery of crew members following the landing of an Assured Crew Return Vehicle.

Billica, Roger↗
NASA NTRS1994

Magellan Project: Evolving enhanced operations efficiency to maximize science value

Magellan has been one of NASA's most successful spacecraft, returning more science data than all planetary spacecraft combined. The Magellan Spacecraft Team (SCT) has maximized the science return with innovative operational techniques to overcome anomalies and to perform activities for which the spacecraft was not designed. Commanding the spacecraft was originally time consuming because the standard development process was envisioned as manual tasks. The Program understood that reducing mission operations costs were essential for an extended mission. Management created an environment which encouraged automation of routine tasks, allowing staff reduction while maximizing the science data returned. Data analysis and trending, command preparation, and command reviews are some of the tasks that were automated. The SCT has accommodated personnel reductions by improving operations efficiency while returning the maximum science data possible.

Cheuvront, Allan R.↗
NASA NTRS1994

Autonomous mission planning and scheduling: Innovative, integrated, responsive

Autonomous mission scheduling, a new concept for NASA ground data systems, is a decentralized and distributed approach to scientific spacecraft planning, scheduling, and command management. Systems and services are provided that enable investigators to operate their own instruments. In autonomous mission scheduling, separate nodes exist for each instrument and one or more operations nodes exist for the spacecraft. Each node is responsible for its own operations which include planning, scheduling, and commanding; and for resolving conflicts with other nodes. One or more database servers accessible to all nodes enable each to share mission and science planning, scheduling, and commanding information. The architecture for autonomous mission scheduling is based upon a realistic mix of state-of-the-art and emerging technology and services, e.g., high performance individual workstations, high speed communications, client-server computing, and relational databases. The concept is particularly suited to the smaller, less complex missions of the future.

Sary, Charisse↗
NASA NTRS1994

SCL: An off-the-shelf system for spacecraft control

In this age of shrinking military, civil, and commercial space budgets, an off-the-shelf solution is needed to provide a multimission approach to spacecraft control. A standard operational interface which can be applied to multiple spacecraft allows a common approach to ground and space operations. A trend for many space programs has been to reduce operational staff by applying autonomy to the spacecraft and to the ground stations. The Spacecraft Command Language (SCL) system developed by Interface and Control Systems, Inc. (ICS) provides an off-the-shelf solution for spacecraft operations. The SCL system is designed to provide a hyper-scripting interface which remains standard from program to program. The spacecraft and ground station hardware specifics are isolated to provide the maximum amount of portability from system to system. Uplink and downlink interfaces are also isolated to allow the system to perform independent of the communications protocols chosen. The SCL system can be used for both the ground stations and the spacecraft, or as a value added package for existing ground station environments. The SCL system provides an expanded stored commanding capability as well as a rule-based expert system on-board. The expert system allows reactive control on-board the spacecraft for functions such as electrical power systems (EPS), thermal control, etc. which have traditionally been performed on the ground. The SCL rule and scripting capability share a common syntax allowing control of scripts from rules and rules from scripts. Rather than telemeter over sampled data to the ground, the SCL system maintains a database on-board which is available for interrogation by the scripts and rules. The SCL knowledge base is constructed on the ground and uploaded to the spacecraft. The SCL system follows an open-systems approach allowing other tasks to communicate with SCL on the ground and in space. The SCL system was used on the Clementine program (launched January 25, 1994) and is required to have bidirectional communications with the guidance, navigation, and control (GNC) algorithms which were written as another task. Sequencing of the spacecraft maneuvers are handled by SCL, but the low-level thruster pulse commands are handled by the GNC software. Attitude information is reported back as telemetry, allowing the SCL expert system to inference on the changing data. The Clementine SCL flight software was largely reused from another Naval Center for Space Technology (NCST) satellite program. This paper details the SCL architecture and how an off-the-shelf solution makes sense for multimission spacecraft programs. The Clementine mission will be used as a case study in the application of the SCL to a 'fast track' program. The benefits of such a system in a 'better, cheaper, faster' climate will be discussed.

Buckley, Brian↗
NASA NTRS1994

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

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

Harbaugh, Randy↗
NASA NTRS1994

CLIPS, AppleEvents, and AppleScript: Integrating CLIPS with commercial software

Many of today's intelligent systems are comprised of several modules, perhaps written in different tools and languages, that together help solve the user's problem. These systems often employ a knowledge-based component that is not accessed directly by the user, but instead operates 'in the background' offering assistance to the user as necessary. In these types of modular systems, an efficient, flexible, and eady-to-use mechanism for sharing data between programs is crucial. To help permit transparent integration of CLIPS with other Macintosh applications, the AI Research Branch at NASA Ames Research Center has extended CLIPS to allow it to communicate transparently with other applications through two popular data-sharing mechanisms provided by the Macintosh operating system: Apple Events (a 'high-level' event mechanism for program-to-program communication), and AppleScript, a recently-released scripting language for the Macintosh. This capability permits other applications (running on either the same or a remote machine) to send a command to CLIPS, which then responds as if the command were typed into the CLIPS dialog window. Any result returned by the command is then automatically returned to the program that sent it. Likewise, CLIPS can send several types of Apple Events directly to other local or remote applications. This CLIPS system has been successfully integrated with a variety of commercial applications, including data collection programs, electronics forms packages, DBMS's, and email programs. These mechanisms can permit transparent user access to the knowledge base from within a commercial application, and allow a single copy of the knowledge base to service multiple users in a networked environment.

Compton, Michael M.↗
NASA NTRS1994

PCLIPS: Parallel CLIPS

A parallel version of CLIPS 5.1 has been developed to run on Intel Hypercubes. The user interface is the same as that for CLIPS with some added commands to allow for parallel calls. A complete version of CLIPS runs on each node of the hypercube. The system has been instrumented to display the time spent in the match, recognize, and act cycles on each node. Only rule-level parallelism is supported. Parallel commands enable the assertion and retraction of facts to/from remote nodes working memory. Parallel CLIPS was used to implement a knowledge-based command, control, communications, and intelligence (C(sup 3)I) system to demonstrate the fusion of high-level, disparate sources. We discuss the nature of the information fusion problem, our approach, and implementation. Parallel CLIPS has also be used to run several benchmark parallel knowledge bases such as one to set up a cafeteria. Results show from running Parallel CLIPS with parallel knowledge base partitions indicate that significant speed increases, including superlinear in some cases, are possible.

Hall, Lawrence O.↗
NASA NTRS1995

Minimizing structural vibrations with Input Shaping (TM)

A new method for commanding machines to move with increased dynamic performance was developed. This method is an enhanced version of input shaping, a patented vibration suppression algorithm. This technique intercepts a command input to a system command that moves the mechanical system with increased performance and reduced residual vibration. This document describes many advanced methods for generating highly optimized shaping sequences which are tuned to particular systems. The shaping sequence is important because it determines the trade off between move/settle time of the system and the insensitivity of the input shaping algorithm to variations or uncertainties in the machine which can be controlled. For example, a system with a 5 Hz resonance that takes 1 second to settle can be improved to settle instantaneously using a 0.2 shaping sequence (thus improving settle time by a factor of 5). This system could vary by plus or minus 15% in its natural frequency and still have no apparent vibration. However, the same system shaped with a 0.3 second shaping sequence could tolerate plus or minus 40% or more variation in natural frequency. This document describes how to generate sequences that maximize performance, sequences that maximize insensitivity, and sequences that trade off between the two. Several software tools are documented and included.

Singhose, Bill↗
NASA NTRS1995

Built-In Diagnostics (BID) Of Equipment/Systems

Diagnostician(TM)-on-Chip (DOC) technology identifies faults and commands systems reconfiguration. Smart microcontrollers operating in conjunction with other system-control circuits, command self-correcting system/equipment actions in real time. DOC microcontroller generates commands for associated built-in test equipment to stimulate unit of equipment diagnosed, collects and processes response data obtained by built-in test equipment, and performs diagnostic reasoning on response data, using diagnostic knowledge base derived from design data.

Granieri, Michael N.↗