Engineering topics

Norris, Jeffrey

Publications and source records attributed to Norris, Jeffrey.

16 records

NASA NTRS2013

Kinect Engineering with Learning (KEWL)

According to a Nielsen survey at the time of this reporting, 41% of all households have a game console. This is one market in which NASA has been absent from education and outreach efforts. Kinect Engineering with Learning (KEWL) is made to enter into that market and bring NASA education and outreach to a very familiar venue. KEWL creates an education and outreach experience that is more participatory, both in a school and museum environment. KEWL is a set of applications that runs on an Xbox 360 using the Kinect controller used for education and outreach. These applications currently include: Train R2, a visual simulation of Robonaut 2 that allows students to control a virtual R2 in a game environment; Drive R2, an interface using the Xbox 360 and Kinect controller that allows students to control the real R2 using the methods they learned playing Train R2; ISS experience, a visual tour of the interior of the International Space Station where students use their body to fly through the virtual ISS; Gravity Ball, a simulation of throwing balls in the gravity of different planets; Solar Array repair, a simulation of the simplified STS-121 solar array repair mission; and PlaySpace, a Mars/Moon application that allows students to experience different aspects of Mars/Moon. Users can "fly through" the ISS using their body, allowing an experience similar to what an astronaut would have on orbit. In PlaySpace, users can fly over the surface of Mars and view surface data obtained by Mars rovers. Users of Train R2 and Drive R2 can experience what it is like to control a robot over a distance with a time delay, simulating the time delay that would occur between ground control and an on-orbit robot. The initial ISS experiences were built using parts of code from the NASA Enigma software. The models used in these experiences were also from the Integrated Graphics Operations and Analysis Lab model database. The PlaySpace experience incorporates surface data obtained from NASA rovers and satellites and was built by NASA JPL.

Goza, Sharon↗

NASA NTRS2009

Extreme Programming: Maestro Style

"Extreme Programming: Maestro Style" is the name of a computer programming methodology that has evolved as a custom version of a methodology, called extreme programming that has been practiced in the software industry since the late 1990s. The name of this version reflects its origin in the work of the Maestro team at NASA's Jet Propulsion Laboratory that develops software for Mars exploration missions. Extreme programming is oriented toward agile development of software resting on values of simplicity, communication, testing, and aggressiveness. Extreme programming involves use of methods of rapidly building and disseminating institutional knowledge among members of a computer-programming team to give all the members a shared view that matches the view of the customers for whom the software system is to be developed. Extreme programming includes frequent planning by programmers in collaboration with customers, continually examining and rewriting code in striving for the simplest workable software designs, a system metaphor (basically, an abstraction of the system that provides easy-to-remember software-naming conventions and insight into the architecture of the system), programmers working in pairs, adherence to a set of coding standards, collaboration of customers and programmers, frequent verbal communication, frequent releases of software in small increments of development, repeated testing of the developmental software by both programmers and customers, and continuous interaction between the team and the customers. The environment in which the Maestro team works requires the team to quickly adapt to changing needs of its customers. In addition, the team cannot afford to accept unnecessary development risk. Extreme programming enables the Maestro team to remain agile and provide high-quality software and service to its customers. However, several factors in the Maestro environment have made it necessary to modify some of the conventional extreme-programming practices. The single most influential of these factors is that continuous interaction between customers and programmers is not feasible.

Norris, Jeffrey↗

NASA NTRS2008

Ensemble: an Architecture for Mission-Operations Software

Ensemble is the name of an open architecture for, and a methodology for the development of, spacecraft mission operations software. Ensemble is also potentially applicable to the development of non-spacecraft mission-operations- type software. Ensemble capitalizes on the strengths of the open-source Eclipse software and its architecture to address several issues that have arisen repeatedly in the development of mission-operations software: Heretofore, mission-operations application programs have been developed in disparate programming environments and integrated during the final stages of development of missions. The programs have been poorly integrated, and it has been costly to develop, test, and deploy them. Users of each program have been forced to interact with several different graphical user interfaces (GUIs). Also, the strategy typically used in integrating the programs has yielded serial chains of operational software tools of such a nature that during use of a given tool, it has not been possible to gain access to the capabilities afforded by other tools. In contrast, the Ensemble approach offers a low-risk path towards tighter integration of mission-operations software tools.

Norris, Jeffrey↗

NASA NTRS2008

Orchestrator Telemetry Processing Pipeline

Orchestrator is a software application infrastructure for telemetry monitoring, logging, processing, and distribution. The architecture has been applied to support operations of a variety of planetary rovers. Built in Java with the Eclipse Rich Client Platform, Orchestrator can run on most commonly used operating systems. The pipeline supports configurable parallel processing that can significantly reduce the time needed to process a large volume of data products. Processors in the pipeline implement a simple Java interface and declare their required input from upstream processors. Orchestrator is programmatically constructed by specifying a list of Java processor classes that are initiated at runtime to form the pipeline. Input dependencies are checked at runtime. Fault tolerance can be configured to attempt continuation of processing in the event of an error or failed input dependency if possible, or to abort further processing when an error is detected. This innovation also provides support for Java Message Service broadcasts of telemetry objects to clients and provides a file system and relational database logging of telemetry. Orchestrator supports remote monitoring and control of the pipeline using browser-based JMX controls and provides several integration paths for pre-compiled legacy data processors. At the time of this reporting, the Orchestrator architecture has been used by four NASA customers to build telemetry pipelines to support field operations. Example applications include high-volume stereo image capture and processing, simultaneous data monitoring and logging from multiple vehicles. Example telemetry processors used in field test operations support include vehicle position, attitude, articulation, GPS location, power, and stereo images.

Powell, Mark↗

NASA NTRS2007

Distributed Operations Planning

Maestro software provides a secure and distributed mission planning system for long-term missions in general, and the Mars Exploration Rover Mission (MER) specifically. Maestro, the successor to the Science Activity Planner, has a heavy emphasis on portability and distributed operations, and requires no data replication or expensive hardware, instead relying on a set of services functioning on JPL institutional servers. Maestro works on most current computers with network connections, including laptops. When browsing down-link data from a spacecraft, Maestro functions similarly to being on a Web browser. After authenticating the user, it connects to a database server to query an index of data products. It then contacts a Web server to download and display the actual data products. The software also includes collaboration support based upon a highly reliable messaging system. Modifications made to targets in one instance are quickly and securely transmitted to other instances of Maestro. The back end that has been developed for Maestro could benefit many future missions by reducing the cost of centralized operations system architecture.

Fox, Jason↗

NASA NTRS2007

Cryogenic Shrouds for Testing Thermal-Insulation Panels

Cryogenic shrouds have been designed and built for use in thermomechanical testing of samples of thermalinsulation panels on cryogenic vessels. In the original application for which these shrouds were specifically designed, the samples are representative of the large-area thermal-insulation panels on the space-shuttle external tanks that hold liquid hydrogen and liquid oxygen, and the purpose of the testing is to demonstrate the ability of bonded layers in the panels to resist delamination under a combination of applied uniaxial mechanical loads and realistic operational temperatures. Presumably, the shrouds and the tests performed by use of them could be modified to enable similar evaluation of thermomechanical properties of thermal-insulation panels for cryogenic vessels other than the external tanks of the space shuttles. The shrouds are required to enable maintenance of required temperatures on the inner and outer surfaces of the thermal-insulation-panel samples, to enable visual observation of the outer surfaces of the samples, and not to introduce any measurable loads into the panels. For each panel sample, there are two shrouds: one to be mounted on the inner surface (the surface that would be in contact with a tank containing a cryogenic liquid during normal use) and one to be mounted on the outer surface (the surface that would be exposed to ambient air or other warmer environment during normal use). The shrouds for testing specimens of thermal-insulation- panels for the liquid-hydrogen tank are made largely of titanium; the shrouds for testing specimens of thermal- insulation-panels for the liquid-oxygen tank are made largely of an aluminum- lithium alloy. The specific temperature requirements are the following: The inner shroud must make it possible to maintain a temperature of 321 degrees F (196 degrees C) [the approximate temperature of liquid nitrogen] or 453 F (about 269 C) [the approximate temperature of liquid helium] on the inner face of the sample. The outer shroud must make it possible to maintain a temperature between 30 degrees and 0 degrees F (between about 34 degrees and about 18 degrees C) on the outer surface of the sample by blowing a cryogenic gas or missile grade air along that surface. To enable viewing of the outer surface of the sample during testing, the outer shroud includes a window comprising two layers of poly(methyl methacrylate) with a gap between them to reduce fogging. To ensure that the shrouds do not introduce any measurable loads into a panel specimen, the shrouds are cushioned on the specimen by seals made of a fluoropolymer-membrane/fabric composite material and are held in place on the specimen by means of symmetrically placed clamps with poly(tetrafluoroethylene) pads. Instrumentation ports for thermocouples and strain gauges used in the tests are incorporated into the shrouds.

Norris, Jeffrey↗

NASA NTRS2007

GIS Methodology for Planning Planetary-Rover Operations

A document describes a methodology for utilizing image data downlinked from cameras aboard a robotic ground vehicle (rover) on a remote planet for analyzing and planning operations of the vehicle and of any associated spacecraft. Traditionally, the cataloging and presentation of large numbers of downlinked planetary-exploration images have been done by use of two organizational methods: temporal organization and correlation between activity plans and images. In contrast, the present methodology involves spatial indexing of image data by use of the computational discipline of geographic information systems (GIS), which has been maturing in terrestrial applications for decades, but, until now, has not been widely used in support of exploration of remote planets. The use of GIS to catalog data products for analysis is intended to increase efficiency and effectiveness in planning rover operations, just as GIS has proven to be a source of powerful computational tools in such terrestrial endeavors as law enforcement, military strategic planning, surveying, political science, and epidemiology. The use of GIS also satisfies the need for a map-based user interface that is intuitive to rover-activity planners, many of whom are deeply familiar with maps and know how to use them effectively in field geology.

Powell, Mark↗

NASA NTRS2007

The PICWidget

The Plug-in Image Component Widget (PICWidget) is a software component for building digital imaging applications. The component is part of a methodology described in GIS Methodology for Planning Planetary-Rover Operations (NPO-41812), which appears elsewhere in this issue of NASA Tech Briefs. Planetary rover missions return a large number and wide variety of image data products that vary in complexity in many ways. Supported by a powerful, flexible image-data-processing pipeline, the PICWidget can process and render many types of imagery, including (but not limited to) thumbnail, subframed, downsampled, stereoscopic, and mosaic images; images coregistred with orbital data; and synthetic red/green/blue images. The PICWidget is capable of efficiently rendering images from data representing many more pixels than are available at a computer workstation where the images are to be displayed. The PICWidget is implemented as an Eclipse plug-in using the Standard Widget Toolkit, which provides a straightforward interface for re-use of the PICWidget in any number of application programs built upon the Eclipse application framework. Because the PICWidget is tile-based and performs aggressive tile caching, it has flexibility to perform faster or slower, depending whether more or less memory is available.

Norris, Jeffrey↗

NASA NTRS2005

Interactive Display of Scenes with Annotations

ThreeDView is a computer program that enables high-performance interactive display of real-world scenes with annotations. ThreeDView was developed primarily as a component of the Science Activity Planner (SAP) software, wherein it is to be used to display annotated images of terrain acquired by exploratory robots on Mars and possibly other remote planets. The images can be generated from sets of multiple-texture image data in the Visible Scalable Terrain (ViSTa) format, which was described in "Format for Interchange and Display of 3D Terrain Data" (NPO-30600) NASA Tech Briefs, Vol. 28, No. 12 (December 2004), page 25. In ThreeDView, terrain data can be loaded rapidly, the geometric level of detail and texture resolution can be selected, false colors can be used to represent scientific data mapped onto terrain, and the user can select among navigation modes. ThreeDView consists largely of modular Java software components that can easily be reused and extended to produce new high-performance, application-specific software systems for displaying images of three-dimensional real-world scenes.

Vona, Marsette↗

NASA NTRS2004

Format for Interchange and Display of 3D Terrain Data

Visible Scalable Terrain (ViSTa) is a software format for production, interchange, and display of three-dimensional (3D) terrain data acquired by stereoscopic cameras of robotic vision systems. ViSTa is designed to support scalability of data, accuracy of displayed terrain images, and optimal utilization of computational resources. In a ViSTa file, an area of terrain is represented, at one or more levels of detail, by coordinates of isolated points and/or vertices of triangles derived from a texture map that, in turn, is derived from original terrain images. Unlike prior terrain-image software formats, ViSTa includes provisions to ensure accuracy of texture coordinates. Whereas many such formats are based on 2.5-dimensional terrain models and impose additional regularity constraints on data, ViSTa is based on a 3D model without regularity constraints. Whereas many prior formats require external data for specifying image-data coordinate systems, ViSTa provides for the inclusion of coordinate-system data within data files. ViSTa admits highspeed loading and display within a Java program. ViSTa is designed to minimize file sizes and maximize compressibility and to support straightforward reduction of resolution to reduce file size for Internet-based distribution.

Backes, Paul↗

NASA NTRS2004

Collaborative Planning of Robotic Exploration

The Science Activity Planner (SAP) software system includes an uplink-planning component, which enables collaborative planning of activities to be undertaken by an exploratory robot on a remote planet or on Earth. Included in the uplink-planning component is the SAP-Uplink Browser, which enables users to load multiple spacecraft activity plans into a single window, compare them, and merge them. The uplink-planning component includes a subcomponent that implements the Rover Markup Language Activity Planning format (RML-AP), based on the Extensible Markup Language (XML) format that enables the representation, within a single document, of planned spacecraft and robotic activities together with the scientific reasons for the activities. Each such document is highly parseable and can be validated easily. Another subcomponent of the uplink-planning component is the Activity Dictionary Markup Language (ADML), which eliminates the need for two mission activity dictionaries - one in a human-readable format and one in a machine-readable format. Style sheets that have been developed along with the ADML format enable users to edit one dictionary in a user-friendly environment without compromising

Norris, Jeffrey↗

NASA NTRS2004

Simulation of Hazards and Poses for a Rocker-Bogie Rover

Provisions for specification of hazards faced by a robotic vehicle (rover) equipped with a rocker-bogie suspension, for prediction of collisions between the vehicle and the hazards, and for simulation of poses of the vehicle at selected positions on the terrain have been incorporated into software that simulates the movements of the vehicle on planned paths across the terrain. The software in question is that of the Web Interface for Telescience (WITS), selected aspects of which have been described in a number of prior NASA Tech Briefs articles. To recapitulate: The WITS is a system of computer software that enables scientists, located at geographically dispersed computer terminals connected to the World Wide Web, to command instrumented robotic vehicles (rovers) during exploration of Mars and perhaps eventually of other planets. The WITS also has potential for adaptation to terrestrial use in telerobotics and other applications that involve computer-based remote monitoring, supervision, control, and planning.

Backes, Paul↗

NASA NTRS2003

Software for Displaying Data from Planetary Rovers

Science Activity Planner (SAP) DownlinkBrowser is a computer program that assists in the visualization of processed telemetric data [principally images, image cubes (that is, multispectral images), and spectra] that have been transmitted to Earth from exploratory robotic vehicles (rovers) on remote planets. It is undergoing adaptation to (1) the Field Integrated Design and Operations (FIDO) rover (a prototype Mars-exploration rover operated on Earth as a test bed) and (2) the Mars Exploration Rover (MER) mission. This program has evolved from its predecessor - the Web Interface for Telescience (WITS) software - and surpasses WITS in the processing, organization, and plotting of data. SAP DownlinkBrowser creates Extensible Markup Language (XML) files that organize data files, on the basis of content, into a sortable, searchable product database, without the overhead of a relational database. The data-display components of SAP DownlinkBrowser (descriptively named ImageView, 3DView, OrbitalView, PanoramaView, ImageCubeView, and SpectrumView) are designed to run in a memory footprint of at least 256MB on computers that utilize the Windows, Linux, and Solaris operating systems.

Powell, Mark↗

NASA NTRS2003

Software Supports Distributed Operations via the Internet

Multi-mission Encrypted Communication System (MECS) is a computer program that enables authorized, geographically dispersed users to gain secure access to a common set of data files via the Internet. MECS is compatible with legacy application programs and a variety of operating systems. The MECS architecture is centered around maintaining consistent replicas of data files cached on remote computers. MECS monitors these files and, whenever one is changed, the changed file is committed to a master database as soon as network connectivity makes it possible to do so. MECS provides subscriptions for remote users to automatically receive new data as they are generated. Remote users can be producers as well as consumers of data. Whereas a prior program that provides some of the same services treats disconnection of a user from the network of users as an error from which recovery must be effected, MECS treats disconnection as a nominal state of the network: This leads to a different design that is more efficient for serving many users, each of whom typically connects and disconnects frequently and wants only a small fraction of the data at any given time.

Norris, Jeffrey↗

NASA NTRS2003

Relating Downlink Data Products to Uplink Commands

An improved data-labeling system provides for automatic association of data products of an exploratory robot (downlink information) with previously transmitted commands (uplink information) that caused the robot to gather the data. Such association is essential to correct and timely analysis of the data products -- including, for example, association of the data with the correct targets. The system was developed for use on Mars Rover missions during the next few years. The system could also be adapted to terrestrial exploratory telerobots for which delays between commands and data returns are long enough to give rise to questions as to which commands resulted in which data returns. The main advantage of this system over prior data-labeling systems is that given a downlink data product, the uplink command and sequence hierarchy that produced it are automatically provided, and given an uplink sequence and command, the downlink data products that it produced are automatically provided.

Backes, Paul↗

NASA NTRS2003

Designing Facilities for Collaborative Operations

A methodology for designing operational facilities for collaboration by multiple experts has begun to take shape as an outgrowth of a project to design such facilities for scientific operations of the planned 2003 Mars Exploration Rover (MER) mission. The methodology could also be applicable to the design of military "situation rooms" and other facilities for terrestrial missions. It was recognized in this project that modern mission operations depend heavily upon the collaborative use of computers. It was further recognized that tests have shown that layout of a facility exerts a dramatic effect on the efficiency and endurance of the operations staff. The facility designs (for example, see figure) and the methodology developed during the project reflect this recognition. One element of the methodology is a metric, called effective capacity, that was created for use in evaluating proposed MER operational facilities and may also be useful for evaluating other collaboration spaces, including meeting rooms and military situation rooms. The effective capacity of a facility is defined as the number of people in the facility who can be meaningfully engaged in its operations. A person is considered to be meaningfully engaged if the person can (1) see, hear, and communicate with everyone else present; (2) see the material under discussion (typically data on a piece of paper, computer monitor, or projection screen); and (3) provide input to the product under development by the group. The effective capacity of a facility is less than the number of people that can physically fit in the facility. For example, a typical office that contains a desktop computer has an effective capacity of .4, while a small conference room that contains a projection screen has an effective capacity of around 10. Little or no benefit would be derived from allowing the number of persons in an operational facility to exceed its effective capacity: At best, the operations staff would be underutilized; at worst, operational performance would deteriorate. Elements of this methodology were applied to the design of three operations facilities for a series of rover field tests. These tests were observed by human-factors researchers and their conclusions are being used to refine and extend the methodology to be used in the final design of the MER operations facility. Further work is underway to evaluate the use of personal digital assistant (PDA) units as portable input interfaces and communication devices in future mission operations facilities. A PDA equipped for wireless communication and Ethernet, Bluetooth, or another networking technology would cost less than a complete computer system, and would enable a collaborator to communicate electronically with computers and with other collaborators while moving freely within the virtual environment created by a shared immersive graphical display.

Norris, Jeffrey↗