SEARCH · Search NASA
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.
This paper describes an 8-degrees-of-freedom macro-micro robot. This robot is capable of performing tasks that require accurate force control, such as polishing, finishing, grinding, deburring, and cleaning. The design of the macro-micro mechanism, the control algorithms, and the hardware/sofware implemtation of the algotithms are described in this paper. Initial experimental results are reported.
We present an multi-agent model-based autonomy architecture with monitoring, planning, diagnosis, and execution elements. We discuss an internal spacecraft free-flying robot prototype controlled by an implementation of this architecture and a ground test facility used for development. In addition, we discuss a simplified environment control life support system for the spacecraft domain also controlled by an implementation of this architecture. We discuss adjustable autonomy and how it applies to this architecture. We describe an interface that provides the user situation awareness of both autonomous systems and enables the user to dynamically edit the plans prior to and during execution as well as control these agents at various levels of autonomy. This interface also permits the agents to query the user or request the user to perform tasks to help achieve the commanded goals. We conclude by describing a scenario where these two agents and a human interact to cooperatively detect, diagnose and recover from a simulated spacecraft fault.
Many of the methods used to develop software bare a close resemblance to Complex Electronics (CE) development. CE are now programmed to perform tasks that were previously handled in software, such as communication protocols. For instance, Field Programmable Gate Arrays (FPGAs) can have over a million logic gates while system-on-chip (SOC) devices can combine a microprocessor, input and output channels, and sometimes an FPGA for programmability. With this increased intricacy, the possibility of "software-like" bugs such as incorrect design, logic, and unexpected interactions within the logic is great. Since CE devices are obscuring the hardware/software boundary, we propose that mature software methodologies may be utilized with slight modifications to develop these devices. By using standardized S/W Engineering methods such as checklists, missing requirements and "bugs" can be detected earlier in the development cycle, thus creating a development process for CE that will be easily maintained and configurable based on the device used.
Under the direction of NASA's Exploration Technology Development Program, robots and space suited subjects from several NASA centers recently completed a very successful demonstration of coordinated activities indicative of base camp operations on the lunar surface. For these activities, NASA chose a site near Meteor Crater, Arizona close to where Apollo Astronauts previously trained. The main scenario demonstrated crew returning from a planetary EVA (extra-vehicular activity) to a temporary base camp and entering a pressurized rover compartment while robots performed tasks in preparation for the next EVA. Scenario tasks included: rover operations under direct human control and autonomous modes, crew ingress and egress activities, autonomous robotic payload removal and stowage operations under both local control and remote control from Houston, and autonomous robotic navigation and inspection. In addition to the main scenario, participants had an opportunity to explore additional robotic operations: hill climbing, maneuvering heaving loads, gathering geo-logical samples, drilling, and tether operations. In this analog environment, the suited subjects and robots experienced high levels of dust, rough terrain, and harsh lighting.
Complex Electronics (CE) now perform tasks that were previously handled in software, such as communication protocols. Many methods used to develop software bare a close resemblance to CE development. Field Programmable Gate Arrays (FPGAs) can have over a million logic gates while system-on-chip (SOC) devices can combine a microprocessor, input and output channels, and sometimes an FPGA for programmability. With this increased intricacy, the possibility of software-like bugs such as incorrect design, logic, and unexpected interactions within the logic is great. With CE devices obscuring the hardware/software boundary, we propose that mature software methodologies may be utilized with slight modifications in the development of these devices. Software Process Assurance for Complex Electronics (SPACE) is a research project that used standardized S/W Assurance/Engineering practices to provide an assurance framework for development activities. Tools such as checklists, best practices and techniques were used to detect missing requirements and bugs earlier in the development cycle creating a development process for CE that was more easily maintained, consistent and configurable based on the device used.
Many of the methods used to develop software bare a close resemblance to Complex Electronics (CE) development. CE are now programmed to perform tasks that were previously handled by software, such as communication protocols. For example, the James Webb Space Telescope will use Field Programmable Gate Arrays (FPGAs), which can have over a million logic gates, to send telemetry. System-on-chip (SoC) devices, another type of complex electronics, can combine a microprocessor, input and output channels, and sometimes an FPGA for programmability. With this increased intricacy, the possibility of software-like bugs such as incorrect design, logic, and unexpected interactions within the logic is great. Since CE devices are obscuring the hardware/software boundary, mature software methodologies have been proposed, with slight modifications, to develop these devices. By using standardized S/W Engineering methods such as checklists, missing requirements and bugs can be detected earlier in the development cycle, thus creating a development process for CE that can be easily maintained and configurable based on the device used.
Complex Electronics (CE) are now programmed to perform tasks that were previously handled in software, such as communication protocols. Many of the methods used to develop software bare a close resemblance to CE development. For instance, Field Programmable Gate Arrays (FPGAs) can have over a million logic gates while system-on-chip (SOC) devices can combine a microprocessor, input and output channels, and sometimes an FPGA for programmability. With this increased intricacy, the possibility of software-like bugs such as incorrect design, logic, and unexpected interactions within the logic is great. Since CE devices are obscuring the hardware/software boundary, we propose that mature software methodologies may be utilized with slight modifications in the development of these devices. Software Process Assurance for Complex Electronics (SPACE) is a research project that looks at using standardized S/W Assurance/Engineering practices to provide an assurance framework for development activities. Tools such as checklists, best practices and techniques can be used to detect missing requirements and bugs earlier in the development cycle creating a development process for CE that will be more easily maintained, consistent and configurable based on the device used.
Microgravity-induced physiological changes, including cardiovascular deconditioning may impair crewmembers f capabilities during exploration missions on the Moon and Mars. The Functional Task Test (FTT), which will be used to assess task performance in short and long duration astronauts, consists of 7 functional tests to evaluate crewmembers f ability to perform activities to be conducted in a partial-gravity environment or following an emergency landing on Earth. The Recovery from Fall/Stand Test (RFST) tests both the subject fs ability to get up from a prone position and orthostatic intolerance. PURPOSE: Crewmembers have never become presyncopal in the first 3 min of quiet stand, yet it is unknown whether 3 min is long enough to cause similar heart rate fluctuations to a 5-min stand. The purpose of this study was to validate and test the reliability of heart rate variability (HRV) analysis of a 3-min quiet stand. METHODS: To determine the validity of using 3 vs. 5-min of standing to assess HRV, 7 healthy subjects remained in a prone position for 2 min, stood up quickly and stood quietly for 6 min. ECG and continuous blood pressure data were recorded. Mean R-R interval and spectral HRV were measured in minutes 0-3 and 0-5 following the heart rate transient due to standing. Significant differences between the segments were determined by a paired t-test. To determine the reliability of the 3-min stand test, 13 healthy subjects completed 3 trials of the complete FTT on separate days, including the RFST with a 3-min stand test. Analysis of variance (ANOVA) was performed on the HRV measures. RESULTS: Spectral HRV measures reflecting autonomic activity were not different (p>0.05) during the 0-3 and 0-5 min segment (mean R-R interval: 738+/-74 ms, 728+/-69 ms; low frequency to high frequency ratio: 6.5+/-2.2, 7.7+/-2.7; normalized high frequency: 0.19+/-0.03, 0.18+/-0.04). The average coefficient of variation for mean R-R interval, systolic and diastolic blood pressures in the prone position and stand test were less than 8% for the test sessions. ANOVA results yielded a greater inter-subject variability (p.0.006) than inter-session variability (p>0.05) for HRV in the stand test. CONCLUSION: These studies show that a 3 minute stand delivers repeatable cardiovascular heart rate and BP data in the context of this larger series of tests such as the FTT.
Space flight-induced muscle atrophy, particularly in the postural and locomotorymuscles, may impair task performance during long-duration space missions and planetary exploration. High intensity free weight (FW) resistive exercise training has been shown to prevent atrophy during bed rest, a space flight analog. NASA developed the Advanced Resistive Exercise Device (ARED) to simulate the characteristics of FW exercise (i.e. constant mass, inertial force) and to be used as a countermeasure during International Space Station (ISS) missions. PURPOSE: To compare the efficacy of ARED and FW training to induce hypertrophy in specific muscle groups in ambulatory subjects prior to deploying ARED on the ISS. METHODS: Twenty untrained subjects were assigned to either the ARED (8 males, 3 females) or FW (6 males, 3 females) group and participated in a periodizedtraining protocol consisting of squat (SQ), heel raise (HR), and deadlift(DL) exercises 3 d wk-1 for 16 wks. SQ, HR, and DL muscle strength (1RM) was measured before, after 8 wks, and after 16 wks of training to prescribe exercise and measure strength changes. Muscle volume of the vastigroup (V), hamstring group (H), hip adductor group (ADD), medial gastrocnemius(MG), lateral gastrocnemius(LG), and deep posterior muscles including soleus(DP) was measured using MRI pre-and post-training. Consecutive cross-sectional images (8 mm slices with a 2 mm gap) were analyzed and summed. Anatomical references insured that the same muscle sections were analyzed pre-and post-training. Two-way repeated measures ANOVAs (p<0.05) were used to test for differences in muscle strength and volume between training devices. RESULTS: SQ, HR, and DL 1RM increased in both FW (SQ: 49+/-6%, HR: 12+/-2%, DL: 23+/-4%) and ARED (SQ: 31+/-4%, HR: 18+/-2%, DL: 23+/-3%) groups. Both groups increased muscle volume in the V (FW: 13+/-2%, ARED: 10+/-2%), H (FW: 3+/-1%, ARED: 3+/-1 %), ADD (FW: 15=/-2%, ARED: 10+/-1%), LG (FW: 7+/-2%, ARED: 4+/-1%), MG (FW: 7+/-2%, ARED: 5+/-2%), and DP (FW: 2+/-1%; ARED: 2+/-1%) after training. There were no between group differences in muscle strength or volume. CONCLUSIONS: The increase in muscle volume and strength following ARED training is not different than FW training. With the training effects similar to FW and a 600 lb load capacity, ARED likely will protect against muscle atrophy in microgravity.
The benefits of automatic-application code generation are widely accepted within the software engineering community. These benefits include raised abstraction level of application programming, shorter product development time, lower maintenance costs, and increased code quality and consistency. Surprisingly, code generation concepts have not yet found wide acceptance and use in the field of programmable logic controller (PLC) software development. Software engineers at Kennedy Space Center recognized the need for PLC code generation while developing the new ground checkout and launch processing system, called the Launch Control System (LCS). Engineers developed a process and a prototype software tool that automatically translates a high-level representation or specification of application software into ladder logic that executes on a PLC. All the computer hardware in the LCS is planned to be commercial off the shelf (COTS), including industrial controllers or PLCs that are connected to the sensors and end items out in the field. Most of the software in LCS is also planned to be COTS, with only small adapter software modules that must be developed in order to interface between the various COTS software products. A domain-specific language (DSL) is a programming language designed to perform tasks and to solve problems in a particular domain, such as ground processing of launch vehicles. The LCS engineers created a DSL for developing test sequences of ground checkout and launch operations of future launch vehicle and spacecraft elements, and they are developing a tabular specification format that uses the DSL keywords and functions familiar to the ground and flight system users. The tabular specification format, or tabular spec, allows most ground and flight system users to document how the application software is intended to function and requires little or no software programming knowledge or experience. A small sample from a prototype tabular spec application is shown.
Autonomous systems of multiple-agent air/ground robotic units for exploration of the surfaces of remote planets are undergoing development. Modified versions of these systems could be used on Earth to perform tasks in environments dangerous or inaccessible to humans: examples of tasks could include scientific exploration of remote regions of Antarctica, removal of land mines, cleanup of hazardous chemicals, and military reconnaissance. A basic system according to this concept (see figure) would include a unit, suspended by a balloon or a blimp, that would be in radio communication with multiple robotic ground vehicles (rovers) equipped with video cameras and possibly other sensors for scientific exploration. The airborne unit would be free-floating, controlled by thrusters, or tethered either to one of the rovers or to a stationary object in or on the ground. Each rover would contain a semi-autonomous control system for maneuvering and would function under the supervision of a control system in the airborne unit. The rover maneuvering control system would utilize imagery from the onboard camera to navigate around obstacles. Avoidance of obstacles would also be aided by readout from an onboard (e.g., ultrasonic) sensor. Together, the rover and airborne control systems would constitute an overarching closed-loop control system to coordinate scientific exploration by the rovers.
A general-purpose computer program for planning the actions of a spacecraft or other complex system has been augmented by incorporating a subprogram that reasons about uncertainties in such continuous variables as times taken to perform tasks and amounts of resources to be consumed. This subprogram computes parametric probability distributions for time and resource variables on the basis of user-supplied models of actions and resources that they consume. The current system accepts bounded Gaussian distributions over action duration and resource use. The distributions are then combined during planning to determine the net probability distribution of each resource at any time point. In addition to a full combinatoric approach, several approximations for arriving at these combined distributions are available, including maximum-likelihood and pessimistic algorithms. Each such probability distribution can then be integrated to obtain a probability that execution of the plan under consideration would violate any constraints on the resource. The key idea is to use these probabilities of conflict to score potential plans and drive a search toward planning low-risk actions. An output plan provides a balance between the user s specified averseness to risk and other measures of optimality.
Defining touch temperature limits for skin contact with both hot and cold objects is important to prevent pain and skin damage, which may affect task performance or become a safety concern. Pain and skin damage depend on the resulting skin temperature during contact, which depends on the object s initial temperature, its material properties and its ability to transfer heat. However, previous spacecraft standards have incorrectly defined touch temperature limits in terms of a single object temperature value for all materials, or have provided limited material-specific values which do not cover the gamut of most designs. A new approach is being used in new NASA standards, which defines touch temperature limits in terms of skin temperature at pain onset for bare skin contact with hot and cold objects. The authors have developed an analytical verification method for safe hot and cold object temperatures for contact times from 1 second to infinity.
A space suit's mobility is critical to an astronaut's ability to perform work efficiently. As mobility increases, the astronaut can perform tasks for longer durations with less fatigue. Mobility can be broken down into two parts: range of motion (ROM) and torque. These two measurements describe how the suit moves and how much force it takes to move. Two methods were chosen to define mobility requirements for the Constellation Space Suit Element (CSSE). One method focuses on range of motion and the second method centers on joint torque. A joint torque test was conducted to determine a baseline for current advanced space suit joint torques. This test utilized the following space suits: Extravehicular Mobility Unit (EMU), Advanced Crew Escape Suit (ACES), I-Suit, D-Suit, Enhanced Mobility (EM)- ACES, and Mark III (MK-III). Data was collected data from 16 different joint movements of each suit. The results were then reviewed and CSSE joint torque requirement values were selected. The focus of this paper is to discuss trends observed during data analysis.
The United States NASA Space Shuttle has long been considered an extremely capable yet relatively expensive rocket. A great part of the roughly US $500 million per launch expense was the support footprint: refurbishment and maintenance of the space shuttle system, together with the long list of resources required to support it, including personnel, tools, facilities, transport and support equipment. NASA determined to make its next rocket system with a smaller logistics footprint, and thereby more cost-effective and quicker turnaround. The logical solution was to adopt a standard Logistics Support Analysis (LSA) process based on GEIA-STD-0007 http://www.logisticsengineers.org/may09pres/GEIASTD0007DEXShortIntro.pdf which is the successor of MIL-STD-1388-2B widely used by U.S., NATO, and other world military services and industries. This approach is unprecedented at NASA: it is the first time a major program of programs, Project Constellation, is factoring logistics and supportability into design at many levels. This paper will focus on one of those levels NASA ground support equipment for the next generation of NASA rockets and on building a Logistics Support Analysis Record (LSAR) for developing and documenting a support solution and inventory of resources for. This LSAR is actually a standards-based database, containing analyses of the time and tools, personnel, facilities and support equipment required to assemble and integrate the stages and umbilicals of a rocket. This paper will cover building this database from scratch: including creating and importing a hierarchical bill of materials (BOM) from legacy data; identifying line-replaceable units (LRUs) of a given piece of equipment; analyzing reliability and maintainability of said LRUs; and therefore making an assessment back to design whether the support solution for a piece of equipment is too much work, i.e., too resource-intensive. If one must replace or inspect an LRU too much, perhaps a modification of the design of the equipment can make such operational effort unnecessary. Finally, this paper addresses processes of tying resources to a timeline of tasks performed in ground operations: this enables various overarching analyses, e.g., a summarization of all resources used for a given piece of equipment. Quality Control of data will also be discussed: importing and exporting data from product teams, including spreadsheets-todatabase or data exchange between databases.
Defining touch temperature limits for skin contact with both hot and cold objects is important to prevent pain and skin damage, which may affect task performance or become a safety concern. Pain and skin damage depend on the skin temperature during contact, which depends on the contact thermal conductance, the object's initial temperature, and its material properties. However, previous spacecraft standards have incorrectly defined touch temperature limits in terms of a single object temperature value for all materials, or have provided limited material-specific values which do not cover the gamut of likely designs. A new approach has been developed for updated NASA standards, which defines touch temperature limits in terms of skin temperature at pain onset for bare skin contact with hot and cold objects. The authors have developed an analytical verification method for safe hot and cold object temperatures for contact times from 1 second to infinity.
This paper presents results of a flight test of the L-1 adaptive control architecture designed to directly compensate for significant uncertain cross-coupling in nonlinear systems. The flight test was conducted on the subscale turbine powered Generic Transport Model that is an integral part of the Airborne Subscale Transport Aircraft Research system at the NASA Langley Research Center. The results presented are for piloted tasks performed during the flight test.
Project M is a mission Johnson Space Center is working on to send an autonomous humanoid robot to the moon (also known as Robonaut 2) in l000 days. The robot will be in a lander, fueled by liquid oxygen and liquid methane, and land on the moon, avoiding any hazardous obstacles. It will perform tasks like maintenance, construction, and simple student experiments. This mission is also being used as inspiration for new advancements in technology. I am considering three of the design assumptions that contribute to determining the mission feasibility: maturity of robotic technology, launch vehicle determination, and the LOX/Methane fueled spacecraft