SEARCH · Search NASA

Results for “Mode Commander”

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 73 records · Page 4

All sources NASA NTRS DOE OSTI

NASA NTRSDate not supplied

Firmware Architecture of the ARMADAS Bolting Robot

The Automated Reconfigurable Mission Adaptive Digital Assembly Systems (ARMADAS) project, under development at NASA Ames Research Center, has demonstrated on-ground autonomous robotic assembly of extensive digital structures, and it is now moving forward towards in-space demonstration. The ARMADAS system comprises of the operation software, the operation user interface (opsUI), and a swarm of robots. The robotic system consists of a multitude of collaborative agents specifically designed to transport, place and bolt the building blocks, called voxels (volumetric pixels). This paper focuses on the bolting robot, referred to as Mobile Metamaterial Internal Co-Integrator (MMIC-I). MMIC-I is a battery-powered crawling robot. It navigates the structure through extension, contraction and gripping. Two distinct controller boards operate the robot's two symmetric modules, referred to as module A and B. Board A is the master board: it coordinates motion planning and motion primitives execution, hosts the WiFi client, performs periodic self-assessment and system idle check and triggers faults if anomalies are detected. Board B periodically sends a heartbeat to board A, through a wired communication channel that uses the Serial protocol. Additionally, board A's WiFi client receives heartbeat packet requests or motion/bolting commands from a dedicated server board, and acknowledges reception sending back a response heartbeat packet containing information about the overall robot status, e. g. electrical current and voltage values, target and actual angles, operating mode, fault status. Whenever a motion command is sent, the motion planning section of the firmware determines the current robot configuration, using Inertial Measurement Unit readings and the motors Pulse Width Modulation values. Afterwards, it calculates the list of primitives needed to reach the target state, and controls their execution in the proper order. MMIC-I can receive and execute motion and bolting commands only when it is in operational mode. MMIC-I has three operating modes: standby, operational and safed. Standby mode is automatically entered upon startup. While in standby mode, all motors are powered off, and the only accepted commands are the ones relative to a change of mode and heartbeat packet request. Fault detection causes the robot to automatically enter safed or standby mode. Whenever the detected fault occurs within a motion and requires immediate intervention, e. g. an over-current situation, the robot enters safed mode. Safed mode powers off all motors except for the locomotion module, thus preventing the robot from collapsing. Conversely, when the detected fault doesn't require immediate intervention (low battery warning, for instance), the robot enters standby mode after completing the ongoing motion. This paper provides a detailed discussion of MMIC-I's firmware architecture. It accurately describes the implementation approach for each module: sensor data reading, motor control and actuation, WiFi server-client communication, intra-boards Serial communication, operating modes and autonomous fault detection, motion planning, coordination and execution, etc. Moreover, in support of the software description, this paper includes a thorough characterization of MMIC-I's hardware and avionics.

In-space assembly↗

NASA NTRSDate not supplied

Astrobee Operations on the Iss: Gui’S Impact on the Operators’ Cognitive Load

The Astrobee free-flying robots have completed their fifth successful year of operations housed in the Japanese Experimental Module (JEM) on the International Space Station (ISS). In this paper, we introduce two Graphical User Interfaces (GUI) used to operate and monitor in real-time the Astrobee free-flying robots onboard the ISS and report on the impact these GUIs have in the operator’s cognitive load. A review of the state-of-the-art GUI design for remotely teleoperated scenarios with minimal time delay is presented and the study’s conclusion used to determine the elements and recommendations to create an interface that minimizes its impact on the overall performance of an operator during an activity at the ISS. The Ground Data System (GDS) is one of the two GUIs in the study: it contains several tabs, each of which displays a different set of controls for specific tasks e.g. Overview, Run Plan, Teleoperate, Guest Science; some also display video and a three-dimensional (3D) representation of the ISS and robot based on the Astrobee’s telemetry. Most tabs enable a single operator-robot connection, however some of its tabs are capable to monitor and control up to three Astrobees simultaneously. The GDS Helper is a text-based user interface created to facilitate commanding and monitoring of an Astrobee robot directly from an SSH session. In full interactive mode it displays a maximum of 5 sections: general commanding, feedback/ack, telemetry, guest science commanding, and data, all in one view. In batch mode, it enables complex command scripting while retaining some interactive capabilities. A comparative analysis between these GUIs is carried out at an analogous ISS environment at the NASA Ames Research Center’s Granite Lab and its results presented. While GDS is able to provide an operator with control and situational awareness via its video and 3D displays, its several tabs may introduce an overwhelming amount of information confusing and delaying the operator especially during time-sensitive maneuvers where the operator may need to switch back and forth between them. GDS helper in the other hand does not provide video or 3D displays thus not allowing an operator to attain situational awareness, however it provides the operator with a design displaying commonly used data in a single window, enabling the operator to understand the state of the robot at a glance and control it through a commands entered via keyboard instead of a combination of mouse clicks and keyboard input. The results of the experiments measure the cognitive load across several operators maneuvering Astrobee to accomplish tasks ranging from fully manual to supervised activities. A GUI combining a single window displaying data along video and a 3D display is expected to reduce the operator’s cognitive load.

Astrobee↗

NASA NTRS1995

Mode Transitions in Glass Cockpit Aircraft: Results of a Field Study

One consequence of increased levels of automation in complex control systems is the presence of modes. A mode is a particular configuration of a control system that defines how human command inputs are interpreted. In complex systems, modes also often determine a specific allocation of control authority between the human and automated systems. Even in simple static devices (e.g., electronic watches, word processors), the presence of modes has been found to cause problems in either-the acquisition or production of skilled performance. Many of these problems arise due to the fact that the selection of a mode causes device behavior to be mediated by hidden internal state information. For these simple systems, many of these interaction problems can be solved by the design of appropriate feedback to communicate internal state information to the human operator. In complex dynamic systems, however, the design issues associated with modes seem to trancend the problem of merely communicating internal state information via displayed feedback. In complex supervisory control systems (e.g., aircraft, spacecraft, military command and control), a key function of modes is the selection of a particular configuration of control authority between the human operator and automated control systems. One mode may result in full manual control, another may result in a mix of manual and automatic control, while a third may result in full automatic control over the entire system. The human operator selects an appropriate mode as a function of current goals, operating conditions, and operating procedures. Thus, the operator is put in a position of essentially trying to control two coupled dynamic systems: the target system itself, and also a highly complex suite of automation controlling the target system. From a historical perspective, it should probably not come as a surprise that very little information is available to guide the design of mode-oriented control systems. The topic of function allocation (i.e., the proper division of control authority among human and computer) has a long history in human-machine systems research. Although this research has produced some relevant guidelines, a design approach capable of defining appropriate allocations of control function between the human and automation is not yet available. As a result, the function allocation decision itself has been allocated to the operator, to be performed in real-time, in the operation of mode-oriented control systems. A variety of documented aircraft accidents and incidents suggest that the real-time selection and monitoring of control modes is a weak link in the effective operation of complex supervisory control systems. Research in human-machine systems and human-computer interaction has barely scraped the surface of the problem of understanding how operators manage this task.The purpose of this paper is to present the results of a field study which examined how operators manage mode selection in a complex supervisory control system. Data on mode engagements using the Boeing B757/767 auto-flight system were collected during approach and descent into four major airports in the East Coast of the United States. Protocols documenting mode selection, automatic mode changes, pilot actions, quantitative records of flight-path variables, and verbal reports during and after mode engagements were collected by an observer from the jumpseat. Observations were conducted on two typical trips between three airports. Each trip was be replicated 11 times, which yielded a total of 22 trips and 66 legs on which data were collected. All data collected concerned the same flight numbers, and therefore, the same time of day, same type of aircraft, and identical operational environments (e.g., ATC facilities, weather patterns, traffic flow etc.)

Degani, Asaf↗

NASA NTRS1974

Mariner Mars 1971 attitude control subsystem

The Mariner Mars 1971 attitude control subsystem (ACS) is discussed. It is comprised of a sun sensor set, a Canopus tracker, an inertial reference unit, two cold gas reaction control assemblies, two rocket engine gimbal actuators, and an attitude control electronics unit. The subsystem has the following eight operating modes: (1) launch, (2) sun acquisition, (3) roll search, (4) celestial cruise, (5) all-axes inertial, (6) roll inertial, (7) commanded turn, and (8) thrust vector control. In the celestial cruise mode, the position control is held to plus or minus 0.25 deg. Commanded turn rates are plus or minus 0.18 deg/s. The attitude control logic in conjunction with command inputs from other spacecraft subsystems establishes the ACS operating mode. The logic utilizes Sun and Canopus acquisition signals generated within the ACS to perform automatic mode switching so that dependence of ground control is minimized when operating in the sun acquisition, roll search, and celestial cruise modes. The total ACS weight is 65.7 lb, and includes 5.4 lb of nitrogen gas. Total power requirements vary from 9 W for the celestial cruise mode to 54 W for the commanded turn mode.

Edmunds, R. S.↗

NASA NTRS1971

The quasi-inertial and wide-deadband modes as backup attitude options for the Skylab mission

The quasi-inertial (QI) and wide deadband (WDB) modes were investigated as alternatives to the solar inertial (SI) mode in case two control moment gyros fail during the Skylab mission. Both modes provide a substantial reduction in propellant requirements from the solar interial hold requirement with either the orbital assembly/thruster attitude control system or service module reaction control system. Spacecraft motion in the QI mode is produced by a command rate and results in a small amplitude oscillation (17 deg, maximum) about the SI orientation. In the WDB mode a somewhat similar, but larger amplitude motion (35 deg maximum) about the SI orientation is developed by appropriate choice of controller deadbands and switch line slopes.

Elrod, B. D.↗

NASA NTRS2005

Control Method for Video Guidance Sensor System

A method is provided for controlling operations in a video guidance sensor system wherein images of laser output signals transmitted by the system and returned from a target are captured and processed by the system to produce data used in tracking of the target. Six modes of operation are provided as follows: (i) a reset mode; (ii) a diagnostic mode; (iii) a standby mode; (iv) an acquisition mode; (v) a tracking mode; and (vi) a spot mode wherein captured images of returned laser signals are processed to produce data for all spots found in the image. The method provides for automatic transition to the standby mode from the reset mode after integrity checks are performed and from the diagnostic mode to the reset mode after diagnostic operations are commands is permitted only when the system is in the carried out. Further, acceptance of reset and diagnostic standby mode. The method also provides for automatic transition from the acquisition mode to the tracking mode when an acceptable target is found.

Richard T Howard↗

NASA NTRS1985

User interface enhancement report

The existing user interfaces to TEMPUS, Plaid, and other systems in the OSDS are fundamentally based on only two modes of communication: alphanumeric commands or data input and grapical interaction. The latter are especially suited to the types of interaction necessary for creating workstation objects with BUILD and with performing body positioning in TEMPUS. Looking toward the future application of TEMPUS, however, the long-term goals of OSDS will include the analysis of extensive tasks in space involving one or more individuals working in concert over a period of time. In this context, the TEMPUS body positioning capability, though extremely useful in creating and validating a small number of particular body positions, will become somewhat tedious to use. The macro facility helps somewhat, since frequently used positions may be easily applied by executing a stored macro. The difference between body positioning and task execution, though subtle, is important. In the case of task execution, the important information at the user's level is what actions are to be performed rather than how the actions are performed. Viewed slightly differently, the what is constant over a set of individuals though the how may vary.

Badler, N. I.↗

NASA NTRS1994

Beware of agents when flying aircraft: Basic principles behind a generic methodology for the evaluation and certification of advanced aviation systems

There is currently a growing interest in the aeronautical community to assess the effects of the increasing levels of automation on pilots' performance and overall safety. The first effect of automation is the change in the nature of the pilot's role on the flight deck. Pilots have become supervisors who monitor aircraft systems in usual situations and intervene only when unanticipated events occur. Instead of 'hand flying' the airplane, pilots contribute to the control of aircraft by acting as mediators, instructions given to the automation. By eliminating the need for manually controlling normal situations, such a role division has reduced the opportunities for the pilot to acquire experience and skills necessary to safely cope with abnormal events. Difficulties in assessing the state and behavior of automation arise mainly from four factors: (1) the complexity of current systems and consequence mode-related problems; (2) the intrinsic autonomy of automation which is able to fire mode transitions without explicit commands from the pilots; (3) the bad quality of feed-back from the control systems displays and interfaces to the pilots; and (4) the fact that the automation currently has no explicit representation of the current pilots' intentions and strategy. Assuming certification has among its major goals to guarantee the passengers' and pilots' safety and the airplane integrity under normal and abnormal operational conditions, the authors suggest it would be particularly fruitful to come up with a conceptual reference system providing the certification authorities both with a theoretical framework and a list of principles usable for assessing the quality of the equipment and designs under examination. This is precisely the scope of this paper. However, the authors recognize that the conceptual presented is still under development and would thus be best considered as a source of reflection for the design, evaluation and certification processes of advanced aviation technologies.

Javaux, Denis↗

NASA NTRS2002

Science opportunity analyzer - a multi-mission tool for planning

For many years the diverse scientific community that supports JPL's wide variety ofinterplanetary space missions has needed a tool in order to plan and develop their experiments. The tool needs to be easily adapted to various mission types and portable to the user community. The Science Opportunity Analyzer, SOA, now in its third year of development, is intended to meet this need. SOA is a java-based application that is designed to enable scientists to identify and analyze opportunities for science observations from spacecraft. It differs from other planning tools in that it does not require an in-depth knowledge of the spacecraft command system or operation modes to begin high level planning. Users can, however, develop increasingly detailed levels of design. SOA consists of six major functions: Opportunity Search, Visualization, Observation Design, Constraint Checking, Data Output and Communications. Opportunity Search is a GUI driven interface to existing search engines that can be used to identify times when a spacecraft is in a specific geometrical relationship with other bodies in the solar system. This function can be used for advanced mission planning as well as for making last minute adjustments to mission sequences in response to trajectory modifications. Visualization is a key aspect of SOA. The user can view observation opportunities in either a 3D representation or as a 2D map projection. The user is given extensive flexibility to customize what is displayed in the view. Observation Design allows the user to orient the spacecraft and visualize the projection of the instrument field of view for that orientation using the same views as Opportunity Search. Constraint Checking is provided to validate various geometrical and physical aspects of an observation design. The user has the ability to easily create custom rules or to use official project-generated flight rules. This capability may also allow scientists to easily impact the cost to science if flight rule changes occur. Data Output generates information based on the spacecraft's trajectory, opportunity search results or based on a created observation. The data can be viewed either in tabular format or as a graph. Finally, SOA is unique in that it is designed to be able to communicate with a variety of existing planning and sequencing tools. From the very beginning SOA was designed with the user in mind. Extensive surveys of the potential user community were conducted in order to develop the software requirements. Throughout the development period, close ties have been maintained with the science community to insure that the tool maintains its user focus. Although development is still in its early stages, SOA is already developing a user community on the Cassini project, which is depending on this tool for their science planning. There are other tools at JPL that do various pieces of what SOA can do; however, there is no other tool which combines all these functions and presents them to the user in such a convenient, cohesive, and easy to use fashion.

SOA science planning mission operations sequence s↗

NASA NTRSDate not supplied

Hamiltonian Control for Coupled Bending-Torsion Motion of a Swept Wing With R. T. Jones' Approximation

This paper presents distributed Hamiltonian control design approach for a Lagrangian infinite-dimensional system describing the coupled bending-torsion motion of a swept wing in unsteady airflow, which is taken into account using Theodorsen's complex valued function of reduced frequency. An implementable flutter suppressing control surface deflection commands are obtained using modes separation and R.T. Jones's approximation, and were validated in desktop simulations for flight conditions beyond the flutter airspeed.

Vahram Stepanyan↗

NASA NTRS2009

CSM RCS Design Considerations and Failure Modes

Objectives include: a) Define major Command and Service Module (CSM) design considerations; b) List Command Module (CM) RCS failures and lessons learned; and c) List Service Module (SM) RCS failures and lessons learned.

Interbartolo, Michael↗

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

NASA NTRS2013

Design and Demonstration of Emergency Control Modes for Enhanced Engine Performance

A design concept is presented for developing control modes that enhance aircraft engine performance during emergency flight scenarios. The benefits of increased engine performance to overall vehicle survivability during these situations may outweigh the accompanied elevated risk of engine failure. The objective involves building control logic that can consistently increase engine performance beyond designed maximum levels based on an allowable heightened probability of failure. This concept is applied to two previously developed control modes: an overthrust mode that increases maximum engine thrust output and a faster response mode that improves thrust response to dynamic throttle commands. This paper describes the redesign of these control modes and presents simulation results demonstrating both enhanced engine performance and robust maintenance of the desired elevated risk level.

aircraft engine simulation↗

NASA NTRS2015

CloudSat Anomaly and Return to the A-Train: Lessons Learned for Satellite Constellations

In April 2011, CloudSat suffered a severe battery anomaly, leaving the space-craft in emergency mode without the ability to command or maneuver the spacecraft. Before the team was able to recover spacecraft operability, CloudSat passed close to the Aqua satellite in the A-Train and then exited the A-Train. A new mode of operations, termed Daylight Only Operations (DO-Op) mode was developed to enable CloudSat to resume science operations in an orbit under the A-Train by November 2011, and in July 2012 CloudSat re-entered the A-Train. This paper describes challenges and lessons-learned during the anomaly, the exit from the A-Train and the return to the A-Train. These lessons-learned may ap-ply to other current and future satellite constellations in Earth orbit.

formation-flying↗

NASA NTRS1988

Telescope protection algorithm for the Space Infrared Telescope Facility

This paper presents a proposed on-board Telescope Protection Algorithm (TPA) for the Space Infrared Telescope Facility (SIRTF). This TPA consists of hardware and software capable of performing both fail-operational and fail-safe modes of operation. In the fail-operational mode, each ephemeris load and slew/dwell command sequence is checked on-board before use. The slew command monitor detects unallowable slew/dwell commands and transfers control to an algorithm which slews to and maintains a safe telescope orientation while preserving precise attitude determination and control. This fail-operational mode is also given the authority to autonomously restart the slew/dwell sequence at a point beyond the faulty command. The fail-safe system consists of software and hardware which detects impending earth, moon, or sun avoidance zone violations and activates a backup hardware safe hold mode. The subject TPA and relevant sensor complement were designed for the SIRTF mission; however, this system can easily be used as a basis for failure detection and correction in a wide range of other missions.

Class, B. F.↗

NASA NTRSDate not supplied

Twenty Years of Terra MODIS Spatial Performance Using the Spectro-Radiometric Calibration Assembly

The Moderate Resolution Imaging Spectroradiometer (MODIS) instrument on-board the NASA’s Earth Observing System Terra satellite has continued successful Earth-sensing operations for over 20 years. To aid in its mission in providing calibrated science data to the worldwide user community, the MODIS instrument is equipped with several on-board calibrators designed to measure changes in the instrument response over time. One such calibrator is the Spectro-Radiometric Calibration Assembly (SRCA), which can provide a source signal for radiometric, spectral, or spatial characterization. When commanded into its spatial calibration mode, the SRCA is able to produce light across the MODIS band spectral range (0.412μm to 14.2μm) at a variety of signal levels thanks to several internal halogen lamps, an IR glow bar, and a neutral density filter. This signal, used in combination with commanded sub-sample measurements of the MODIS detectors, provides a basis for determining changes in the spatial performance of the MODIS spectral bands. This work summarizes the spatial calibration process using the SRCA and presents 20 years of Terra MODIS spatial performance characterized through co-registration between MODIS bands, detectors, and focal plane assemblies. Results from pre-launch testing using the Integration and Alignment Collimator and the SRCA are incorporated in the history of the Terra MODIS mission-long spatial performance. We also note modifications to the spatial characterization methodology brought on by changes to the SRCA’s operational configuration and changes to the MODIS spectral band performance, particularly after the recovery from the safe-mode event in February 2016. Results are compared against the MODIS design specifications.

MODIS↗

NASA NTRS1984

A preliminary analysis of flight data from the AFTI/F-16 airplane

Flight test data from the AFTI/F-16 airplane are analyzed. Two flight control system modes (Independent Backup Unit and Standard Normal Mode) are considered. Estimated stability and control derivatives are compared with values from the wind tunnel and F-16A flight tests. Modeling difficulties are shown to arise due to the near-neutral static stability of the airplane and the number of coordinated control surface movements commanded in the Standard Normal Mode.

Batterson, J. G.↗

NASA NTRS1994

A software architecture for automating operations processes

The Operations Engineering Lab (OEL) at JPL has developed a software architecture based on an integrated toolkit approach for simplifying and automating mission operations tasks. The toolkit approach is based on building adaptable, reusable graphical tools that are integrated through a combination of libraries, scripts, and system-level user interface shells. The graphical interface shells are designed to integrate and visually guide a user through the complex steps in an operations process. They provide a user with an integrated system-level picture of an overall process, defining the required inputs and possible output through interactive on-screen graphics. The OEL has developed the software for building these process-oriented graphical user interface (GUI) shells. The OEL Shell development system (OEL Shell) is an extension of JPL's Widget Creation Library (WCL). The OEL Shell system can be used to easily build user interfaces for running complex processes, applications with extensive command-line interfaces, and tool-integration tasks. The interface shells display a logical process flow using arrows and box graphics. They also allow a user to select which output products are desired and which input sources are needed, eliminating the need to know which program and its associated command-line parameters must be executed in each case. The shells have also proved valuable for use as operations training tools because of the OEL Shell hypertext help environment. The OEL toolkit approach is guided by several principles, including the use of ASCII text file interfaces with a multimission format, Perl scripts for mission-specific adaptation code, and programs that include a simple command-line interface for batch mode processing. Projects can adapt the interface shells by simple changes to the resources configuration file. This approach has allowed the development of sophisticated, automated software systems that are easy, cheap, and fast to build. This paper will discuss our toolkit approach and the OEL Shell interface builder in the context of a real operations process example. The paper will discuss the design and implementation of a Ulysses toolkit for generating the mission sequence of events. The Sequence of Events Generation (SEG) system provides an adaptable multimission toolkit for producing a time-ordered listing and timeline display of spacecraft commands, state changes, and required ground activities.

Miller, Kevin J.↗