Input files or file list. These can be any MSL image EDR or single-frame RDR. The image data is not used; only the label is examined.
Output XML file containing the filter data. See the program MARSFILTER for a description of the file format.
Specifies the collision tolerance for the model. In other words, each object is effectively expanded by this amount in all directions when computing the mask. This allows for some error in the model or kinematics. Default is 1.5cm (0.015).
The coordinate system used for interaction with the FSW. Specifies the CS in which the data is returned from the FSW. This must be RMECH. Don't even think about changing it. Really.
Specifies what to do with the arm joint angles. There are three values: NEVER - Does not change the joint angles from what's in the label. ALWAYS - Replaces the joint angles with those for the stowed position in all cases. WHEN_ZERO - Replaces the joint angles with those for the stowed position only when the joint angles are all 0. This parameter is useful for cases where the arm position is unititialized, in which case the joints are all 0 but the arm is likely to be stowed. It can also be used to disable the arm mask (-ALWAYS, which effectively stows it) if needed.
Specifies the list of RMC indices that indicate relevant kinematic state. These are the indices that will be reported in the XML file in the <camera> element. Setting the parameter to null (--) will turn off all RMC index writing. This set should not be changed, unless at some future point the RSM head is enabled for use with MAHLI (only).
By default, if multiple images are given, each will be checked against its predecessor to see if the RMC indices listed in RMC_INDEX are the same. If so, the image is skipped, because the info has already been written. -ALL_INPUTS will cause all inputs to be written regardless. Note that only the immediately prior image is checked, so if the input images are not sorted in RMC order, there could be duplicate entries in the file. This will not hurt anything other than file size and execution time.
Override for the arm joints. If specified, the arm will use the joints in this configuration rather than what's in the label. This can be used to make a predictive mask, showing the situation after a planned arm move. All 5 joints must be given if any are given. Both the resolver and encoder values are set to the given angles. A value of 1e30 means "unknown" and will cause the program to use a swept volume (all possible angles) for that joint. The joints are in the standard order: azimuth, elevation, elbow, wrist, turret
A colon-separated list of directories in which to look for configuration and calibration files. Environment variables are allowed in the list (and may themselves contain colon-separated lists). The directories are searched in order for each config/cal file when it is loaded. This allows multiple projects to be supported simultaneously, and allows the user to override any given config/cal file. Note that the directory structure below the directories specified in this path must match what the project expects. For example, Mars 98 expects flat fields to be in a subdirectory named "flat_fields" while Mars Pathfinder expects them to be directly in the directory specified by the path (i.e. no intermediate subdirectories).
Specifies a mission-specific pointing method to use. Normally this parameter is not used, in which case the "default" pointing methods are used. Some missions may have special, or alternate, pointing methods available, which are indicated by this string (for example, backlash models, using arm joint angles instead of x/y/z/az/el, etc). A substring search is used, so multiple methods (where that makes sense) can be specified by separating the keywords with commas. Note that nav files created using one pointing method will most likely not be compatible with a mosaic created using a different pointing method. The methods available vary per mission, but some methods available at the time of this writing are: BACKLASH : Mars 98 SSI only. Selects a backlash pointing model, which adjusts the telemetered azimuth and elevation values based on knowledge of the camera's mechanical backlash and the direction the motor was travelling when the image was taken.
Disables all label-derived parameters to the Site mechanism which underlies coordinate systems. This forces all sites to be identical, with all rotations and offsets set the same. In the case of MPF or Mars 98, this disables the lander quaternion and offset (sets them to identity and 0, respectively). This option should not be used with images taken from different vantage points (e.g. the spacecraft moved, or mixing a lander and a rover) or invalid results will be obtained. The use of this option invalidates the Fixed coordinate frame; any values reported in the Fixed frame will not correctly reflect the orientation of the lander/rover. Obviously, this option should be rarely used; it is intended for when the image labels defining the site are invalid or inconsistent.
Rover State File. This is a list of filenames to load containing Rover State information. These files contain position and orientation information for a rover (or other mobile spacecraft) at various sites. They are in XML format. See the "Rover Motion Counter (RMC) Master File SIS" for details on these files. Rover State Files have a priority order. The files listed first have the highest priority. Environment variables may be used in the list.
If enabled, this causes the internal database of RMC locations to be printed out to the stdout log. This is after the RSF files have been loaded and the coordinate systems read from the input label(s).
The coordinate system to use for the output UVW vectors. The interpretation
of the values is dependent on the mission. Some representative missions are
listed here:
Fixed - The Fixed frame (default). This is the ultimate reference frame
(see also FIXED_SITE for rover missions).
Instrument - The "natural" frame for the instrument (of the first input
image). MPF: Lander or Rover; M98: MVACS; MER: Rover.
Site - A major Site frame. For rover missions, COORD_INDEX specifies which
Site frame to use. Non-rover missions treat this as Fixed.
Rover - An instance of the Rover frame. For rover missions, COORD_INDEX
specifies which instance of the rover frame to use. Non-rover mission
use the spacecraft frame (e.g. Lander for M98).
Local_Level - An instance of a Local Level frame. This is typically
coincident with the Rover frame (in XYZ) but oriented toward North
like the Site and Fixed frames. For MER, this is an instance of a
Drive index move.
For MSLFILTER, this is the coordinate system in which the output file is
expressed. Since the file does not label the coordinate system, MARSFILTER
assumes rover (nav). Therefore this parameter should not be changed.
The index specifies which instance of a coordinate system to use. It is currently applicable only to rover-based missions, but could have other uses. The index is equivalent to the Rover Motion Counter (RMC) for MER and FIDO. For MER/FIDO, there are many Site frames. Each is numbered with a single index. For Site Frames, coord_index specifies which to use. Likewise, there are many Local_Level and Rover frames, corresponding to values of the RMC. The multiple instances of this frame are selected by COORD_INDEX. Generally COORD_INDEX defaults sensibly so you don't usually need to specify it. It will default to the instance used by the first input. NOTE: THIS MUST NOT BE CHANGED FOR MSLREACH!!! This is a standard PIG parameter, but mslreach requires that processing be done in the Rover Mechanical frame corresponding to the inputs. The results will be undefined if you use it.
Specifies which major Site is the "Fixed" Site for this run.
Historically, MPF and M98 had a single "Surface Fixed" frame which never
moved, and which all other coordinate system frames were referenced to.
With the advent of long-range rovers (such as MER and FIDO), that became
insufficient. The rover traverses far enough that errors in knowledge of
coordinate system offset and orientation become unacceptable.
For this reason, a system of major Sites was introduced. Periodically
during the mission, a Site frame is declared. This then becomes the
reference frame for all activities until the next Site is declared.
References are kept local, and errors don't propogate across Sites.
However, if images from more than one Site are combined together, the
Site's must be placed relative to each other. Therefore a single reference
frame is still needed to combine different sites.
The FIXED_SITE parameter controls which of the major Site frames is
the reference ("fixed") site for this program run. This fixed frame
can vary in different program runs, but is constant throughout one
execution.
If not specified, FIXED_SITE defaults to the minimum Site number (i.e.
lowest numbered, or earliest chronologically) used in all input images.
Normally this default is sufficient; rarely must FIXED_SITE be specified.
One or more Rover State Files must usually be specified in order to combine
image from more than one Site. These describe the relationship between
sites. See the RSF parameter.
Specifies which solution ID to use when specifying the coordinate system. There are potentially many different definitions for the same coordinate system. These are identified via a unique Solution ID. If this parameter is given, only the specified solution's definition is searched for. Without it, the "best" available solution is chosen. It is extremely rare that this parameter should be needed. The default will be sufficient in almost every case. Note that the current MER implementation requires that a value for COORD_INDEX also be provided, in order for this parameter to take effect.