Demonstration of Robust Execution on a NASA Lunar Rover Testbed
Total Page:16
File Type:pdf, Size:1020Kb
Demonstration of Robust Execution on a NASA Lunar Rover Testbed Vandi Verma1, Vijay Baskaran2, Hans Utz3, Robert Harris2, Charles Fry2 Jet Propulsion Laboratory, California Institute of Technology 1, Perot Systems2, RIACS3: NASA Ames Research Center [email protected], <bvk, hutz, harrris, cfry>@email.arc.nasa.gov Abstract A rim of Shackleton crater is one of the candidate sites for a lunar outpost, balancing requirements for This paper presents the onboard execution software power, stable thermal environment and potential for used for operating two rovers in a simulated lunar resources. Detailed surveys of the site will be needed robotic site survey at Haughton Crater in July-August to lay out infrastructure and search for resources. The 2007. The execution software consists of a language polar environment is harsh and site surveys require called Plan Execution Interchange Language systematic coverage of an area with extensive (PLEXIL) that represents the control, monitoring, and sampling. fault protection desired, and an engine called Universal Executive that executes plans written in PLEXIL and interfaces to controlled systems. PLEXIL and UE controlled two K10 rovers from NASA Ames in site survey experiments totaling 200 hours of operation, covering 45 km of moon-like terrain. 1. Introduction The NASA vision for space exploration plans to return astronauts to the moon by 2020. “Astronauts Figure 2: Shackleton crater. Diameter=19km. will search for resources and learn how to work safely It is not unusual for site surveys to require in a harsh environment -- stepping stones to future thousands of measurements and hundreds of hours to exploration.” complete. To help reduce the number and duration of human Extravehicular Activity (EVA) sorties NASA would develop robots to perform systematic mapping or site survey. To be approved for operation alongside astronauts, these robots must meet requirements for a high level of safety and reliability. They must also significantly reduce crew workload to justify the high cost of launch and landing. It must therefore be possible to operate these rovers remotely from Earth or with minimal supervision from crew at an outpost. In addition to making the robotic hardware reliable there would be a need for software that could provide guarantees about Figure 1: Artist's rendering representing the lunar behavior. A collaborative team from multiple NASA exploration concept. (Image credit John Frassanito centers and universities has developed verifiable and Associates) execution software to meet this challenge. This paper 1 This work was performed while the primary author was with Perot Systems at NASA Ames Research Center. presents this technology and some results from robotic Hill”, K10 red was used to survey other areas around site survey field trials in an analog lunar environment. Haughton base camp. Simulated ground control was located at NASA Johnson Space center and at NASA 2. Lunar Robotic Site Survey Ames Research center’s Future Flight Central facility. Field operations were from a HMMWV at Drill Hill. The approach for lunar robotic site survey adopted Hab-ops were conducted from Haughton base camp. by the Intelligent Robotics group (IRG) at NASA Details on the rovers, instruments, computing, and the Ames Research Center uses multiple independent field test may be found in [5]. robots to autonomously survey different parts of a region with remote human supervision. The human supervision of these robots may be performed either from a nearby habitat/vehicle or from Earth and is nominally at a high level. In this approach, humans outline a region to survey. The software system autonomously generates a plan to survey the region, executes the plan, and sends data. Humans analyze this data and get continuous updates on rover state. They may also remotely intervene at any time. Figure 4: Drill Hill In July-August 2007 IRG conducted a field experiment to test operational concepts for systematic Figure 5 shows a high-level schematic of the site site surveys. Two K10 rovers from NASA Ames were survey software system. The remote operator specifies used to perform robotic survey of a simulated lunar a region. The coverage planner automatically generates site in Haughton crater. The rovers carried ground- a mission plan for the region. It runs off-board on the penetrating radar to map subsurface structure and a 3D operator console. The mission plan consists of scanning laser to map terrain topography. waypoints with details on data to be collected at each Haughton Crater is located on Devon Island in the location. The executive (UE/PLEXIL) executes the Canadian Arctic. It is a popular site for robotic field plan based on an operational policy, which is also tests since it provides a relevant analog for the polar called an execution plan. It issues commands to the regions of the Moon and Mars. In addition, there is 24 navigator and to the survey instrument controllers and hours of light during the summer months and monitors progress. The executive, navigator and Haughton Mars Project [7] provides logistic support instrument controllers all run on-board as part of the for a field team. SORA [6] architecture. The operator may pause, un- pause, and abort the plan at any time. The execution plan handles these interrupts and notifies the user when errors occur. Operator Pause/un-pause Abort signals Request and get next waypoint/task Coverage UE/PLEXIL Planner Report completion status of task Navigator LIDAR/GPR Figure 3: K10 black and K10 red rovers from NASA Figure 5. Schematic of high-level software Ames in Haughton crater. interactions. The two K10 rovers were ‘K10 Black’ and ‘K10 Red’ (see Figure 3). K10 Black was assigned a site survey task on a 700x700m region called “Drill 3. Plan Execution Interchange What is unique about PLEXIL is that the Language (PLEXIL) semantics of executing a PLEXIL plan are clearly defined and formally verified [2]. Unambiguous PLEXIL is a small, well-defined language that semantics make it easier to do verification and provides a great deal of power in terms of high-level validation and to implement a lightweight executive control, while being easy to formally validate and that conforms to the semantics of execution. A simple verify. PLEXIL plans are programs that specify actions PLEXIL plan is shown below: to be performed by an execution system. These actions Example1: { may represent nominal spacecraft operations or fault Invariant:(LookupOnChange(rover_state) != "estop"); monitoring and protection handlers. The specification Repeat-while: (LookupNow(distance) != 10); of spacecraft operation plans like command sequences PostCondition: Acquire.outcome=SUCCESS has been limited to very simple control structures. This List: has largely been due to the difficulty of specifying DriveNode:{ Command: drive();} control structures like loops and event (and sensor) AquireNode:{ driven concurrent monitors in such plans, without StartCondition: Drive.outcome == SUCCESS making the expected semantics unclear and the SkipCondton: Drive.outcome==FAILED validation problem unsolvable. Existing languages Command: aquire(); } with expressive representations do so at the cost of } losing formal guarantees about execution. A PLEXIL plan is a set of processes, called nodes, 2 In this simple example the rover drives to a organized in a tree structure . The leaves are action target and acquires a sample and then repeats the nodes that initiate tasks requiring external interaction, process until it has covered a distance of 10m. The such as commanding systems, assigning values to local plan consists of a list node called Example1. The list variables, etc. Non-leaf nodes, called list nodes, node contains two nodes – Drive and Acquire – that provide scope for collections of nodes. Local variables issue commands drive() and acquire() respectively. declared in the list node may be shared by the nodes The start condition of AcquireNode ensures that the within the collection. In addition each node has node starts execution only after DriveNode has implicit variables representing the status of execution finished successfully and the skip condition ensures which may be one of a finite set of values – Inactive, that it is skipped if the drive failed. By default, Waiting, Executing, Finishing, IterationEnded, PLEXIL nodes represented in a list are concurrent. Failing, or Finished; and the outcome of node The invariant condition ensures that all executing execution – Skipped, Success, or Failure. Nodes only commands will be aborted if the rover state changes to have access to implicit variables in a parent, child, or “estop” at any time. The Repeat-while condition sibling. specifies that the sequence of drive and acquire PLEXIL is event driven, where each node has a commands iterates until the state variable distance is set of conditions that react to changes in the 10m3. The information about state variables such as environment, changes to the value of shared variables, rover_state and distance is requested from the rover and failures. Start, end, and skip conditions specify flight software via a lookup. The post condition sets when a node should start, end, and skip execution, the outcome of each iteration of node Example1. If while repeat conditions specify when the execution of AcquireNode fails during execution or is skipped the a node should be iterated. Pre- and post conditions are outcome will be FAILED or SKIPPED and the post checked before and after node execution and invariant condition