34   The Berta Mission

34.1 Overview of the Berta Mission Components and Topics
34.2 Launching the Berta Mission
34.3 Topic #1: The AvoidCollision Behavior and Dynamic Behavior Spawning
34.4 Topic #2: Contact Management with pBasicContactMgr
34.5 Suggestions for Tinkering in the Berta Mission

The Berta mission involves two vehicles repeatedly performing collision avoidance with one another. The primary capabilities highlighted are the helm's collision avoidance behavior, the basic contact manager, pBasicContactMgr, and the dynamic spawning and removal of behaviors related to contacts from the helm.

34.1   Overview of the Berta Mission Components and Topics    [top]

Here is a bit of what the Berta mission should look like:

http://vimeo.com/84492574

Figure 34.1: The Berta mission. video:(0:43): https://vimeo.com/84492574

Behaviors:Loiter, AvoidCollision
Vehicles:henry and gilda
MOOS Apps:pHelmIvP, pLogger, uSimMarine, pBasicContactMgr, pMarinePID, pNodeReporter, pMarineViewer, uTimerScript, pShare
Primary Topics:(1) The IvP Helm AvoidCollision behavior / Dynamic behavior spawning.
(2) Contact management with the pBasicContactMgr application.
Side Topics:(1) uTimerScript is used in a command and control role for random permuting of vehicle loiter assignments.
(2) pShare is used for connecting one shoreside command and control community to two simulated vehicle communities.
(3) The Loiter behavior is configured to receive dynamic updates on its loiter position.

34.2   Launching the Berta Mission    [top]

The Berta mission may be launched from the command line: 

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

This should bring up a pMarineViewer window like that shown in Figure 34.2, with two vehicles, henry and gilda, each initially in the "PARK" state. After hitting the DEPLOY button in the lower right corner, the vehicle enters the "LOITERING" mode and begins to proceed along the loiter pattern as shown. The example mission is configured to periodically alter the position of each vehicle's loiter pattern, alternating between a random point in Region-A and Region-B shown in Figure 34.2. The user may click the PERMUTE-NOW button to immediately cause a new permutation and command sent to the vehicle, which otherwise happens automatically every three minutes.

34.3   Topic #1: The AvoidCollision Behavior and Dynamic Behavior Spawning    [top]

The AvoidCollision behavior runs on both vehicles and is configured identically on each vehicle in this mission. Its configuration is shown in Listing 34.1. When the helm first launches on each vehicle this behavior is not present. It is configured to be a dynamically spawned behavior - one for each known contact within a certain range of the vehicle. In this regard it depends on alerts from a contact manager running separately on each vehicle that posts the MOOS variable CONTACT_INFO, with the name of the new contact for which to spawn a new behavior.

    The CONTACT_INFO variable is the variable for which the behavior is configured to receive dynamic updates, on line 6. The behavior is configured to allow dynamic instantiations on line 8 with templating = spawn. The choice of spawn (vs. clone) means that a behavior of this configuration is not initially present unless cued via the updates interface. See the discussion on dynamic behavior spawning in Section 7.7.

Listing 34.1 - Configuration of the AvoidCollision behavior in the Berta example mission. 

   1  Behavior = BHV_AvoidCollision
   2  {
   3    name       = avd_collision
   4    pwt        = 200
   5    condition  = AVOID=true
   6    updates    = CONTACT_INFO
   7    endflag    = CONTACT_RESOLVED = $[CONTACT] 
   8    templating = spawn
   9 
  10                contact = to-be-set
  11       on_no_contact_ok = true
  12            extrapolate = true
  13                  decay = 30,60
  14    
  15         pwt_outer_dist = 50
  16         pwt_inner_dist = 20
  17              pwt_grade = linear
  18         completed_dist = 75
  19      min_util_cpa_dist = 8
  20      max_util_cpa_dist = 25
  21    bearing_line_config = white:0, green:0.65, yellow:0.8, red:1.0
  22  }

    The parameters in lines 15-17 determine the level of activity of the behavior based on the range to the contact. The parameters in lines 15 and 16 refer to the priority weight of the behavior. Beyond 50 meters in range, the weight will be 0% of its static weight of 200 assigned on line 4. (A weight of zero means that no objective function will be produced and the behavior is in the running state, but not the active state.) At 20 meters range, it will be at 100% of its static priority weight. The grade in priority between outer and inner distances is linear, due to the setting on line 17. The min_util_cpa_dist, and max_util_cpa_dist on lines 19 and 20 refer to the utilities assigned to candidate maneuvers in the objective function output by the behavior. Any candidate maneuver whose CPA is less than 8 meters will be given the lowest utility rating, equivalent to an actual collision. Likewise, any candidate maneuver whose CPA is greater than 25 will be given the highest utility rating, equivalent to missing the contact by infinite distance.

    The completed_dist, on line 18, refers to the range to the contact beyond which the behavior will declare itself to be complete. Once completed, the behavior will post its end flags (none in this case), and will remove itself from the helm. In this regard, some coordination with the contact manager is needed. At the very least, the contact manager must be configured to post alerts to the mutually configured MOOS variable, CONTACT_INFO, on line 6 in Listing 34.1 and on line 16 in Listing 34.2. Note also that the completed_dist is set to 75 meters, which is higher than the 55 meters set for the alert_range in the contact manager. This means that, after the avoid collision behavior dies, the contact must come back within 55 meters before the contact manager generates another alert, triggering the helm to once again spawn a behavior for the contact.

    Once a contact has gone out of range to the point where the AvoidCollision behavior dies, it typically never returns, in practice. There is no guarantee of this however, since the future maneuvers of either the contact or ownship may once again put them on a collision course. The Berta mission tests this scenario repeatedly. The two vehicles are configured to loiter in a loiter pattern that keeps them out range from each other in terms of triggering an AvoidCollision behavior in each of their helms (as in Figure 34.2). In this mission, a uTimerScript script is running in the shoreside community that periodically picks a new loiter location within one of the two regions shown in Figure 34.2. It picks a new location once every three minutes, alternating between the two regions for each vehicle each time. This ensures that there will be a reasonably unpredictable collision avoidance situation each time the vehicles transit to their new loiter locations. The permutations happen automatically once every three minutes, but the user may jump to the next permutation by clicking on the PERMUTE-NOW button.

    In Figure 34.3, note the line segment rendered between the two vehicles. This line segment is posted to the MOOSDB by the IvP Helm on behalf of the AvoidCollision behavior. A white line is drawn between the two vehicles as soon as the AvoidCollision behavior is spawned. The line turns a non-white color as soon as the behavior begins to generate an objective function, thus actively influencing the helm to prefer maneuvers with a lower expected CPA. The line is initially green to indicate a lower behavior priority. As the priority grows, the line turns yellow and finally red when it is at the higher priorities. The behavior posting of these line segments is optional and configurable. The configuration on line 21 in Listing 34.1 is responsible for the postings in this mission.

    In this example, the extrapolate option is turned on for the AvoidCollision behavior (line 12 in Listing 34.1). Extrapolation is typically enabled when long durations are experienced between updates on contact position (which is not the case here in simulation). The behavior will automatically use the linear extrapolated position given the contact's last known position, trajectory and time-stamp. The linear extrapolation will decay down to a zero speed (stationary solution) beginning at 30 seconds and coming to a complete stop at 60 seconds, due to the decay specification on line 13 of Listing 34.1.

34.4   Topic #2: Contact Management with pBasicContactMgr    [top]

In the Berta mission, the pBasicContactMgr is running on both simulated vehicles, configured identically with the configuration block shown in Listing 34.2. Both the contact manager and the helm are receiving NODE_REPORT messages containing information about contacts. The helm stores this information in its information buffer for any behavior that requests it during normal operation. The contact manager uses contact information to generate alerts, which potentially cues the helm to spawn new contact-related behaviors.

    The contact manager may be configured to generate more than one alert. However, in the Berta mission, a single alert, on line 15 in Listing 34.2 is sufficient for spawning collision avoidance behaviors. Note the alert specifies a variable name, and variable value. The variable name, (CONTACT_INFO), is set to be the variable used for updates in the AvoidCollision behavior, on line 6 in Listing 34.1. The variable value is configured to be #-separated list of parameter-value pairs suitable as input to any behavior receiving updates. (See Section 7.2.5 on behavior updates.) In this case, the alert is configured to "update" the AvoidCollision behavior parameters name, and contact. Both parameter values are comprised, in part, of the name of the contact, [@$[VNAME]@]. In the case of the behavior name, this is to ensure that the behavior name is unique, a condition for spawning a new behavior. It also ensures that multiple AvoidCollision behaviors will not be spawned for the same contact. In the case of the contact name, the behavior simply must know the name of the contact for which it avoiding a collision.

    In the unlikely event that two distinct contacts are present in the field, and reporting the same vehicle name, it would be up to the contact manager to discern that these are indeed two contacts and not one. Currently this is beyond the algorithms implemented in pBasicContactMgr.

Listing 34.2 - Configuration of the pBasicContactMgr application in the Berta example mission. 

   1  // pBasicContactMgr MOOS Configuration Block
   2  
   3  ProcessConfig = pBasicContactMgr
   4  {
   5    AppTick   = 2
   6    CommsTick = 2
   7  
   8    alert_range     = 55
   9    alert_cpa_range = 70
  10    alert_cpa_time  = 30
  11    contact_max_age = 3600
  12    display_raddii  = false
  13    verbose         = true
  14
  15    alert = var=CONTACT_INFO, val="name=avd_$[VNAME] # contact=$[VNAME]" 
  16  }

    In the Berta example mission, the contact manager is configured to generate alerts when a known contact comes within 55 meters of the vehicle (line 8 of Listing 34.2). The contact manager also is configured to generate alerts when a contact comes within 70 meters (line 9) and its calculated CPA over next 30 seconds (line 10) falls within the alert range (again line 8). See the pBasicContactMgr documentation, [43], for more on the relationship between these two ranges.

    The contact manager is capable of optionally posting to the MOOSDB two circles rendering the two ranges, the alert_range and alert_cpa_range. The rendering is turned off and on with the setting on line 12. The circles are posted under the variable VIEW_POLYGON in the local MOOSDBs on each vehicle, and each vehicle is configured to bridge this variable (via pShare) to the shoreside community running the pMarineViewer.

34.5   Suggestions for Tinkering in the Berta Mission    [top]

  • Alter the alert ranges in the contact manager, and enable the displaying of range radii (line 8 in Listing 34.2) and notice when the AvoidCollision behavior is spawned, by the presence of the bearing lines between the two contacts.
  • Alter the pwt_*_dist parameters in the AvoidCollision behavior (lines 15-16 in Listing 34.1) and check how this affects the ranges between the vehicles as they avoid collisions.

Figure 34.2: The Berta Mission (1): The two vehicles, henry and gilda, initially transit to their respective loiter stations and await further random location changes between the shown boxes.

Figure 34.3: The Berta Mission (2): The vehicles have changed their loiter stations and this puts them at risk for collision. The green bearing line between the vehicle indicates the presence of the AvoidCollision behavior.

Page built from LaTeX source using the texwiki program.