Engineering PapersSearch

SEARCH · Engineering Papers

Results for “operator interface”

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 37 records · Page 2

IUS/TUG orbital operations and mission support study. Volume 3: Space tug operations

A study was conducted to develop space tug operational concepts and baseline operations plan, and to provide cost estimates for space tug operations. Background data and study results are presented along with a transition phase analysis (the transition from interim upper state to tug operations). A summary is given of the tug operational and interface requirements with emphasis on the on-orbit checkout requirements, external interface operational requirements, safety requirements, and system operational interface requirements. Other topics discussed include reference missions baselined for the tug and details for the mission functional flows and timelines derived for the tug mission, tug subsystems, tug on-orbit operations prior to the tug first burn, spacecraft deployment and retrieval by the tug, operations centers, mission planning, potential problem areas, and cost data.

Source record

Hardware for a real-time multiprocessor simulator

The hardware for a real time multiprocessor simulator (RTMPS) developed at the NASA Lewis Research Center is described. The RTMPS is a multiple microprocessor system used to investigate the application of parallel processing concepts to real time simulation. It is designed to provide flexible data exchange paths between processors by using off the shelf microcomputer boards and minimal customized interfacing. A dedicated operator interface allows easy setup of the simulator and quick interpreting of simulation data. Simulations for the RTMPS are coded in a NASA designed real time multiprocessor language (RTMPL). This language is high level and geared to the multiprocessor environment. A real time multiprocessor operating system (RTMPOS) has also been developed that provides a user friendly operator interface. The RTMPS and supporting software are currently operational and are being evaluated at Lewis. The results of this evaluation will be used to specify the design of an optimized parallel processing system for real time simulation of dynamic systems.

Blech, R. A.

Telerobot control system

This invention relates to an operator interface for controlling a telerobot to perform tasks in a poorly modeled environment and/or within unplanned scenarios. The telerobot control system includes a remote robot manipulator linked to an operator interface. The operator interface includes a setup terminal, simulation terminal, and execution terminal for the control of the graphics simulator and local robot actuator as well as the remote robot actuator. These terminals may be combined in a single terminal. Complex tasks are developed from sequential combinations of parameterized task primitives and recorded teleoperations, and are tested by execution on a graphics simulator and/or local robot actuator, together with adjustable time delays. The novel features of this invention include the shared and supervisory control of the remote robot manipulator via operator interface by pretested complex tasks sequences based on sequences of parameterized task primitives combined with further teleoperation and run-time binding of parameters based on task context.

Backes, Paul G.

IUS/TUG orbital operations and mission support study. Volume 4: Project planning data

Planning data are presented for the development phases of interim upper stage (IUS) and tug systems. Major project planning requirements, major event schedules, milestones, system development and operations process networks, and relevant support research and technology requirements are included. Topics discussed include: IUS flight software; tug flight software; IUS/tug ground control center facilities, personnel, data systems, software, and equipment; IUS mission events; tug mission events; tug/spacecraft rendezvous and docking; tug/orbiter operations interface, and IUS/orbiter operations interface.

Source record

A computerized aircraft battery servicing facility

The latest upgrade to the Aerospace Energy Systems Laboratory (AESL) is described. The AESL is a distributed digital system consisting of a central system and battery servicing stations connected by a high-speed serial data bus. The entire system is located in two adjoining rooms; the bus length is approximately 100 ft. Each battery station contains a digital processor, data acquisition, floppy diskette data storage, and operator interfaces. The operator initiates a servicing task and thereafter the battery station monitors the progress of the task and terminates it at the appropriate time. The central system provides data archives, manages the data bus, and provides a timeshare interface for multiple users. The system also hosts software production tools for the battery stations and the central system.

Glover, Richard D.

Petri net controllers for distributed robotic systems

Petri nets are a well established modelling technique for analyzing parallel systems. When coupled with an event-driven operating system, Petri nets can provide an effective means for integrating and controlling the functions of distributed robotic applications. Recent work has shown that Petri net graphs can also serve as remarkably intuitive operator interfaces. In this paper, the advantages of using Petri nets as high-level controllers to coordinate robotic functions are outlined, the considerations for designing Petri net controllers are discussed, and simple Petri net structures for implementing an interface for operator supervision are presented. A detailed example is presented which illustrates these concepts for a sensor-based assembly application.

Lefebvre, D. R.

User interface and operational issues with thermionic space power systems

Thermionic space power systems have unique features which facilitate predeployment operations, provide operational flexibility and simplify the interface with the user. These were studied in some detail during the SP-100 program from 1983 to 1985. Three examples are reviewed in this paper: (1) system readiness verification in the prelaunch phase; (2) startup, shutdown, and dormancy in the operations phase; (3) part-load operation in the operations phase.

Dahlberg, R. C.

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.

Dual Mode Shock-Expansion/Reflected-Shock Tunnel

NASA s HYPULSE facility at GASL has been reconfigured to permit free jet testing of the Hyper-X flowpath at flight Mach numbers of 7 and 10. Among the required changes are addition of a converging-diverging nozzle to permit operation in a reflected shock tunnel mode, a 7 ft. diameter test cabin and a 30 in. diameter contoured nozzle. However, none of these changes were allowed to interfere with rapid recovery of the prior shock-expansion tunnel mode of operation, and indeed certain changes should enhance facility usefulness and productivity in either mode. A previously-developed shock-induced detonation mode of driving the facility has been successfully applied to both reflected shock tunnel operation at Mach 10 flight conditions, with tailored interface operation, and shock-expansion tunnel operation at flight conditions corresponding to Mach numbers from 12 to 25. Tailored interface operation at Mach 7 has been achieved with an unheated helium driver. In the present paper, the rationale for a dual mode shock expansion/reflected shock tunnel is discussed, and the capabilities and limitations for each mode are outlined. The physical changes in the HYPULSE facility to achieve dual mode capability are also described. Limited calibration data obtained to date in the new reflected shock tunnel mode are presented and the anticipated flight simulation map with dual mode operation is also outlined.

Erdos, John I.

Space station automation and robotics study. Operator-systems interface

This is the final report of a Space Station Automation and Robotics Planning Study, which was a joint project of the Boeing Aerospace Company, Boeing Commercial Airplane Company, and Boeing Computer Services Company. The study is in support of the Advanced Technology Advisory Committee established by NASA in accordance with a mandate by the U.S. Congress. Boeing support complements that provided to the NASA Contractor study team by four aerospace contractors, the Stanford Research Institute (SRI), and the California Space Institute. This study identifies automation and robotics (A&R) technologies that can be advanced by requirements levied by the Space Station Program. The methodology used in the study is to establish functional requirements for the operator system interface (OSI), establish the technologies needed to meet these requirements, and to forecast the availability of these technologies. The OSI would perform path planning, tracking and control, object recognition, fault detection and correction, and plan modifications in connection with extravehicular (EV) robot operations.

Source record

Development of Ada language control software for the NASA power management and distribution test bed

The Ada language software developed to control the NASA Lewis Research Center's Power Management and Distribution testbed is described. The testbed is a reduced-scale prototype of the electric power system to be used on space station Freedom. It is designed to develop and test hardware and software for a 20-kHz power distribution system. The distributed, multiprocessor, testbed control system has an easy-to-use operator interface with an understandable English-text format. A simple interface for algorithm writers that uses the same commands as the operator interface is provided, encouraging interactive exploration of the system.

Wright, Ted

Evolvable synthetic neural system

An evolvable synthetic neural system includes an evolvable neural interface operably coupled to at least one neural basis function. Each neural basis function includes an evolvable neural interface operably coupled to a heuristic neural system to perform high-level functions and an autonomic neural system to perform low-level functions. In some embodiments, the evolvable synthetic neural system is operably coupled to one or more evolvable synthetic neural systems in a hierarchy.

Curtis, Steven A.

The IOAG Recommendations on Spacecraft Emergency Cross Support

In 2014, the Inter-agency Operations Advisory Group (IOAG) chartered a multi-agency team effort to study how to best handle spacecraft emergency as part of cross support among network assets. The original intent is to put in place for the first time a process and guidelines to make emergency support as part of a permanent cross-support capability between space agencies. From the perspective of space communications service providers, a few key issues, common to all agencies, concerning the Spacecraft Emergency Cross Support (SECS) have been explored. They are: context of emergency support, provision of emergency support under a cross-support agreement, provision of emergency support with no cross-support agreement, legal and liability issues, response time, support priority, services provided, sustaining emergency support capabilities, and charge for the support. The positions of the various participating agencies with respect to these issues have been collected, analyzed, and finally harmonized to form the recommended IOAG positions. A central challenge most communications service providers are facing is that since the spacecraft emergency is an unplanned critical event, it typically requires fast response to the emergency call, hence lacking an international standard process for the operational interfaces seems to exacerbate the difficulty in providing SECS. For reducing the response time, i.e. from the time of accepting a request for SECS to the readiness for support, it is recommended that a “cross-support emergency system” be established by IOAG member agencies. Along with it, the IOAG core services, just-in-time ground communications line, cross support service management (CSSM), and standard operations procedures (SOP) for operational interfaces form the basic foundation of the “cross support emergency system”. Of the above, new to the cross support conducted thus far in the IOAG community is the concept of the SOP specifically for the interfaces between the service provider and service user during the SECS. Use cases, salient features, and definition of the key operational activities/tasks relevant to the interfaces are addressed by the effort. Underpinning such a system is the availability of the RF license granted by the local authority, at national and/or regional level, for a given ground station to communicate with and track the spacecraft in emergency mode at the uplink and downlink frequencies assigned to that spacecraft. That means it is critical for the IOAG member agencies to obtain a priori all-band licenses (for the entire X-band or S-band) for some, if not all, of their ground stations that are most capable of or likely to provide SECS. It is also recommended that certain prior arrangements be made with the relevant local licensing authorities for a process that will allow expedited authorization to transmit/receive signals to/from the declared spacecraft over the declared ground stations specifically and solely for the emergency case. Our analysis of the SECS has also uncovered a few fundamental programmatic issues. Recognizing any IOAG positions reached on these issues do not necessarily lead to any binding authority, it is recommended that they, along with those key attributes of the cross support emergency system, be explicitly stated as multi-agency guidelines to guide the implementation and provision of the SECS. The paper will present the results of the working group on Spacecraft Emergency Cross Support and, in particular, its findings, products and recommendations. It will also identify the next steps of this work that may include the production of some international standards as an extension of this work, or the process to make this emergency system usable by other spacecraft operators beyond the space agencies.

Tai, Wallace S.

The IOAG Recommendations on Spacecraft Emergency Cross Support

In 2014, the Inter-agency Operations Advisory Group (IOAG) chartered a multi-agency team effort to study how to best handle spacecraft emergency as part of cross support among network assets. The original intent is to put in place for the first time a process and guidelines to make emergency support as part of a permanent cross-support capability between space agencies. From the perspective of space communications service providers, a few key issues, common to all agencies, concerning the Spacecraft Emergency Cross Support (SECS) have been explored. They are: context of emergency support, provision of emergency support under a cross-support agreement, provision of emergency support with no cross-support agreement, legal and liability issues, response time, support priority, services provided, sustaining emergency support capabilities, and charge for the support. The positions of the various participating agencies with respect to these issues have been collected, analyzed, and finally harmonized to form the recommended IOAG positions. A central challenge most communications service providers are facing is that since the spacecraft emergency is an unplanned critical event, it typically requires fast response to the emergency call, hence lacking an international standard process for the operational interfaces seems to exacerbate the difficulty in providing SECS. For reducing the response time, i.e. from the time of accepting a request for SECS to the readiness for support, it is recommended that a “cross-support emergency system” be established by IOAG member agencies. Along with it, the IOAG core services, just-in-time ground communications line, cross support service management (CSSM), and standard operations procedures (SOP) for operational interfaces form the basic foundation of the “cross support emergency system”. Of the above, new to the cross support conducted thus far in the IOAG community is the concept of the SOP specifically for the interfaces between the service provider and service user during the SECS. Use cases, salient features, and definition of the key operational activities/tasks relevant to the interfaces are addressed by the effort. Underpinning such a system is the availability of the RF license granted by the local authority, at national and/or regional level, for a given ground station to communicate with and track the spacecraft in emergency mode at the uplink and downlink frequencies assigned to that spacecraft. That means it is critical for the IOAG member agencies to obtain a priori all-band licenses (for the entire X-band or S-band) for some, if not all, of their ground stations that are most capable of or likely to provide SECS. It is also recommended that certain prior arrangements be made with the relevant local licensing authorities for a process that will allow expedited authorization to transmit/receive signals to/from the declared spacecraft over the declared ground stations specifically and solely for the emergency case. Our analysis of the SECS has also uncovered a few fundamental programmatic issues. Recognizing any IOAG positions reached on these issues do not necessarily lead to any binding authority, it is recommended that they, along with those key attributes of the cross support emergency system, be explicitly stated as multi-agency guidelines to guide the implementation and provision of the SECS. The paper will present the results of the working group on Spacecraft Emergency Cross Support and, in particular, its findings, products and recommendations. It will also identify the next steps of this work that may include the production of some international standards as an extension of this work, or the process to make this emergency system usable by other spacecraft operators beyond the space agencies.

Tai, Wallace S.

Simulation Based Studies of Low Latency Teleoperations for NASA Exploration Missions

Human exploration of Mars will involve both crewed and robotic systems. Many mission concepts involve the deployment and assembly of mission support assets prior to crew arrival on the surface. Some of these deployment and assembly activities will be performed autonomously while others will be performed using teleoperations. However, significant communications latencies between the Earth and Mars make teleoperations challenging. Alternatively, low latency teleoperations are possible from locations in Mars orbit like Mars' moons Phobos and Deimos. To explore these latency opportunities, NASA is conducting a series of studies to investigate the effects of latency on telerobotic deployment and assembly activities. These studies are being conducted in laboratory environments at NASA's Johnson Space Center (JSC), the Human Exploration Research Analog (HERA) at JSC and the NASA Extreme Environment Mission Operations (NEEMO) underwater habitat off the coast of Florida. The studies involve two human-in-the-loop interactive simulations developed by the NASA Exploration Systems Simulations (NExSyS) team at JSC. The first simulation investigates manipulation related activities while the second simulation investigates mobility related activities. The first simulation provides a simple real-time operator interface with displays and controls for a simulated 6 degree of freedom end effector. The initial version of the simulation uses a simple control mode to decouple the robotic kinematic constraints and a communications delay to model latency effects. This provides the basis for early testing with more detailed manipulation simulations planned for the future. Subjects are tested using five operating latencies that represent teleoperation conditions from local surface operations to orbital operations at Phobos, Deimos and ultimately high Martian orbit. Subject performance is measured and correlated with three distance-to-target zones of interest. Each zone represents a target distance ranging from beyond 10m in Zone 1, through 1 cm to contact in Zone 5 with a step size factor of 10. Collected data consists of both objective simulation data (time, distance, hand controller inputs, velocity) and subjective questionnaire data. The second simulation provides a simple real-time operator interface with displays and control of a simulated surface rover. The rover traverses a synthetic Mars-like terrain and must be maneuvered to avoid obstacles while progressing to its destination. Like the manipulator simulation, subjects are tested using five operating latencies that represent teleoperation conditions from local surface operations to orbital operations at Phobos, Deimos and ultimately high Martian orbit. The rover is also operated at three different traverse speeds to assess the correlation between latency and speed. Collected data consisted of both objective simulation data (time, distance, hand controller inputs, braking) and subjective questionnaire data. These studies are exploring relationships between task complexity, operating speeds, operator efficiencies, and communications latencies for low latency teleoperations in support of human planetary exploration. This paper presents early results from these studies along with the current observations and conclusions. These and planned future studies will help to inform NASA on the potential for low latency teleoperations to support human exploration of Mars and inform the design of robotic systems and exploration missions.

Gernhardt, Michael L.

Transportability, distributability and rehosting experience with a kernel operating system interface set

For the past two years, PRC has been transporting and installing a software engineering environment framework, the Automated Product control Environment (APCE), at a number of PRC and government sites on a variety of different hardware. The APCE was designed using a layered architecture which is based on a standardized set of interfaces to host system services. This interface set called the APCE Interface Set (AIS), was designed to support many of the same goals as the Common Ada Programming Support Environment (APSE) Interface Set (CAIS). The APCE was developed to provide support for the full software lifecycle. Specific requirements of the APCE design included: automation of labor intensive administrative and logistical tasks: freedom for project team members to use existing tools: maximum transportability for APCE programs, interoperability of APCE database data, and distributability of both processes and data: and maximum performance on a wide variety of operating systems. A brief description is given of the APCE and AIS, a comparison of the AIS and CAIS both in terms of functionality and of philosophy and approach and a presentation of PRC's experience in rehosting AIS and transporting APCE programs and project data. Conclusions are drawn from this experience with respect to both the CAIS efforts and Space Station plans.

Blumberg, F. C.