SEARCH · Engineering Papers

Results for “Command”

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 793 records · Page 44

All sources NASA NTRS DOE OSTI

NASA NTRS2006

Helicopter force-feel and stability augmentation system with parallel servo-actuator

A force-feel system is implemented by mechanically coupling a servo-actuator to and in parallel with a flight control system. The servo-actuator consists of an electric motor, a gearing device, and a clutch. A commanded cockpit-flight-controller position is achieved by pilot actuation of a trim-switch. The position of the cockpit-flight-controller is compared with the commanded position to form a first error which is processed by a shaping function to correlate the first error with a commanded force at the cockpit-flight-controller. The commanded force on the cockpit-flight-controller provides centering forces and improved control feel for the pilot. In an embodiment, the force-feel system is used as the basic element of stability augmentation system (SAS). The SAS provides a stabilization signal that is compared with the commanded position to form a second error signal. The first error is summed with the second error for processing by the shaping function.

Hoh, Roger H.↗

NASA NTRS2007

Network device interface for digitally interfacing data channels to a controller via a network

The present invention provides a network device interface and method for digitally connecting a plurality of data channels, such as sensors, actuators, and subsystems, to a controller using a network bus. The network device interface interprets commands and data received from the controller and polls the data channels in accordance with these commands. Specifically, the network device interface receives digital commands and data from the controller, and based on these commands and data, communicates with the data channels to either retrieve data in the case of a sensor or send data to activate an actuator. Data retrieved from the sensor is converted into digital signals and transmitted to the controller. In some embodiments, network device interfaces associated with different data channels coordinate communications with the other interfaces based on either a transition in a command message sent by the bus controller or a synchronous clock signal.

Ellerbrock, Philip J.↗

NASA NTRS2008

Proven and Robust Ground Support Systems - GSFC Success and Lessons Learned

Over the past fifteen years, Goddard Space Flight Center has developed several successful science missions in-house: the Wilkinson Microwave Anisotropy Probe (WMAP), the Imager for Magnetopause-to-Aurora Global Exploration (IMAGE), the Earth Observing 1 (EO-1) [1], and the Space Technology 5 (ST-5)[2] missions, several Small Explorers, and several balloon missions. Currently in development are the Solar Dynamics Observatory (SDO) [3] and the Lunar Reconnaissance Orbiter (LRO)[4]. What is not well known is that these missions have been supported during spacecraft and/or instrument integration and test, flight software development, and mission operations by two in house satellite Telemetry and Command (T & C) Systems, the Integrated Test and Operations System (ITOS) and the Advanced Spacecraft Integration and System Test (ASIST). The advantages of an in-house satellite Telemetry and Command system are primarily in the flexibility of management and maintenance - the developers are considered a part of the mission team, get involved early in the development process of the spacecraft and mission operations-control center, and provide on-site, on-call support that goes beyond Help Desk and simple software fixes. On the other hand, care must be taken to ensure that the system remains generic enough for cost effective re-use from one mission to the next. The software is designed such that many features are user-configurable. Where user-configurable options were impractical, features were designed so as to be easy for the development team to modify. Adding support for a new ground message header, for example, is a one-day effort because of the software framework on which that code rests. This paper will discuss the many features of the Goddard satellite Telemetry and Command systems that have contributed to the success of the missions listed above. These features include flexible user interfaces, distributed parallel commanding and telemetry decommutation, a procedure language, the interfaces and tools needed for a high degree of automation, and instantly accessible archives of spacecraft telemetry. It will discuss some of the problems overcome during development, including secure commanding over networks or the Internet, constellation support for the three satellites that comprise the ST-5 mission, and geographically distributed telemetry end users.

Pfarr, Barbara↗

NASA NTRS2009

Hardware-Efficient Monitoring of I/O Signals

In this invention, command and monitor functionality is moved between the two independent pieces of hardware, in which one had been dedicated to command and the other had been dedicated to monitor, such that some command and some monitor functionality appears in each. The only constraint is that the monitor for signal cannot be in the same hardware as the command I/O it is monitoring. The splitting of the command outputs between independent pieces of hardware may require some communication between them, i.e. an intra-switch trunk line. This innovation reduces the amount of wasted hardware and allows the two independent pieces of hardware to be designed identically in order to save development costs.

Driscoll, Kevin R.↗

NASA NTRS2009

Network device interface for digitally interfacing data channels to a controller via a network

A communications system and method are provided for digitally connecting a plurality of data channels, such as sensors, actuators, and subsystems, to a controller using a network bus. The network device interface interprets commands and data received from the controller and polls the data channels in accordance with these commands. Specifically, the network device interface receives digital commands and data from the controller, and based on these commands and data, communicates with the data channels to either retrieve data in the case of a sensor or send data to activate an actuator. Data retrieved from the sensor is converted into digital signals and transmitted to the controller. Network device interfaces associated with different data channels can coordinate communications with the other interfaces based on either a transition in a command message sent by the bus controller or a synchronous clock signal.

Ellerbrock, Philip J.↗

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 NTRS2007

Loss-of-Control-Inhibitor Systems for Aircraft

Systems to provide improved tactile feedback to aircraft pilots are being developed to help the pilots maintain harmony between their control actions and the positions of aircraft control surfaces, thereby helping to prevent loss of control. A system of this type, denoted a loss-of-control-inhibitor system (LOCIS) can be implemented as a relatively simple addition to almost any pre-existing flight-control system. The LOCIS concept offers at least a partial solution to the problem of (1) keeping a pilot aware of the state of the control system and the aircraft and (2) maintaining sufficient control under conditions that, as described below, have been known to lead to loss of control. Current commercial aircraft exhibit uneven responses of primary flight-control surfaces to aggressive pilot control commands, leading to deterioration of pilots ability to control their aircraft. In severe cases, this phenomenon can result in loss of control and consequent loss of aircraft. For an older aircraft equipped with a purely mechanical control system, the loss of harmony between a pilot s command action and the control- surface response can be attributed to compliance in the control system (caused, for example, by stretching of control cables, flexing of push rods, or servo-valve distortion). In a newer aircraft equipped with a fly-by-wire control system, the major contributions to loss of harmony between the pilot and the control surfaces are delays attributable to computer cycle time, control shaping, filtering, aliasing, servo-valve distortion, and actuator rate limiting. In addition, a fly-by-wire control system provides no tactile feedback that would enable the pilot to sense such features of the control state as surface flutter, surface jam, position limiting, actuator rate limiting, and control limiting imposed by the aircraft operational envelope. Hence, for example, when a pilot is involved in aggressive closed-loop maneuvering, as when encountering a wake-vortex upset on final landing approach, the control-surface delay can lead to loss of control. Aggressive piloting can be triggered and exacerbated by control-system anomalies, which the pilot cannot diagnose because of the lack of symptoms caused by the absence of feedback through the controls. The purpose served by a LOCIS is to counteract these adverse effects by providing real-time feedback that notifies the pilot that the aircraft is tending to lag the pilot s commands. A LOCIS (see figure) includes cockpit control input-position sensors, control-surface output-position sensors, variable dampers (for example, shock absorbers containing magneto-rheological fluids such that the damping forces can be varied within times of the order of milliseconds by varying applied magnetic fields) attached to the cockpit control levers, electromagnet coils to apply the magnetic fields, and feedback control circuits to drive the electromagnet coils. The feedback control gains are chosen so that the current applied to each electromagnet coil results in a damping force that increases in a suitable nonlinear manner (e.g., exponentially) with the difference between the actual and commanded positions of the affected control surface. The increasing damping force both alerts the pilot to the onset of a potentially dangerous situation and resists the pilot s effort to command a control surface to change position at an excessive rate

AHarrah, Ralph C.↗

NASA NTRS2011

Using Spare Logic Resources To Create Dynamic Test Points

A technique has been devised to enable creation of a dynamic set of test points in an embedded digital electronic system. As a result, electronics contained in an application specific circuit [e.g., gate array, field programmable gate array (FPGA)] can be internally probed, even when contained in a closed housing during all phases of test. In the present technique, the test points are not fixed and limited to a small number; the number of test points can vastly exceed the number of buffers or pins, resulting in a compact footprint. Test points are selected by means of spare logic resources within the ASIC(s) and/or FPGA(s). A register is programmed with a command, which is used to select the signals that are sent off-chip and out of the housing for monitoring by test engineers and external test equipment. The register can be commanded by any suitable means: for example, it could be commanded through a command port that would normally be used in the operation of the system. In the original application of the technique, commanding of the register is performed via a MIL-STD-1553B communication subsystem.

Katz, Richard↗

NASA NTRS2004

Improving Control of Two Motor Controllers

A computer program controls motors that drive translation stages in a metrology system that consists of a pair of two-axis cathetometers. This program is specific to Compumotor Gemini (or equivalent) motors and the Compumotor 6K-series (or equivalent) motor controller. Relative to the software supplied with the controller, this program affords more capabilities and is easier to use. Written as a Virtual Instrument in the LabVIEW software system, the program presents an imitation control panel that the user can manipulate by use of a keyboard and mouse. There are three modes of operation: command, movement, and joystick. In command mode, single commands are sent to the controller for troubleshooting. In movement mode, distance, speed, and/or acceleration commands are sent to the controller. Position readouts from the motors and from position encoders on the translation stages are displayed in marked fields. At any time, the position readouts can be recorded in a file named by the user. In joystick mode, the program yields control of the motors to a joystick. The program sends commands to, and receives data from, the controller via a serial cable connection, using the serial-communication portion of the software supplied with the controller.

Toland, Ronald W.↗

NASA NTRS2011

MicroShell Minimalist Shell for Xilinx Microprocessors

MicroShell is a lightweight shell environment for engineers and software developers working with embedded microprocessors in Xilinx FPGAs. (MicroShell has also been successfully ported to run on ARM Cortex-M1 microprocessors in Actel ProASIC3 FPGAs, but without project-integration support.) Micro Shell decreases the time spent performing initial tests of field-programmable gate array (FPGA) designs, simplifies running customizable one-time-only experiments, and provides a familiar-feeling command-line interface. The program comes with a collection of useful functions and enables the designer to add an unlimited number of custom commands, which are callable from the command-line. The commands are parameterizable (using the C-based command-line parameter idiom), so the designer can use one function to exercise hardware with different values. Also, since many hardware peripherals instantiated in FPGAs have reasonably simple register-mapped I/O interfaces, the engineer can edit and view hardware parameter settings at any time without stopping the processor. MicroShell comes with a set of support scripts that interface seamlessly with Xilinx's EDK tool. Adding an instance of MicroShell to a project is as simple as marking a check box in a library configuration dialog box and specifying a software project directory. The support scripts then examine the hardware design, build design-specific functions, conditionally include processor-specific functions, and complete the compilation process. For code-size constrained designs, most of the stock functionality can be excluded from the compiled library. When all of the configurable options are removed from the binary, MicroShell has an unoptimized memory footprint of about 4.8 kB and a size-optimized footprint of about 2.3 kB. Since MicroShell allows unfettered access to all processor-accessible memory locations, it is possible to perform live patching on a running system. This can be useful, for instance, if a bug is discovered in a routine but the system cannot be rebooted: Shell allows a skilled operator to directly edit the binary executable in memory. With some forethought, MicroShell code can be located in a different memory location from custom code, permitting the custom functionality to be overwritten at any time without stopping the controlling shell.

Werne, Thomas A.↗

NASA NTRS2013

XTCE GOVSAT Tool Suite 1.0

The XTCE GOVSAT software suite contains three tools: validation, search, and reporting. The Extensible Markup Language (XML) Telemetric and Command Exchange (XTCE) GOVSAT Tool Suite is written in Java for manipulating XTCE XML files. XTCE is a Consultative Committee for Space Data Systems (CCSDS) and Object Management Group (OMG) specification for describing the format and information in telemetry and command packet streams. These descriptions are files that are used to configure real-time telemetry and command systems for mission operations. XTCE s purpose is to exchange database information between different systems. XTCE GOVSAT consists of rules for narrowing the use of XTCE for missions. The Validation Tool is used to syntax check GOVSAT XML files. The Search Tool is used to search (i.e. command and telemetry mnemonics) the GOVSAT XML files and view the results. Finally, the Reporting Tool is used to create command and telemetry reports. These reports can be displayed or printed for use by the operations team.

Rice, J. Kevin↗

NASA NTRS2013

MPST Software: grl_pef_check

This innovation is a tool used to verify and validate spacecraft sequences at the predicted events file (PEF) level for the GRAIL (Gravity Recovery and Interior Laboratory, see http://www.nasa. gov/mission_pages/grail/main/index. html) mission as part of the Multi-Mission Planning and Sequencing Team (MPST) operations process to reduce the possibility for errors. This tool is used to catch any sequence related errors or issues immediately after the seqgen modeling to streamline downstream processes. This script verifies and validates the seqgen modeling for the GRAIL MPST process. A PEF is provided as input, and dozens of checks are performed on it to verify and validate the command products including command content, command ordering, flight-rule violations, modeling boundary consistency, resource limits, and ground commanding consistency. By performing as many checks as early in the process as possible, grl_pef_check streamlines the MPST task of generating GRAIL command and modeled products on an aggressive schedule. By enumerating each check being performed, and clearly stating the criteria and assumptions made at each step, grl_pef_check can be used as a manual checklist as well as an automated tool. This helper script was written with a focus on enabling the user with the information they need in order to evaluate a sequence quickly and efficiently, while still keeping them informed and active in the overall sequencing process. grl_pef_check verifies and validates the modeling and sequence content prior to investing any more effort into the build. There are dozens of various items in the modeling run that need to be checked, which is a time-consuming and errorprone task. Currently, no software exists that provides this functionality. Compared to a manual process, this script reduces human error and saves considerable man-hours by automating and streamlining the mission planning and sequencing task for the GRAIL mission.

Call, Jared A.↗

NASA NTRS2013

Towards Human-Friendly Efficient Control of Multi-Robot Teams

This paper explores means to increase efficiency in performing tasks with multi-robot teams, in the context of natural Human-Multi-Robot Interfaces (HMRI) for command and control. The motivating scenario is an emergency evacuation by a transport convoy of unmanned ground vehicles (UGVs) that have to traverse, in shortest time, an unknown terrain. In the experiments the operator commands, in minimal time, a group of rovers through a maze. The efficiency of performing such tasks depends on both, the levels of robots' autonomy, and the ability of the operator to command and control the team. The paper extends the classic framework of levels of autonomy (LOA), to levels/hierarchy of autonomy characteristic of Groups (G-LOA), and uses it to determine new strategies for control. An UGVoriented command language (UGVL) is defined, and a mapping is performed from the human-friendly gesture-based HMRI into the UGVL. The UGVL is used to control a team of 3 robots, exploring the efficiency of different G-LOA; specifically, by (a) controlling each robot individually through the maze, (b) controlling a leader and cloning its controls to followers, and (c) controlling the entire group. Not surprisingly, commands at increased G-LOA lead to a faster traverse, yet a number of aspects are worth discussing in this context.

multi-robot control↗

NASA NTRS2014

ULSGEN (Uplink Summary Generator)

Uplink is an important part of spacecraft operations. Ensuring the accuracy of uplink content is essential to mission success. Before commands are radiated to the spacecraft, the command and sequence must be reviewed and verified by various teams. In most cases, this process requires collecting the command data, reviewing the data during a command conference meeting, and providing physical signatures by designated members of various teams to signify approval of the data. If commands or sequences are disapproved for some reason, the whole process must be restarted. Recording data and decision history is important for traceability reasons. Given that many steps and people are involved in this process, an easily accessible software tool for managing the process is vital to reducing human error which could result in uplinking incorrect data to the spacecraft. An uplink summary generator called ULSGEN was developed to assist this uplink content approval process. ULSGEN generates a web-based summary of uplink file content and provides an online review process. Spacecraft operations personnel view this summary as a final check before actual radiation of the uplink data. .

Wang, Y.-F.↗

NASA NTRS2016

Using Natural Language to Enhance Mission Effectiveness

The availability of highly capable, yet relatively cheap, unmanned aerial vehicles (UAVs) is opening up new areas of use for hobbyists and for professional-related activities. The driving function of this research is allowing a non-UAV pilot, an operator, to define and manage a mission. This paper describes the preliminary usability measures of an interface that allows an operator to define the mission using speech to make inputs. An experiment was conducted to begin to enumerate the efficacy and user acceptance of using voice commands to define a multi-UAV mission and to provide high-level vehicle control commands such as "takeoff." The primary independent variable was input type - voice or mouse. The primary dependent variables consisted of the correctness of the mission parameter inputs and the time needed to make all inputs. Other dependent variables included NASA-TLX workload ratings and subjective ratings on a final questionnaire. The experiment required each subject to fill in an online form that contained comparable required information that would be needed for a package dispatcher to deliver packages. For each run, subjects typed in a simple numeric code for the package code. They then defined the initial starting position, the delivery location, and the return location using either pull-down menus or voice input. Voice input was accomplished using CMU Sphinx4-5prealpha for speech recognition. They then inputted the length of the package. These were the option fields. The subject had the system "Calculate Trajectory" and then "Takeoff" once the trajectory was calculated. Later, the subject used "Land" to finish the run. After the voice and mouse input blocked runs, subjects completed a NASA-TLX. At the conclusion of all runs, subjects completed a questionnaire asking them about their experience in inputting the mission parameters, and starting and stopping the mission using mouse and voice input. In general, the usability of voice commands is acceptable. With a relatively well-defined and simple vocabulary, the operator can input the vast majority of the mission parameters using simple, intuitive voice commands. However, voice input may be more applicable to initial mission specification rather than for critical commands such as the need to land immediately due to time and feedback constraints. It would also be convenient to retrieve relevant mission information using voice input. Therefore, further on-going research is looking at using intent from operator utterances to provide the relevant mission information to the operator. The information displayed will be inferred from the operator's utterances just before key phrases are spoken. Linguistic analysis of the context of verbal communication provides insight into the intended meaning of commonly heard phrases such as "What's it doing now?" Analyzing the semantic sphere surrounding these common phrases enables us to predict the operator's intent and supply the operator's desired information to the interface. This paper also describes preliminary investigations into the generation of the semantic space of UAV operation and the success at providing information to the interface based on the operator's utterances.

Trujillo, Anna C.↗

NASA NTRS2016

Marshall Space Flight Center Telescience Resource Kit

Telescience Resource Kit (TReK) is a suite of software applications that can be used to monitor and control assets in space or on the ground. The Telescience Resource Kit was originally developed for the International Space Station program. Since then it has been used to support a variety of NASA programs and projects including the WB-57 Ascent Vehicle Experiment (WAVE) project, the Fast Affordable Science and Technology Satellite (FASTSAT) project, and the Constellation Program. The Payloads Operations Center (POC), also known as the Payload Operations Integration Center (POIC), provides the capability for payload users to operate their payloads at their home sites. In this environment, TReK provides local ground support system services and an interface to utilize remote services provided by the POC. TReK provides ground system services for local and remote payload user sites including International Partner sites, Telescience Support Centers, and U.S. Investigator sites in over 40 locations worldwide. General Capabilities: Support for various data interfaces such as User Datagram Protocol, Transmission Control Protocol, and Serial interfaces. Data Services - retrieve, process, record, playback, forward, and display data (ground based data or telemetry data). Command - create, modify, send, and track commands. Command Management - Configure one TReK system to serve as a command server/filter for other TReK systems. Database - databases are used to store telemetry and command definition information. Application Programming Interface (API) - ANSI C interface compatible with commercial products such as Visual C++, Visual Basic, LabVIEW, Borland C++, etc. The TReK API provides a bridge for users to develop software to access and extend TReK services. Environments - development, test, simulations, training, and flight. Includes standalone training simulators.

Wade, Gina↗

NASA NTRS2017

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

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

Trimble, Jay↗

NASA NTRS2021

Waypoint Following Dynamics of a Quaternion Error Feedback Attitude Control System

Closed-loop attitude steering can be used to implement alternative attitude maneuvers by using a conventional attitude control system to track a non-standard attitude profile sampled as a series of sequential commands. The idea has been employed in practice to perform zero-propellant maneuvers on the International Space Station and minimum time maneuvers on NASA’s TRACE space telescope. A challenge for operational implementation of the idea is the finite capacity of a space vehicle’s command storage buffer. One approach to mitigate the problem is to downsample-and-hold the attitude commands so that the attitude control system to follows a set of waypoints. This paper explores the waypoint following dynamics of a quaternion error feedback control law for downsample-and-hold. It is shown that downsample-and-hold induces a ripple between downsamples that causes the satellite angular rate to significantly overshoot the desired limit. Analysis in the z-domain is carried out in order to understand the phenomenon. An interpolating Chebyshev-type filter is proposed that allows attitude commands to be encoded in terms of a small set of filter coefficients. Using the interpolating filter, commands can be issued at the ACS rate but with significantly reduced memory requirements. The attitude control system of NASA’s Lunar Reconnaissance Orbiter is used as an example to illustrate the behavior of a practical attitude control system.

Mark Karpenko↗