Search NASA⌕ Search

SEARCH · Search NASA

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.

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

At least 649 records · Page 36
All sourcesNASA NTRSDOE OSTI
NASA NTRS2021

On-demand Command and Control of ASTERIA with Cloud-based Ground Station Services

ASTERIA (Arcsecond Space Telescope Enabling Research in Astrophysics) was a 6-unit CubeSat technology demonstration mission that deployed from the International Space Station on November 20th, 2017. After successfully completing its 90-day primary mission that demonstrated arcsecond-level line-of-sight pointing and focal plane thermal stability for exoplanet detection, it entered an extended mission performing onboard software demonstrations to mature technology both in space and on the ground. One of the technologies was a completely cloud-based ground system leveraging Amazon Web Services (AWS) Ground Station service. Announced in December 2018 and launched in May 2019, AWS Ground Station is a fully managed ground station service that aims to reduce the overhead associated with developing and maintaining ground system infrastructure throughout the mission lifecycle. AWS Ground Station makes available the suite of features required for any ground system in support of low-Earth orbit (LEO) and medium-Earth Orbit (MEO) satellite operations on-demand and without setting up or maintaining long-term contracts. Charges are incurred on a per-minute basis for antenna usage during scheduled tracks. Support is available for S-band uplink and downlink, along with X-band narrowband and wideband downlink. Missions that use the service may reserve tracks with any licensed AWS Ground Station antennas located across each service region and have direct access to any AWS services in support of mission operations. The cloud-based architecture built around the AWS Ground Station service greatly enhanced ASTERIA mission operations by enabling end-to-end pass automation, on-demand contact scheduling and contingency planning, along with more efficient data downlink through station availability and station-tostation handovers. It incorporated open-source software, particularly NASA's AMMOS Instrument Toolkit (AIT) and Open Mission Control Technologies (OpenMCT), along with the AWS application programming interfaces (API) to the Ground Station, Elastic Compute Cloud (EC2) and Simple Storage Service (S3) services. After showcasing operability in August 2019, the team continued using and improving this novel ground system architecture until the end of mission in December 2019. This paper describes the cloud-based ground system, how it was designed, tested, and evaluated with an inorbit spacecraft, the operational capabilities that it enabled, along with lessons learned and recommendations for future missions.

Fesq, Lorraine↗
NASA NTRSDate not supplied

Gateway Command and Data Handling Network Implementation and Validation

As initial Lunar Gateway modules approach design maturity, the Artemis Network Validation and Integration Lab (ANVIL) has begun demonstrations to validate avionics network dataflows. The flight architecture design includes utilizing Time-Triggered Ethernet (TTE) and layer-3 switching capabilities to enable greater automation and flexibility of critical and best effort traffic. Critical traffic is considered as Time-Triggered (TT), Rate Constrained (RC) and prioritized Best Effort (BE) traffic classes. End systems, such as mission computers, power control, and robotics, use three planes and all traffic classes while other devices interface via Best Effort. Typical best effort devices include video, laptops, wireless access points, and payloads. Other devices have a various hybrid approach of interfaces including alarms, telemetry/logging, and communication units. In the paper, we will present an update of the Gateway network architecture and how the system will operate nominally and during a stack topology reconfiguration. We will also discuss the network risks, and trade-offs of performance, flexibility, and redundancy. Finally, we will show the process for validation, demonstration, and verification approaches to the vehicle network.

Gateway↗
NASA NTRS2007

Neural Net Safety Monitor Design

The National Aeronautics and Space Administration (NASA) at the Dryden Flight Research Center (DFRC) has been conducting flight-test research using an F-15 aircraft (figure 1). This aircraft has been specially modified to interface a neural net (NN) controller as part of a single-string Airborne Research Test System (ARTS) computer with the existing quad-redundant flight control system (FCC) shown in figure 2. The NN commands are passed to FCC channels 2 and 4 and are cross channel data linked (CCDL) to the other computers as shown. Numerous types of fault-detection monitors exist in the FCC when the NN mode is engaged; these monitors would cause an automatic disengagement of the NN in the event of a triggering fault. Unfortunately, these monitors still may not prevent a possible NN hard-over command from coming through to the control laws. Therefore, an additional and unique safety monitor was designed for a single-string source that allows authority at maximum actuator rates but protects the pilot and structural loads against excessive g-limits in the case of a NN hard-over command input. This additional monitor resides in the FCCs and is executed before the control laws are computed. This presentation describes a floating limiter (FL) concept1 that was developed and successfully test-flown for this program (figure 3). The FL computes the rate of change of the NN commands that are input to the FCC from the ARTS. A window is created with upper and lower boundaries, which is constantly floating and trying to stay centered as the NN command rates are changing. The limiter works by only allowing the window to move at a much slower rate than those of the NN commands. Anywhere within the window, however, full rates are allowed. If a rate persists in one direction, it will eventually hit the boundary and be rate-limited to the floating limiter rate. When this happens, a persistent counter begins and after a limit is reached, a NN disengage command is generated. The tunable metrics for the FL are (1) window size, (2) drift rate, and (3) persistence counter. Ultimate range limits are also included in case the NN command should drift slowly to a limit value that would cause the FL to be defeated. The FL has proven to work as intended. Both high-g transients and excessive structural loads are controlled with NN hard-over commands. This presentation discusses the FL design features and presents test cases. Simulation runs are included to illustrate the dramatic improvement made to the control of NN hard-over effects. A mission control room display from a flight playback is presented to illustrate the neural net fault display representation. The FL is very adaptable to various requirements and is independent of flight condition. It should be considered as a cost-effective safety monitor to control single-string inputs in general.

Larson, Richard R.↗
NASA NTRS2009

Implementation of an Adaptive Controller System from Concept to Flight Test

The National Aeronautics and Space Administration (NASA) at the Dryden Flight Research Center (DFRC) has been conducting flight-test research using an F-15 aircraft (figure 1). This aircraft has been specially modified to interface a neural net (NN) controller as part of a single-string Airborne Research Test System (ARTS) computer with the existing quad-redundant flight control system (FCC) shown in figure 2. The NN commands are passed to FCC channels 2 and 4 and are cross channel data linked (CCDL) to the other computers as shown. Numerous types of fault-detection monitors exist in the FCC when the NN mode is engaged; these monitors would cause an automatic disengagement of the NN in the event of a triggering fault. Unfortunately, these monitors still may not prevent a possible NN hard-over command from coming through to the control laws. Therefore, an additional and unique safety monitor was designed for a single-string source that allows authority at maximum actuator rates but protects the pilot and structural loads against excessive g-limits in the case of a NN hard-over command input. This additional monitor resides in the FCCs and is executed before the control laws are computed. This presentation describes a "floating limiter" (FL) concept that was developed and successfully test-flown for this program (figure 3). The FL computes the rate of change of the NN commands that are input to the FCC from the ARTS. A window is created with upper and lower boundaries, which is constantly "floating" and trying to stay centered as the NN command rates are changing. The limiter works by only allowing the window to move at a much slower rate than those of the NN commands. Anywhere within the window, however, full rates are allowed. If a rate persists in one direction, it will eventually "hit" the boundary and be rate-limited to the floating limiter rate. When this happens, a persistent counter begins and after a limit is reached, a NN disengage command is generated. The tunable metrics for the FL are (1) window size, (2) drift rate, and (3) persistence counter. Ultimate range limits are also included in case the NN command should drift slowly to a limit value that would cause the FL to be defeated. The FL has proven to work as intended. Both high-g transients and excessive structural loads are controlled with NN hard-over commands. This presentation discusses the FL design features and presents test cases. Simulation runs are included to illustrate the dramatic improvement made to the control of NN hard-over effects. A mission control room display from a flight playback is presented to illustrate the neural net fault display representation. The FL is very adaptable to various requirements and is independent of flight condition. It should be considered as a cost-effective safety monitor to control single-string inputs in general.

Larson, Richard R.↗
NASA NTRS2010

Multi-agent autonomous system

A multi-agent autonomous system for exploration of hazardous or inaccessible locations. The multi-agent autonomous system includes simple surface-based agents or craft controlled by an airborne tracking and command system. The airborne tracking and command system includes an instrument suite used to image an operational area and any craft deployed within the operational area. The image data is used to identify the craft, targets for exploration, and obstacles in the operational area. The tracking and command system determines paths for the surface-based craft using the identified targets and obstacles and commands the craft using simple movement commands to move through the operational area to the targets while avoiding the obstacles. Each craft includes its own instrument suite to collect information about the operational area that is transmitted back to the tracking and command system. The tracking and command system may be further coupled to a satellite system to provide additional image information about the operational area and provide operational and location commands to the tracking and command system.

Fink, Wolfgang↗
NASA NTRS2005

Encryption for Remote Control via Internet or Intranet

A data-communication protocol has been devised to enable secure, reliable remote control of processes and equipment via a collision-based network, while using minimal bandwidth and computation. The network could be the Internet or an intranet. Control is made secure by use of both a password and a dynamic key, which is sent transparently to a remote user by the controlled computer (that is, the computer, located at the site of the equipment or process to be controlled, that exerts direct control over the process). The protocol functions in the presence of network latency, overcomes errors caused by missed dynamic keys, and defeats attempts by unauthorized remote users to gain control. The protocol is not suitable for real-time control, but is well suited for applications in which control latencies up to about 0.5 second are acceptable. The encryption scheme involves the use of both a dynamic and a private key, without any additional overhead that would degrade performance. The dynamic key is embedded in the equipment- or process-monitor data packets sent out by the controlled computer: in other words, the dynamic key is a subset of the data in each such data packet. The controlled computer maintains a history of the last 3 to 5 data packets for use in decrypting incoming control commands. In addition, the controlled computer records a private key (password) that is given to the remote computer. The encrypted incoming command is permuted by both the dynamic and private key. A person who records the command data in a given packet for hostile purposes cannot use that packet after the public key expires (typically within 3 seconds). Even a person in possession of an unauthorized copy of the command/remote-display software cannot use that software in the absence of the password. The use of a dynamic key embedded in the outgoing data makes the central-processing unit overhead very small. The use of a National Instruments DataSocket(TradeMark) (or equivalent) protocol or the User Datagram Protocol makes it possible to obtain reasonably short response times: Typical response times in event-driven control, using packets sized .300 bytes, are <0.2 second for commands issued from locations anywhere on Earth. The protocol requires that control commands represent absolute values of controlled parameters (e.g., a specified temperature), as distinguished from changes in values of controlled parameters (e.g., a specified increment of temperature). Each command is issued three or more times to ensure delivery in crowded networks. The use of absolute-value commands prevents additional (redundant) commands from causing trouble. Because a remote controlling computer receives "talkback" in the form of data packets from the controlled computer, typically within a time interval < or =1 s, the controlling computer can re-issue a command if network failure has occurred. The controlled computer, the process or equipment that it controls, and any human operator(s) at the site of the controlled equipment or process should be equipped with safety measures to prevent damage to equipment or injury to humans. These features could be a combination of software, external hardware, and intervention by the human operator(s). The protocol is not fail-safe, but by adopting these safety measures as part of the protocol, one makes the protocol a robust means of controlling remote processes and equipment by use of typical office computers via intranets and/or the Internet.

Lineberger, Lewis↗
NASA NTRS2005

Rover Sequencing and Visualization Program

The Rover Sequencing and Visualization Program (RSVP) is the software tool for use in the Mars Exploration Rover (MER) mission for planning rover operations and generating command sequences for accomplishing those operations. RSVP combines three-dimensional (3D) visualization for immersive exploration of the operations area, stereoscopic image display for high-resolution examination of the downlinked imagery, and a sophisticated command-sequence editing tool for analysis and completion of the sequences. RSVP is linked with actual flight-code modules for operations rehearsal to provide feedback on the expected behavior of the rover prior to committing to a particular sequence. Playback tools allow for review of both rehearsed rover behavior and downlinked results of actual rover operations. These can be displayed simultaneously for comparison of rehearsed and actual activities for verification. The primary inputs to RSVP are downlink data products from the Operations Storage Server (OSS) and activity plans generated by the science team. The activity plans are high-level goals for the next day s activities. The downlink data products include imagery, terrain models, and telemetered engineering data on rover activities and state. The Rover Sequence Editor (RoSE) component of RSVP performs activity expansion to command sequences, command creation and editing with setting of command parameters, and viewing and management of rover resources. The HyperDrive component of RSVP performs 2D and 3D visualization of the rover s environment, graphical and animated review of rover-predicted and telemetered state, and creation and editing of command sequences related to mobility and Instrument Deployment Device (IDD) operations. Additionally, RoSE and HyperDrive together evaluate command sequences for potential violations of flight and safety rules. The products of RSVP include command sequences for uplink that are stored in the Distributed Object Manager (DOM) and predicted rover state histories stored in the OSS for comparison and validation of downlinked telemetry. The majority of components comprising RSVP utilize the MER command and activity dictionaries to automatically customize the system for MER activities. Thus, RSVP, being highly data driven, may be tailored to other missions with minimal effort. In addition, RSVP uses a distributed, message-passing architecture to allow multitasking, and collaborative visualization and sequence development by scattered team members.

Cooper, Brian↗
NASA NTRS2005

Update on Rover Sequencing and Visualization Program

The Rover Sequencing and Visualization Program (RSVP) has been updated. RSVP was reported in Rover Sequencing and Visualization Program (NPO-30845), NASA Tech Briefs, Vol. 29, No. 4 (April 2005), page 38. To recapitulate: The Rover Sequencing and Visualization Program (RSVP) is the software tool to be used in the Mars Exploration Rover (MER) mission for planning rover operations and generating command sequences for accomplishing those operations. RSVP combines three-dimensional (3D) visualization for immersive exploration of the operations area, stereoscopic image display for high-resolution examination of the downlinked imagery, and a sophisticated command-sequence editing tool for analysis and completion of the sequences. RSVP is linked with actual flight code modules for operations rehearsal to provide feedback on the expected behavior of the rover prior to committing to a particular sequence. Playback tools allow for review of both rehearsed rover behavior and downlinked results of actual rover operations. These can be displayed simultaneously for comparison of rehearsed and actual activities for verification. The primary inputs to RSVP are downlink data products from the Operations Storage Server (OSS) and activity plans generated by the science team. The activity plans are high-level goals for the next day s activities. The downlink data products include imagery, terrain models, and telemetered engineering data on rover activities and state. The Rover Sequence Editor (RoSE) component of RSVP performs activity expansion to command sequences, command creation and editing with setting of command parameters, and viewing and management of rover resources. The HyperDrive component of RSVP performs 2D and 3D visualization of the rover s environment, graphical and animated review of rover predicted and telemetered state, and creation and editing of command sequences related to mobility and Instrument Deployment Device (robotic arm) operations. Additionally, RoSE and HyperDrive together evaluate command sequences for potential violations of flight and safety rules. The products of RSVP include command sequences for uplink that are stored in the Distributed Object Manager (DOM) and predicted rover state histories stored in the OSS for comparison and validation of downlinked telemetry. The majority of components comprising RSVP utilize the MER command and activity dictionaries to automatically customize the system for MER activities.

Cooper, Brian↗
NASA NTRS2013

Robot Sequencing and Visualization Program (RSVP)

The Robot Sequencing and Visualization Program (RSVP) is being used in the Mars Science Laboratory (MSL) mission for downlink data visualization and command sequence generation. RSVP reads and writes downlink data products from the operations data server (ODS) and writes uplink data products to the ODS. The primary users of RSVP are members of the Rover Planner team (part of the Integrated Planning and Execution Team (IPE)), who use it to perform traversability/articulation analyses, take activity plan input from the Science and Mission Planning teams, and create a set of rover sequences to be sent to the rover every sol. The primary inputs to RSVP are downlink data products and activity plans in the ODS database. The primary outputs are command sequences to be placed in the ODS for further processing prior to uplink to each rover. RSVP is composed of two main subsystems. The first, called the Robot Sequence Editor (RoSE), understands the MSL activity and command dictionaries and takes care of converting incoming activity level inputs into command sequences. The Rover Planners use the RoSE component of RSVP to put together command sequences and to view and manage command level resources like time, power, temperature, etc. (via a transparent realtime connection to SEQGEN). The second component of RSVP is called HyperDrive, a set of high-fidelity computer graphics displays of the Martian surface in 3D and in stereo. The Rover Planners can explore the environment around the rover, create commands related to motion of all kinds, and see the simulated result of those commands via its underlying tight coupling with flight navigation, motor, and arm software. This software is the evolutionary replacement for the Rover Sequencing and Visualization software used to create command sequences (and visualize the Martian surface) for the Mars Exploration Rover mission.

Cooper, Brian K.↗
NASA NTRS2024

Hierarchical Semantic Frames for Grounding Language in Robot Control Primitives

As robots become increasingly present in human environments, we need robots to be intuitively commanded by and effectively communicate with humans. In particular, non-expert users should be able to communicate task goals with robots. Language emerges as a logical mode of interaction due to its ubiquity in human environments and, more importantly, as the way humans naturally express tasks. Natural language commands present challenges in that robots must reason over ambiguous language probabilistically and reason over commands they may not be able to execute. We present hierarchical semantic frames , which ground commands in robot control primitives through hierarchies that construct high-level commands from lower-level commands. We demonstrate that hierarchical semantic frames allow robots to understand and execute a variety of commands, such as those involving multiple verb meanings, command variations, and compound nouns. The robot quickly processes hierarchical semantic frames and accurately grounds and executes the commanded tasks, demonstrating the power of hierarchical semantic frames for allowing users to intuitively interact with robots.

Emily Sheetz↗
NASA NTRS1975

Roll maneuver evaluation

The current roll maneuver to the flight azimuth following lift-off is achieved by commanding roll attitude using a linear profile with no roll rate command. The linearity of this command profile implies an infinite acceleration to a constant roll rate; the vehicle cannot instantaneously achieve this rate, so the actual roll attitude lags the command attitude throughout the maneuver. The roll attitude error which thus develops can be reduced by augmenting the attitude command with a rate command and utilizing finite slopes on the rate command to give the vehicle time to accelerate. Results obtained from commanding various roll attitude and rate combinations to perform the maneuver are presented.

Webb, W. W.↗
NASA NTRS1993

Software to model AXAF image quality

This draft final report describes the work performed under this delivery order from May 1992 through June 1993. The purpose of this contract was to enhance and develop an integrated optical performance modeling software for complex x-ray optical systems such as AXAF. The GRAZTRACE program developed by the MSFC Optical Systems Branch for modeling VETA-I was used as the starting baseline program. The original program was a large single file program and, therefore, could not be modified very efficiently. The original source code has been reorganized, and a 'Make Utility' has been written to update the original program. The new version of the source code consists of 36 small source files to make it easier for the code developer to manage and modify the program. A user library has also been built and a 'Makelib' utility has been furnished to update the library. With the user library, the users can easily access the GRAZTRACE source files and build a custom library. A user manual for the new version of GRAZTRACE has been compiled. The plotting capability for the 3-D point spread functions and contour plots has been provided in the GRAZTRACE using the graphics package DISPLAY. The Graphics emulator over the network has been set up for programming the graphics routine. The point spread function and the contour plot routines have also been modified to display the plot centroid, and to allow the user to specify the plot range, and the viewing angle options. A Command Mode version of GRAZTRACE has also been developed. More than 60 commands have been implemented in a Code-V like format. The functions covered in this version include data manipulation, performance evaluation, and inquiry and setting of internal parameters. The user manual for these commands has been formatted as in Code-V, showing the command syntax, synopsis, and options. An interactive on-line help system for the command mode has also been accomplished to allow the user to find valid commands, command syntax, and command function. A translation program has been written to convert FEA output from structural analysis to GRAZTRACE surface deformation file (.dfm file). The program can accept standard output files and list files from COSMOS/M and NASTRAN finite analysis programs. Some interactive options are also provided, such as Cartesian or cylindrical coordinate transformation, coordinate shift and scale, and axial length change. A computerized database for technical documents relating to the AXAF project has been established. Over 5000 technical documents have been entered into the master database. A user can now rapidly retrieve the desired documents relating to the AXAF project. The summary of the work performed under this contract is shown.

Ahmad, Anees↗
NASA NTRS1996

Flight evaluation of advanced controls and displays for transition and landing on the NASA V/STOL systems research aircraft

Flight experiments were conducted on Ames Research Center's V/STOL Systems Research Aircraft (VSRA) to assess the influence of advanced control modes and head-up displays (HUD's) on flying qualities for precision approach and landing operations. Evaluations were made for decelerating approaches to hover followed by a vertical landing and for slow landings for four control/display mode combinations: the basic YAV-8B stability augmentation system; attitude command for pitch, roll, and yaw; flightpath/acceleration command with translational rate command in the hover; and height-rate damping with translational-rate command. Head-up displays used in conjunction with these control modes provided flightpath tracking/pursuit guidance and deceleration commands for the decelerating approach and a mixed horizontal and vertical presentation for precision hover and landing. Flying qualities were established and control usage and bandwidth were documented for candidate control modes and displays for the approach and vertical landing. Minimally satisfactory bandwidths were determined for the translational-rate command system. Test pilot and engineer teams from the Naval Air Warfare Center, the Boeing Military Airplane Group, Lockheed Martin, McDonnell Douglas Aerospace, Northrop Grumman, Rolls-Royce, and the British Defense Research Agency participated in the program along with NASA research pilots from the Ames and Lewis Research Centers. The results, in conjunction with related ground-based simulation data, indicate that the flightpath/longitudinal acceleration command response type in conjunction with pursuit tracking and deceleration guidance on the HUD would be essential for operation to instrument minimums significantly lower than the minimums for the AV-8B. It would also be a superior mode for performing slow landings where precise control to an austere landing area such as a narrow road is demanded. The translational-rate command system would reduce pilot workload for demanding vertical landing tasks aboard ship and in confined land-based sites.

Franklin, James A.↗