36   The Jake Kasper Baseline Mission

36.1 Module Topology in the Jake Kasper Mission
36.2 Key MOOS Variables in the Jake Kasper Mission
36.3 General Description of Events in the Jake Kasper Mission
     36.3.1 Phase 1: Sensor Configuration and Handling of Mission Parameters
     36.3.2 Phase 2: Executing the Search Phase
     36.3.3 Phase 3: Reporting Results
36.4 Required MOOS Variable Bridges
     36.4.1 Variable Bridges from the Shoreside to the Vehicle
     36.4.2 Variable Bridges from the Vehicle to the Shoreside
36.5 Hazard Files in the Jake Kasper Mission

The Jake Kasper mission is distributed with the MOOS-IvP code and was designed to highlight four things:

The example mission contains a default hazard field and a few other hazard fields for testing. Assuming the reader has downloaded the source code available at www.moos-ivp.org and built the code successfully, the Jake Kasper Baseline mission may be launched by: 

  $ cd moos-ivp/ivp/missions-2680/lab_10_jake_kasper_baseline/
  $ ./launch.sh 12

The argument, 12, in the line above will launch the simulation in 12x real time. Once this launches, pMarineViewer should launch and the mission may be initiated by hitting the DEPLOY_ALL button. Shortly thereafter, two vehicles named jake and kasper will begin simple lawnmower patterns, each over half of the search region, as shown in the video in Figure 36.1 below.

http://vimeo.com/88824022

Figure 36.1: The Jake Kasper Baseline mission: Two vehicles are on independent lawn-mower shaped search patterns, each with a chosen swath width. Each vehicle will generate a hazardset report upon completion of their initial search. This is a straw-man solution to the hazard-search problem. Several changes or additions need to be made to improve the performance, but this mission constitutes a syntactically valid hazard-search mission. video:(0:32): https://vimeo.com/88824022

    Any time after the vehicle has been deployed, the user may request the generation of a hazardset report. The REQ_REPORT button sends a HAZARDSET_REQUEST message to the vehicles, each running uFldHazardMgr. Repeated requests result in updated reports. The overall score of the reports tends higher as the mission progresses and more hazards are detected.

36.1   Module Topology in the Jake Kasper Mission    [top]

The key components of the Jake Kasper mission are shown in Figure 36.2 below. The uFldHazardSensor and uFldHazardMetric apps run on the shoreside, the uFldHazardMgr runs on the vehicle. The latter is a straw-man implementation of a application to be implemented by individual developers in the hazard search competition. All three applications are described in detail in their own separate sections.

    A high-level description of operation is that the vehicles (a) configure the hazard sensor, (b) process the sensor information as they move through the field, and finally (c) generate a hazardset report and send it back to the shoreside for evaluation.

Figure 36.2: The Jake Kasper Baseline Mission Module Topology: The three key modules of the Jake mission are uFldHazardSensor, uFldHazardMetric, and uFldHazardMgr.

36.2   Key MOOS Variables in the Jake Kasper Mission    [top]

To digest what is going on in this mission, familiarity with the key MOOS variables published by each key modules is needed. We list these here for reference in the following discussion. It's worth remembering that this information is always available on the command-line, by typing for example: 

  $ uFldHazardSensor --interface or -i

The above also provides example values for the key variables, whereas below just the variable names are listed.

uFldHazardSensor Interface    [top]

  • Publications: UHZ_DETECTION_REPORT, UHZ_HAZARD_REPORT, UHZ_CONFIG_ACK, UHZ_OPTIONS_SUMMARY, VIEW_CIRCLE, VIEW_MARKER, VIEW_POLYGON.
  • Subscriptions: NODE_REPORT, UHZ_SENSOR_REQUEST, UHZ_CONFIG_REQUEST,UHZ_CLASSIFY_REQUEST.

uFldHazardMetric Interface    [top]

  • Publications: UHZ_MISSION_PARAMS, HAZARDSET_EVAL.
  • Subscriptions: HAZARD_SEARCH_START, HAZARDSET_REPORT.

uFldHazardMgr Interface    [top]

This information, and example values for each variable, may be obtained from the command-line by typing uFldHazardMgr -i.

  • Publications: UHZ_CONFIG_REQUEST, UHZ_SENSOR_REQUEST, HAZARDSET_REPORT.
  • Subscriptions: HAZARDSET_REQUEST, UHZ_CONFIG_ACK, UHZ_DETECTION_REPORT, UHZ_OPTIONS_SUMMARY.

36.3   General Description of Events in the Jake Kasper Mission    [top]

There are roughly three phases to the Jake Kasper example mission, (a) initialization and startup, (b) search, and (c) reporting results. These are described below with some reference to what additional measures would be needed beyond the straw-man mission.

36.3.1   Phase 1: Sensor Configuration and Handling of Mission Parameters    [top]

For each vehicle, there are two steps in the initialization phase, (a) initializing the hazard sensor, and (b) digesting the mission parameters.

Sensor Configuration    [top]

The hazard sensor initialization is done in three steps. First uFldHazardSensor publishes the sensor options, with something similar to: 

   UHZ_OPTIONS_SUMMARY = width=10,exp=6,class=0.91:width=25,exp=4,class=0.85:
                         width=50,exp=2,class=0.78

Once the vehicle knows the sensor options, it can pick one. In this case the uFldHazardMgr, running on vehicle jake posts something similar to: 

   UHZ_CONFIG_REQUEST = vname=jake,width=25,pd=0.9

Once the request has been received, uFldHazardSensor, will either accept the requested swath width outright, or map it to the closest legal option. After setting the value for PD, it will determine the PFA and PC, and post a confirmation to the following variable: 

   UHZ_CONFIG_ACK = vname=jake,width=20,pd=0.9,pfa=0.53,pclass=0.91

Once this is done, the sensor is configured. In the Jake Kasper mission, being a straw-man mission, some of the above steps are over-simplified. In the Jake Kasper mission, uFldHazardMgr on the vehicle does not handle the options summary and just blindly requests a particular sensor setting. It also does not handle the configuration acknowledgement. This may be something improved by a user extending this mission.

Handling of Mission Parameters    [top]

Upon startup, the mission parameters are published by uFldHazardMetric on the shoreside and sent to each of the vehicles. The format of this message may look something like: 

 UHZ_MISSION_PARAMS = penalty_missed_hazard=100,               
              penalty_false_alarm=35,
              max_time=600, 
              penalty_max_time_over=200,                         
              penalty_max_time_rate=0.45,                        
              search_region = pts={-150,-75:-150,-50:40,-50:40,-75}

The straw-man Jake Kasper mission however does not consume and react to these mission parameters. The search mission pattern is hard-coded and the penalties are disregarded, all detections are reported as hazards. This will almost certainly need to be handled by users wishing to improve on the baseline performance provided in the Jake Kasper mission.

36.3.2   Phase 2: Executing the Search Phase    [top]

The activities during the search phase consist of two types of messages originating in the vehicle, and two types of messages originating in the hazard sensor back to the vehicle. Basic sensor operation is turned on when the vehicle publishes the variable: 

   UHZ_SENSOR_REQUEST = vname=jake

In the Jake Kasper mission, the above message originates in uFldHazardMgr. This is received on the shoreside by uFldHazardSensor. The hazard sensor regards the sensor to be on if, for the named vehicle, it has received a sensor request recently. If the sensor is on and the vehicle passes over an object and produces a detection, then a detection report is posted by the sensor and sent back to the vehicle: 

   UHZ_DETECTION_REPORT = x=51,y=11.3,label=12

The vehicle may decide to request a classification report for a given detection and publish: 

   UHZ_CLASSIFY_REQUEST = vname=jake,label=12,priority=80

However, in the Jake Kasper mission, no classify requests are generated. The vehicle simply interprets all detections to be hazards and generates a report without using the classify capability of the hazard sensor. This is another area where the user wishing to improve on the baseline mission would focus their effort. Classify requests are eventually answered by the uFldHazardSensor publishing: 

   UHZ_HAZARD_REPORT = x=51,y=11.3,type=hazard,label=12

36.3.3   Phase 3: Reporting Results    [top]

The final phase of the mission involves sending a report from the vehicle to the shoreside, handled by uFldHazardMetric: 

   HAZARDSET_REPORT = source=jake#
                      x=-151,y=-217.3,label=01# 
                      x=-178.8,y=-234,label=15# 
                      x=-59.8,y=-294.1,label=13

When is this report sent? In the Jake Kasper mission, this report is sent simply after the vehicles have completed their lawnmower pattern. Furthermore, in this mission, each vehicle sends their own report; there is no coordination or communication. The uFldHazardMetric evaluates a single latest report, so the earlier report in the mission is simply dropped. This is another obvious issue for improvement.

    After receiving and evaluating a report, the uFldHazardMgr publishes the evaluation to the below variable, consisting partly of results, and partly reiterating the criteria for evaluation: 

   HAZARDSET_EVAL  = vname=jake,                               
              report_name=jake_team,                            
              total_score=675,                                   
              norm_score=37.5,                                   
              score_missed_hazards=500,                          
              score_false_alarms=175,                            
              score_time_overage=0,                              
              total_objects=10,                                  
              total_time=1284.91,                                
              received_time=1314.05,                             
              start_time=29.14,                                  
              missed_hazards=5,                                  
              correct_hazards=5,                                 
              false_alarms=5,                                    
              penalty_false_alarm=35,                            
              penalty_missed_hazard=100,                         
              penalty_max_time_over=100,                         
              penalty_max_time_rate=0.05,                        
              max_time=1800

In the Jake Kasper mission, the uFldHazardMgr also will publish a hazardset report upon request when it receives incoming mail HAZARDSET_REQUEST=true. In this baseline mission, the pMarineViewer GUI is configured to generate this request with one of the custom action buttons.

36.4   Required MOOS Variable Bridges    [top]

The Jake Kasper mission requires MOOS variables to be be shared between the vehicle and shoreside community depicted in Figure 36.2 . The variables of key processes were described above in Section 36.2 and Section 36.3 . The sharing (also referred to as bridging) between MOOS communities is done with the pShare MOOS app distributed with MOOS. Configuration involves specifying which variables are to be sent to which other machine (IP address) along with the port where the other MOOSDB resides. This is configured on the shoreside for variables shared from the shoreside to the vehicles. A similar configuration exists on the vehicles for variables going in the other direction.

36.4.1   Variable Bridges from the Shoreside to the Vehicle    [top]

Many of the variables shared from the shoreside to the vehicle were discussed in the previously in Section 36.2 and Section 36.3 . The variable share configuration is handled on the shoreside with the uFldShoreBroker application. Below is the configuration used in the Jake Kasper mission: 

 ProcessConfig = uFldShoreBroker
 {
   AppTick       = 1
   CommsTick     = 1

   // Note: [qbridge = FOO]  is shorthand for
   //       [bridge = src=FOO_$V,  alias=FOO] and
   //       [bridge = src=FOO_ALL, alias=FOO]

   qbridge  = DEPLOY, RETURN, NODE_REPORT, NODE_MESSAGE
   qbridge  = MOOS_MANUAL_OVERRIDE

   bridge   = src=APPCAST_REQ
   bridge   = src=UHZ_MISSION_PARAMS
   bridge   = src=UHZ_OPTIONS_SUMMARY

   bridge   = src=UHZ_CONFIG_ACK_$V,       alias=UHZ_CONFIG_ACK
   bridge   = src=UHZ_HAZARD_REPORT_$V,    alias=UHZ_HAZARD_REPORT
   bridge   = src=UHZ_DETECTION_REPORT_$V, alias=UHZ_DETECTION_REPORT
   bridge   = src=HAZARDSET_REQUEST_ALL,   alias=HAZARDSET_REQUEST
 }

    In addition to the sensor variables discussed previously, certain basic mission variables, e.g., DEPLOY, RETURN are shared to allow for basic command-and-control of the vehicles. More on uFldShoreBroker application can be found in the documentation for that application. In short, the application allows for configurable automatic point-to-point sharing of information as vehicles become known.

36.4.2   Variable Bridges from the Vehicle to the Shoreside    [top]

Most of the variables shared from the vehicle to the shoreside were discussed in the previous secions, 36.2 and 36.3 . The variable share configuration, for variables sent fom the vehicle to the shoreside, is handled on vehicle with the uFldNodeBroker application. Below is the configuration used in the Jake Kasper mission: 

 ProcessConfig = uFldNodeBroker
 {
   AppTick   = 1
   CommsTick = 1

   TRY_SHORE_HOST = pshare_route=multicast_9

   BRIDGE = src=VIEW_POLYGON
   BRIDGE = src=VIEW_POINT
   BRIDGE = src=VIEW_SEGLIST
   BRIDGE = src=APPCAST
   BRIDGE = src=UHZ_CLASSIFY_REQUEST
   BRIDGE = src=UHZ_SENSOR_REQUEST
   BRIDGE = src=UHZ_CONFIG_REQUEST
   BRIDGE = src=HAZARDSET_REPORT
   BRIDGE = src=NODE_REPORT_LOCAL,  alias=NODE_REPORT
   BRIDGE = src=NODE_MESSAGE_LOCAL, alias=NODE_MESSAGE
 }

    In addition to the sensor variables discussed previously, a few geometry variables, e.g., VIEW_POLYGON, are shared to the shore for rendering thing such as the vehicle search path or search region in the shoreside display. More on the uFldNodeBroker application can be found in the documentation for that application. In short, the application allows for configurable autonomatic point-to-point sharing of information as the location of the shoreside is discovered, without requiring changes to the misison files if the shoreside location, i.e., IP address, changes.

36.5   Hazard Files in the Jake Kasper Mission    [top]

There are several example hazard files included in the Jake Kasper mission. The default file used is hazards.txt, but there are additionally four other files:

  • hazards_01.txt
  • hazards_02.txt
  • hazards_03.txt
  • hazards_04.txt

    They vary in (a) number of benign objects, (b) number of hazards, and (c) hazard resemblance of the benign objects. Each of these files was created with the gen_hazards utility distributed with moos-ivp. The first line of each file contains a comment, a line showing exactly the command-line invocation of gen_hazards used in making the file. You are welcome to create your own to test situations beyond those in the handful of files included in this mission.

    To launch the mission with a different hazard file, the --hazards command-line switch is supported with the provided launch script. For example: 

  $ ./launch.sh --hazards=hazards_03.txt 10

As before, the 10 on the command-line specifies the time warp and individual machines may vary in the magnitude of time warp supported, correlated to the machines raw computing capacity.

Page built from LaTeX source using the texwiki program.