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 721 records · Page 40
All sourcesNASA NTRSDOE OSTI
NASA NTRS1997

Moving-Base Simulation Evaluation of Control/Display Integration Issues for ASTOVL Aircraft

A moving-base simulation has been conducted on the Vertical Motion Simulator at Ames Research Center using a model of an advanced, short takeoff and vertical landing (STOVL) lift fan fighter aircraft. This experiment expanded on investigations during previous simulations with this STOVL configuration with the objective of evaluating (1) control law modifications over the low speed flight envelope, (2) integration of the throttle inceptor with flight control laws that provide direct thrust command for conventional flight, vertical and short takeoff, and flightpath or vertical velocity command for transition, hover, and vertical landing, (3) control mode blending for pitch, roll, yaw, and flightpath control during transition from wing-borne to jet-borne flight, and (4) effects of conformal versus nonconformal presentation of flightpath and pursuit guidance symbology on the out-the-window display for low speed STOVL operations. Assessments were made for takeoff, transition, hover, and landing, including precision hover and landing aboard an LPH-type amphibious assault ship in the presence of winds and rough seas. Results yielded Level 1 pilot ratings for the flightpath and vertical velocity command modes for a range of land-based and shipboard operation and were consistent with previous experience with earlier control laws and displays for this STOVL concept. Control mode blending was performed over speed ranges in accord with the pilot's tasks and with the change of the basic aircraft's characteristics between wing-borne and hover flight. Blending of yaw control from heading command in hover to sideslip command in wing-borne flight performed over a broad speed range helped reduce yaw transients during acceleration through the low speed regime. Although the pilots appreciated conformality of flightpath and guidance symbols with the external scene during the approach, increased sensitivity of the symbols for lateral path tracking elevated the pilots' control activity in the presence of turbulence. The pilots preferred the choice of scaling that was originally established during the display development and in-flight evaluations.

Franklin, James A.↗
NASA NTRS1998

Secure Web-based Ground System User Interfaces over the Open Internet

A prototype has been developed which makes use of commercially available products in conjunction with the Java programming language to provide a secure user interface for command and control over the open Internet. This paper reports successful demonstration of: (1) Security over the Internet, including encryption and certification; (2) Integration of Java applets with a COTS command and control product; (3) Remote spacecraft commanding using the Internet. The Java-based Spacecraft Web Interface to Telemetry and Command Handling (Jswitch) ground system prototype provides these capabilities. This activity demonstrates the use and integration of current technologies to enable a spacecraft engineer or flight operator to monitor and control a spacecraft from a user interface communicating over the open Internet using standard World Wide Web (WWW) protocols and commercial off-the-shelf (COTS) products. The core command and control functions are provided by the COTS Epoch 2000 product. The standard WWW tools and browsers are used in conjunction with the Java programming technology. Security is provided with the current encryption and certification technology. This system prototype is a step in the direction of giving scientist and flight operators Web-based access to instrument, payload, and spacecraft data.

Langston, James H.↗
NASA NTRS2000

Autonomy Architectures for a Constellation of Spacecraft

Until the past few years, missions typically involved fairly large expensive spacecraft. Such missions have primarily favored using older proven technologies over more recently developed ones, and humans controlled spacecraft by manually generating detailed command sequences with low-level tools and then transmitting the sequences for subsequent execution on a spacecraft controller. This approach toward controlling a spacecraft has worked spectacularly on previous missions, but it has limitations deriving from communications restrictions - scheduling time to communicate with a particular spacecraft involves competing with other projects due to the limited number of deep space network antennae. This implies that a spacecraft can spend a long time just waiting whenever a command sequence fails. This is one reason why the New Millennium program has an objective to migrate parts of mission control tasks onboard a spacecraft to reduce wait time by making spacecraft more robust. The migrated software is called a "remote agent" and has 4 components: a mission manager to generate the high level goals, a planner/scheduler to turn goals into activities while reasoning about future expected situations, an executive/diagnostics engine to initiate and maintain activities while interpreting sensed events by reasoning about past and present situations, and a conventional real-time subsystem to interface with the spacecraft to implement an activity's primitive actions. In addition to needing remote planning and execution for isolated spacecraft, a trend toward multiple-spacecraft missions points to the need for remote distributed planning and execution. The past few years have seen missions with growing numbers of probes. Pathfinder has its rover (Sojourner), Cassini has its lander (Huygens), and the New Millenium Deep Space 3 (DS3) proposal involves a constellation of 3 spacecraft for interferometric mapping. This trend is expected to continue to progressively larger fleets. For example, one mission proposed to succeed DS3 would have 18 spacecraft flying in formation in order to detect earth-sized planets orbiting other stars. A proposed magnetospheric constellation would involve 5 to 500 spacecraft in Earth orbit to measure global phenomena within the magnetosphere. This work describes and compares three autonomy architectures for a system that continuously plans to control a fleet of spacecraft using collective mission goals instead of goals or command sequences for each spacecraft. A fleet of self-commanding spacecraft would autonomously coordinate itself to satisfy high level science and engineering goals in a changing partially-understood environment making feasible the operation of tens or even a hundred spacecraft (such as for interferometry or plasma physics missions). The easiest way to adapt autonomous spacecraft research to controlling constellations involves treating the constellation as a single spacecraft. Here one spacecraft directly controls the others as if they were connected. The controlling "master" spacecraft performs all autonomy reasoning, and the slaves only have real-time subsystems to execute the master's commands and transmit local telemetry/observations. The executive/diagnostics module starts actions and the master's real-time subsystem controls the action either locally or remotely through a slave. While the master/slave approach benefits from conceptual simplicity, it relies on an assumption that the master spacecraft's executive can continuously monitor the slaves' real-time subsystems, and this relies on high-bandwidth highly-reliable communications. Since unintended results occur fairly rarely, one way to relax the bandwidth requirements involves only monitoring unexpected events in spacecraft. Unfortunately, this disables the ability to monitor for unexpected events between spacecraft and leads to a host of coordination problems among the slaves. Also, failures in the communications system can result in losing slaves. The other two architectures improve robustness while reducing communications by progressively distributing more of the other three remote agent components across the constellation. In a teamwork architecture, all spacecraft have executives and real-time subsystems - only the leader has the planner/scheduler and mission manager. Finally, distributing all remote agent components leads to a peer-to-peer approach toward constellation control.

Barrett, Anthony↗
NASA NTRS2000

Reusable Launch Vehicle Control In Multiple Time Scale Sliding Modes

A reusable launch vehicle control problem during ascent is addressed via multiple-time scaled continuous sliding mode control. The proposed sliding mode controller utilizes a two-loop structure and provides robust, de-coupled tracking of both orientation angle command profiles and angular rate command profiles in the presence of bounded external disturbances and plant uncertainties. Sliding mode control causes the angular rate and orientation angle tracking error dynamics to be constrained to linear, de-coupled, homogeneous, and vector valued differential equations with desired eigenvalues placement. Overall stability of a two-loop control system is addressed. An optimal control allocation algorithm is designed that allocates torque commands into end-effector deflection commands, which are executed by the actuators. The dual-time scale sliding mode controller was designed for the X-33 technology demonstration sub-orbital launch vehicle in the launch mode. Simulation results show that the designed controller provides robust, accurate, de-coupled tracking of the orientation angle command profiles in presence of external disturbances and vehicle inertia uncertainties. This is a significant advancement in performance over that achieved with linear, gain scheduled control systems currently being used for launch vehicles.

Shtessel, Yuri↗
NASA NTRS2000

The NASA Spacecraft Transponding Modem

A new deep space transponder is being developed by the Jet Propulsion Laboratory for NASA. The Spacecraft Transponding Modem (STM) implements the standard transponder functions and the channel service functions that have previously resided in spacecraft Command/Data Subsystems. The STM uses custom ASICs, MMICs, and MCMs to reduce the active device parts count to 70, mass to I kg, and volume to 524 cc. The first STMs will be flown on missions launching in the 2003 time frame. The STM tracks an X-band uplink signal and provides both X-band and Ka-band downlinks, either coherent or non-coherent with the uplink. A NASA standard Command Detector Unit is integrated into the STM, along with a codeblock processor and a hardware command decoder. The decoded command codeblocks are output to the spacecraft command/data subsystem. Virtual Channel 0 (VC-0) (hardware) commands are processed and output as critical controller (CRC) commands. Downlink telemetry is received from the spacecraft data subsystem as telemetry frames. The STM provides the following downlink coding options: the standard CCSDS (7-1/2) convolutional coding, ReedSolomon coding with interleave depths one and five, (15-1/6) convolutional coding, and Turbo coding with rates 1/3 and 1/6. The downlink symbol rates can be linearly ramped to match the G/T curve of the receiving station, providing up to a 1 dB increase in data return. Data rates range from 5 bits per second (bps) to 24 Mbps, with three modulation modes provided: modulated subcarrier (3 different frequencies provided), biphase-L modulated direct on carrier, and Offset QPSK. Also, the capability to generate one of four non-harmonically related telemetry beacon tones is provided, to allow for a simple spacecraft status monitoring scheme for cruise phases of missions. Three ranging modes are provided: standard turn around ranging, regenerative pseudo-noise (PN) ranging, and Differential One-way Ranging (DOR) tones. The regenerative ranging provides the capability of increasing the ground received ranging SNR by up to 30 dB. Two different avionics interfaces to the command/data subsystem's data bus are provided: a MIL STD 1553B bus or an industry standard PCI interface. Digital interfaces provide the capability to control antenna selection (e.g., switching between high gain and low gain antennas) and antenna pointing (for future steered Ka-band antennas).

Berner, Jeff B.↗
NASA NTRS2002

Procedure for Tooth Contact Analysis of a Face Gear Meshing With a Spur Gear Using Finite Element Analysis

A procedure was developed to perform tooth contact analysis between a face gear meshing with a spur pinion using finite element analysis. The face gear surface points from a previous analysis were used to create a connected tooth solid model without gaps or overlaps. The face gear surface points were used to create a five tooth face gear Patran model (with rim) using Patran PCL commands. These commands were saved in a series of session files suitable for Patran input. A four tooth spur gear that meshes with the face gear was designed and constructed with Patran PCL commands. These commands were also saved in a session files suitable for Patran input. The orientation of the spur gear required for meshing with the face gear was determined. The required rotations and translations are described and built into the session file for the spur gear. The Abaqus commands for three-dimensional meshing were determined and verified for a simplified model containing one spur tooth and one face gear tooth. The boundary conditions, loads, and weak spring constraints were determined to make the simplified model work. The load steps and load increments to establish contact and obtain a realistic load was determined for the simplified two tooth model. Contact patterns give some insight into required mesh density. Building the two gears in two different local coordinate systems and rotating the local coordinate systems was verified as an easy way to roll the gearset through mesh. Due to limitation of swap space, disk space and time constraints of the summer period, the larger model was not completed.

Bibel, George↗
NASA NTRS2002

STS 107 Shuttle Press Kit: Providing 24/7 Space Science Research

Space shuttle mission STS-107, the 28th flight of the space shuttle Columbia and the 113th shuttle mission to date, will give more than 70 international scientists access to both the microgravity environment of space and a set of seven human researchers for 16 uninterrupted days. Columbia's 16-day mission is dedicated to a mixed complement of competitively selected and commercially sponsored research in the space, life and physical sciences. An international crew of seven, including the first Israeli astronaut, will work 24 hours a day in two alternating shifts to carry out experiments in the areas of astronaut health and safety; advanced technology development; and Earth and space sciences. When Columbia is launched from Kennedy Space Center's Launch Pad 39A it will carry a SPACEHAB Research Double Module (RDM) in its payload bay. The RDM is a pressurized environment that is accessible to the crew while in orbit via a tunnel from the shuttle's middeck. Together, the RDM and the middeck will accommodate the majority of the mission's payloads/experiments. STS-107 marks the first flight of the RDM, though SPACEHAB Modules and Cargo Carriers have flown on 17 previous space shuttle missions. Astronaut Rick Husband (Colonel, USAF) will command STS-107 and will be joined on Columbia's flight deck by pilot William 'Willie' McCool (Commander, USN). Columbia will be crewed by Mission Specialist 2 (Flight Engineer) Kalpana Chawla (Ph.D.), Mission Specialist 3 (Payload Commander) Michael Anderson (Lieutenant Colonel, USAF), Mission Specialist 1 David Brown (Captain, USN), Mission Specialist 4 Laurel Clark (Commander, USN) and Payload Specialist 1 Ilan Ramon (Colonel, Israeli Air Force), the first Israeli astronaut. STS-107 marks Husband's second flight into space - he served as pilot during STS-96, a 10-day mission that saw the first shuttle docking with the International Space Station. Husband served as Chief of Safety for the Astronaut Office until his selection to command the STS-107 crew. Anderson and Chawla will also be making their second spaceflights. Anderson first flew on STS-89 in January 1998 (the eighth Shuttle-Mir docking mission) while Chawla flew on STS-87 in November 1997 (the fourth U.S. Microgravity Payload flight). McCool, Brown, Clark and Ramon will be making their first flights into space.

Source record↗
NASA NTRS2003

TOPEX NASA Altimeter Operations Handbook, September 1992

This operations handbook identifies the commands for the NASA radar altimeter for the TOPEX/Poseidon spacecraft, defines the functions of these commands, and provides supplemental reference material for use by the altimeter operations personnel. The main emphasis of this document is placed on command types, command definitions, command sequences, and operational constraints. Additional document sections describe uploadable altimeter operating parameters, the telemetry stream data contents (for both the science and the engineering data), the Missions Operations System displays, and the spacecraft and altimeter health monitors.

Hancock, David W., III↗
NASA NTRS2004

Telescience Resource Kit Software Capabilities and Future Enhancements

The Telescience Resource Kit (TReK) is a suite of PC-based software applications that can be used to monitor and control a payload on board the International Space Station (ISS). This software provides a way for payload users to operate their payloads from their home sites. It can be used by an individual or a team of people. TReK provides both local ground support system services and an interface to utilize remote services provided by the Payload Operations Integration Center (POIC). by the POIC and to perform local data functions such as processing the data, storing it in local files, and forwarding it to other computer systems. TReK can also be used to build, send, and track payload commands. In addition to these features, work is in progress to add a new command management capability. This capability will provide a way to manage a multi- platform command environment that can include geographically distributed computers. This is intended to help those teams that need to manage a shared on-board resource such as a facility class payload. The environment can be configured such that one individual can manage all the command activities associated with that payload. This paper will provide a summary of existing TReK capabilities and a description of the new command management capability. For example, 7'ReK can be used to receive payload data distributed

Schneider, Michelle↗
NASA NTRS2006

AERCam Autonomy: Intelligent Software Architecture for Robotic Free Flying Nanosatellite Inspection Vehicles

The NASA Johnson Space Center has developed a nanosatellite-class Free Flyer intended for future external inspection and remote viewing of human spacecraft. The Miniature Autonomous Extravehicular Robotic Camera (Mini AERCam) technology demonstration unit has been integrated into the approximate form and function of a flight system. The spherical Mini AERCam Free Flyer is 7.5 inches in diameter and weighs approximately 10 pounds, yet it incorporates significant additional capabilities compared to the 35-pound, 14-inch diameter AERCam Sprint that flew as a Shuttle flight experiment in 1997. Mini AERCam hosts a full suite of miniaturized avionics, instrumentation, communications, navigation, power, propulsion, and imaging subsystems, including digital video cameras and a high resolution still image camera. The vehicle is designed for either remotely piloted operations or supervised autonomous operations, including automatic stationkeeping, point-to-point maneuvering, and waypoint tracking. The Mini AERCam Free Flyer is accompanied by a sophisticated control station for command and control, as well as a docking system for automated deployment, docking, and recharge at a parent spacecraft. Free Flyer functional testing has been conducted successfully on both an airbearing table and in a six-degree-of-freedom closed-loop orbital simulation with avionics hardware in the loop. Mini AERCam aims to provide beneficial on-orbit views that cannot be obtained from fixed cameras, cameras on robotic manipulators, or cameras carried by crewmembers during extravehicular activities (EVA s). On Shuttle or International Space Station (ISS), for example, Mini AERCam could support external robotic operations by supplying orthogonal views to the intravehicular activity (IVA) robotic operator, supply views of EVA operations to IVA and/or ground crews monitoring the EVA, and carry out independent visual inspections of areas of interest around the spacecraft. To enable these future benefits with minimal impact on IVA operators and ground controllers, the Mini AERCam system architecture incorporates intelligent systems attributes that support various autonomous capabilities. 1) A robust command sequencer enables task-level command scripting. Command scripting is employed for operations such as automatic inspection scans over a region of interest, and operator-hands-off automated docking. 2) A system manager built on the same expert-system software as the command sequencer provides detection and smart-response capability for potential system-level anomalies, like loss of communications between the Free Flyer and control station. 3) An AERCam dynamics manager provides nominal and off-nominal management of guidance, navigation, and control (GN&C) functions. It is employed for safe trajectory monitoring, contingency maneuvering, and related roles. This paper will describe these architectural components of Mini AERCam autonomy, as well as the interaction of these elements with a human operator during supervised autonomous control.

Fredrickson, Steven E.↗
NASA NTRS2006

Evaluating the Performance of the NASA LaRC CMF Motion Base Safety Devices

This paper describes the initial measured performance results of the previously documented NASA Langley Research Center (LaRC) Cockpit Motion Facility (CMF) motion base hardware safety devices. These safety systems are required to prevent excessive accelerations that could injure personnel and damage simulator cockpits or the motion base structure. Excessive accelerations may be caused by erroneous commands or hardware failures driving an actuator to the end of its travel at high velocity, stepping a servo valve, or instantly reversing servo direction. Such commands may result from single order failures of electrical or hydraulic components within the control system itself, or from aggressive or improper cueing commands from the host simulation computer. The safety systems must mitigate these high acceleration events while minimizing the negative performance impacts. The system accomplishes this by controlling the rate of change of valve signals to limit excessive commanded accelerations. It also aids hydraulic cushion performance by limiting valve command authority as the actuator approaches its end of travel. The design takes advantage of inherent motion base hydraulic characteristics to implement all safety features using hardware only solutions.

Gupton, Lawrence E.↗
NASA NTRS1977

Voice Controlled Wheelchair

Michael Condon, a quadraplegic from Pasadena, California, demonstrates the NASA-developed voice-controlled wheelchair and its manipulator, which can pick up packages, open doors, turn a TV knob, and perform a variety of other functions. A possible boon to paralyzed and other severely handicapped persons, the chair-manipulator system responds to 35 one-word voice commands, such as "go," "stop," "up," "down," "right," "left," "forward," "backward." The heart of the system is a voice-command analyzer which utilizes a minicomputer. Commands are taught I to the computer by the patient's repeating them a number of times; thereafter the analyzer recognizes commands only in the patient's particular speech pattern. The computer translates commands into electrical signals which activate appropriate motors and cause the desired motion of chair or manipulator. Based on teleoperator and robot technology for space-related programs, the voice-controlled system was developed by Jet Propulsion Laboratory under the joint sponsorship of NASA and the Veterans Administration. The wheelchair-manipulator has been tested at Rancho Los Amigos Hospital, Downey, California, and is being evaluated at the VA Prosthetics Center in New York City.

Source record↗
NASA NTRS1963

Apollo-Lunar Orbital Rendezvous Technique

The film shows artists rendition of the spacecrafts, boosters, and flight of the Apollo lunar missions. The Apollo spacecraft will consist of three modules: the manned Command Module; the Service Module, which contains propulsion systems; and the Lunar Excursion Module (LEM) to carry astronauts to the moon and back to the Command and Service Modules. The spacecraft will be launched via a three-stage Saturn booster. The first stage will provide 7.5 million pounds of thrust from five F-1 engines for liftoff and initial powered flight. The second stage will develop 1 million pounds of thrust from five J-2 engines to boost the spacecraft almost into Earth orbit. Immediately after ignition of the second stage, the Launch Escape System will be jettisoned. A single J-2 engine in the S4B stage will provide 200,000 pounds of thrust to place the spacecraft in an earth parking orbit. It also will be used to propel the spacecraft into a translunar trajectory, then it will separate from the Apollo Modules. Onboard propulsion systems will be used to insert the spacecraft into lunar orbit. Two astronauts will enter the LEM, which will separate from the command and service modules. The LEM will go into elliptical orbit and prepare for landing. The LEM will lift off of the Moon's surface to return to the Command and Service Modules, and most likely be left in lunar orbit. After leaving the Moon's orbit, and shortly before entering Earth's orbit, the Service Module will be ejected. The Command Module will be oriented for reentry into the Earth's atmosphere. A drogue parachute will deploy at approximately 50,000 feet, followed by the main parachute system for touchdown.

Source record↗
NASA NTRS2000

Stepper motor control that adjusts to motor loading

A system and method are provided for controlling a stepper motor having a rotor and a multi-phase stator. Sinusoidal command signals define a commanded position of the motor's rotor. An actual position of the rotor is sensed as a function of an electrical angle between the actual position and the commanded position. The actual position is defined by sinusoidal position signals. An adjustment signal is generated using the sinusoidal command signals and sinusoidal position signals. The adjustment signal is defined as a function of the cosine of the electrical angle. The adjustment signal is multiplied by each sinusoidal command signal to generate a corresponding set of excitation signals, each of which is applied to a corresponding phase of the multi-phase stator.

Howard, David E.↗
NASA NTRS1985

Total energy based flight control system

An integrated aircraft longitudinal flight control system uses a generalized thrust and elevator command computation (38), which accepts flight path angle, longitudinal acceleration command signals, along with associated feedback signals, to form energy rate error (20) and energy rate distribution error (18) signals. The engine thrust command is developed (22) as a function of the energy rate distribution error and the elevator position command is developed (26) as a function of the energy distribution error. For any vertical flight path and speed mode the outerloop errors are normalized (30, 34) to produce flight path angle and longitudinal acceleration commands. The system provides decoupled flight path and speed control for all control modes previously provided by the longitudinal autopilot, autothrottle and flight management systems.

Lambregts, Antonius A.↗
NASA NTRS2006

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 then converted into digital signals and transmitted back to the controller. In one embodiment, the bus controller sends commands and data a defined bit rate, and the network device interface senses this bit rate and sends data back to the bus controller using the defined bit rate.

Ellerbrock, Philip J.↗
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.↗