SEARCH · Search NASA

Results for “Planning scheduling execution rovers”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

35 records · Page 2

All sources NASA NTRS DOE OSTI

NASA NTRS1999

Autonomous Rovers for Mars Exploration

Rovers will play a critical role in the exploration of Mars. Near-term mission plans call for long traverses over unknown terrain, robust navigation and instrument placement, and reliable operations for extended periods of time. Longer-term missions may visit multiple science sites in a single day and perform opportunistic science data collection, as well as complex scouting, construction, and maintenance tasks in preparation for an eventual human presence. The Pathfinder mission demonstrated the potential for robotic Mars exploration but at the same time indicated the need for more rover autonomy. The highly ground-intensive control with infrequent communication and high latency limited the effectiveness of the Sojourner rover. When failures occurred, Sojourner often sat idle for extended periods of time, awaiting further commands from earth. In future missions, the tasks will be more complex and extended; hence there will be even more situations where things do not go exactly as planned. Significant advances in rover autonomy are needed to cope with increasing task complexity and greater execution uncertainty. Towards this end, we have designed an on-board executive architecture that incorporates robust operation, resource utilization, and failure recovery. In addition, we have designed ground tools to produce and refine contingent schedules that take advantage of the on-board architecture's flexible execution characteristics. Together, the on-board executive and the ground tools constitute an integrated rover autonomy architecture. This work draws from our experience with the Deep Space One autonomy experiment, with enhancements to ensure robust operation in the face of the unpredictable, complex environment that the rover will encounter on Mars. The rover autonomy architecture is currently being developed and deployed on the Marsokhod rover platform at NASA Ames Research Center. The capabilities of the rover autonomy architecture to support autonomous operations will be demonstrated concretely in upcoming field tests.

Anderson, Corin↗

NASA NTRS2002

Continual coordination of shared activities

Interacting agents that interleave planning and execution must reach consensus on their commitments to each other. For domains with varying degrees of interaction and different constraints on communication and computation, agents will require different coordination protocols in order to efficiently achieve their goals. ShAC (Shared Activity Coordination) is a framework for designing coordination protocols and an algorithm for continually coordinating agents using these protocols during execution. We show how a variety of protocols can be constructed using this framework and describe how ShAC coordinates two rovers and an orbiter in a simulated Mars scenario.

multiple agents coordination planning scheduling M↗

NASA NTRS2002

Continual coordination of spacecraft through shared activities

Interacting agents that interleave planning and execution must reach consensus on their commitments to each other. In domains where agents have varying degrees of interaction and different constraints on communication and computation, agents will require different coordination protocols in order to efficiently reach consensus. ShAC (Shared Activity Coordination) is a framework for designing coordination protocols with an algorithm for continually coordinating agents using these protocols during execution. We show how to construct a wide range of protocols using this framework and describe how ShAC coordinates two rovers and an orbiter in a simulated Mars scenario.

Multiple agents coordination planning scheduling M↗

NASA NTRS2003

An Approach to Autonomous Operations for Remote Mobile Robotic Exploration

This viewgraph presentation addresses the use of autonomy for remote mobile robotic exploration. The contents include; 1) Why Use Autonomy?; 2) What Are Some Options? JPL (Reasoning); 3) More Options.. . (Modeling); 4) The CLEaR Control System (Closed Loop Execution and Recovery); 5) Method of Response; 6) Overall Goal; 7) CLEaR in Action; 8) Initial Scenario; 9) Initial Scenario - Planned; 10) Unforeseen Events; and 11) Ongoing Research.

rovers↗

NASA NTRS2002

The Mars Exploration Rover/Collaborative Information Portal

Astrology has long argued that the alignment of the planets governs human affairs. Science usually scoffs at this. There is, however, an important exception: sending spacecraft for planetary exploration. In late May and early June, 2003, Mars will be in position for Earth launch. Two Mars Exploration Rovers (MER) will rocket towards the red planet. The rovers will perform a series of geological and meteorological experiments, seeking to examine geological evidence for water and conditions once favorable for life. Back on earth, a small army of surface operations staff will work to keep the rovers running, sending directions for each day's operations and receiving the files encoding the outputs of the Rover's six instruments. (Mars is twenty light minutes from Earth. The rovers must be robots.) The fundamental purpose of the project is, after all, Science. Scientists have experiments they want to run. Ideally, scientists want to be immediately notified when the data products of their experiments have been received, so that they can examine their data and (collaboratively) deduce results. Mars is an unpredictable environment. We may issue commands to the rovers but there is considerable uncertainty in how the commands will be executed and whether what the rovers sense will be worthy of further pursuit. The steps of what is, to a scientist, conceptually an individual experiment may be scattered over a large number of activities. While the scientific staff has an overall strategic idea of what it would like to accomplish, activities are planned daily. The data and surprises of the previous day need to be integrated into the negotiations for the next day's activities, all synchronized to a schedule of transmission windows . Negotiations is the operative term, as different scientists want the resources to run possibly incompatible experiments. Many meetings plan each day's activities.

Walton, Joan↗

NASA NTRS2008

Orbital Express Mission Operations Planning and Resource Management using ASPEN

As satellite equipment and mission operations become more costly, the drive to keep working equipment running with less man-power rises.Demonstrating the feasibility of autonomous satellite servicing was the main goal behind the Orbital Express (OE) mission. Planning the satellite mission operations for OE required the ability to create a plan which could be executed autonomously over variable conditions. The Automated-Scheduling and Planning Environment (ASPEN)tool, developed at the Jet Propulsion Laboratory, was used to create the schedule of events in each daily plan for the two satellites of the OE mission. This paper presents an introduction to the ASPEN tool, the constraints of the OE domain, the variable conditions that were presented within the mission, and the solution to operations that ASPEN provided. ASPEN has been used in several other domains, including research rovers, Deep Space Network scheduling research, and in flight operations for the ASE project's EO1 satellite. Related work is discussed, as are the future of ASPEN and the future of autonomous satellite servicing.

Automated Scheduling and Planning Environment (ASP↗

NASA NTRS2021

Ground-based Automated Scheduling for Operations of the Mars 2020 Rover Mission

The National Aeronautics and Space Administration’s (NASA) Mars 2020 Rover, named Perseverance, landed on the surface of Mars in Jezero Crater on February 18, 2021. Since the landing, the rover’s activities have been planned with the aid of a ground-based automated scheduling system called Copilot. Automated scheduling is very rare for planetary rover missions. Historically humans have created a schedule manually and ensured that the schedule satisfied all constraints. Higher levels of automation in the system allows science planners to produce schedules for the rover more quickly. In addition to scheduling user-provided activities, Copilot generates and schedules two types of support activities: sleep activities and heating activities. Some activities require the CPU to be on as they execute, so Copilot schedules wakeups and shutdowns of the CPU at the appropriate times. Some activities require areas of the rover to be heated before they can execute, and that heating must be maintained throughout the duration of the activity. Copilot schedules the preheat and maintenance heating activities for the user-provided activities that require them. To facilitate Copilot usage, the Crosscheck tool shows the science planners how Copilot constructed a schedule. For activities that fail to be scheduled, Crosscheck gives information on the constraints that the activity would have violated. This gives the users insight into how to change the input activities and constraints in order to achieve a schedule that satisfies their goals.

Towey, Shannon↗

NASA NTRS2019

Supporting automation in spacecraft activity planning with simulation and visualization

Automation is gaining momentum in spacecraft operations, however, at a much slower pace than comparable application domains. The reasons behind slow adoption is (1) the need for high reliability and (2) the limited interaction between human operators and the automated systems. For automated systems to be adopted and trusted by humans, humans need to gain intuition about the decision making process of the automated system and trust in its execution [1]. In this paper, we present how simulation and visualization can enhance adoption of an automated on-board activity scheduling system, specifically in the context of Mars2020 rover mission[2]. The visualization aims to communicate to the users degree of variance and uncertainty in possible schedule execution. Our preliminary validation results suggest that the proposed visualization increases operators’ conﬁdence in—and likelihood of adopting—the automated scheduling system.

Chien, Steve↗

NASA NTRS2021

Commanding Curiosity from the Couch: MSL Remote Operations, Challenges, and Path Ahead

This paper describes how the Mars ScienceLaboratory (MSL) project prepared for and successfully beganCuriosity rover Mars operations from their homes in responseto the COVID-19 work-from-home orders. In a very shortperiod, the team developed procedures and executed a remoteoperations readiness test in parallel with the team's support fornominal operations. Continuing regular rover operations withan entirely remote team had not previously been consideredfeasible due to a variety of factors. These included both thehuman factors, such as multiple concurrent person-to-personinteractions of the uplink planning team, as well as technicalfactors, such as reliance on powerful workstations dedicated tographically intensive software tools used for planning. The testwas conducted on March 12th, with both the downlink anduplink teams successfully simulating a near full planning day.The JPL administration announced the transition to mandatorytelework on Monday, March 16th. MSL stood down the uplinkplanning originally scheduled for the next day while downlinkcontinued monitoring the rover. Full operations then resumedper schedule with nearly the entire operations team teleworkingon Friday, March 20th, during which the team planned roveractivities for three Martian days (sols). These activities includedthe successful drilling of the "Edinburgh" rock target, a highlycomplex contact science activity.As of October 1st, 2020, the Mars Science Laboratory missionoperations team has conducted 88 remote tactical uplink shiftsfor a total of 190 sols of planned rover activity, which accountsfor more than 6% of the mission to date. In this period the roverhas completed four drilling campaigns and driven over 1150meters towards its next major science target – a sulfate bearinggeologic unit at the foot of Mount Sharp. Success has not beenwithout its challenges. Many of these have been addressed whileothers will remain in some form until the team can safely returnto JPL, which in turn is the largest challenge for the future.

Stroupe, Ashley↗

NASA NTRSDate not supplied

VIPER Mission Traverse Planning – Design, Strategies, and Dynamics

The Volatiles Investigation Polar Exploration Rover (VIPER) is a lunar polar volatiles prospecting mission developed through NASA’s Science Mission Directorate (SMD) Planetary Science Di-vision[1].VIPER is scheduled to land on Mons Mouton near the lunar South Pole in late 2024. VIPER’s primary mission goal is to characterize the distribution of water and volatiles across a range of thermal environments. This characterization aims to assist in understanding the origin of lunar polar volatiles and also help evaluate the In-Situ Resource Utilization (ISRU) potential of the lunar poles. The VIPER rover is a four-wheeled robotic vehicle weighing ~450 kg. It is solar-powered and teleoperated from Earth over a line-of-sight radio link. The rover can move at up to 20 cm/s on flat terrain. Accounting for commanding, localization, navigation, and obstacle-avoidance delays, however, the effective speed is closer to 1 cm/s. This effective speed is known as “Speed Made Good” (SMG), adopted from maritime culture, and kept as a key performance metric for VIPER oper-ations planning, execution, and evaluation. The mission duration is anticipated to be more than 90 Earth days and involves up to 20 km of driving. VIPER’s prospecting payload consists of spectrometers to detect volatiles and assess concentrations, context imagers, and a drill for sub-surface measurements down to one meter depth [2]. Mobility, combined with the prospecting and drill instrument suite, makes VIPER an analytically powerful resource mapper.

Volatiles Investigation Polar Exploration Rover (V↗

NASA NTRS2000

Autonomy Architectures for a Constellation of Spacecraft

Until the past few years, missions typically involved fairly large expensive spacecraft. Such missions have primarily favored using older proven technologies over more recently developed ones, and humans controlled spacecraft by manually generating detailed command sequences with low-level tools and then transmitting the sequences for subsequent execution on a spacecraft controller. This approach toward controlling a spacecraft has worked spectacularly on previous missions, but it has limitations deriving from communications restrictions - scheduling time to communicate with a particular spacecraft involves competing with other projects due to the limited number of deep space network antennae. This implies that a spacecraft can spend a long time just waiting whenever a command sequence fails. This is one reason why the New Millennium program has an objective to migrate parts of mission control tasks onboard a spacecraft to reduce wait time by making spacecraft more robust. The migrated software is called a "remote agent" and has 4 components: a mission manager to generate the high level goals, a planner/scheduler to turn goals into activities while reasoning about future expected situations, an executive/diagnostics engine to initiate and maintain activities while interpreting sensed events by reasoning about past and present situations, and a conventional real-time subsystem to interface with the spacecraft to implement an activity's primitive actions. In addition to needing remote planning and execution for isolated spacecraft, a trend toward multiple-spacecraft missions points to the need for remote distributed planning and execution. The past few years have seen missions with growing numbers of probes. Pathfinder has its rover (Sojourner), Cassini has its lander (Huygens), and the New Millenium Deep Space 3 (DS3) proposal involves a constellation of 3 spacecraft for interferometric mapping. This trend is expected to continue to progressively larger fleets. For example, one mission proposed to succeed DS3 would have 18 spacecraft flying in formation in order to detect earth-sized planets orbiting other stars. A proposed magnetospheric constellation would involve 5 to 500 spacecraft in Earth orbit to measure global phenomena within the magnetosphere. This work describes and compares three autonomy architectures for a system that continuously plans to control a fleet of spacecraft using collective mission goals instead of goals or command sequences for each spacecraft. A fleet of self-commanding spacecraft would autonomously coordinate itself to satisfy high level science and engineering goals in a changing partially-understood environment making feasible the operation of tens or even a hundred spacecraft (such as for interferometry or plasma physics missions). The easiest way to adapt autonomous spacecraft research to controlling constellations involves treating the constellation as a single spacecraft. Here one spacecraft directly controls the others as if they were connected. The controlling "master" spacecraft performs all autonomy reasoning, and the slaves only have real-time subsystems to execute the master's commands and transmit local telemetry/observations. The executive/diagnostics module starts actions and the master's real-time subsystem controls the action either locally or remotely through a slave. While the master/slave approach benefits from conceptual simplicity, it relies on an assumption that the master spacecraft's executive can continuously monitor the slaves' real-time subsystems, and this relies on high-bandwidth highly-reliable communications. Since unintended results occur fairly rarely, one way to relax the bandwidth requirements involves only monitoring unexpected events in spacecraft. Unfortunately, this disables the ability to monitor for unexpected events between spacecraft and leads to a host of coordination problems among the slaves. Also, failures in the communications system can result in losing slaves. The other two architectures improve robustness while reducing communications by progressively distributing more of the other three remote agent components across the constellation. In a teamwork architecture, all spacecraft have executives and real-time subsystems - only the leader has the planner/scheduler and mission manager. Finally, distributing all remote agent components leads to a peer-to-peer approach toward constellation control.

Barrett, Anthony↗

NASA NTRS2008

Spatial Coverage Planning and Optimization for Planetary Exploration

We are developing onboard planning and scheduling technology to enable in situ robotic explorers, such as rovers and aerobots, to more effectively assist scientists in planetary exploration. In our current work, we are focusing on situations in which the robot is exploring large geographical features such as craters, channels or regional boundaries. In to develop valid and high quality plans, the robot must take into account a range of scientific and engineering constraints and preferences. We have developed a system that incorporates multiobjective optimization and planning allowing the robot to generate high quality mission operations plans that respect resource limitations and mission constraints while attempting to maximize science and engineering objectives. An important scientific objective for the exploration of geological features is selecting observations that spatially cover an area of interest. We have developed a metric to enable an in situ explorer to reason about and track the spatial coverage quality of a plan. We describe this technique and show how it is combined in the overall multiobjective optimization and planning algorithm.

autonomy↗

NASA NTRSDate not supplied

COCPIT: Collaborative Activity Planning Software for Mars Perseverance Rover

Since landing on the Martian surface, the Perseverance rover has relied on a distributed team to generate commands for exploring its new environment each sol(Martian day). The team uses a complex suite of software tools to accomplish this challenging task in time for the next window of opportunity to send commands to the rover. A key piece of this software ecosystem is COCPIT (Component-based Campaign Planning, Implementation, and Tactical). COCPIT is part of the next generation of planning and scheduling software tools developed by NASA's Jet Propulsion Laboratory in partnership with NASA's Ames Research Center. COCPIT is a web-based application that allows users to collaboratively view and update the Perseverance rover's activity plans, continuously verify that the plan satisfies constraints, assign targets for directing scientific instruments, document science intent, and model power and data resources. Mars Surface Operations requires diverse expertise from team members within the Engineering, Science, Robotic, and Instrument Operations groups, distributed across North America and Europe. In order to improve efficiency and reduce risk, all teams are able to review and edit their activities simultaneously and see the effects on the plan in its entirety. As part of the Ground Data System (GDS) tool suite, COCPIT is responsible for the activity plan. It provides specialized views that allow operators to understand where there may be room for additional observations, see whether any planning constraints are being violated, and confirm that energy usage and data generation are within the defined limits. It contains details such as which filters a camera will use for a given observation, what the resolution of the images should be, where to store the data onboard, and how long the observation is expected to take. It predicts when specific data will be downlinked from the rover to a passing orbiter, so that the team knows when to expect that data on Earth for evaluation in future planning. Ultimately the information from the COCPIT plan is translated to sequences that will be bundled and radiated to Perseverance for execution. The COCPIT tool is used throughout all planning phases.

activity planning↗

NASA NTRSDate not supplied

COCPIT: Collaborative Activity Planning Software for Mars Perseverance Rover

activity planning↗

NASA NTRS2022

COCPIT: Collaborative Activity Planning Software for Mars Perseverance Rover

Since landing on the Martian surface, the Perseverance rover has relied on a distributed team to generate commands for exploring its new environment each sol (Martian day). The team uses a complex suite of software tools to accomplish this challenging task in time for the next window of opportunity to send commands to the rover. A key piece of this software ecosystem is COCPIT (Component-based Campaign Planning, Implementation, and Tactical). COCPIT is part of the next generation of planning and scheduling software tools developed by NASA's Jet Propulsion Laboratory in partnership with NASA's Ames Research Center. COCPIT is a web-based application that allows users to collaboratively view and update the Perseverance rover's activity plans, continuously verify that the plan satisfies constraints, assign targets for directing scientific instruments, document science intent, and model power and data resources. Mars Surface Operations requires diverse expertise from team members within the Engineering, Science, Robotic, and Instrument Operations groups, distributed across North America and Europe. In order to improve efficiency and reduce risk, all teams are able to review and edit their activities simultaneously and see the effects on the plan in its entirety. As part of the Ground Data System (GDS) tool suite, COCPIT is responsible for the activity plan. It provides specialized views that allow operators to understand where there may be room for additional observations, see whether any planning constraints are being violated, and confirm that energy usage and data generation are within the defined limits. It contains details such as which filters a camera will use for a given observation, what the resolution of the images should be, where to store the data onboard, and how long the observation is expected to take. It predicts when specific data will be downlinked from the rover to a passing orbiter, so that the team knows when to expect that data on Earth for evaluation in future planning. Ultimately the information from the COCPIT plan is translated to sequences that will be bundled and radiated to Perseverance for execution. The COCPIT tool is used throughout all planning phases.

Kanefsky, Bob↗

NASA NTRSDate not supplied

Using Open Standards and NASA Open Source Simulation Tools to Model Artemis Base Camp Mission Timelines

The United States’ National Aeronautics and Space Administration (NASA) has announced that the Artemis Program will return humans to the Moon, establishing a persistent presence with the Artemis Base Camp (ABC), and extend human exploration to Mars. The NASA Exploration Systems Simulations (NExSyS) team at NASA’s Johnson Space Center is using internationally developed simulation interoperability standards and NASA open source simulation tools to support Artemis concept, analysis, designs, development, training, and ultimately operations. The NExSyS team has been tasked to support early ABC architecture and mission analysis using mission time lines developed by the crew operations mission planning team. The NExSyS team is developing a distributed simulation framework with initial Artemis element implementations to model the ABC mission timelines using the international simulation interoperability standard High Level Architecture (HLA), the Simulation Interoperability Standards Organization’s Space Reference Federation Object Model (SpaceFOM), the NASA open source Trick Simulation Environment, and another NASA open source interface package called TrickHLA. The ABC architecture is composed of a number of key surface elements and resources. Some examples of modeled elements (also known as entities) are landers, habitats, rovers, logistics carriers, and astronauts. Some examples of modeled transferable and consumable resources are power, water, oxygen, nitrogen, scientific samples, and food. These entities and resources are modeled in a collection of individual simulations called Federates. A coordinated collection of interoperable federates is called a Federation and when these federates are tied together in a coordinated simulation run, it is referred to as a Federation Execution. The federates communicate through HLA using data exchange formats defined by a collection of machine readable files called Federation Object Models (FOMs). These FOM files are based on extensions to the SpaceFOM. This enables the instantiation and sharing of objects and interactions between federates in the federation. These provide for entity and resource tracking, object transfer, and data collection. Federate interactions are used to trigger events and notify federates of entity or resource transfers. For the initial implementation, the constituent federates are Trick-based simulations that use TrickHLA to provide the required HLA-base interoperability. These Trick-based simulations provide the required modeling for the individual Artemis elements along with the associated element resources. These federates provide a means to explore traverses between surface elements and exploration sites as scheduled in a mission timeline and explore the affects traverse times have on the overall mission timeline. The mission time lines are modeled using a Trick input file event handling capabilities. Each timeline operation is handled as individual simulation events, and triggered based on previous event status, time of operation, and simulated task completions. In addition, the ABC Federation can be used to perform Monte Carlo analysis. The Monte Carlo tool can vary the inputs, timings, and malfunctions to show how various contingencies in the mission can affect the mission timeline.

Keaton Craig Dodd↗

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↗