12   The PeriodicSpeed Behavior

12.1 Configuration Parameters
12.2 Variables Published
12.3 State Transition Policy and Initial Condition Parameters

This behavior will periodically influence the speed of the vehicle while remaining neutral at other times. The timing is specified by a given period in which the influence is on (busy), and a period specifying when the influence if off (lazy), as depicted in Figure 12.1.

Figure 12.1: Busy and Lazy Modes: In the busy mode the behavior will produce an objective function defined over speed that will potentially influence the speed of the vehicle. In the lazy mode, it simply will not produce an objective function.

    It was conceived for use on an AUV equipped with an acoustic modem to periodically slow the vehicle to reduce self-noise and reduce communication difficulty. One can also specify a flag (a MOOS variable and value) to be posted at the start of the period to prompt an outside action such as the start of communication attempts.

12.1   Configuration Parameters    [top]

Listing 12.1 - Configuration Parameters Common to All Behaviors.

activeflag:A MOOS variable-value pair posted when the behavior is in the active state. Section 6.5.4.
condition:Specifies a condition that must be met for the behavior to be running. Section 6.5.1.
duration:Time in behavior will remain running before declaring completion. Section 7.2.6.
duration_idle_decay:When true, duration clock is running even when in the idle state. Section 7.2.6.
duration_reset:A variable-pair such as MY_RESET=true, that will trigger a duration reset. See Section 7.2.6.
duration_status:The name of a MOOS variable to which the vehicle duration status is published. Section 7.2.6.
endflag:A MOOS variable-value pair posted when the behavior has completed. Section 6.5.4.
idleflag:A MOOS variable-value pair posted when the behavior is in the idle state. Section 6.5.4.
inactiveflag:A MOOS variable-value posted when the behavior is not in the active state. Section 6.5.4.
name:The (unique) name of the behavior. Section 7.2.2.
nostarve:Allows a behavior to assert a maximum staleness for a MOOS variable Section 7.2.9.
perpetual:If true allows the behavior to to run even after it has completed. Section 7.2.7.
post_mapping:Re-direct behavior output normally to one MOOS variable to another instead. Section 7.2.4.
priority:The priority weight of the behavior. Section 7.2.3.
pwt:Same as priority.
runflag:A MOOS variable and a value posted when a behavior has met its conditions. Section 6.5.4.
spawnflag:A MOOS variable and a value posted when a behavior is spawned. Section 6.5.4.
templating:Turns a behavior into a template for spawning behaviors dynamically. Section 7.7.
updates:A MOOS variable from which behavior parameter updates are read dynamically. Section 7.2.5.

Listing 12.2 - Configuration Parameters for the Periodic Speed Behavior.

ParameterDescription
basewidth:The width of the ZAIC basewidth, in m/sec, in the IvP function.
initially_busy:If true the initial state is busy. The default is false.
peakwidth:The width of the ZAIC peakwidth, in m/sec in the IvP function.
period_busy:The duration of the busy period, in seconds.
period_lazy:The duration of the lazy period, in seconds.
period_speed:The desired speed, in m/sec, in the IvP function.
reset_upon_running:Initial conditions reset upon entering the running state. Default is true.
summit_delta:The extent of the ZAIC summit delta in the IvP function.

Listing 12.3 - Example Configuration Block. 

 Behavior = BHV_PeriodicSpeed
 {
   // General Behavior Parameters
   // ---------------------------
   name         = transit            // example
   pwt          = 100                // default
   condition    = MODE==TRANSITING   // example
   updates      = PSPD_UPDATES       // example

   // Parameters specific to this behavior
   // ------------------------------------
            basewidth = 0            // default
       initially_busy = false        // default
            peakwidth = 0            // default
          period_busy = 0            // default
          period_lazy = 0            // default
         period_speed = 0            // default
   reset_upon_running = true         // default
         summit_delta = 25           // default
 }

12.2   Variables Published    [top]

Listing 12.4 - Variables Published the Periodic Speed Behavior.

VariableDescription
PS_PENDING_BUSY:Publishes the amount of time in seconds until the behavior reaches the busy mode. During the busy mode this value is zero, and it resets to the value given by the period_lazy parameter upon transitioning into the lazy mode.
PS_PENDING_LAZY:Publishes the amount of time in seconds until the behavior reaches the lazy mode. During the lazy mode this value is zero, and it resets to the value given by period_busy upon transitioning back into the busy mode. To reduce posting volume, the values posted will be rounded to the nearest second until less than one second remains, after which fractions are posted.
PS_BUSY_COUNT:Thi variable is posted by the behavior each time it enters the busy mode. The value is an integer indicating the number of times it has entered the busy mode, posting zero initially.

12.3   State Transition Policy and Initial Condition Parameters    [top]

The behavior alternates between one of two modes, the busy mode or the lazy mode. In the former, it will produce an objective function over the speed decision variable, and in the latter mode it will simply refrain from producing the objective function. Note that these modes are different from the general behavior run states described in Section 6.5.3. If this behavior is idle, i.e., has not met the conditions for being in the running state, it will not generate an objective function regardless of whether it is in the busy or lazy mode.

    When the behavior enters the busy mode, it resets a timer which counts down from period_busy seconds, after which it enters the lazy mode. When it enters the lazy mode, it resets a timer which counts down from period_lazy seconds, after which it goes back to the busy mode. By default the behavior is initially in the lazy mode, but it can be configured in the opposite manner by setting initially_busy to true.

    By default, when reset_upon_running is true, each time the behavior enters the running state, the busy/lazy mode is set to its initial value, and all timers are reset to their initial values. This is true regardless of whether it is entering the running state upon initial helm engagement, or due to transitioning from the idle state. This can be changed by setting reset_upon_running to false. In this case the timers are counting down immediately upon helm engagement and continue to do so regardless of the behavior run state.

Page built from LaTeX source using the texwiki program.