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.

SourceResearch connectionFrom yearThrough year

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

At least 1,081 records · Page 60

All sources NASA NTRS DOE OSTI

NASA NTRS2005

Predictive Interfaces for Long-Distance Tele-Operations

We address the development of predictive tele-operator interfaces for humanoid robots with respect to two basic challenges. Firstly, we address automating the transition from fully tele-operated systems towards degrees of autonomy. Secondly, we develop compensation for the time-delay that exists when sending telemetry data from a remote operation point to robots located at low earth orbit and beyond. Humanoid robots have a great advantage over other robotic platforms for use in space-based construction and maintenance because they can use the same tools as astronauts do. The major disadvantage is that they are difficult to control due to the large number of degrees of freedom, which makes it difficult to synthesize autonomous behaviors using conventional means. We are working with the NASA Johnson Space Center's Robonaut which is an anthropomorphic robot with fully articulated hands, arms, and neck. We have trained hidden Markov models that make use of the command data, sensory streams, and other relevant data sources to predict a tele-operator's intent. This allows us to achieve subgoal level commanding without the use of predefined command dictionaries, and to create sub-goal autonomy via sequence generation from generative models. Our method works as a means to incrementally transition from manual tele-operation to semi-autonomous, supervised operation. The multi-agent laboratory experiments conducted by Ambrose et. al. have shown that it is feasible to directly tele-operate multiple Robonauts with humans to perform complex tasks such as truss assembly. However, once a time-delay is introduced into the system, the rate of tele\ioperation slows down to mimic a bump and wait type of activity. We would like to maintain the same interface to the operator despite time-delays. To this end, we are developing an interface which will allow for us to predict the intentions of the operator while interacting with a 3D virtual representation of the expected state of the robot. The predictive interface anticipates the intention of the operator, and then uses this prediction to initiate appropriate sub-goal autonomy tasks.

Wheeler, Kevin R.↗

NASA NTRS2006

Entertainment and Pacification System For Car Seat

An entertainment and pacification system for use with a child car seat has speakers mounted in the child car seat with a plurality of audio sources and an anti-noise audio system coupled to the child car seat. A controllable switching system provides for, at any given time, the selective activation of i) one of the audio sources such that the audio signal generated thereby is coupled to one or more of the speakers, and ii) the anti-noise audio system such that an ambient-noise-canceling audio signal generated thereby is coupled to one or more of the speakers. The controllable switching system can receive commands generated at one of first controls located at the child car seat and second controls located remotely with respect to the child car seat with commands generated by the second controls overriding commands generated by the first controls.

Elrod, Susan Vinz↗

NASA NTRS2006

A Low Noise, Microprocessor-Controlled, Internally Digitizing Rotating-Vane Electric Field Mill for Airborne Platforms

This paper reports on a new generation of aircraft-based rotating-vane style electric field mills designed and built at NASA's Marshall Spaceflight Center. The mills have individual microprocessors that digitize the electric field signal at the mill and respond to commands from the data system computer. The mills are very sensitive (1 V/m per bit), have a wide dynamic range (115 dB), and are very low noise (+/-1 LSB). Mounted on an aircraft, these mills can measure fields from +/-1 V/m to +/-500 kV/m. Once-per-second commanding from the data collection computer to each mill allows for precise timing and synchronization. The mills can also be commanded to execute a self-calibration in flight, which is done periodically to monitor the status and health of each mill.

Bateman, M. G.↗

NASA NTRS2006

Global Radius of Curvature Estimation and Control System for Segmented Mirrors

An apparatus controls positions of plural mirror segments in a segmented mirror with an edge sensor system and a controller. Current mirror segment edge sensor measurements and edge sensor reference measurements are compared with calculated edge sensor bias measurements representing a global radius of curvature. Accumulated prior actuator commands output from an edge sensor control unit are combined with an estimator matrix to form the edge sensor bias measurements. An optimal control matrix unit then accumulates the plurality of edge sensor error signals calculated by the summation unit and outputs the corresponding plurality of actuator commands. The plural mirror actuators respond to the actuator commands by moving respective positions of the mixor segments. A predetermined number of boundary conditions, corresponding to a plurality of hexagonal mirror locations, are removed to afford mathematical matrix calculation.

Rakoczy, John M.↗

NASA NTRS2006

The K9 On-Board Rover Architecture

This paper describes the software architecture of NASA Ames Research Center s K9 rover. The goal of the onboard software architecture team was to develop a modular, flexible framework that would allow both high- and low-level control of the K9 hardware. Examples of low-level control are the simple drive or pan/tilt commands which are handled by the resource managers, and examples of high-level control are the command sequences which are handled by the conditional executive. In between these two control levels are complex behavioral commands which are handled by the pilot, such as drive to goal with obstacle avoidance or visually servo to a target. This paper presents the design of the architecture as of Fall 2000. We describe the state of the architecture implementation as well as its current evolution. An early version of the architecture was used for K9 operations during a dual-rover field experiment conducted by NASA Ames Research Center (ARC) and the Jet Propulsion Laboratory (JPL) from May 14 to May 16, 2000.

Bresina, John L.↗

NASA NTRS2006

Standardizing an End-to-end Accounting Service

Currently there are no space system standards available for space agencies to accomplish end-to-end accounting. Such a standard does not exist for spacecraft operations nor for tracing the relationship between the mission planning activities, the command sequences designed to perform those activities, the commands formulated to initiate those activities and the mission data and specifically the mission data products created by those activities. In order for space agencies to cross-support one another for data accountability/data tracing and for inter agency spacecraft to interoperate with each other, an international CCSDS standard for end-to-end data accountability/tracing needs to be developed. We will first describe the end-to-end accounting service model and functionality that supports the service. This model will describe how science plans that are ultimately transformed into commands can be associated with the telemetry products generated as a result of their execution. Moreover, the interaction between end-to-end accounting and service management will be explored. Finally, we will show how the standard end-to-end accounting service can be applied to a real life flight project i.e., the Mars Reconnaissance Orbiter project.

recommendations↗

NASA NTRS2012

SRMS Assisted Docking and Undocking for the Orbiter Repair Maneuver

As part of the Orbiter Repair Maneuver (ORM) planned for Return to Flight (RTF) operations, the Shuttle Remote Manipulator System (SRMS) must undock the Orbiter, maneuver it through a complex trajectory at extremely low rates, present it to an EVA crewman at the end of the Space Station Remote Manipulator System to perform the Thermal Protection System (TPS) repair, and then retrace back through the trajectory to dock the Orbiter with the Orbiter Docking System (ODS). The initial and final segments of this operation involve the interaction between the SRMS, ISS, Orbiter and ODS. Previously, a technique entitled "SRMS assisted docking" for installation of a payload to the ODS had been developed and was utilized for the Russian provided Docking Module on STS-74 during Shuttle-Mir missions and both the Node 1 and FGB elements on STS-88/Flight 2A. This procedure consisted of the SRMS grappling the respective payload, maneuvering it to a pre-install position inches above the ODS Androgynous Peripheral Attachment System (APAS) ring, commanding the SRMS into Test mode (which allows brakes-off motion of the joints), and then down-firing Primary Reaction Control System (PRCS) jets in order to effect a capture of the APAS latches. Once a successful capture had been achieved, then the AP AS was operated through its nominal retraction sequence to complete the mating sequence. While this technique can once again be used for the tail end docking portion of the ORM, the initial undocking of the orbiter and ISS vehicles with the assistance of the SRMS has yet to be attempted on orbit. The objective here is to determine the most efficient means to separate or extract the vehicles. Two techniques were analyzed in support of RTF: (1) the 'nominal' demating from the mated interface, and (2) the SRMS performing the operation (either in an active or passive fashion). In the first operation, the demating process would replicate standard undocking operations, with the exception that the SRMS is allowed to arrest the resulting motion. The second operation would be to extend the APAS ring to a ready to dock position, open the capture latches, and then detach the vehicles using the SRMS either actively or passively. In the active case, the APAS ring is extended and latched, and the SRMS is commanded to pull the two interfaces apart (assuming that the effective pull force of the SRMS can overcome the spec values of the combined latch resistance). In the passive case, the SRMS brakes are engaged and the AP AS mechanism is commanded to retract, pulling the two interfaces apart. Since the emphasis of both STS-74 and STS-88 had solely been on the installation operation, as opposed to the separation operation, two new models required development and incorporation within simulation tools designed to analyze those scenarios. These enhancements included: (1) a detailed demating dynamics model to characterize the pusher spring characteristics during undocking, and (2) contact and mechanical system modeling of the back side of the latches to represent unlatching dynamics. This paper first provides an overview of the Monte-Carlo screening analysis for the installation (both nominal and contingency), including the variation of separation distance, misalignment conditions, SRMS joint/brake parameter characteristics, and PRCS jet combinations and corresponding thrust durations. The resulting 'optimum' solution is presented based on trade studies between predicted capture success and integrated system loads. This paper then discusses the upgrades to the APAS math model associated with the new SRMS assisted undocking technique and reviews simulation results for various options investigated for either the active and passive separation of the ISS from the Orbiter.

Space Station Remote Manipulator System↗

NASA NTRS2007

Robotics

Lunar robotic functions include: 1. Transport of crew and payloads on the surface of the moon; 2. Offloading payloads from a lunar lander; 3. Handling the deployment of surface systems; with 4. Human commanding of these functions from inside a lunar vehicle, habitat, or extravehicular (space walk), with Earth-based supervision. The systems that will perform these functions may not look like robots from science fiction. In fact, robotic functions may be automated trucks, cranes and winches. Use of this equipment prior to the crew s arrival or in the potentially long periods without crews on the surface, will require that these systems be computer controlled machines. The public release of NASA's Exploration plans at the 2nd Space Exploration Conference (Houston, December 2006) included a lunar outpost with as many as four unique mobility chassis designs. The sequence of lander offloading tasks involved as many as ten payloads, each with a unique set of geometry, mass and interface requirements. This plan was refined during a second phase study concluded in August 2007. Among the many improvements to the exploration plan were a reduction in the number of unique mobility chassis designs and a reduction in unique payload specifications. As the lunar surface system payloads have matured, so have the mobility and offloading functional requirements. While the architecture work continues, the community can expect to see functional requirements in the areas of surface mobility, surface handling, and human-systems interaction as follows: Surface Mobility 1. Transport crew on the lunar surface, accelerating construction tasks, expanding the crew s sphere of influence for scientific exploration, and providing a rapid return to an ascent module in an emergency. The crew transport can be with an un-pressurized rover, a small pressurized rover, or a larger mobile habitat. 2. Transport Extra-Vehicular Activity (EVA) equipment and construction payloads. 3. Transport habitats and power modules over long distances, pre-positioning them for the arrival of crew on a subsequent lander. Surface Handling 1. Offload surface system payloads from the lander, breaking launch restraints and power/data connections. Payloads may be offloaded to a wheeled vehicle for transport. 2. Deploy payloads from a wheeled vehicle at a field site, placing the payloads in their final use site on the ground or mating them with existing surface systems. 3. Support regolith collection, site preparation, berm construction, or other civil engineering tasks using tools and implements attached to rovers. Human-Systems Interaction 1. Provide a safe command and control interface for suited EVA to ride on and drive the vehicles, making sure that the systems are also safe for working near dismounted crew. 2. Provide an effective control system for IV crew to tele-operate vehicles, cranes and other equipment from inside the surface habitats with evolving independence from Earth. .. Provide a supervisory system that allows machines to be commanded from the ground, working across the Earth-Lunar time delays on the order of 5-10 seconds (round trip) to support operations when crew are not resident on the surface. Technology Development Needs 1. Surface vehicles that can dock, align and mate with outpost equipment such as landers, habitats and fluid/power interfaces. 2. Long life motors, drive trains, seals, motor electronics, sensors, processors, cable harnesses, and dash board displays. 3. Active suspension control, localization, high speed obstacle avoidance, and safety systems for operating near dismounted crew. 4. High specific energy and specific power batteries that are safe, rechargeable, and long lived.

Ambrose, Robert O.↗

NASA NTRS2007

Orion Entry Flight Control Stability and Performance

The Orion Spacecraft will be required to perform entry and landing functions for both Low Earth Orbit (LEO) and Lunar return missions, utilizing only the Command Module (CM) with its unique systems and GN&C design. This paper presents the current CM Flight Control System (FCS) design to support entry and landing, with a focus on analyses that have supported its development to date. The CM FCS will have to provide for spacecraft stability and control while following guidance or manual commands during exo-atmospheric flight, after Service Module separation, translational powered flight required of the CM, atmospheric flight supporting both direct entry and skip trajectories down to drogue chute deploy, and during roll attitude reorientation just prior to touchdown. Various studies and analyses have been performed or are on-going supporting an overall FCS design with reasonably sized Reaction Control System (RCS) jets, that minimizes fuel usage, that provides appropriate command following but with reasonable stability and control margin. Results from these efforts to date are included, with particular attention on design issues that have emerged, such as the struggle to accommodate sub-sonic pitch and yaw control without using excessively large jets that could have a detrimental impact on vehicle weight. Apollo, with a similar shape, struggled with this issue as well. Outstanding CM FCS related design and analysis issues, planned for future effort, are also briefly be discussed.

Strahan, Alan L.↗

NASA NTRS2004

Characterization of bioelectric potentials

Method and system for recognizing and characterizing bioelectric potential or electromyographic (EMG) signals associated with at least one of a coarse gesture and a fine gesture that is performed by a person, and use of the bioelectric potentials to enter data and/or commands into an electrical and/or mechanical instrument. As a gesture is performed, bioelectric signals that accompany the gesture are subjected to statistical averaging, within selected time intervals. Hidden Markov model analysis is applied to identify hidden, gesture-related states that are present. A metric is used to compare signals produced by a volitional gesture (not yet identified) with corresponding signals associated with each of a set of reference gestures, and the reference gesture that is closest to the volitional gesture is identified. Signals representing the volitional gesture are analyzed and compared with a database of reference gestures to determine if the volitional gesture is likely to be one of the reference gestures. Electronic and/or mechanical commands needed to carry out the gesture may be implemented at an interface to control an instrument. Applications include control of an aircraft, entry of data from a keyboard or other data entry device, and entry of data and commands in extreme environments that interfere with accurate entry.

Jorgensen, Charles C.↗

NASA NTRS1986

Patient ECG recording control for an automatic implantable defibrillator

An implantable automatic defibrillator includes sensors which are placed on or near the patient's heart to detect electrical signals indicative of the physiology of the heart. The signals are digitally converted and stored into a FIFO region of a RAM by operation of a direct memory access (DMA) controller. The DMA controller operates transparently with respect to the microprocessor which is part of the defibrillator. The implantable defibrillator includes a telemetry communications circuit for sending data outbound from the defibrillator to an external device (either a patient controller or a physician's console or other) and a receiver for sensing at least an externally generated patient ECG recording command signal. The patient recording command signal is generated by the hand held patient controller. Upon detection of the patient ECG recording command, DMA copies the contents of the FIFO into a specific region of the RAM.

Fountain, Glen H.↗

NASA NTRS1988

Star sightings by satellite for image navigation

Stars are sensed by one or more instruments (1, 2) on board a three-axis stabilized satellite, for purposes of assisting in image navigation. A star acquistion computer (64), which may be located on the earth, commands the instrument mirror (33, 32) to slew just outside the limb of the earth or other celestial body around which the satellite is orbiting, to look for stars that have been cataloged in a star map stored within the computer (64). The instrument (1, 2) is commanded to dwell for a period of time equal to a star search window time, plus the maximum time the instrument (1, 2) takes to complete a current scan, plus the maximum time it takes for the mirror (33, 32) to slew to the star. When the satellite is first placed in orbit, and following first stationkeeping and eclipse, a special operation is performed in which the star-seeking instrument (1, 2) FOV is broadened. The elevation dimension can be broadened by performing repetitive star seeks; the azimuth dimension can be broadened by lengthening the commanded dwell times.

Kamel, Ahmed A.↗

NASA NTRS2005

Step 1: Human System Integration Simulation and Flight Test Progress Report

The Access 5 Human Systems Integration Work Package produced simulation and flight demonstration planning products for use throughout the program. These included: Test Objectives for Command, Control, Communications; Pilot Questionnaire for Command, Control, Communications; Air Traffic Controller Questionnaire for Command, Control, Communications; Test Objectives for Collision Avoidance; Pilot Questionnaire for Collision Avoidance; Plans for Unmanned Aircraft Systems Control Station Simulations Flight Requirements for the Airspace Operations Demonstration

Source record↗

NASA NTRS2008

Re-Engineering the Tropical Rainfall Measuring Mission (TRMM) Satellite Utilizing Goddard Space Flight Center (GSFC) Mission Services Center (GMSEC) Middleware Based Technology to Enable Lights Out Operations and Autonomous Re-Dump of Lost Telemetry Data

The Tropical Rainfall Measuring Mission (TRMM) spacecraft was launched in November of 1996 in order to obtain unique three dimensional radar cross sectional observations of cloud structures with particular interest in hurricanes. The TRMM mission life was recently extended with current estimates that operations will continue through the 2012-2013 timeframe. Faced with this extended mission profile, the project has embarked on a technology refresh and re-engineering effort. TRMM has recently implemented a re-engineering effort to expand a middleware based messaging architecture to enable fully redundant lights-out of flight operations activities. The middleware approach is based on the Goddard Mission Services Evolution Center (GMSEC) architecture, tools and associated open-source Applications Programming Interface (API). Middleware based messaging systems are useful in spacecraft operations and automation systems because private node based knowledge (such as that within a telemetry and command system) can be broadcast on the middleware messaging bus and hence enable collaborative decisions to be made by multiple subsystems. In this fashion, private data is made public and distributed within the local area network and multiple nodes can remain synchronized with other nodes. This concept is useful in a fully redundant architecture whereby one node is monitoring the processing of the 'prime' node so that in the event of a failure the backup node can assume operations of the prime, without loss of state knowledge. This paper will review and present the experiences, architecture, approach and lessons learned of the TRMM re-engineering effort centered on the GMSEC middleware architecture and tool suite. Relevant information will be presented that relates to the dual redundant parallel nature of the Telemetry and Command (T and C) and Front-End systems and how these systems can interact over a middleware bus to achieve autonomous operations including autonomous commanding to recover missing science data during the same spacecraft contact.

Marius, Julio L.↗

NASA NTRS2008

Mars Reconnaissance Orbiter Wrapper Script

The MRO OLVM wrapper script software allows Mars Reconnaissance Orbiter (MRO) sequence and spacecraft engineers to rapidly simulate a spacecraft command product through a tool that simulates the onboard sequence management software (OLVM). This script parses sequence files to determine the appropriate time boundaries for the sequence, and constructs the script file to be executed by OLVM to span the entirety of the designated sequence. It then constructs script files to be executed by OLVM, constructs the appropriate file directories, populates these directories with needed input files, initiates OLVM to simulate the actual command product that will be sent to the spacecraft, and captures the results of the simulation run to an external file for later review. Additionally, the tool allows a user to manually construct the script, if desired, and then execute the script with a simple command line.

Gladden, Roy↗

NASA NTRS2009

The Radio Frequency Health Node Wireless Sensor System

The Radio Frequency Health Node (RFHN) wireless sensor system differs from other wireless sensor systems in ways originally intended to enhance utility as an instrumentation system for a spacecraft. The RFHN can also be adapted to use in terrestrial applications in which there are requirements for operational flexibility and integrability into higher-level instrumentation and data acquisition systems. As shown in the figure, the heart of the system is the RFHN, which is a unit that passes commands and data between (1) one or more commercially available wireless sensor units (optionally, also including wired sensor units) and (2) command and data interfaces with a local control computer that may be part of the spacecraft or other engineering system in which the wireless sensor system is installed. In turn, the local control computer can be in radio or wire communication with a remote control computer that may be part of a higher-level system. The remote control computer, acting via the local control computer and the RFHN, cannot only monitor readout data from the sensor units but can also remotely configure (program or reprogram) the RFHN and the sensor units during operation. In a spacecraft application, the RFHN and the sensor units can also be configured more nearly directly, prior to launch, via a serial interface that includes an umbilical cable between the spacecraft and ground support equipment. In either case, the RFHN wireless sensor system has the flexibility to be configured, as required, with different numbers and types of sensors for different applications. The RFHN can be used to effect realtime transfer of data from, and commands to, the wireless sensor units. It can also store data for later retrieval by an external computer. The RFHN communicates with the wireless sensor units via a radio transceiver module. The modular design of the RFHN makes it possible to add radio transceiver modules as needed to accommodate additional sets of wireless sensor units. The RFHN includes a core module that performs generic computer functions, including management of power and input, output, processing, and storage of data. In a typical application, the processing capabilities in the RFHN are utilized to perform preprocessing, trending, and fusion of sensor data. The core module also serves as the unit through which the remote control computer configures the sensor units and the rest of the RFHN.

Valencia, J. Emilio↗

NASA NTRS2009

Autonomous Instrument Placement for Mars Exploration Rovers

Autonomous Instrument Placement (AutoPlace) is onboard software that enables a Mars Exploration Rover to act autonomously in using its manipulator to place scientific instruments on or near designated rock and soil targets. Prior to the development of AutoPlace, it was necessary for human operators on Earth to plan every motion of the manipulator arm in a time-consuming process that included downlinking of images from the rover, analysis of images and creation of commands, and uplinking of commands to the rover. AutoPlace incorporates image analysis and planning algorithms into the onboard rover software, eliminating the need for the downlink/uplink command cycle. Many of these algorithms are derived from the existing groundbased image analysis and planning algorithms, with modifications and augmentations for onboard use.

Leger, P. Chris↗

NASA NTRS2008

Improved CLARAty Functional-Layer/Decision-Layer Interface

Improved interface software for communication between the CLARAty Decision and Functional layers has been developed. [The Coupled Layer Architecture for Robotics Autonomy (CLARAty) was described in Coupled-Layer Robotics Architecture for Autonomy (NPO-21218), NASA Tech Briefs, Vol. 26, No. 12 (December 2002), page 48. To recapitulate: the CLARAty architecture was developed to improve the modularity of robotic software while tightening coupling between planning/execution and basic control subsystems. Whereas prior robotic software architectures typically contained three layers, the CLARAty contains two layers: a decision layer (DL) and a functional layer (FL).] Types of communication supported by the present software include sending commands from DL modules to FL modules and sending data updates from FL modules to DL modules. The present software supplants prior interface software that had little error-checking capability, supported data parameters in string form only, supported commanding at only one level of the FL, and supported only limited updates of the state of the robot. The present software offers strong error checking, and supports complex data structures and commanding at multiple levels of the FL, and relative to the prior software, offers a much wider spectrum of state-update capabilities.

Estlin, Tara↗