To appear in i-SAIRAS Conference Proceedings, Feb 2008, Los Angeles, CA, USA Mars Exploration Rover Mobility and IDD Downlink Analysis Tools Jeffrey J. Biesiadecki and Robert Liebersbach and Mark W. Maimone Jet Propulsion Laboratory, California Institute of Technology Pasadena, CA USA [email protected] Abstract— Driving and manipulation activities on the Mars various flight software (FSW) subsystems [13] (e.g., the Exploration Rovers often must be planned from scratch Mobility software module [2]), and are typically stored in each day, making this a fast-paced activity by typical space Flash memory prior to transmission [15]. Data are usually mission standards. Such a schedule requires rapid turnaround in understanding what happened during activities on the relayed through UHF frequencies to an orbiter at Mars previous Martian Solar Day (Sol). In addition to obvious (e.g., Mars Odyssey) or can be transmitted directly to faults, subtle changes in expected behavior must be detected Earth at lower bandwidth using X-band frequencies. The and understood rapidly, to prevent the next day's plan from Deep Space Network receives the raw data and forwards exacerbating any imminent problem. it to the Jet Propulsion Laboratory (JPL), where processes We developed an advanced set of tools to help speed up the understanding of previous Sols' activities. Plots of detailed en- controlled by the Ground Data Systems [19] and Mission gineering data are generated automatically and incorporated Data Operations Teams automatically archive the raw data, into HTML pages, allowing quick visual inspection of each generate preliminary reports [18], and populate an archived activity. Data from different sources are grouped together filesystem with individual Data Product files. These files and written into “Annotated CSV” (Column-Separated Value) are stored in a format similar to that used in the onboard files, enabling detailed analysis even in the presence of only partial data, enabling multi-Sol queries (including those flash memory, but they are split into a directory structure spanning the whole mission lifetime), and greatly reducing based on the Martian Solar Day on which they were created the need for all operations team members to acquire a (each Sol is about 24.6 hours long). The tools described in deep understanding of the many constituent pieces of data. this paper deal with the data only after it has already been Automated processing of newly received data informs the populated into the UNIX filesystem. team of the current vehicle state via email and multimedia cell phone updates. Several issues complicate the analysis of mobility and Our system has enabled rapid understanding of complex manipulation operations. Spacecraft telemetry is typically a mobility and manipulation activities during the first four disjoint set of independent pieces of information (text mes- years of Mars Exploration Rover operations. This paper sages, scalar “channelized” values with only approximate describes the tools developed by the downlink team that timestamps, and individual data products each adhering perform the bulk of this analysis. Index Terms— MER, Mars rover, Ground software, Down- to a particular fixed format), so discovering correlations link Assessment, Telemetry Analysis, Partial Data, Mobility among raw downlink data and the commands that created and Manipulation them can be difficult. The format of the generated data has evolved over time, since there have been four updates to I. BACKGROUND the MER flight software between launch in June 2003 and The goal of the Mars Exploration Rover (MER) project December 2007 [9]. Most importantly, only a fraction of is to elucidate the history of water on the surface of the engineering data generated by the rovers is typically Mars. The scientific instruments on the vehicles must be received on the same day it was created, so we often have deployed at multiple surface locations to perform the in to describe the activities given only partial information. situ analysis needed to support this goal. Such activities In addition, the distributed nature of the operations team are only possible through use of mobility and Instrument makes it critical that results be viewable from sites outside Deployment Device (IDD, or robotic arm) manipulation the primary physical operations area. subsystems, which must be monitored as part of the daily Although there are many specialized interactive tools operations process [11], [16], [17], [7]. that perform specific useful downlink analysis duties (e.g., Telemetry data generated on a spacecraft follow a long our nominal 3D visualization and planning tool RSVP [20], and circuitous route to Earth. Data are created by the remote science planning tool SAP/Maestro [12], image browser Marsviewer [6], and science team visualizer Viz of data therefore comprises time-tagged scalar quantities, [3]), they did not (or still do not) support detailed views much of which is only available inside Data Products. into all the necessary data products and were not amenable There is some non-temporal data as well. Scientists and to automated scripting or remote display. So we developed Rover Drivers generate lists of 3D targets and features of a system comprised of tools written in C and C++ that interest (indexed by RMC and location rather than SCLK), parse the low-level information, and scripts written in Perl either explicitly or implicitly in the sequences of commands that organize the results and orchestrate the automated that execute drive and manipulation activities. Also, the analysis. Our system produces plain text and HTML- Rover Driver sequences of commands often contain useful annotated reports either automatically or interactively, and predictions or annotations in command arguments and provides interactive query tools that work effectively via comments. These can be automatically correlated with the remote access. received data by tracking their execution time using the “Command Dispatched” EVR text messages. II. RAW DATA How do we know whether all of the generated data has been received? The Data Product Summary report (which is There are three categories of data produced by the MER itself a data product) includes a catalog of the data products flight software: currently stored onboard, including those that were created 1) “Event Reports” (or EVRs) are timestamped non- earlier during the current Sol. The combination of this periodic text messages with a severity level and up to report's contents and the original command sequences with six scalar parameters. One important use of EVRs is EVR annotations informs the analyst not only what data has to trace progress through executing sequences, indi- yet to be downlinked, but also when no further information cated by command dispatch and completion reports. should be expected. Generally a handful of EVR messages are generated Mobility Data Products The Mobility flight software per minute, though it depends on the activities being produces several types of data products which are used to performed. track the path driven by the rover, describe characteristics 2) Engineering, Housekeeping, and Accountability of the terrain that was driven over (such as terrain slope and “Channelized Telemetry” (EH&A) comprise inde- roughness, and wheel traction), assess and monitor mobility pendent scalar values (commonly sensor measure- mechanism health, and troubleshoot mobility faults. These ments and flight software state variables) recorded data products consist of the following main types: roughly once every ten minutes regardless of what 1) Parameter dumps, which contain the control param- activities are being performed. The timestamp associ- eters currently in use by the rover and are generated ated with EH&A data is only approximate; it reflects by an explicit dump-parameters command. the multi-minute poll time, not the time the data was 2) Rover kinematic state, which is a snapshot of rover generated. pose estimate and all mechanism positions (e.g., 3) Timestamped binary files called Data Products. Each rocker/bogie suspension). These are very small in flight software subsystem generates its own data size and are generated by explicit dump-state com- products, with unique format and information con- mand tent. Although many of these products have XML 3) Mobility summary, which contains information cap- descriptions, there is little consistency in how their tured after every drive segment regardless of whether various components are labeled. All images, and the motion was explicitly commanded or selected by nearly all of the detailed time sampled information autonomous navigation [2]. This includes intended are reported in data products. segment path length and heading change, final pose Each Data Product is tagged with additional meta-data estimate after maneuver, statistics about any goal- including a numeric label representing its type, the name ward and anti-goalward terrain assessment images of the sequence and number of the command that created taken, delta pose computed by Visual Odometry [8], it, and the time at which it was created. Certain critical and average current draw and final positions of mo- products also report the Rover Motion Counter (RMC), bility mechanisms (steering, wheels, and suspension). a set of five integer indices that uniquely identifies each These small products typically are assigned a high spacecraft configuration. All timestamps are logged in priority for the telemetry scheduler. Therefore they “Spacecraft Clock” (or SCLK) units.1