Search NASA⌕ Search

Engineering topics

Cannon, Howard

Publications and source records attributed to Cannon, Howard.

14 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2019

Planetary Rover Simulation for Lunar Exploration Missions

When planning planetary rover missions it is useful to develop intuition and skills driving in, quite literally, alien environments before incurring the cost of reaching said locales. Simulators make it possible to operate in environments that have the physical characteristics of target locations without the expense and overhead of extensive physical tests. To that end, NASA Ames and Open Robotics collaborated on a Lunar rover driving simulator based on the open source Gazebo simulation platform and leveraging ROS (Robotic Operating System) components. The simulator was integrated with research and mission software for rover driving, system monitoring, and science instrument simulation to constitute an end-to-end Lunar mission simulation capability. Although we expect our simulator to be applicable to arbitrary Lunar regions, we designed to a reference mission of prospecting in polar regions. The harsh lighting and low illumination angles at the Lunar poles combine with the unique reflectance properties of Lunar regolith to present a challenging visual environment for both human and computer perception. Our simulator placed an emphasis on high fidelity visual simulation in order to produce synthetic imagery suitable for evaluating human rover drivers with navigation tasks, as well as providing test data for computer vision software development.In this paper, we describe the software used to construct the simulated Lunar environment and the components of the driving simulation. Our synthetic terrain generation software artificially increases the resolution of Lunar digital elevation maps by fractal synthesis and inserts craters and rocks based on Lunar size-frequency distribution models. We describe the necessary enhancements to import large scale, high resolution terrains into Gazebo, as well as our approach to modeling the visual environment of the Lunar surface. An overview of the mission software system is provided, along with how ROS was used to emulate flight software components that had not been developed yet. Finally, we discuss the effect of using the high-fidelity synthetic Lunar images for visual odometry. We also characterize the wheel slip model, and find some inconsistencies in the produced wheel slip behaviour.

Allan, Mark↗
NASA NTRS2018

Starling1 - Mission Technologies Overview

The Starling series of demonstration missions will test technologies required to achieve affordable, distributed spacecraft ("swarm") missions that: are scalable to at least 100 spacecraft for applications that include synchronized multipoint measurements; involve closely coordinated ensembles of two or more spacecraft operating as a single unit for interferometric, synthetic aperture, or similar sensor architectures; or use autonomous or semi-autonomous operation of multiple spacecraft functioning as a unit to achieve science or other mission objectives with low-cost small spacecraft.Starling1 will focus on developing technologies that enable scalability and deep space application. The mission goals include the demonstration of a Mobile Ad-hoc NETwork (MANET) through an in-space communication experiment, vision based relative navigation through the Starling Formation-flying Optical eXperiment (StarFOX), and demonstration of autonomous spacecraft reconfiguration using technologies developed by the Distributed System Autonomy (DSA) project.

Cannon, Howard↗
NASA NTRS2017

Application of CFS to a Lunar Rover: Resource Prospector (RP)

Resource Prospector (RP) is a lunar mission sponsored by NASA's Advanced Exploration Systems (AES) division, that aims to study in-situ resource utilization (ISRU) feasibility and technologies on the surface of the moon. The RP mission's lunar surface segment includes a rover equipped with with a suite of instruments specifically designed to measure and map volatiles both at the surface and in the subsurface. Of particular interest is the quantity and state of volatiles in permanently shadowed regions. To conduct the mission, ground system operators will remotely drive the rover, directing it to waypoints along the surface in order to achieve measurement objectives. At selected locations, an onboard drill will be deployed to collect material and obtain direct measurements of the subsurface constituents. RP is currently planned for launch in 2022. RP is managed at NASA Ames Research Center. The RP Rover is being designed and developed by NASA Johnson Space Center (JSC) in partnership with NASA Ames. NASA Kennedy Space Center (KSC) is responsible for the Honeybee drilling system and science payload. In order to better understand the technical challenges and demonstrate capability, in 2015 the RP project developed a rover testbed (known as RP15). In this mission in a year, a rover was designed, developed, and outfitted with science instruments and a drill. The rover was operated from a remote operations center, and operated in an outdoor lunar rock yard at Johnson space center. The study was a resounding success meeting all objectives. The RP Rover software architecture and development processes were based on the successful Lunar Atmosphere and Dust Environment Explorer spacecraft. This architecture is built on the Core Flight System software and an interface to Matlab/Simulink auto-generated software components known as the Simulink Interface Layer (SIL). The application of this lunar satellite inspired framework worked well for the rover application, and is currently being planned for the mission. This presentation provides an overview of the architecture and processes, and describes some of the changes and challenges for the rover application.

RP↗
NASA NTRS2017

Application of the Core Flight System to a Lunar Rover

Resource Prospector (RP) is a lunar mission sponsored by NASAs Advanced Exploration Systems (AES) division, that aims to study in-situ resource utilization (ISRU) feasibility and technologies on the surface of the moon. The RP missions lunar surface segment includes a rover equipped with with a suite of instruments specifically designed to measure and map volatiles both at the surface and in the subsurface. Of particular interest is the quantity and state of volatiles in permanently shadowed regions. To conduct the mission, ground system operators will remotely drive the rover, directing it to waypoints along the surface in order to achieve measurement objectives. At selected locations, an onboard drill will be deployed to collect material and obtain direct measurements of the subsurface constituents. RP is currently planned for launch in 2022. RP is managed at NASA Ames Research Center. The RP Rover is being designed and developed by NASA Johnson Space Center (JSC) in partnership with NASA Ames. NASA Kennedy Space Center (KSC) is responsible for the Honeybee drilling system and science payload.In order to better understand the technical challenges and demonstrate capability, in 2015 the RP project developed a rover testbed (known as RP15). In this mission in a year, a rover was designed, developed, and outfitted with science instruments and a drill. The rover was operated from a remote operations center, and operated in an outdoor lunar rock yard at Johnson space center. The study was a resounding success meeting all objectives. The RP Rover software architecture and development processes were based on the successful Lunar Atmosphere and Dust Environment Explorer spacecraft. This architecture is built on the Core Flight System software and an interface to MatlabSimulink auto-generated software components known as the Simulink Interface Layer (SIL). The application of this lunar satellite inspired framework worked well for the rover application, and is currently being planned for the mission. This presentation provides an overview of the architecture and processes, and describes some of the changes and challenges for the rover application.

CFS↗
NASA NTRS2016

Characterization of Stereo Vision Performance for Roving at the Lunar Poles

Surface rover operations at the polar regions of airless bodies, particularly the Moon, are of particular interest to future NASA science missions such as Resource Prospector (RP). Polar optical conditions present challenges to conventional imaging techniques, with repercussions to driving, safeguarding and science. High dynamic range, long cast shadows, opposition and white out conditions are all significant factors in appearance. RP is currently undertaking an effort to characterize stereo vision performance in polar conditions through physical laboratory experimentation with regolith simulants, obstacle distributions and oblique lighting.

Sensor Characterization↗
NASA NTRS2015

LADEE Preparations for Contingency Operations for the Lunar Orbit Insertion Maneuver

The Lunar Atmosphere and Dust Environment Explorer (LADEE) spacecraft was launched on September 7, 2013 UTC, and completed its mission on April 17, 2014 UTC with a directed impact to the Lunar Surface. Its primary goals were to examine the lunar atmosphere, measure lunar dust, and to demonstrate high rate laser communications. The mission objectives, much of which can be attributed to careful LADEE mission was a resounding success, achieving all planning and preparation. This paper discusses the specific preparations for fault conditions that could occur during a highly-critical phase of the mission, the Lunar Orbit Insertion (LOI). highly critical phase of the mission.

failure analysis↗
NASA NTRS2015

LADEE Preparations for Contingency Operations for the Lunar Orbit Insertion Maneuver

The Lunar Atmosphere and Dust Environment Explorer (LADEE) spacecraft was launched on September 6, 2013, and completed its mission on April 17, 2014 with a directed impact to the Lunar Surface. Its primary goals were to examine the lunar atmosphere, measure lunar dust, and to demonstrate high rate laser communications. The LADEE mission was a resounding success, achieving all mission objectives, much of which can be attributed to careful planning and preparation. This paper discusses the specific preparations for fault conditions that could occur during a highly-critical phase of the mission. To get to the Moon, the spacecraft traversed multiple phasing loops around the Earth, and then executed a breaking maneuver to achieve lunar orbit. This Lunar Orbit Insertion (LOI) maneuver was perhaps the most time-critical phase of the entire mission. The LOI maneuver had to occur within a twenty minute window in order to achieve lunar orbit with an acceptable amount of propellant remaining. Missing this window would have likely resulted in a loss of the entire mission. An additional challenge of the maneuver was that spacecraft was out of view for approximately one hour prior to the main thruster burn, with the burn needing to occur within five minutes after coming into view. These conditions resulted in unique challenges for ground operations and the fault management system. Early in the planning stages of the mission, the criticality and challenges of this maneuver were evident to the system designers. The major concern was that any triggering of the on-board fault management system, whether it is in response to a true fault or a false positive, would result in an unacceptable delay to the burn. Therefore the flight software was designed with a flexible fault management system, such that any or all of the fault management responses could be disabled for the lead up and execution of the maneuver. Later, a triage was conducted to develop a list of fault responses, mapped to various parts of the timeline of the maneuver. Some of these contingency responses were solely ground-based if the time to detect, diagnose, and respond were adequate. Other responses were automated on-board if the response time from the ground would have been inadequate. For instance, in order to recover from a system reboot, on-board automation would have automatically reconfigured the spacecraft for the burn and reoriented the spacecraft to the burn attitude.These contingency responses were practiced, over and over, during numerous rehearsals. Although the LOI maneuver was executed without having to use any of these contingencies, the LADEE team was adequately prepared for this highly critical phase of the mission.

Cannon, Howard↗
NASA NTRS2011

LADEE Satellite Modeling and Simulation Development

As human activity on and around the Moon increases, so does the likelihood that our actions will have an impact on its atmosphere. The Lunar Atmosphere and Dust Environment Explorer (LADEE), a NASA satellite scheduled to launch in 2013, will orbit the Moon collecting composition, density, and time variability data to characterize the current state of the lunar atmosphere. LADEE will also test the concept of the "Modular Common Bus" spacecraft architecture, an effort to reduce both development time and cost by designing reusable, modular components for use in multiple missions with similar requirements. An important aspect of this design strategy is to both simulate the spacecraft and develop the flight code in Simulink, a block diagram-style programming language that allows easy algorithm visualization and performance testing. Before flight code can be tested, however, a realistic simulation of the satellite and its dynamics must be generated and validated. This includes all of the satellite control system components such as actuators used for force and torque generation and sensors used for inertial orientation reference. My primary responsibilities have included designing, integrating, and testing models for the LADEE thrusters, reaction wheels, star trackers, and rate gyroscopes.

Adams, Michael↗
NASA NTRS2007

Automated Diagnosis and Control of Complex Systems

Livingstone2 is a reusable, artificial intelligence (AI) software system designed to assist spacecraft, life support systems, chemical plants, or other complex systems by operating with minimal human supervision, even in the face of hardware failures or unexpected events. The software diagnoses the current state of the spacecraft or other system, and recommends commands or repair actions that will allow the system to continue operation. Livingstone2 is an enhancement of the Livingstone diagnosis system that was flight-tested onboard the Deep Space One spacecraft in 1999. This version tracks multiple diagnostic hypotheses, rather than just a single hypothesis as in the previous version. It is also able to revise diagnostic decisions made in the past when additional observations become available. In such cases, Livingstone might arrive at an incorrect hypothesis. Re-architecting and re-implementing the system in C++ has increased performance. Usability has been improved by creating a set of development tools that is closely integrated with the Livingstone2 engine. In addition to the core diagnosis engine, Livingstone2 includes a compiler that translates diagnostic models written in a Java-like language into Livingstone2's language, and a broad set of graphical tools for model development.

Kurien, James↗
NASA NTRS2007

Hybrid Automated Diagnosis of Discrete/Continuous Systems

A recently conceived method of automated diagnosis of a complex electromechanical system affords a complete set of capabilities for hybrid diagnosis in the case in which the state of the electromechanical system is characterized by both continuous and discrete values (as represented by analog and digital signals, respectively). The method is an integration of two complementary diagnostic systems: (1) beacon-based exception analysis for multi-missions (BEAM), which is primarily useful in the continuous domain and easily performs diagnoses in the presence of transients; and (2) Livingstone, which is primarily useful in the discrete domain and is typically restricted to quasi-steady conditions. BEAM has been described in several prior NASA Tech Briefs articles: "Software for Autonomous Diagnosis of Complex Systems" (NPO-20803), Vol. 26, No. 3 (March 2002), page 33; "Beacon-Based Exception Analysis for Multimissions" (NPO-20827), Vol. 26, No. 9 (September 2002), page 32; "Wavelet-Based Real-Time Diagnosis of Complex Systems" (NPO-20830), Vol. 27, No. 1 (January 2003), page 67; and "Integrated Formulation of Beacon-Based Exception Analysis for Multimissions" (NPO-21126), Vol. 27, No. 3 (March 2003), page 74. Briefly, BEAM is a complete data-analysis method, implemented in software, for real-time or off-line detection and characterization of faults. The basic premise of BEAM is to characterize a system from all available observations and train the characterization with respect to normal phases of operation. The observations are primarily continuous in nature. BEAM isolates anomalies by analyzing the deviations from nominal for each phase of operation. Livingstone is a model-based reasoner that uses a model of a system, controller commands, and sensor observations to track the system s state, and detect and diagnose faults. Livingstone models a system within the discrete domain. Therefore, continuous sensor readings, as well as time, must be discretized. To reason about continuous systems, Livingstone uses monitors that discretize the sensor readings using trending and thresholding techniques. In development of the a hybrid method, BEAM results were sent to Livingstone to serve as an independent source of evidence that is in addition to the evidence gathered by Livingstone standard monitors. The figure depicts the flow of data in an early version of a hybrid system dedicated to diagnosing a simulated electromechanical system. In effect, BEAM served as a "smart" monitor for Livingstone. BEAM read the simulation data, processed the data to form observations, and stored the observations in a file. A monitor stub synchronized the events recorded by BEAM with the output of the Livingstone standard monitors according to time tags. This information was fed to a real-time interface, which buffered and fed the information to Livingstone, and requested diagnoses at the appropriate times. In a test, the hybrid system was found to correctly identify a failed component in an electromechanical system for which neither BEAM nor Livingstone alone yielded the correct diagnosis.

Park, Han↗
NASA NTRS2005

Robotic and Human-Tended Collaborative Drilling Automation for Subsurface Exploration

Future in-situ lunar/martian resource utilization and characterization, as well as the scientific search for life on Mars, will require access to the subsurface and hence drilling. Drilling on Earth is hard - an art form more than an engineering discipline. Human operators listen and feel drill string vibrations coming from kilometers underground. Abundant mass and energy make it possible for terrestrial drilling to employ brute-force approaches to failure recovery and system performance issues. Space drilling will require intelligent and autonomous systems for robotic exploration and to support human exploration. Eventual in-situ resource utilization will require deep drilling with probable human-tended operation of large-bore drills, but initial lunar subsurface exploration and near-term ISRU will be accomplished with lightweight, rover-deployable or standalone drills capable of penetrating a few tens of meters in depth. These lightweight exploration drills have a direct counterpart in terrestrial prospecting and ore-body location, and will be designed to operate either human-tended or automated. NASA and industry now are acquiring experience in developing and building low-mass automated planetary prototype drills to design and build a pre-flight lunar prototype targeted for 2011-12 flight opportunities. A successful system will include development of drilling hardware, and automated control software to operate it safely and effectively. This includes control of the drilling hardware, state estimation of both the hardware and the lithography being drilled and state of the hole, and potentially planning and scheduling software suitable for uncertain situations such as drilling. Given that Humans on the Moon or Mars are unlikely to be able to spend protracted EVA periods at a drill site, both human-tended and robotic access to planetary subsurfaces will require some degree of standalone, autonomous drilling capability. Human-robotic coordination will be important, either between a robotic drill and humans on Earth, or a human-tended drill and its visiting crew. The Mars Analog Rio Tinto Experiment (MARTE) is a current project that studies and simulates the remote science operations between an automated drill in Spain and a distant, distributed human science team. The Drilling Automation for Mars Exploration (DAME) project, by contrast: is developing and testing standalone automation at a lunar/martian impact crater analog site in Arctic Canada. The drill hardware in both projects is a hardened, evolved version of the Advanced Deep Drill (ADD) developed by Honeybee Robotics for the Mars Subsurface Program. The current ADD is capable of 20m, and the DAME project is developing diagnostic and executive software for hands-off surface operations of the evolved version of this drill. The current drill automation architecture being developed by NASA and tested in 2004-06 at analog sites in the Arctic and Spain will add downhole diagnosis of different strata, bit wear detection, and dynamic replanning capabilities when unexpected failures or drilling conditions are discovered in conjunction with simulated mission operations and remote science planning. The most important determinant of future 1unar and martian drilling automation and staffing requirements will be the actual performance of automated prototype drilling hardware systems in field trials in simulated mission operations. It is difficult to accurately predict the level of automation and human interaction that will be needed for a lunar-deployed drill without first having extensive experience with the robotic control of prototype drill systems under realistic analog field conditions. Drill-specific failure modes and software design flaws will become most apparent at this stage. DAME will develop and test drill automation software and hardware under stressful operating conditions during several planned field campaigns. Initial results from summer 2004 tests show seven identifi distinct failure modes of the drill: cuttings-removal issues with low-power drilling into permafrost, and successful steps at executive control and initial automation.

Glass, Brian↗
NASA NTRS2004

Mars Analog Rio Tinto Experiment (MARTE): 2003 Drilling Campaign to Search for a Subsurface Biosphere at Rio Tinto Spain

The MARTE (Mars Astrobiology Research and Technology Experiment) project, an ASTEP field experiment, is exploring for a hypothesized subsurface anaerobic chemoautotrophic biosphere in the region of the Tinto River- or Rio Tinto- in southwestern Spain. It is also demonstrating technology needed to search for a subsurface biosphere on Mars. The project has three primary objectives: (1) search for and characterize subsurface life at Rio Tinto along with the physical and chemical properties and sustaining energy sources of its environment, (2) perform a high fidelity simulation of a robotic Mars drilling mission to search for life, and (3) demonstrate the drilling, sample handling, and instrument technologies relevant to searching for life on Mars. The simulation of the robotic drilling mission is guided by the results of the aseptic drilling campaign to search for life at Rio Tinto. This paper describes results of the first phase of the aseptic drilling campaign.

Stoker, Carol↗
NASA NTRS2004

Teleoperated Modular Robots for Lunar Operations

Solar system exploration is currently carried out by special purpose robots exquisitely designed for the anticipated tasks. However, all contingencies for in situ resource utilization (ISRU), human habitat preparation, and exploration will be difficult to anticipate. Furthermore, developing the necessary special purpose mechanisms for deployment and other capabilities is difficult and error prone. For example, the Galileo high gain antenna never opened, severely restricting the quantity of data returned by the spacecraft. Also, deployment hardware is used only once. To address these problems, we are developing teleoperated modular robots for lunar missions, including operations in transit from Earth. Teleoperation of lunar systems from Earth involves a three second speed-of-light delay, but experiment suggests that interactive operations are feasible.' Modular robots typically consist of many identical modules that pass power and data between them and can be reconfigured for different tasks providing great flexibility, inherent redundancy and graceful degradation as modules fail. Our design features a number of different hub, link, and joint modules to simplify the individual modules, lower structure cost, and provide specialized capabilities. Modular robots are well suited for space applications because of their extreme flexibility, inherent redundancy, high-density packing, and opportunities for mass production. Simple structural modules can be manufactured from lunar regolith in situ using molds or directed solar sintering. Software to direct and control modular robots is difficult to develop. We have used genetic algorithms to evolve both the morphology and control system for walking modular robots3 We are currently using evolvable system technology to evolve controllers for modular robots in the ISS glove box. Development of lunar modular robots will require software and physical simulators, including regolith simulation, to enable design and test of robot software and hardware, particularly automation software. Ready access to these simulators could provide opportunities for contest-driven development ala RoboCup (http://www.robocup.org/). Licensing of module designs could provide opportunities in the toy market and for spin-off applications.

Globus, Al↗