SEARCH · Engineering Papers
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.
PARS processors and their use, flutter analysis, sensitivity analysis for stresses, and resizing are presented. Design variable definition and interface with finite element model, static constraints and their derivatives, flutter derivatives, and optimization are discussed.
The results of a cooperative effort to develop fluid components and systems that facilitate on-orbit servicing are discussed. The evolution from manual couplings to semi-automatic dual line interfaces to fully automatic multi-line resupply interfaces is traced. Hardware designs are presented in the context of solutions to requirements. Test data and user evaluations are reviewed.
A description is given of the CHIMERA II programming environment and operating system, which was developed for implementing real-time robotic systems. Sensor-based robotic systems contain both general- and special-purpose hardware, and thus the development of applications tends to be a time-consuming task. The CHIMERA II environment is designed to reduce the development time by providing a convenient software interface between the hardware and the user. CHIMERA II supports flexible hardware configurations which are based on one or more VME-backplanes. All communication across multiple processors is transparent to the user through an extensive set of interprocessor communication primitives. CHIMERA II also provides a high-performance real-time kernel which supports both deadline and highest-priority-first scheduling. The flexibility of CHIMERA II allows hierarchical models for robot control, such as NASREM, to be implemented with minimal programming time and effort.
The purpose of this paper is to present an update of an intelligent robotics simulator package, ROBOSIM, first introduced at Technology 2000 in 1990. ROBOSIM is used for three-dimensional geometrical modeling of robot manipulators and various objects in their workspace, and for the simulation of action sequences performed by the manipulators. Geometric modeling of robot manipulators has an expanding area of interest because it can aid the design and usage of robots in a number of ways, including: design and testing of manipulators, robot action planning, on-line control of robot manipulators, telerobotic user interface, and training and education. NASA developed ROBOSIM between 1985-88 to facilitate the development of robotics, and used the package to develop robotics for welding, coating, and space operations. ROBOSIM has been further developed for academic use by its co-developer Vanderbilt University, and has been in both classroom and laboratory environments for teaching complex robotic concepts. Plans are being formulated to make ROBOSIM available to all U.S. engineering/engineering technology schools (over three hundred total with an estimated 10,000+ users per year).
The crash of an automated passenger jet at Nagoya, Japan, in 1995, is used as an example of crew error in using automatic systems. Automation provides pilots with the ability to perform tasks in various ways. National culture is cited as a factor that affects how a pilot and crew interact with each other and equipment.
What makes virtual actors and objects in virtual environments seem real? How can the illusion of their reality be supported? What sorts of training or user-interface applications benefit from realistic user-environment interactions? These are some of the central questions that designers of virtual environments face. To be sure simulation realism is not necessarily the major, or even a required goal, of a virtual environment intended to communicate specific information. But for some applications in entertainment, marketing, or aspects of vehicle simulation training, realism is essential. The following chapters will examine how a sense of truly interacting with dynamic, intelligent agents may arise in users of virtual environments. These chapters are based on presentations at the London conference on Intelligent Motion and Interaction within a Virtual Environments which was held at University College, London, U.K., 15-17 September 2003.
This paper describes the SIMSCAPE middleware toolkit that has been developed recently to provide a common infrastructure for importing terrain model data from multiple data sources and making them available to simulation applications. The SIMSCAPE infrastructure simplifies the overall simulation design by eliminating the traditional need for custom terrain model interfaces to terrain data sources and simulation users. SIMSCAPE provides a collection of libraries and tools to use and manage terrain environment models within a wide range of simulation applications.
The Interface Anywhere Project was funded through Innovation Charge Account (ICA) at NASA JSC in the Fall of 2012. The project was collaboration between human factors and engineering to explore the possibility of designing an interface to control basic habitat operations through gesture and voice control; (a) Current interfaces require the users to be physically near an input device in order to interact with the system; and (b) By using voice and gesture commands, the user is able to interact with the system anywhere they want within the work environment.
The X-HAB team in the CU Graduate Projects course was tasked with developing a Distributed Robotic Plant Production System (DRoPPS) that provided remote food production capability for long-duration space missions. The system consists of a Remotely Operated Gardening Robot (ROGR) and a Smart Pot (SPOT). SPOT was designed to grow a plant in a hydroponic system, while also providing multiple sensor data feedback to a remote user. ROGR was designed to give a remote user a method of moving SPOT and caring for the plant. A User Interface (UI) was created to provide a means by which a remote user could interact with the system. At the conclusion of the semester, ROGR was 95% complete, and only required minor mechanical fixes. SPOT was 85% complete, and required additional machining of mechanical parts. The UI was 75% complete, and required additional functionality and user testing. The project was not fully completed due to the scope of the project. Regardless, multiple team members have agreed to continue working on the project to finish by the June 1st presentation day at NASA.
The NASA Earth Observation System Data and Information System (EOSDIS) delivers an average of 22 terabytes per day of data collected by orbital and airborne sensor systems to end users through an integrated online search environment (the Reverb/ECHO system). Earth observations data collected by sensors on the International Space Station (ISS) are not currently included in the EOSDIS system, and are only accessible through various individual online locations. This increases the effort required by end users to query multiple datasets, and limits the opportunity for data discovery and innovations in analysis. The Earth Science and Remote Sensing Unit of the Exploration Integration and Science Directorate at NASA Johnson Space Center has collaborated with the School of Earth and Space Exploration at Arizona State University (ASU) to develop the ISS Instrument Integration Implementation (I4) data query tool to provide end users a clean, simple online interface for querying both current and historical ISS Earth Observations data. The I4 interface is based on the Lunaserv and Lunaserv Global Explorer (LGE) open-source software packages developed at ASU for query of lunar datasets. In order to avoid mirroring existing databases - and the need to continually sync/update those mirrors - our design philosophy is for the I4 tool to be a pure query engine only. Once an end user identifies a specific scene or scenes of interest, I4 transparently takes the user to the appropriate online location to download the data. The tool consists of two public-facing web interfaces. The Map Tool provides a graphic geobrowser environment where the end user can navigate to an area of interest and select single or multiple datasets to query. The Map Tool displays active image footprints for the selected datasets (Figure 1). Selecting a footprint will open a pop-up window that includes a browse image and a link to available image metadata, along with a link to the online location to order or download the actual data. Search results are either delivered in the form of browse images linked to the appropriate online database, similar to the Map Tool, or they may be transferred within the I4 environment for display as footprints in the Map Tool. Datasets searchable through I4 (http://eol.jsc.nasa.gov/I4_tool) currently include: Crew Earth Observations (CEO) cataloged and uncataloged handheld astronaut photography; Sally Ride EarthKAM; Hyperspectral Imager for the Coastal Ocean (HICO); and the ISS SERVIR Environmental Research and Visualization System (ISERV). The ISS is a unique platform in that it will have multiple users over its lifetime, and that no single remote sensing system has a permanent internal or external berth. The open source I4 tool is designed to enable straightforward addition of new datasets as they become available such as ISS-RapidSCAT, Cloud Aerosol Transport System (CATS), and the High Definition Earth Viewing (HDEV) system. Data from other sensor systems, such as those operated by the ISS International Partners or under the auspices of the US National Laboratory program, can also be added to I4 provided sufficient access to enable searching of data or metadata is available. Commercial providers of remotely sensed data from the ISS may be particularly interested in I4 as an additional means of directing potential customers and clients to their products.
Two and a half years after a design study began, and a year and a half after development commenced, version 1.0 of the Virtual Solar Observatory (VSO) was released at the 2004 Fall AGU meeting. Although internal elements of the VSO have changed, the basic design has remained the same, reflecting the team's belief in the importance of a simple, robust mechanism for registering data provider holdings, initiating queries at the appropriate provider sites, aggregating the responses, allowing the user to iterate before making a final selection, and enabling the delivery of data directly from the providers. In order to make the VSO transparent, lightweight, and portable, the developers employed XML for the registry, SOAP for communication between a VSO instance and data services, and HTML for the graphic user interface (GUI's). We discuss the internal data model, the API, and user responses to various trial GUI's as typical design issues for any virtual observatory. We also discuss the role of the "small box" of data search, identification, and delivery services provided by the VSO in the larger, Sun-Solar System Connection virtual observatory (VxO) scheme.
The Surface Currents Database Management System (SCDBMS) provides access to the Surface Currents Data Base (SCDB) which is maintained by the Naval Oceanographic Office (NAVOCEANO). The SCDBMS incorporates database technology in providing seamless access to surface current data. The SCDBMS is an interactive software application with a graphical user interface (GUI) that supports user control of SCDBMS functional capabilities. The purpose of this document is to define and describe the structural framework and logistical design of the software components/units which are integrated into the major computer software configuration item (CSCI) identified as the SCDBMS, Version 1.0. The preliminary design is based on functional specifications and requirements identified in the governing Statement of Work prepared by the Naval Oceanographic Office (NAVOCEANO) and distributed as a request for proposal by the National Aeronautics and Space Administration (NASA).
This report describes the results of a workshop conducted at Goddard Space Flight Center (GSFC) to identify current and anticipated trends in human-computer interface technology that may influence the design or operation of a space station workstation. The workshop was attended by approximately 40 persons from government and academia who were selected for their expertise in some aspect of human-machine interaction research. The focus of the workshop was a 1 1/2 brainstorming/forecasting session in which the attendees were assigned to interdisciplinary working groups and instructed to develop predictions for each of the following technology areas: (1) user interface, (2) resource management, (3) control language, (4) data base systems, (5) automatic software development, (6) communications, (7) training, and (8) simulation. This report is significant in that it provides a unique perspective on workstation design for the space station. This perspective, which is characterized by a major emphasis on user requirements, should be most valuable to Phase B contractors involved in design development of the space station workstation. One of the more compelling results of the workshop is the recognition that no major technological breakthroughs are required to implement the current workstation concept. What is required is the creative application of existing knowledge and technology.
An integrated modeling capability that provides the tools by which entire optical systems and instruments can be simulated and optimized is a key technology development, applicable to all mission classes, especially astrophysics. Many of the future missions require optical systems that are physically much larger than anything flown before and yet must retain the characteristic sub-micron diffraction limited wavefront accuracy of their smaller precursors. It is no longer feasible to follow the path of 'cut and test' development; the sheer scale of these systems precludes many of the older techniques that rely upon ground evaluation of full size engineering units. The ability to accurately model (by computer) and optimize the entire flight system's integrated structural, thermal, and dynamic characteristics is essential. Two distinct integrated modeling capabilities are required. These are an initial design capability and a detailed design and optimization system. The content of an initial design package is shown. It would be a modular, workstation based code which allows preliminary integrated system analysis and trade studies to be carried out quickly by a single engineer or a small design team. A simple concept for a detailed design and optimization system is shown. This is a linkage of interface architecture that allows efficient interchange of information between existing large specialized optical, control, thermal, and structural design codes. The computing environment would be a network of large mainframe machines and its users would be project level design teams. More advanced concepts for detailed design systems would support interaction between modules and automated optimization of the entire system. Technology assessment and development plans for integrated package for initial design, interface development for detailed optimization, validation, and modeling research are presented.
Applications of rapid prototyping and Artificial Intelligence techniques to problems associated with Space Station-era information management systems are described. In particular, the work is centered on issues related to: (1) intelligent man-machine interfaces applied to scientific data user support, and (2) the requirement that intelligent information management systems (IIMS) be able to efficiently process metadata updates concerning types of data handled. The advanced IIMS represents functional capabilities driven almost entirely by the needs of potential users. Space Station-era scientific data projected to be generated is likely to be significantly greater than data currently processed and analyzed. Information about scientific data must be presented clearly, concisely, and with support features to allow users at all levels of expertise efficient and cost-effective data access. Additionally, mechanisms for allowing more efficient IIMS metadata update processes must be addressed. The work reported covers the following IIMS design aspects: IIMS data and metadata modeling, including the automatic updating of IIMS-contained metadata, IIMS user-system interface considerations, including significant problems associated with remote access, user profiles, and on-line tutorial capabilities, and development of an IIMS query and browse facility, including the capability to deal with spatial information. A working prototype has been developed and is being enhanced.
The MOODS Data Management System (MDMS) provides access to the Master Oceanographic Observation Data Set (MOODS) which is maintained by the Naval Oceanographic Office (NAVOCEANO). The MDMS incorporates database technology in providing seamless access to parameter (temperature, salinity, soundspeed) vs. depth observational profile data. The MDMS is an interactive software application with a graphical user interface (GUI) that supports user control of MDMS functional capabilities. The purpose of this document is to define and describe the structural framework and logical design of the software components/units which are integrated into the major computer software configuration item (CSCI) identified as MDMS, Version 1.0. The preliminary design is based on functional specifications and requirements identified in the governing Statement of Work prepared by the Naval Oceanographic Office (NAVOCEANO) and distributed as a request for proposal by the National Aeronautics and Space Administration (NASA).
The anticipated NASA Mars Sample Return Mission (MSR) requires a simple and reliable method in which to return collected Martian samples back to earth for scientific analysis. The Multi-Mission Earth Entry Vehicle (MMEEV) is NASA's proposed solution to this MSR requirement. Key aspects of the MMEEV are its reliable and passive operation, energy absorbing foam-composite structure, and modular impact sphere (IS) design. To aid in the development of an EEV design that can be modified for various missions requirements, two fully parametric finite element models were developed. The first model was developed in an explicit finite element code and was designed to evaluate the impact response of the vehicle and payload during the final stage of the vehicle's return to earth. The second model was developed in an explicit code and was designed to evaluate the static and dynamic structural response of the vehicle during launch and reentry. In contrast to most other FE models, built through a Graphical User Interface (GUI) pre-processor, the current model was developed using a coding technique that allows the analyst to quickly change nearly all aspects of the model including: geometric dimensions, material properties, load and boundary conditions, mesh properties, and analysis controls. Using the developed design tool, a full range of proposed designs can quickly be analyzed numerically and thus the design trade space for the EEV can be fully understood. An engineer can then quickly reach the best design for a specific mission and also adapt and optimize the general design for different missions.
There is considerable interest at this time in developing small satellites for quick-turnaround missions to investigate near-earth phenomena from space. One problem to be solved in mission planning is the means of communication between the control infrastructure in the ground segment and the satellite in the space segment. A nominal small-satellite mission design often includes an omni-directional or similar wide-pattern antenna on the satellite and a dedicated ground station for telemetry, tracking, and command support. These terminals typically provide up to 15 minutes of coverage during an orbit that is within the visibility of the ground station; however, not all orbits will pass over the ground station so that coverage gaps will exist in the data flow. To overcome this general limitation on data transmission for low-earth orbiting satellites, the Space Network (SN), operated by the National Aeronautics and Space Administration, (NASA) has been designed to transmit data to and from user satellites through the Tracking and Data Relay Satellites (TDRS) in geostationary orbit and interfacing to the White Sands Complex (WSC) in New Mexico for the data's ground entry point. The advantage of the SN over a fixed ground station is that all low-earth-satellite orbits will be within the visibility area of at least one TDRS within the SN for a large part of the orbit and the potential exists to establish a communications link if the user satellite can point an antenna in the direction of any one of the relay satellites. Within NASA, there is considerable interest in seeing that small satellite developers are aware of the advantages to the SN and that designs to include the SN are part of the satellite design. Small satellite users have not often considered using the SN because of: (1) The 26-dB link penalty differential between direct broadcast to a ground station and transmission through a TDRS to the ground; (2) The class of satellite is too small to support high-gain antennas and associated attitude control and drive electronics; (3) The class of satellites is severely weight and power limited; (4) There are perceived problems in scheduling communications for this class of user on the SN. This report addresses the potential for SN access using non-gimbaled, i.e. fixed-pointed, antennas in the design of the small satellite using modest transmission power to achieve the necessary space-to-ground transmissions. The advantage of using the SN is in the reduction of mission costs arising from using the SN infrastructure instead of a dedicated, proprietary ground station using a similar type of communications package. From the simulations and analysis presented, we will show that a modest satellite configuration can be used with the space network to achieve the data transmission goals of a number of users and thereby rival the performance achieved with proprietary ground stations. In this study, we will concentrate on the return data link (from the user satellite through a TDRS to the ground data entry point). The forward command link (from the ground data entry point through a TDRS to the user satellite) will usually be a lower data rate service and the data volume will also be considerably lower than the return link's requirement. Therefore, we assume that if the return link requirements are satisfied, then the forward link requirements can also be satisfied.