The Delta Mission


Maintained by: mikerb@mit.edu         Get PDF


src: project-pavlab/chapters/chap_xmiss_delta


1  The Delta Mission
     1.1 Overview of the Delta Mission Components and Topics
     1.2 Launching the Delta Mission
     1.3 Topic #1: Configuring the Helm for Operation at Depth
     1.4 Topic #2: The ConstantDepth Behavior
     1.5 Topic #3: The PeriodicSurface Behavior
     1.6 Topic #4: The Waypoint Behavior with Survey Patterns
     1.7 Topic #4: Using pMarineViewer with Geo-referenced Mouse Clicks
     1.8 Suggestions for Further Experimenting with the Delta Mission
          1.8.1 Failing to Reason about Depth

1   The Delta Mission


The Delta example mission is used to illustrate the operation of a a vehicle in the depth plane (an underwater as opposed to surface vehicle), the illustration of the PeriodicSurface behavior, the use of the Waypoint behavior with survey patterns, and the use of the pMarineViewer application to send field-control commands to alter the mission as it unfolds. The vehicle will initially deploy using the Loiter behavior, and will periodically come to the surface. If commanded by the user, the vehicle will break off from the Loiter behavior to execute a survey pattern, after which it will resume loitering at its original location.

1.1   Overview of the Delta Mission Components and Topics    [top]


Behaviors:Waypoint, Loiter, PeriodicSurface, ConstantDepth
MOOS Apps:pHelmIvP, pLogger, uSimMarine, pMarinePID, pNodeReporter, pMarineViewer uTimerScript
Primary Topics:(1) Configuring the Helm for operation at depth
(2) The ConstantDepth behavior
(3) The PeriodicSurface behavior
(4) The Waypoint behavior with survey patterns
(5) Using pMarineViewer with Geo-referenced mouse clicks
Side Topics:(1) uTimerScript is used to simulate a UUV receiving a GPS update.

1.2   Launching the Delta Mission    [top]


The delta mission may be launched from the command line:

  $ cd moos-ivp/missions/s4_delta/
  $ ./launch.sh --warp=10

This should bring up a pMarineViewer window like that shown in , with a single vehicle, "dudley", initially in the PARK helm state. See Section ??? for more on the helm state. After hitting the DEPLOY button in the lower right corner, the vehicle enters the DRIVE state, and the LOITERING helm mode, and begins to proceed along the waypoints as shown. See Section ??? for more on more on the helm mode, vs. the helm state. The mode declarations for the Delta mission are defined at the top of the delta.moos file, and amount to the following simple hierarchy:

       o ROOT          
       |--o INACTIVE   
       |--o ACTIVE     
          |--o RETURNING
          |--o SURVEYING
          |--o LOITERING

In the initial helm mode after deployment, the LOITERING mode, the helm is running the Loitering behavior, Section ???, the ConstantDepth behavior, Section ???, and the PeriodicSurface behavior, Section ???. It will stay in this mode indefinitely until it is either commanded to return or break off to another region to conduct a survey pattern. In the LOITERING mode the vehicle will periodically come to the surface for a GPS fix, presumably to correct for accumulated navigation error. The uTimerScript utility is used to simulate the event of receiving a GPS fix. This script is described in more detail in the uTimerScript documentation in the Section "A Script Used as Proxy for an On-Board GPS Unit".

In the SURVEYING mode, the Waypoint behavior becomes active and will execute a survey lawn-mower type pattern, as shown in and . In this mode, the periodic surfacing for GPS fixes is suppressed until the pattern is completed. The SURVEYING mode is entered whenever the MOOS variable SURVEY is set to true. In this mission, pMarineViewer is configured to toggle the SURVEY MOOS variable with on-screen buttons, and it is configured to accept mouse clicks which not only put the vehicle into the SURVEYING mode, but also accept the location of the mouse click as the center location of a predefined survey pattern. This kind of pMarineViewer configuration is discussed in .

1.3   Topic #1: Configuring the Helm for Operation at Depth    [top]


The Delta mission is configured to simulate a UUV and the helm is configured to produce decisions about the decision variables heading, speed, as well as depth. Adding depth to the helm decision space is done in the helm configuration block as shown below in , taken from the delta.moos mission file. In this case, the depth decision space is defined on line 13 with a range from 0 to 500 meters, with a resolution of 1 meter. See Section ??? for more on configuring the helm decision space with the domain parameter.

Listing 1.1 - Configuring pHelmIvP in the Delta mission to use behaviors concerning vehicle depth.

   1  // pHelmIvP config block
   2  
   3  ProcessConfig = pHelmIvP
   4  {
   5    AppTick    = 4
   6    CommsTick  = 4
   7  
   8    behaviors  = delta.bhv
   9    verbose    = quiet
  10    domain     = course:0:359:360
  11    domain     = speed:0:4:21
  12    domain     = depth:0:500:501
  13  }

In this example, the depth decision variable is a mandatory variable, along with heading and speed. This means that, on any given helm iteration, there must be a decision made about depth, or else the helm will post a helm error. How does the helm ensure that a depth decision is always part of any decision? The helm must be configured such that a behavior that reasons about depth is always active regardless of the helm mode. In the Delta mission, the three primary modes, LOITERING, SURVEYING, RETURNING, are all sub-modes of the ACTIVE mode, as shown above. The ConstantDepth behavior is configured to be running whenever the helm is in the Active mode.

1.4   Topic #2: The ConstantDepth Behavior    [top]


The ConstantDepth behavior is used in the Delta mission to keep the vehicle a prescribed depth while it is transiting, surveying, and loitering. For simplicity a single ConstantDepth behavior is used, but a different behavior instance could also be used for each vehicle mode. The behavior configuration, in file delta.bhv is shown in below. The first part of the configuration block, in lines 3-6, are for parameters defined generally for all IvP Helm behaviors, and the second part, on line 8, is a parameter defined for the ConstantDepth behavior.

Listing 1.2 - The ConstantDepth behavior in the Delta mission, from the file delta.bhv.

  1  Behavior = BHV_ConstantDepth
  2  {
  3    name      = bhv_const_depth
  4    pwt       = 100
  5    duration  = no-time-limit
  6    condition = MODE==ACTIVE
  7  
  8        depth = 15
  9  }

    The ConstantDepth behavior's primary parameter is the depth parameter on line 8. This behavior does make provisions for providing a range of depths, or a more gradually degrading utility function when this behavior is used to work with other behaviors reasoning about depth. In this mission however, the depth is mostly non-contentious between behaviors. The exception is when the PeriodicSurface behavior is active, in which case the priority weight for the PeriodicSurface behavior is simply set to suppress the ConstantDepth behavior.

1.5   Topic #3: The PeriodicSurface Behavior    [top]


The PeriodicSurface behavior, described generally in Section ???, is used in the Delta mission to bring the vehicle to the surface for GPS fixes periodically, to simulate the need for occasional navigation corrections. The behavior configuration, in file delta.bhv is shown in below. The first part of the configuration block, in lines 3-6, is for parameters defined generally for all IvP Helm behaviors, and the second part, in lines 8-13, is for parameters defined for the PeriodicSurface behavior.

Listing 1.3 - The PeriodicSurface behavior in the Delta mission, from the file delta.bhv.

   1  Behavior = BHV_PeriodicSurface
   2  {
   3    name             = bhv_periodic_surface
   4    pwt              = 1000
   5    condition        = (MODE == LOITERING) or (MODE == RETURNING)
   6    condition        = PSURFACE = true
   7  
   8                 period = 120
   9       zero_speed_depth = 2
  10    max_time_at_surface = 60
  11           ascent_speed = 1.0
  12           ascent_grade = fullspeed
  13          mark_variable = GPS_UPDATE_RECEIVED
  14  }

    The PeriodicSurface behavior outputs an objective function solely on the depth decision variable. Note the priority weight in line 4 in is set to 1000, in comparison to the priority weight set for the ConstantDepth behavior on line 4 in . When the PeriodicSurface behavior is running, it may or may not be active and producing an objective function over the depth decision variable. When it is active, the influence on depth simply overrules the influence from the ConstantDepth behavior due to these relative priority weights. For this reason, the ConstantDepth behavior may be conditioned on all active modes as in line 6 of .

    Note the parameter setting on line 13 above, setting the "mark variable" to GPS_UPDATE_RECEIVED. This is the default value, and the line could be safely be removed from the configuration block, but it is included anyway to be clear. The PeriodicSurface behavior, once it has noted that the vehicle has reached the surface, will wait until a value has been posted to GPS_UPDATE_RECEIVED that is different than its previous posting. Usually a timestamp suffices. The configuration of uTimerScript to achieve simulated GPS updates is described in more detail in the uTimerScript documentation in the Section "A Script Used as Proxy for an On-Board GPS Unit".

1.6   Topic #4: The Waypoint Behavior with Survey Patterns    [top]


The Waypoint behavior, described generally in Section ???, is used in the Delta mission to conduct survey patterns like that shown in . The behavior configuration, in file delta.bhv is shown in below. Note the survey pattern, described on line 15, does not list a set of points, but instead describes the pattern in terms of its properties such as the lane width and pattern orientation. This format is supported generally for building SegList objects from string specifications, discussed in the Geometry documentation.

Listing 1.4 - The Waypoint behavior in the Delta mission, from the file delta.bhv.

   1 Behavior = BHV_Waypoint
   2 {
   3   name      = waypt_survey
   4   pwt       = 100
   5   condition = MODE==SURVEYING
   6   perpetual = true
   7   updates   = SURVEY_UPDATES
   8   endflag   = SURVEY = false
   9 
  10           lead = 8
  11    lead_damper = 1
  12          speed = 2.0   // meters per second
  13         radius = 8.0
  14         points = format=lawnmower, label=dudley_survey, x=80, y=-80,  
                      width=70, height=30, lane_width=8, rows=north-south, 
                      degs=30
  15 }

    The waypoint behavior is configured to execute the survey pattern once, since the repeat parameter is not set and defaults to zero. Upon completion, it posts an end flag, configured on line 8, SURVEY=false to the MOOSDB. This immediately moves the vehicle out of the SURVEYING and into either the LOITERING or RETURNING mode depending on what it was doing when it was commanded to begin the survey. See the hierarchical mode declarations at the top of the delta.bhv file. Since the behavior is set with perpetual=true on line 6, completion of the survey pattern merely puts the behavior in a virtual stand-by mode until it is given a new set of waypoints and it once again meets its run conditions.

    The waypoint behavior is configured to accept dynamic parameter updates on line 7 through the MOOS variable SURVEY_UPDATES. In the Delta mission, updates are initiated by a mouse click in the pMarineViewer window, with the result being a post to the MOOSDB of the SURVEY_UPDATES variable. Such a posting would consist of a new value for the points parameter, replacing the initial configuration on line 14. This is discussed next.

1.7   Topic #4: Using pMarineViewer with Geo-referenced Mouse Clicks    [top]


In the Delta mission, the pMarineViewer application is used to post messages to the MOOSDB to (a) put the vehicle into the SURVEYING mode from either the LOITERING or RETURNING modes and (b) grab a user specified point in the operation area, from the user's mouse click, to be used as the center point of the commanded survey pattern. This situation is shown in . This is achieved by utilizing the Mouse Context feature of pMarineViewer, discussed in the pMarineViewer documentation, \cite{?} , in the section "Contextual Mouse Poking with Embedded OpArea Information". The below two lines are inserted into the pMarineViewer configuration block in delta.moos:

   left_context[survey-point] = SURVEY = true
   left_context[survey-point] = SURVEY_UPDATES = points = vname=$(VNAME),  [=\=]
         x=$(XPOS), y=$(YPOS), format=lawnmower, label=delta, width=70,    [=\=]
         height=30, lane_width=8, rows=north-south, degs=80

Both lines declare that a MOOS variable-value pair is to be posted whenever a left mouse click is generated by the user. The fist line sets SURVEY=true, in an attempt to put the helm into the SURVEYING mode. This alone will not suffice to switch modes if the current value of the MOOS variable RETURN is set to true. See the mode declarations near the top of the delta.bhv file for this mission - a command to return overrides a command to perform a survey. The second line above associates with a left-mouse click a posting to the SURVEY_UPDATES variable. Recall from that this is the very variable through which the surveying waypoint behavior is configured to receive dynamic parameter updates. This posting is configured with a few macros, $(VNAME), $(XPOS), $(YPOS), which are filled in with the name and position of the current vehicle in the pMarineViewer window . Each user left-mouse click thus re-assigns the vehicle to a new survey pattern, and switches the helm mode, unless it has been commanded to return.

1.8   Suggestions for Further Experimenting with the Delta Mission    [top]


1.8.1   Failing to Reason about Depth    [top]


In this mission, depth is a mandatory helm decision variable, along with course and speed, as configured in delta.moos and shown in . If a mission is not configured properly it's possible to bring about a helm mode where no behavior is reasoning about depth. Declaring depth to mandatory is equivalent to declaring that a situation where a helm iteration with no decision on depth is an error condition worth of an all-stop.

One way to bring this about in this mission, is to reconfigure the ConstantDepth behavior configuration in delta.bhv to replace line 6 in with the following

     condition = (MODE==LOITERING)

By doing this, there will be no depth related behavior when the vehicle is in the RETURNING mode. Try re-running the mission. Note when the mission is first launched, the label next to the vehicle in pMarineViewer reads "dudley (PARK)(ManualOverride)". This is normal and indicates that the helm state is PARK, simply because the operator retains manual control. In addition to seeing this in the pMarineViewer window, this can also be confirmed by scoping on a few key helm variables including IVPHELM_STATE and IVPHELM_ALLSTOP:

  $ uXMS delta.moos IVPHELM_STATE IVPHELM_ALLSTOP BHV_ERROR --show=source,time,community

should produce something similar to:

   VarName            (S)ource    (T)ime      (C)ommunity   VarValue (MODE = SCOPE:PAUSED)
   ----------------   ----------  ----------  ----------    ----------- (61)
   IVPHELM_STATE      pHelmIvP    81.86       dudley        "PARK"
   IVPHELM_ALLSTOP    pHelmIvP    1.69        dudley        "ManualOverride"
   BHV_ERROR           n/a         n/a         n/a          n/a
   MODE                n/a         n/a         n/a          n/a

Note that the IVPHELM_ALLSTOP value is posted once, until its value changes, and IVPHELM_STATE posts its value on every helm iteration regardless of the value. The latter variable also serves the purpose of a helm heartbeat indicator.

After noting the above, launch the mission by hitting the DEPLOY button, and note that the label next to the vehicle has changed to "dudley (LOITERING)". The four MOOS variables from above have also changed to:

  VarName            (S)ource    (T)ime      (C)ommunity   VarValue (MODE = SCOPE:PAUSED)
  ----------------   ----------  ----------  ----------    ----------- (103)
  IVPHELM_STATE      pHelmIvP    109.56      dudley        "DRIVE"
  IVPHELM_ALLSTOP    pHelmIvP    98.07       dudley        "clear"
  BHV_ERROR           n/a         n/a         n/a          n/a
  MODE               pHelmIvP    98.07       dudley        "ACTIVE:LOITERING"

After the vehicle has been running a bit, try hitting the RETURN button which changes the helm to the RETURNING mode. In this case, due to our tinkering with the mission above, there is no behavior reasoning about depth, and the following message appears next to the vehicle on the screen: "dudley (Returning)(MissingDecVars:depth)". The four scoped MOOS variables also change to the following:

  VarName            (S)ource    (T)ime      (C)ommunity   VarValue (MODE = SCOPE:PAUSED)
  ----------------   ----------  ----------  ----------    ----------- (134)
  IVPHELM_STATE      pHelmIvP    621.34      dudley        "DRIVE"
  IVPHELM_ALLSTOP    pHelmIvP    617.09      dudley        "MissingDecVars:depth"
  BHV_ERROR          pHelmIvP    621.59      dudley        "MissingDecVars:depth"
  MODE               pHelmIvP    617.09      dudley        "ACTIVE:RETURNING"

Note that, despite the error and all-stop event, the helm remains in drive, and may return to loitering or surveying at any time. Try configuring the helm in delta.moos to contain the line park_on_allstop=true and note the difference in the above experiment. The generated error will bump the helm into the PARK helm status.

Figure 1.1: The Delta Mission (1): The vehicle "dudley" heads to its loiter region where it will remain indefinitely until it is commanded to return or perform a survey pattern. It will periodically surface for a GPS fix.

Figure 1.2: The Delta Mission (2): The user has clicked a point in the viewer around which a survey pattern is built. The vehicle exits the loitering mode and begins to execute the survey pattern.

Figure 1.3: The Delta Mission (3): Once the vehicle has finished the survey pattern, it re-enters the loiter mode returning to its loiter region. It resumes periodic surfacing and immediately surfaces for a GPS fix.

Figure 1.4: The Delta Mission (4): After resumption of loitering, the user clicks in the viewer a new point around which a new survey pattern is built. The entry point of the survey pattern automatically accommodates the vehicle.


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