This behavior will drive the vehicle to trail or follow another specified vehicle at a given relative position. A tool for “formation flying”. The following parameters are defined for this behavior: 9.5.1 Brief Overview of Configuration Parameters and Variables Published
The behavior configuration parameters, and variables published by the behavior, collectively define the interface for the behavior. A more detailed description of usage is provided other parts of this section.
Configuration Parameters for the BHV Trail Behavior
The following are the configuration parameters for this behavior, in addition to the configuration parameters defined for all behaviors, described in Section7.2 beginning on page79.
Parameter Description BHV Trail
PWT OUTER DIST Range to contact outside which the behavior has zero priority. NM RADIUS If in this range to contact and ahead of it, slow down.
RADIUS If outside this radius to the contact, head to nm radius ahead of trail point TRAIL ANGLE Relative angle to the contact to set the trail-point.
TRAIL ANGLE TYPE Either ”relative” or ”absolute” bearing/angle to the contact. TRAIL RANGE Relative distance to the contact to set the trail-point.
CONTACT Name or unique identifier of a contact to be avoided.
DECAY Time interval during which extrapolated position slows to a halt.
EXTRAPOLATE If "true", contact position is extrapolated from last position and trajectory. ON NO CONTACT OK If false, a helm error is posted if no contact information exists.
TIME ON LEG The time on leg, in seconds, used for calculating closest point of approach. Table 22: Configuration paramters for the BHV Trail behavior.
Variables Published by the BHV CutRange Behavior
The below MOOS variables will be published by the behavior during normal operation, in addition to any configured flags. A variable published by any behavior may be supressed or changed to a different variable name using thepost mapping configuration parameter described in Section 7.2.1 on page 80.
Variable Description BHV CutRange
VIEW SEGLIST A bearing line between ownship and the contact if configured for rendering. Table 23: Variables posted by the BHV Trail behavior.
9.5.2 Specifying the Priority Policy - the pwt * dist Parameters
TRAIL RANGE: The range component of the relative position to the contact to trail.
TRAIL ANGLE: The relative angle of the relative position to the contact to trail. (180 is directly behind, 90 is a parallel track to the contacts starboard side, -90 is on the port side of the contact.)
TRAIL ANGLE TYPE: The trail angle may be set to either relative(the default), orabsolute.
RADIUS: The distance (in meters) from the trail position that will result in the behavior “cutting range” to the trail position, and inside of which will result in the behavior “shadowing” the contact. The default is 5 meters.
NM RADIUS: The distance in meters from the trail point within which the speed will be gradually change from the outer chase speed (max speed) and the speed of the contact, as illustrated in Fig. 42. This parameter should typically be set to several times the value of RADIUS to achieve smooth formation flying. Default is 20 meters.
MAX RANGE: The distance (in meters) that the contact must be within for the behavior to be active and produce an objective function. The default is max range value is zero meaning it will be active regardless of the distance to the contact.
10 Extended Example Missions with the IvP Helm
This section addresses a number of example mission configurations the user may run in simulation, to explore various aspects of the helm, certain behaviors, and certain tools for configuring, running and analyzing missions. All missions are available in the moos-ivp software tree in the following location:
moos-ivp/ivp/missions/
Obtaining the moos-ivp software tree from the public server was discussed in Section1.4.
10.1 Preliminaries
Each mission in themissions/directory is contained in a dedicated subdirectory such ass1 alpha, orm2 berta. The ’s’ and ’m’ in the prefix indicate whether it is a single-vehicle or multi-vehicle mission. The numbering roughly correlates to an increase in complexity from commonly used bread-and-butter behaviors and configurations to more complex mission configurations.
Each directory contains one or more mission files, i.e., files that end in the.moossuffix, and one or more behavior files, i.e., files that end in the.bhvsuffix. During the course of running a mission, certain additional temporary files may be created. In all cases, the temporary files may be removed by running the clean.sh script included in each directory. The configuration and launching of the missions requires some familiarity with three tools, (a) pAntler, for launching multiple MOOS applications, (b) thensplug tool, for building composite .moos and .bhv files from a template and set of include files, and (c) basics of shell scripts for organizing the overall launch process and cleanup. A brief recap of these three tools is covered next.
10.1.1 Using pAntler to Launch Missions
ThepAntler utility is a command-line tool used to orchestrate the launching of a group of MOOS processes. A typical invocation is:
> pAntler charlie.moos
The MOOS file contains a configuration block for each process, and an Antler configuration block which is typically the first block in the file. Each block contains a collection of local “parameter = value” pairs read in by each individual application. There are also typically a number of global parameter=value pairs for possible use by all applications.
10.1.2 Using the nsplug Utility for Configuring Mission and Behavior Files
In multi-vehicle missions, the maintenance of mission and behavior files across multiple vehicles can become cumbersome and user error-prone. Since many of the file components are identical between vehicles, a fair amount of the problem is mitigated by building the files from file template files that include the common components from separate files. Thensplugcommand-line utility is used to expand a template file into a target file, with arguments passed that typically distinguish the produced file from others produced from the same template. For example, two mission files, one for the vehicle ”charlie”, and one for the vehicle ”frankie” may differ only in their vehicle names and IP Port number, and may be produced from a template file with the following two commands:
> nsplug meta_vehicle.moos targ_charlie.moos VNAME=charlie PORT=9201 > nsplug meta_vehicle.moos targ_frankie.moos VNAME=charlie PORT=9202
For the multi-vehicle example missions distributed with the moos-ivp tree and described in this section, this use of templates is used in all cases. The mission directories downloaded will not contain the nsplug ”output” files such as targ charlie.moos above. Rather, they are built by executing the launch scripts provided in each directory with a command such as:
> ./launch.sh
The above invocation will both build the mission and behavior files and invoke pAntler for each vehi- cle to start the simulation. Certain common command-line options such as"./launch --just build", to build the mission files without launching, are available in all scripts. A few conventions with respect to templates andnsplug are used across all example mission directories.
1. Files used as templates have a"meta "prefix.
2. Files meant to be included or plugged into another template file have a"plug "prefix. 3. Output files that are built from templates and plug-ins viansplug have "targ "prefix. 4. Template or plug-in files that contribute to a target MOOS file have".moos" suffix. 5. Template or plug-in files that contribute to a target Helm behavior file have ".bhv"suffix. For example, in them2 bertamission, the following files exist prior to building any target files and launching:
> cd missions/m2_berta > ls
clean.sh* plug_uSimMarine.moos plug_pMOOSBridgeV.moos launch.sh* plug_origin_warp.moos plug_pMarinePID.moos meta_shoreside.moos plug_pBasicContactMgr.moos plug_pNodeReporter.moos meta_vehicle.bhv plug_pHelmIvP.moos plug_uProcessWatch.moos meta_vehicle.moos plug_pLogger.moos plug_uXMS.moos
After building all the target files, the following additionaltarg * files exist:
> ./launch.sh --just_build > ls
clean.sh* plug_pBasicContactMgr.moos plug_uXMS.moos
launch.sh* plug_pHelmIvP.moos targ_gilda.bhv
meta_shoreside.moos plug_pLogger.moos targ_gilda.moos meta_vehicle.bhv plug_pMOOSBridgeV.moos targ_henry.bhv meta_vehicle.moos plug_pMarinePID.moos targ_henry.moos plug_uSimMarine.moos plug_pNodeReporter.moos targ_shoreside.moos plug_origin_warp.moos plug_uProcessWatch.moos
The mission may launched, withMOOSTimeWarp=10, by: