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 667 records · Page 37
All sourcesNASA NTRSDOE OSTI
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↗
DOE OSTI2020

High command fidelity electromagnetically driven calorimeter

An example apparatus can comprise an emitter to emit radio frequency radiation, an absorber that changes temperature based on emissions from the emitter, and one or more sensors to measure a temperature difference between a sample and a reference coupled to the absorber.

42 ENGINEERING↗
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.↗