An Implementation Example - the SimpleWaypoint Behavior
Maintained by: mikerb@mit.edu Get PDF
src: project-pavlab/chapters/chap_bldu_simpwpt
1 An Implementation Example - the SimpleWaypoint Behavior
1.1 The SimpleWaypoint Behavior Class Definition
1.2 The SimpleWaypoint Behavior Class Implementation
1.2.1 The SimpleWaypoint Behavior Constructor
1.2.2 The SimpleWaypoint Behavior setParam() Function
1.2.3 The SimpleWaypoint onIdleState() and postViewPoint() Functions
1.2.4 The SimpleWaypoint Behavior onRunState() Function
1.2.5 The SimpleWaypoint Behavior buildFunctionWithZAIC() Function
1.2.6 The SimpleWaypoint Behavior buildFunctionWithReflector() Function
1.3 Running an Example Mission with the SimpleWaypoint Behavior
1 An Implementation Example - the SimpleWaypoint Behavior
In this section an example IvP behavior is presented. It is a simplified waypoint behavior version of the waypoint behavior in the standard suite of behaviors distributed with the MOOS-IvP public software bundle. The class name for this behavior is BHV_SimpleWaypoint. This behavior is distributed in the moos-ivp-extend repository and should build out of the box. After going through the class itself, later in this section example missions, also distributed with moos-ivp-extend, for running the behavior are discussed.
1.1 The SimpleWaypoint Behavior Class Definition [top]
The SimpleWaypoint behavior is configured with four parameters: a single waypoint given in terms of local x and y coordinates, a transit speed in meters per second, and a radius in meters around the destination point within which the vehicle will be declared to have arrived at its waypoint. The behavior, at every iteration of the helm loop, notes the vehicle's own position in x and y local coordinates. The idea is shown in .
Figure 1.1: The SimpleWaypoint behavior: The SimpleWaypoint behavior works with a single waypoint. The location of the waypoint is stored in the local variable m_nextpt and is set during behavior configuration. The local variables m_osx and m_osy reflect the current vehicle (ownship) position updated at every helm iteration. The m_arrival_radius determines how close the vehicle needs to be from the waypoint destination before declaring completion.
The BHV_SimpleWaypoint class definition is given below in . Note that it is declared to be a subclass of the IvPBehavior superclass on line 8. The three helm-invoked overloadable functions are declared on lines 13-15. The constructor is defined to take an IvPDomain as an argument. The helm will instantiate each behavior with the same helm-configured domain as an argument to a behavior constructor.
Listing 1.1 - BHV_SimpleWaypoint.h - the class definition for the "simple waypoint" behavior.
1 #ifndef BHV_SIMPLE_WAYPOINT_HEADER 2 #define BHV_SIMPLE_WAYPOINT_HEADER 3 4 #include <string> 5 #include "IvPBehavior.h" 6 #include "XYPoint.h" 7 8 class BHV_SimpleWaypoint : public IvPBehavior { 9 public: 10 BHV_SimpleWaypoint(IvPDomain); 11 ~BHV_SimpleWaypoint() {}; 12 13 bool setParam(std::string, std::string); 14 void onIdleState(); 15 IvPFunction* onRunState(); 16 17 protected: 18 void postViewPoint(bool viewable=true); 19 IvPFunction* buildFunctionWithZAIC(); 20 IvPFunction* buildFunctionWithReflector(); 21 22 protected: // Configuration parameters 23 double m_arrival_radius; 24 XYPoint m_nextpt; 25 double m_desired_speed; 26 std::string m_ipf_type; 27 28 protected: // State variables 29 double m_osx; 30 double m_osy; 31 }; 32 33 extern "C" { 34 IvPBehavior * createBehavior(std::string name, IvPDomain domain) 35 {return new BHV_SimpleWaypoint(domain);} 36 } 37 #endif
The two configuration parameters depicted in , the waypoint and arrival radius, are declared on lines 23-124. The two remaining configuration parameters, "speed" and "ipf_type" are on the following two lines. The former sets the ideal speed for waypoint transiting, and the latter indicates the type of IvP function to be generated. Two different ways of generating an IvP function are implemented in this behavior to demonstrate two different tools. The last part, lines 33-36 are the hooks needed for each behavior class to implement the dynamic loading of behaviors into the helm. These lines are therefore not present for behaviors compiled into the IvP helm. These lines are very pertinent to the discussion of extending" the helm.
1.2 The SimpleWaypoint Behavior Class Implementation [top]
The class implementation is given in - below.
1.2.1 The SimpleWaypoint Behavior Constructor [top]
The first part contains the class constructor in lines 17-34. On line 18, a call to the base-class constructor is made with the given domain. A default for the behavior name is also set on line 20. On line 21, the behavior declares that the domain over which it will produce an IvP function is comprised of both the course and speed variables. If the domain given to the behavior by the helm in the constructor does not have either of these variables, a null IvP domain will result in line 21. A null domain will make the behavior thereafter not capable of running, and is considered a fatal error, prompting the helm to post all-stop output values. This is purposely drastic. Configuring the behaviors in a vehicle mission where one of the behaviors is not runnable is worthy of stopping the helm and addressing the problem. Since this condition is checked for on all behaviors on each helm iteration, this problem would always reveal itself at launch time, never during a mission, regardless of any dynamic behavior configurations during a mission.
On lines 25-27, default values for class member variables representing key behavior parameters are set in the constructor. In lines 30-31, class member variables representing behavior state variables are initialized. The grouping of member variables into two sets, one that represent parameter configurations and the other that otherwise represent behavior state maintained during operation, is merely a convention that has provided clarity in practice.
Listing 1.2 - BHV_SimpleWaypoint.cpp - The SimpleWaypoint Behavior Constructor.
1 #include <cstdlib> 2 #include <math.h> 3 #include "BHV_SimpleWaypoint.h" 4 #include "MBUtils.h" 5 #include "AngleUtils.h" 6 #include "BuildUtils.h" 7 #include "ZAIC_PEAK.h" 8 #include "OF_Coupler.h" 9 #include "OF_Reflector.h" 10 #include "AOF_SimpleWaypoint.h" 11 12 using namespace std; 13 14 //----------------------------------------------------------- 15 // Procedure: Constructor 16 17 BHV_SimpleWaypoint::BHV_SimpleWaypoint(IvPDomain gdomain) : 18 IvPBehavior(gdomain) 19 { 20 IvPBehavior::setParam("name", "simple_waypoint"); 21 m_domain = subDomain(m_domain, "course,speed"); 22 23 // All distances are in meters, all speed in meters per second 24 // Default values for configuration parameters 25 m_desired_speed = 0; 26 m_arrival_radius = 10; 27 m_ipf_type = "zaic"; 28 29 // Default values for behavior state variables 30 m_osx = 0; 31 m_osy = 0; 32 33 addInfoVars("NAV_X, NAV_Y"); 34 } 35
Finally, on line 33, the behavior declares two variables, NAV_X and NAV_Y, representing vehicle ownship position. The IvP helm, containing this behavior, will need to register for these to variables on the behavior's behalf. This is the hook where the behavior tells the helm what it needs from the MOOSDB. It is from these two variables that the behavior will populate its variables m_osx and m_osy representing the current vehicle position.
1.2.2 The SimpleWaypoint Behavior setParam() Function [top]
In below, a key overloadable behavior function is implemented, the setParam() function, in lines 39-69. This function handles the configuration of the behavior for its five parameters, "ptx", "pty", "speed", "radius", and "ipf_type". An example configuration for this behavior is given in . Behavior parameters defined at the IvPBehavior superclass level, such as name, condition, endflag, etc., are handled in the setParam() function of the superclass. The helm, when it handles a behavior parameter from a *.bhv file, first attempts to handle the parameter at the superclass level. If the IvPBehavior::setParam() function returns false, the helm passes the parameter-value pair to the behavior's locally implemented version of setParam().
Listing 1.3 - BHV_SimpleWaypoint.cpp - The setParam() function.
36 //--------------------------------------------------------------- 37 // Procedure: setParam - handle behavior configuration parameters 38 39 bool BHV_SimpleWaypoint::setParam(string param, string val) 40 { 41 // Convert the parameter to lower case for more general matching 42 param = tolower(param); 43 44 double double_val = atof(val.c_str()); 45 if((param == "ptx") && (isNumber(val))) { 46 m_nextpt.set_vx(double_val); 47 return(true); 48 } 49 else if((param == "pty") && (isNumber(val))) { 50 m_nextpt.set_vy(double_val); 51 return(true); 52 } 53 else if((param == "speed") && (double_val > 0) && (isNumber(val))) { 54 m_desired_speed = double_val; 55 return(true); 56 } 57 else if((param == "radius") && (double_val > 0) && (isNumber(val))) { 58 m_arrival_radius = double_val; 59 return(true); 60 } 61 else if(param == "ipf_type") { 62 val = tolower(val); 63 if((val == "zaic") || (val == "reflector")) { 64 m_ipf_type = val; 65 return(true); 66 } 67 } 68 return(false); 69 } 70
A fair amount of error checking is done for parameter. For example, in setting the "speed" parameter, the string value is checked to ensure that is both numerical and larger than zero. Solid error checking implemented in this function is a very good idea that will save headaches down the road. This function should only return true if it has been passed a proper parameter-value pair. Another common practice is to perform a case insensitive parameter match, e.g., "pty" and "PTY" are both allowable configurations. This is done by converting the string representing the parameter to lower case in line 42. In this case, the tolower() function is defined in a local utility toolbox.
1.2.3 The SimpleWaypoint onIdleState() and postViewPoint() Functions [top]
The onIdleState() function, lines 74-77, is only executed when the behavior is in the idle state, i.e., not in the running state. See Sections ??? and ??? for more on behavior states. In this behavior, the only task executed in the onIdleState() function is to publish a waypoint marker in the form of the MOOS variable VIEW_POINT.
Listing 1.4 - BHV_SimpleWaypoint.cpp -The onIdleState() and postViewPoint() functions.
71 //----------------------------------------------------------- 72 // Procedure: onIdleState 73 74 void BHV_SimpleWaypoint::onIdleState() 75 { 76 postViewPoint(false); 77 } 78 79 //----------------------------------------------------------- 80 // Procedure: postViewPoint 81 82 void BHV_SimpleWaypoint::postViewPoint(bool viewable) 83 { 84 m_nextpt.set_label(m_us_name + "'s next waypoint"); 85 m_nextpt.set_type("waypoint"); 86 m_nextpt.set_source(m_descriptor); 87 88 string point_spec; 89 if(viewable) 90 point_spec = m_nextpt.get_spec("active=true"); 91 else 92 point_spec = m_nextpt.get_spec("active=false"); 93 postMessage("VIEW_POINT", point_spec); 94 } 95
An example produced by this would be:
VIEW_POINT = "active,false:label,alder's next waypoint: type,waypoint:source,waypt_return:0,0,0"
In this case, due to the "active,false" component, the posting of this variable would serve to "erase" similar postings to this variable made in the onRunState() function described next. For more on how VIEW_POINT is consumed, see the documentation for the pMarineViewer.
1.2.4 The SimpleWaypoint Behavior onRunState() Function [top]
Implementation of the onRunState() function is where the primary unique operation of the behavior is implemented. For the SimpleWaypoint behavior, the full function is in below. It is implemented in four parts:
- Part 1: Get the vehicle position from the information buffer.
- Part 2: Determine if the waypoint has been reached and possibly enter complete mode. \vspace{-0.07in}
- Part 3: Build a status message regarding the waypoint for third party viewers. \vspace{-0.07in}
- Part 4: Build an IvP function with either the ZAIC or Reflector tool.
In the first part, lines 101-109, information from the information buffer is retrieved regarding the vehicle's own position. This is done with the getBufferDoubleVal() function described in Section ???. In this behavior the result of the query to the buffer is stored in the ok1 and ok2 variables and subsequently checked and handled in lines 106-109. In this behavior, if essential information like the vehicle's own position is missing, a warning is posted (line 107) and the onRunState() function returns without producing an objective function (line 108). In such a case the behavior would be considered to be in the running state, but not the active state for the present iteration.
A fair point to raise regarding Part 1 is the possibility that the vehicle's position information is in the buffer but has become so old that it no longer reflects the vehicle's true current position. In other words, what if the navigation module on board the vehicle has somehow shut down? First, in most situations with a vehicle implementing the backseat/front-seat driver architecture, a heartbeat monitor for the navigation system is typically put in place at the larger autonomy system level and an all-stop would be invoked overriding the helm. However, for the sake of having some fail-safe redundancy within the helm to handle this situation, the no_starve parameter could be used (Section ???) for this behavior, or any behavior since it is defined at the IvPBehavior superclass level. An example of it's usage is shown in , setting a no_starve threshold of 3 seconds for NAV_X and NAV_Y.
Listing 1.5 - BHV_SimpleWaypoint.cpp - the onRunState() implementation.
96 //----------------------------------------------------------- 97 // Procedure: onRunState 98 99 IvPFunction *BHV_SimpleWaypoint::onRunState() 100 { 101 // Part 1: Get vehicle position from InfoBuffer and post a 102 // warning if problem is encountered 103 bool ok1, ok2; 104 m_osx = getBufferDoubleVal("NAV_X", ok1); 105 m_osy = getBufferDoubleVal("NAV_Y", ok2); 106 if(!ok1 || !ok2) { 107 postWMessage("No ownship X/Y info in info_buffer."); 108 return(0); 109 } 110 111 // Part 2: Determine if the vehicle has reached the destination 112 // point and if so, declare completion. 113 double dist = hypot((m_nextpt.x()-m_osx), (m_nextpt.y()-m_osy)); 114 if(dist <= m_arrival_radius) { 115 setComplete(); 116 postViewPoint(false); 117 return(0); 118 } 119 120 // Part 3: Post the waypoint as a string for consumption by 121 // a viewer application. 122 postViewPoint(true); 123 124 // Part 4: Build the IvP function with either the ZAIC tool 125 // or the Reflector tool. 126 IvPFunction *ipf = 0; 127 if(m_ipf_type == "zaic") 128 ipf = buildFunctionWithZAIC(); 129 else 130 ipf = buildFunctionWithReflector(); 131 if(ipf == 0) 132 postWMessage("Problem Creating the IvP Function"); 133 134 return(ipf); 135 } 136
In Part 2 of the onRunState() function, in lines 111-118 of , the determination of waypoint arrival is made. This is just a simple comparison between the current distance of the vehicle and the waypoint to the configured arrival radius in the parameter m_arrival_radius. If a determination of arrival is made, the behavior calls the setComplete() function. This function is defined at the behavior superclass level and was described in detail in Section ???. The invocation of this function will put the behavior in the group of completed behaviors on the next helm iteration. In the current iteration this behavior would be considered in the running state, but not the active state since the onRunState() function returns (line 117) without generating an objective function. See Section ??? for more on behavior run states.
In Part 3, the behavior generates a visual artifact for consumption by a viewer, for rendering the waypoint the behavior is using as its destination. This point is shown in and with the label "Alder's next waypoint". An example produced by this would be:
VIEW_POINT = "label=alder's next waypoint,type=waypoint,source=transit,x=60,y=-40"
Compare this to the value for VIEW_POINT generated in the onIdleState() function described in . This variable-value pair is generated by the behavior for posting on each invocation of the onRunState() even though the value posted does not generally change between iterations. The posting of the variable-value pair is done with the postMessage() function, described in Section ???. The invocation of postMessage() will result in an actual post to the MOOSDB only if the value of string posted changes. Successive duplicate postings are filtered out by the Duplication Filter. The Duplication Filter was described in Section ??? where alternative functions for overriding the filter are given to accommodate other situations. The postMessage() function was discussed in Section ???.
In Part 4 of the onRunState() function, in lines 124-135 of , an IvP function is generated over a domain of heading and speed choices to reflect the goal of reaching a waypoint given a current vehicle position. For the purposes of providing an example usage of the IvPBuild Toolbox, the behavior is implemented to produced an IvP function using two different methods of the toolbox. The SimpleWaypoint behavior can be configured with the "ipf_type" parameter, as shown in , to accept either the configuration of "zaic" or "reflector". In the example mission, mission "Alder" described below in , the helm is configured in to use the ZAIC tool on the outbound transit trip, and the Reflector tool on the return trip. The implementation of the onRunState() function merely checks the type of IvP function desired and makes the appropriate call to either the buildFunctionWithZAIC() function or the buildFunctionWithReflector() function. These two functions are described next.
1.2.5 The SimpleWaypoint Behavior buildFunctionWithZAIC() Function [top]
When the SimpleWaypoint behavior is configured to generate an IvP function with the ZAIC tool, it invokes the function buildFunctionWithZAIC(), shown below in . Of the three ZAIC tools described in Section ???, the ZAIC_PEAK is used in this behavior. It is used to generate two one-variable IvP functions. The first function is defined over the speed decision variable in lines 142-151. The second function is defined over heading decision variable. The functions are shown in .
Listing 1.6 - BHV_SimpleWaypoint.cpp - the buildFunctionWithZAIC() implementation.
137 //----------------------------------------------------------- 138 // Procedure: buildFunctionWithZAIC 139 140 IvPFunction *BHV_SimpleWaypoint::buildFunctionWithZAIC() 141 { 142 ZAIC_PEAK spd_zaic(m_domain, "speed"); 143 spd_zaic.setSummit(m_desired_speed); 144 spd_zaic.setPeakWidth(0.5); 145 spd_zaic.setBaseWidth(1.0); 146 spd_zaic.setSummitDelta(0.8); 147 if(spd_zaic.stateOK() == false) { 148 string warnings = "Speed ZAIC problems " + spd_zaic.getWarnings(); 149 postWMessage(warnings); 150 return(0); 151 } 152 153 double rel_ang_to_wpt = relAng(m_osx, m_osy, m_nextpt.x(), m_nextpt.y()); 154 ZAIC_PEAK crs_zaic(m_domain, "course"); 155 crs_zaic.setSummit(rel_ang_to_wpt); 156 crs_zaic.setPeakWidth(0); 157 crs_zaic.setBaseWidth(180.0); 158 crs_zaic.setSummitDelta(0); 159 crs_zaic.setValueWrap(true); 160 if(crs_zaic.stateOK() == false) { 161 string warnings = "Course ZAIC problems " + crs_zaic.getWarnings(); 162 postWMessage(warnings); 163 return(0); 164 } 165 166 IvPFunction *spd_ipf = spd_zaic.extractIvPFunction(); 167 IvPFunction *crs_ipf = crs_zaic.extractIvPFunction(); 168 169 OF_Coupler coupler; 170 IvPFunction *ivp_function = coupler.couple(crs_ipf, spd_ipf, 50, 50); 171 172 return(ivp_function); 173 } 174
The first step in creating an IvPFunction with the ZAIC_PEAK tool is to create an instance of the ZAIC_PEAK, on line 142, passing it the IvPDomain used by the behavior and set in the behavior constructor in . The ZAIC constructor is also passed the name of the one variable in the IvPDomain for which to create the IvPFunction. The ZAIC_PEAK parameters, set in lines 143-146, are described in detail in Section ???. In lines 147-151, a check is made to determine whether the ZAIC_PEAK instance has been configured properly. The stateOK() function returns false if there were any configuration problems, and the string returned by getWarnings() function on line 148 will provide insight into any configuration errors. The postWMessage() function on lines 149 and 162 will result in the helm posting to the MOOSDB the variable BHV_WARNING with the contents of string warnings. The postWMessage() function is discussed in Section ??? on page \pageref{lab_postwmessage}.
The second one-variable function, defined over course, is created with a second ZAIC_PEAK instance in lines 153-164. First, the angle between the current vehicle position and the waypoint destination is calculated on line 153, with a call to the relAng() function, defined in one of the MOOS-IvP utility libraries. The creation and configuration of the ZAIC_PEAK instance proceeds much in same way as for the first one. In this case, the valuewrap parameter is set to true on line 159 to indicate that the domain values should ``wrap around'', that is, a course of 350 is 20 degrees separated from a course of 10 degrees, not separated by 340 degrees. The valuewrap parameter is discussed in Section ??? on page \pageref{lab_valuewrap}.
Figure 1.2: IvP functions produced by the ZAIC_PEAK Tool: The two functions produced by the SimpleWaypoint behavior by use of the ZAIC_PEAK tool would produce a function over speed with six pieces and a function over heading with three pieces.
When these two functions are coupled using the Coupler tool, lines 169-170, an IvP function over the coupled decision 2D space is created as shown in below. The Coupler tool is discussed in Section ??? on page \pageref{sec_coupler}.
Figure 1.3: An IvP function coupled from two one-variable functions: This function is created by coupling the pair of one-variable functions of using the OF_Coupler tool. Decisions of increasing speed are represented by points on the function radially farther from the center.
The two one-variable functions are combined with an equal weight of 50 on line 170. The choice of relative weight has a distinct influence over the resulting function. In below, two IvP functions similarly generated, but with alternative weights are shown. The Coupler, by default, normalizes the combined function to the range of [0,100]. This can be turned off, or normalized with a different range as described in Section ???. The range of [0, 100] is a common range for functions returned by an IvP behavior to the IvP Solver.
Figure 1.4: Two IvP functions coupled from the same two one-variable functions: These functions were created by coupling the pair of one-variable functions of using the OF_Coupler tool. They differ only in the relative weight applied to each function. The one on the left had a weight of 75 to the speed function and a weight of 25 to the course function. These weights are reversed on the right. The function on the right shows two off-peak decision points with equal utility rating. Decisions of increasing speed are represented by points on the function radially farther from the center.
In each IvP function in and , the location of the peak of the function is the same. When this behavior is the only active behavior, the path taken by the vehicle will be the same regardless of the weights chosen to combine the two one-variable functions with the Coupler. The only thing that matters is the value of the summit parameters passed to the two ZAIC tools creating the two one-variable functions. The off-peak characteristics of the function begin to matter when the behavior is coordinated with functions from other behaviors. In the function on the right in , two off-peak decisions with equal utility values are shown. One point represents a decision with the heading more toward the destination with a speed much higher than the desired speed, and the other decision represents a heading less toward the destination but with speed near the optimal speed. In the absence of mission metrics that clarify the relative utility of sub-optimal transit paths versus sub-optimal speeds, the construction of the off-peak shape of the objective function is typically a subjective decision of the behavior implementor.
1.2.6 The SimpleWaypoint Behavior buildFunctionWithReflector() Function [top]
The Reflector tool can be used to generate objective functions that cannot otherwise be formed as the product of the coupling of two independent functions. This gives the behavior implementor more freedom to generate functions with off-peak characteristics more in-line with the goals of the behavior. The Reflector tool is described in detail in Sections ??? and ???.
The use of the Reflector tool in the SimpleWaypoint behavior is given in below. The Reflector generates an IvP function approximation of an underlying function, an instance of the AOF_SimpleWaypoint class. The underlying function and the IvP function are defined over the same domain. This domain is passed to the underlying function in its constructor (line 183). The underlying function is passed required parameters (lines 184-188) and initialized (line 189). If any part of the initialization fails, a null IvP function is returned (line 180, 196).
Listing 1.7 - BHV_SimpleWaypoint.cpp - the buildFunctionWithReflector() implementation.
175 //----------------------------------------------------------- 176 // Procedure: buildFunctionWithReflector 177 178 IvPFunction *BHV_SimpleWaypoint::buildFunctionWithReflector() 179 { 180 IvPFunction *ivp_function = 0; 181 182 bool ok = true; 183 AOF_SimpleWaypoint aof_wpt(m_domain); 184 ok = ok && aof_wpt.setParam("desired_speed", m_desired_speed); 185 ok = ok && aof_wpt.setParam("osx", m_osx); 186 ok = ok && aof_wpt.setParam("osy", m_osy); 187 ok = ok && aof_wpt.setParam("ptx", m_nextpt.x()); 188 ok = ok && aof_wpt.setParam("pty", m_nextpt.y()); 189 ok = ok && aof_wpt.initialize(); 190 if(ok) { 191 OF_Reflector reflector(&aof_wpt); 192 reflector.create(1000); 193 ivp_function = reflector.extractIvPFunction(); 194 } 195 196 return(ivp_function); 197 }
The Reflector tool does its work (lines 191-193) after it has been determined that a proper instance of the underlying function, AOF_SimpleWaypoint, has been created and initialized. The Reflector tool has several options for creating a piecewise defined IvP function, described later in Sections ??? and ???. The simplest method is to specify the number of pieces desired in the piecewise function, in this case 1000 pieces were requested, on line 192. After creation, the IvP function is extracted from the Reflector (line 193), and returned (line 196).
An example of the IvP function created with the Reflector is shown in . The function represents a preference for maneuvers that bring the vehicle toward the waypoint at a desired speed. The values of off-peak areas are evaluated based on (a) the rate of closure, (b) the rate of detour, and (c) the deviation from the desired speed. For this function generated by the Reflector, and the particular underlying function, it is not possible to generate a function of equal form using the ZAIC tools.
Figure 1.5: An IvP function created with the Reflector tool: The function represents a preference for maneuvers that bring the vehicle toward the waypoint at a desired speed. The values of off-peak areas are evaluated based on (a) the rate of closure, (b) the rate of detour, and (c) the deviation from the desired speed. Decisions of increasing speed are represented by points on the function radially farther from the center.
1.3 Running an Example Mission with the SimpleWaypoint Behavior [top]
An example mission file, alder.moos, and behavior file, alder.bhv, have been configured to demonstrate the usage of the SimpleWaypoint behavior. The files may be found in the moos-ivp-extend tree. Refer back to Section ??? for information on obtaining this tree from the web. The example mission with the SimpleWaypoint behavior is called the Alder mission and is found by:
$ cd moos-ivp-extend/missions/alder $ ls $ README alder.bhv alder.moos
The behavior file is given in below. The SimpleWaypoint behavior is used twice. It is used to transit to a point and then to return to the starting point. The transiting use of the behavior is configured in lines 7-20, and the returning use of the behavior in lines 23-35.
Listing 1.8 - The alder.bhv file - For running the Alder example mission.
1 //-------- FILE: alder.bhv ------------- 2 3 initialize DEPLOY = false 5 initialize RETURN = false 6 7 //---------------------------------------------- 8 Behavior = BHV_SimpleWaypoint 9 { 10 name = transit_to_point 11 pwt = 100 12 condition = RETURN = false 13 condition = DEPLOY = true 14 endflag = RETURN = true 15 16 speed = 2.0 // meters per second 17 radius = 8.0 18 ptx = 60 19 pty = -40 20 ipf_type = zaic 21 } 22 23 //---------------------------------------------- 24 Behavior = BHV_SimpleWaypoint 25 { 26 name = waypt_return 27 pwt = 100 28 condition = RETURN = true 29 condition = DEPLOY = true 30 31 speed = 2.0 32 radius = 8.0 33 ptx = 0 34 pty = 0 35 ipf_type = reflector 36 }
Both behaviors are idle upon startup. Presumably the transit behavior is activated first by setting DEPLOY=true, and the second instance of the behavior is activated when the transit behavior completes and sets its endflag. The alder.moos file is not discussed here, but may be examined in the tree.
The example mission may be started by:
$ cd moos-ivp-extend/missions/alder $ pAntler alder.moos
The pMarineViewer window should launch, and look similar to image in . After clicking on the DEPLOY button in the lower right corner, the transiting instance of the SimpleWaypoint behavior becomes active and the vehicle begins to form a track to the waypoint as shown. Clicking on the DEPLOY button initiates a MOOS poke on the MOOSDB connected to both the pMarineViewer, and pHelmIvP application.
Figure 1.6: The SimpleWaypoint behavior in action: After the user clicks on the DEPLOY button, the condition for the transiting SimpleWaypoint behavior is satisfied (line 13 in ).
Figure 1.7: The SimpleWaypoint behavior in action: After the vehicle has reached the waypoint prescribed in the transiting instance of the SimpleWaypoint behavior, the second instance of the SimpleWaypoint behavior, returning to the start point, becomes active.
Document Maintained by: mikerb@mit.edu
Page built from LaTeX source using texwiki, developed at MIT. Errata to issues@moos-ivp.org. Get PDF