The PeriodicSpeed Behavior
Maintained by: mikerb@mit.edu Get PDF
src: project-pavlab/bhvdocs/bhv_periodic_speed
1 The PeriodicSpeed Behavior
1.1 Configuration Parameters
1.2 Variables Published
1.3 State Transition Policy and Initial Condition Parameters
1 The PeriodicSpeed Behavior
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 1.1.
Figure 1.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.
1.1 Configuration Parameters [top]
Listing 1.1 - Configuration Parameters Common to All Behaviors.
activeflag: | A MOOS variable-value pair posted when the behavior is in the active state. [more]. |
condition: | Specifies a condition that must be met for the behavior to be running. [more]. |
duration: | Time in behavior will remain running before declaring completion. [more]. |
duration_idle_decay: | When true, duration clock is running even when in the idle state. [more]. |
duration_reset: | A variable-pair such as MY_RESET=true, that will trigger a duration reset. [more]. |
duration_status: | The name of a MOOS variable to which the vehicle duration status is published. [more]. |
endflag: | A MOOS variable-value pair posted when the behavior has completed. [more]. |
idleflag: | A MOOS variable-value pair posted when the behavior is in the idle state. [more]. |
inactiveflag: | A MOOS variable-value posted when the behavior is not in the active state. [more]. |
name: | The (unique) name of the behavior. [more]. |
nostarve: | Allows a behavior to assert a maximum staleness for a MOOS variable. [more]. |
perpetual: | If true allows the behavior to to run even after it has completed. [more]. |
post_mapping: | Re-direct behavior output normally to one MOOS variable to another instead. [more]. |
priority: | The priority weight of the behavior. [more]. |
pwt: | Same as priority. |
runflag: | A MOOS variable and a value posted when a behavior has met its conditions. [more]. |
spawnflag: | A MOOS variable and a value posted when a behavior is spawned. [more]. |
spawnxflag: | A MOOS variable and a value posted when a behavior is spawned. [more]. |
templating: | Turns a behavior into a template for spawning behaviors dynamically. [more]. |
updates: | A MOOS variable from which behavior parameter updates are read dynamically. [more]. |
Listing 1.2 - Configuration Parameters for the Periodic Speed Behavior.
Parameter | Description |
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 1.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 }
1.2 Variables Published [top]
Listing 1.4 - Variables Published the Periodic Speed Behavior.
Variable | Description |
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. |
1.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 ???. 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.
Document Maintained by: mikerb@mit.edu
Page built from LaTeX source using texwiki, developed at MIT. Errata to issues@moos-ivp.org. Get PDF