Behaviors of the IvP Helm


Maintained by: mikerb@mit.edu         Get PDF


src: project-pavlab/chapters/chap_moos


1  Behaviors of the IvP Helm

1   Behaviors of the IvP Helm


The following is a description of some single-vehicle behaviors currently written for the helm. The below is a guide for users of these behaviors. The topic of developing new behaviors is addressed separately. The setting of behavior parameters is the primary method for affecting the overall autonomy behavior in a vehicle. Parameters may also be dynamically altered once the mission has commenced. A parameter is set with a single line of the form:

    parameter = value

The left-hand side, the parameter component, is case insensitive, while the value component is typically case sensitive. When the helm is launched, each behavior is created and the parameters are set. If a parameter setting in the behavior file references an unknown parameter, or if the value component fails a syntactic or semantic test, the line is noted and the helm ceases to launch.

Overview of Parameters Common to All Behaviors    [top]


The parameters below are common to all IvP behaviors, although they may have more relevance to some behaviors than others. They are defined in the IvPBehavior superclass of which all the behaviors described in this section are a subclass. More information on the functionality behind these parameters was given in Section ???.

Listing 1.1 - Configuration Parameters Common to All IvP Behaviors.

ParameterDescription
activeflag:A flag (MOOSVar,Data) pair, posted when in the active state.
condition:A logical condition that must satisfied for the behavior to run.
duration:Behavior duration, in seconds. Default is "unlimited".
duration_idle_decay:If true, clock will progress even if in the idle state.
duration_reset:If limited duration, duration is reset when this variable is received.
duration_status:MOOS variable informing of remaining duration, if duration is set.
endflag:A flag (MOOSVar,Data) pair, posted when the behavior completes.
idleflag:A flag (MOOSVar,Data) pair, posted when in the idle state.
inactiveflag:A flag (MOOSVar,Data) pair, posted when in the inactive state.
name:A unique identifier for the behavior instance.
nostarve:If a given MOOSVar is stale by a given amount, an error is posted.
perpetual:If true, a behavior may be reset after completion or duration timeout.
post_mapping:A mapping to change the default MOOS variable output of a behavior.
priority, pwt:Priority weight of the IvP function produced by behavior.
runflag:A flag (MOOSVar,Data) pair, posted when in the running state.
templating:Enable the behavior spec as a template for dynamic spawning.
updates:A MOOSVar from which behavior parameter updates are received.

Configuring One Variable Objective Functions    [top]


Several behaviors use a common tool for constructing objective functions over a single decision variable. These behaviors have a similar interface for configuring this tool, and it is described here to avoid redundancy. Examples of behaviors that use this tool are the Waypoint, Loiter, PeriodicSurface, ConstantDepth, ConstantSpeed, ConstantHeading, and Shadow behaviors. This tool is called the ZAIC_PEAK tool, and is describe in more detail in \cite{?} . This tool is designed with the objective function form shown in in mind, where there is an identifiable preferred single decision choice (the summit) with maximum utility, and then a gradual drop in utility as the variable varies from the preferred choice.

Figure 1.1: The ZAIC_PEAK tool: defines an IvP function over one variable defined by the four parameters shown here. In the case rendered here, the tool would create an IvP function with six pieces. The function rendered was created with summit=180, peakwidth=85, basewidth=70, summitdelta=40.

    The form in which the utility drops is dependent on the settings of other parameters shown in the figure. The summit, peakwidth, and basewidth values are given in units native to the decision variable, while the summitdelta, minutil, and maxutil values are given in terms of units of utility. The latter two variables default to 0 and 100 respectively and are not typically exposed as configuration parameters in behaviors that use this tool, unlike the other four parameters.


Document Maintained by: mikerb@mit.edu        
Page built from LaTeX source using texwiki, developed at MIT. Errata to issues@moos-ivp.org. Get PDF