简述

==注:本文章是基于官网的文档(MOOS-IvP : Helm - Cover browse (mit.edu))进行了简单的机翻,主要用于学习该仿真系统,文章中多少存在一些错误,请指出。==

2.4发布-订阅中间件设计思想与MOOS

星形拓扑通讯机制,使用发布订阅的方式进行。

2.5基于行为的控制设计思想与Ivp Helm

Ivp Behavior 为用户的使命行为,例如避障,速度控制,搜索区域

Ivp Helm 用于调节个行为,哪些是活性的,哪些是非活性的。通过结合ivp function ,ivp solver进行协调多个冲突行为,将决策输出到MOOSDB。

3.4 MOOS应用程序中的重载函数


MOOS应用程序基类的关键虚函数:在从CMOOSApp派生的类上调用Run()后的执行流。滚动条指示CMOOSApp功能的用户将在哪里编写新代码,以实现新应用程序所需的任何内容。

3.4.1 The Iterate() Method

通过在一 个新的派生类中重写 CMOOSApp :: Iterate ( )函数 ,作者创建了一个函数,可以从该 函数中编排应用程序要执行的工作 。。SetAppFreq ( ) 方法 或 通过在任务文件中指定AppTick 参数调用 Iterate ()的 速率 。请 注意 , 请求的频率指定了调用 Iterate ( )的 最 大 频率 - 它 并不保证它 将以请求的速率被调用 。例如 ,如果您在 Iterate ( ) 中编写需要1 秒才能 完成的 代码 , 则无法以超过 1Hz 的 频率调用此 方法 。

3.4.2 The OnNewMail() Method

就在调用Iterate()之前,CMOOSApp基类确定是否存在新邮件,如上所述,某个其他进程是否已经发布了客户机先前已经注册的数据。如果新邮件正在等待,CMOOSApp基类将调OnNewMail()虚拟函数,该函数通常由应用程序重载。邮件以CMOOSMsg对象列表的形式到达(请参见表1)。程序员可以自由地遍历这个集合,检查数据是谁发送的,它属于什么,它有多老,它是字符串还是数字数据,并相应地对数据进行操作或处理。在MOOS的最新版本中,可以直接快速地调用OnNewMail(),以响应后端通信线程接收到的新邮件。

3.4.3 The OnStartUp() Method

OnStartUp()函数是在应用程序进入它自己的forever循环之前调用的。这是实现应用程序初始化代码的应用程序,特别是从文件中读取配置参数。

3.6使用Antler启动MOOS应用程序组

Antler提供了一种简单而紧凑的方式来启动由几个MOOS进程组成的MOOS使命,MOOS社区。例如,

3.7确定MOOSDB的范围和戳

重要的调试工具。
确定MOOSDB范围的工具:

- uMS -一种基于GUI的工具,用FLTK编写

- uXMS --一种基于终端的工具

  • uHelmScope-一个基于终端的工具,专门用于显示正在运行的helm实例的信息,但它也包含一个类似于uXMS的通用作用域实用程序。
    戳MOOSDB的工具:
  • uMS -,上面列出的基于GUI的范围界定工具也提供了一种戳的方法。。
  • uPokeDB --一个轻量级的命令行工具,用于插入一个或多个变量值对,在退出之前,可以选择插入变量之前和之后的值。
  • pMarineViewer -一个基于GUI的工具,主要用于在Geo显示器上渲染2D空间中的车辆路径,但也可以配置为使用与显示器上的按钮相连的变量值对来戳DB。
  • uTimerScript -允许用户编写一组预先配置的戳到MOOSDB的脚本,脚本中的每个条目都在指定的时间后发生。脚本可能已暂停或快进。事件也可以配置为随机值,并在选定的时间窗口内随机发生。
  • uTermCommand --一个基于终端的工具,用于使用预先定义的变量值对插入数据库。用户可以配置工具关联别名(短至单个字符),以快速插入数据库。
  • iRemote -一种基于终端的工具,用于远程控制运行MOOS的机器人平台。它可以配置为将预先定义的可变值拨键与键盘上的任何未映射键相关联。

3.9面向公众的MOOS应用程序

3.9.1 牛津 MOOS 模块

  • pAntler:用于在给定使命文件的情况下启动一组MOOS进程。
  • pShare:一个允许消息在社区之间传递的工具,它允许在社区之间传递消息时对消息进行重命名
  • pLogger:用于记录MOOS会话活动的记录器。它可以配置为记录任意数量MOOS变量的一部分或所有发布。
  • pScheduler:用于生成和响应由MOOS社区中的进程发送到MOOSDB的消息。
  • uMS:基于GUI的MOOS范围,用于监控一个或多个MOOSDB。
  • uPlayback:一个基于FLTK的跨平台GUI应用程序,可以加载日志文件并将其回放到MOOS社区中,就好像数据的发起者实际上正在运行并发出通知一样。
  • iMatlab:一个允许Matlab加入MOOS社区的应用程序–即使只是为了监听和渲染传感器数据。它允许连接到MOOSDB和访问本地串行端口。
  • iRemote:一种基于终端的工具,用于远程控制运行MOOS的机器人平台。它可以配置为将预先定义的可变值拨键与键盘上的任何未映射键相关联。
  • uMVS:一种多艇AUV模拟器,能够模拟任意数量的艇以及艇与声应答器之间的声测距。

3.9.2使命监控模块

  • pMarineViewer:用于渲染车辆操作区域中的事件的GUI工具。它反复更新来自传入节点报告的车辆位置,并将渲染从其他MOOS应用程序发布的几种几何类型。查看器还可以基于用户配置的键盘或鼠标事件向MOOSDB发布消息。
  • uHelmScope:基于终端的(非GUI)作用域到正在运行的IvP Helm进程和关键MOOS变量。它向MOOSDB提供行为摘要、活动状态和最近的行为帖子。一个非常有用的工具,用于调试舵异常。
  • uXMS:一个基于终端(非GUI)的MOOSDB作用域工具用户可以通过在命令行或MOOS配置块中明确命名变量,精确配置他们希望作用域的变量集。变量集也可以通过命名一个或多个MOOS进程来配置,这些进程发布的所有变量都将在这些进程上起作用。用户还可以限定单个变量的历史记录。
  • uProcessWatch:此应用程序监视监视列表上MOOS应用程序的存在。如果发现一个或多个不存在,则将在MOOS变量PROC WATCH SUMMARY上注明。uProcessWatch支持appcast,将生成一个简洁的表格摘要,其中包含受监视的进程以及进程本身报告的CPU负载。观察列表中的项目可在配置中明确命名,或从moos或DB客户列表中推断。如果需要,可以从监视列表中排除应用程序。
  • uMAC:uMAC应用程序是用于监控AppCast的实用程序。它在终端窗口中启动和运行,并将解析在其自己的MOOS社区或桥接或共享到本地MOOSDB的其他MOOS社区中生成的应用程序。与其他appcast监控工具相比,uMAC的主要优势在于用户可以通过ssh远程登录车辆,并在终端本地启动uMAC。参见uMAC的文档,
  • uMACView:一个GUI工具,用于可视化地监控应用程序。它将解析在其自己的MOOS社区内生成的应用程序,或来自桥接或共享到本地MOOSDB的其他MOOS社区的应用程
  • pMarineViewer内置的appcast查看功能几乎相同。它旨在作为非pMarineViewer用户appcast查看器。

3.9.3使命执行模块

  • pNodeReporter:一种工具,用于收集节点信息,例如当前车辆位置、轨迹和类型,并将其张贴在单个报告中,以便在车辆之间共享或发送到岸上显示器。
  • pBasicContactMgr:联系管理器处理其附近的其他已知车辆。它处理可能经由传感器应用或通过通信链路接收的传入报告。它至少会将摘要报告发布到MOOSDB,但也可以配置为发布包含用户配置的关于一个或多个联系人的内容的警报。可与Helm 结合使用,以产生与接触相关的行为,用于避免碰撞、跟踪等。
  • pEchoVar:订阅变量并以不同名称重新发布的工具。它也可用于从由相互分离的参数值对组成的字符串出版物中提取某些字段,使用不同的参数发布新字符串。
  • pSearchGrid::一种应用程序,用于存储在运行区域内定义的二维网格中的车辆位置历史。

3.9.4使命模拟模块

  • uSimMarine:一种简单的3D车辆模拟器,其基于当前的致动器值和先前的车辆状态来更新车辆状态、位置和轨迹。
  • uSimCurrent:一个模拟水流效果的简单应用程序。根据来自给定文件的本地当前信息,它重复读取车辆的当前位置并发布漂移矢量,推测由uSimMarine使用。

3.9.5用于插入MOOSDB的模块

  • uPokeDB:一个命令行工具,用于使用命令行上提供的变量值对来插入MOOSDB。它通过命令行上提供的使命文件或命令行上给定的IP地址和端口号找到MOOSDB。它将连接到数据库,显示插入前的值,插入数据库,并等待来自数据库的邮件确认插入结果 。
  • uTimerScript:允许用户将一组预先配置的插入脚本写入MOOSDB,脚本中的每个条目都在指定时间后发生。脚本可能已暂停或快进。事件也可以配置为随机值,并在选定的时间窗口内随机发生。
  • uTermCommand::一个终端应用程序,用于使用预定义的变量值对戳MOOSDB。唯一密钥可以与每个扑克相关联。

3.9.6 Alog工具箱

  • alogscan:一个命令行工具,用于报告给定MOOS .alog文件的内容。
  • alogclip:一个命令行工具,通过删除给定时间窗口之外的条目,从给定的.alog文件创建一个新的MOOS .alog文件。
  • loggrep:一个命令行工具,通过只保留给定的.alog文件中的给定MOOS变量或源文件来创建新的MOOS .alog文件。
  • alogrm:一个命令行工具,通过从给定的.alog文件中删除给定的MOOS变量或源文件来创建新的MOOS .alog文件。
  • alogview:一种图形用户界面工具,用于通过在操作区域绘制一个或多个飞行器轨迹来分析飞行器使命,同时查看模拟文件中任何数值的绘图。

3.9.7 uField工具箱

  • pHostInfo::自动检测车辆的主机信息,包括IP地址、MOOSDB使用的端口、本地pShare用于UDP侦听的端口以及本地MOOSDB的社区名称。发布这些信息以促进自动车辆间通信,尤其是在本地IP地址随DHCP更改的多车辆情况下。
  • uFldNodeBroker:通常在车辆或多车辆环境中的模拟车辆上运行。用于通过发送有关车辆的本地信息(如IP地址、社区名称和pShare用于传入UDP消息的端口号)与岸上社区建立连接。据推测,岸上社区使用此信息来了解向车辆发送传出UDP消息的位置。
  • uFldShoreBroker:通常在岸边社区运行。从远程车辆获取报告,描述如何联系到它们。将注册请求发布到shoreise pShare,以将用户提供的变量列表连接到车辆。
  • uFldNodeComms:用于管理车辆之间通信的岸上工具。它根据输入节点报告了解所有车辆位置。通信可基于车辆范围、消息频率或消息大小而受到限制。消息也可以基于团队成员身份被阻止。
  • uFldMessageHandler::一种用于处理来自其他节点的传入消息的工具。消息是一个字符串,其中包含消息的源和目标以及MOOS变量和值。这个应用程序只是将消息的变量-值对内容发布到本地MOOSDB。
  • uFldScope:通常在岸边社区运行。从用户配置的一组传入报告中获取信息,并将关键信息解析为简明的表格格式。报告可以是以逗号分隔的参数值对形式的任何报告。
  • uFldPathCheck:通常在岸边社区运行。从远程车辆获取节点报告,计算当前车辆速度和总行驶距离,并将其发布在两个简明报告中。里程计数可能会被其他应用程序重置为零。
  • uFldHazardSensor:通常在岸边社区运行。配置一组具有给定x,y位置和分类(危险或益处)的对象。传感器模拟器接收来自远程车辆的一系列请求。当传感器确定一个物体位于请求车辆的传感器范围内时,它可能返回或不返回该物体的传感器检测报告,也可能返回适当的分类。接受检测和正确分类的几率取决于传感器配置和用户在主要ROC曲线上对P D/P FA的偏好。
  • uFldHazardMetric:一种用于对传入危险报告进行分级的应用程序,可能uFldHazardSensor用户在探索模拟危险现场后生成。
  • uFldHazardMgr:uFldHazardMgr是一款稻草人MOOS应用程序,用于在自主搜索使命过程中管理危险传感器信息并生成危险报告。
  • uFldBeaconRangeSensor: 通常在岸边社区运行。配置一个或多个信标,信标位置已知。从远程无人机获取距离请求,并返回一个距离报告,指出无人机到附近信标的距离。距离请求可能应答也可能不应答,这取决于到信标的距离。报告可能添加了噪声,可能包含也可能不包含信标ID。

- uFldContactRangeSensor:通常在岸边社区运行。接收远程车辆的报告,记录他们的位置。接受远程车辆的距离请求,并返回一个距离报告,指示该车辆与附近车辆的距离。根据车辆之间的距离,可能会或可能不会对距离请求做出响应。报告的范围值中也可能添加了噪声。‘

4.3深入了解Alpha示例使命中的MOOS应用程序

4.3.2 pMarinePID应用程序

pMarinePID应用程序实现了一个简单的PID控制器,该控制器根据来自舵的输入产生适合于执行器控制的值。在模拟中,输出由车辆模拟器而不是车辆执行器消耗。简而言之:pMarinePID应用程序通常从pHelmIvP获取其信息;生成uSimMarine或执行器MOOS进程在未运行模拟时消耗的信息。
订阅:DESIRED HEADING, DESIRED SPEED.
发布到:DESIRED RUDDER, DESIRED THRUST.。

4.3.3 uSimMarine应用程序和配置块

uSimMarine应用程序是一个非常简单的车辆模拟器,它考虑了当前的车辆姿态和执行器命令,并产生一个新的车辆姿态。它可以用一个给定的姿势初始化。简而言之:uSimMarine应用程序通常从pMarinePID获取其信息;在uSimMarine的下一次迭代中生成由pNodeReporter及其自身使用的信息。
Subcribes to: DESIRED RUDDER, DESIRED THRUST, NAV X, NAV Y, NAV SPEED, NAV HEADING.
Publishes to: NAV X, NAV Y, NAV HEADING, NAV SPEED.

4.3.4 pNodeReporter应用程序和配置块

自动化信息系统(AIS)在许多较大的船舶上是常见的,并且包括转发器和接收器,该接收器向附近装备有AIS接收器的其它船舶广播自己的交通工具ID和姿态。它周期性地收集所有最新的姿态元素,纬度和经度位置以及最新测量的航向和速度,并将其打包成要广播的单个更新。该MOOS过程通过订阅MOOSDB来收集姿态信息,包括NAV X、NAV Y、NAV HEADING、NAV SPEED和NAV DEPTH,并将其打包到称为NODE REPORT LOCAL的单个MOOS变量中。该变量又可以被订阅到连接到充当AIS应答器的实际串行设备的另一个MOOS进程。出于我们的目的,pMarineViewer也订阅了此变量,用于渲染车辆姿势序列。
简而言之:pNodeReporter应用程序通常从uSimMarine或其他车载导航系统(如GPS或罗盘)获取信息;生成pMarineViewer使用的信息以及在其他车辆或模拟车辆中运行的pHelmIvP实例。
Subcribes to: NAV X, NAV Y, NAV SPEED, NAV HEADING.

Publishes to: NODE REPORT LOCAL

4.3.5 pMarineViewer应用程序和配置块

pMarineViewer是一个MOOS进程,订阅MOOS变量NODE REPORT LOCA L和NODE REPORT(包含车辆ID、姿态和时间戳)。它渲染更新的车辆位置。它是一个多线程进程,既允许与MOOS通信,又允许用户平移和缩放,以及与GUI交互。它对于车辆运行不是必需的,但对于目视确认一切按计划进行是必需的。
简而言之:pMarineViewer应用程序通常从pNodeReporter和pHelmIvP获取信息;当pHelmIvP配置为具有命令和控制挂接时(如本例所示),生成pHelmIvP使用的信息。
Subcribes to: NODE REPORT, NODE REPORT LOCAL, VIEW POINT, VIEW SEGLIST, VIEW POLYGON, VIEW MARKER.

Publishes to: Depends on configuration, but in this example: DEPLOY, RETURN

5 IvP Helm作为MOOS应用程序

IvP Helm作为名为pHelmIvP的MOOS模块实现。从表面上看,它类似于任何其他MOOS应用程序-它作为一个单独的进程运行,该进程通过发布-订阅接口连接到正在运行的MOOSDB进程


舵具有两个信息性的高级状态描述,舵状态和全停状态,其可以与汽车的操作相比较。启动pHelmIvP MOOS过程类似于打开汽车引擎。把舵盘放在驾驶模式就像把汽车从“停车”换到“驾驶”。而全停状态是指轿厢是否正在停止。类比总结如下。

5.2 The Helm State

与舵的最高级别接口反映在舵状态中。舵的状态可能有两个值之一,即驻车或驾驶(除非使用第5.7节中描述的备用舵)。在驾驶模式中,舵可能处于执行使命的过程中。在停车模式中,舵盘等待,可能是因为它被要求等待,但也可能是因为舵盘可能已经注意到某些错误(产生全停),并随后将其自身置于停车模式,等待返回驱动状态的机会。
在任何情况下,监视helm状态的最佳方式是在由helm本身发布的MOOS变量IVPHELM STATE上设置范围,或者使用uHelmScope工具。

5.4 pHelmIvP MOOS配置块的参数

  • allow park:如果为false,舵不能置于PARK。此参数不是必需的。
  • behaviors:行为配置文件的名称和位置。此参数不是必需的,但通常会使用。从技术上讲,可以从命令行启动头盔,并在命令行上提供行为文件。
  • ivp behavior dir:用于查找动态加载的行为的目录。此参数不是必需的,因为也可以使用shell环境变量处理目录信息。
  • community:全局MOOS参数。确定所有权名称。该参数是强制性的,但它在舵配置块之外提供,并由其他应用程序使用。
  • park on allstop:如果真的舵会停在全停。此参数不是必需的,默认值为false。
  • domain:IvP求解器的决策空间。
  • hold on app:在helm通过行为的onHelmStart()函数调用发布帖子之前要等待的MOOS应用列表。
  • ok skew:传入邮件在因太旧而被拒绝之前的时间容限(秒)。
  • other override var: 该参数指定了一个附加的MOOS变量,用作MOOS MANUAL OVERIDE。
  • start in drive: 确定启动时舵是否处于超控模式。此参数不是必需的。预设值为false。
  • helm prefix::为所有DESIRED * 舵输出增加一个前缀。例如,helm前缀=FOO将导致FOO DESIRED SPEED等。
  • verbose:确定终端输出的详细程度-安静、简洁或详细。

5.6 IvP Helm的发布和订阅

5.6.1 IvP Helm发布的变量

  • IVPHELM SUMMARY::在helm的每次迭代上生成,供uHelmScope应用程序使用,。它包含有关当前helm迭代的信息,包括创建的IvP函数的数量、创建时间、求解时间、哪些行为处于活动、运行、空闲状态以及迭代期间最终产生的决策。摘要不包括每个摘要中的每个组件。从当前摘要中删除自上一个摘要以来值未更改的组件。这是出于减少helm日志文件占用空间的目的。

  • IVPHELM STATEVARS:由helm定期生成,供uHelmScope应用程序使用。它包含一个逗号分隔的MOOS变量列表,这些变量包含在任何行为的前提条件中,即:影响运行状态行为变量

  • ·IVPHELM DOMAIN:由helm在启动时生成一次,供uHelmScope应用程序使用。它包含头盔使用的IvP域的规范。

  • IVPHELM MODESET:由helm在启动时生成一次,供uHelmScope应用程序使用。它包含了头盔所使用的分层模式声明(如有)的规范。

  • IVPHELM STATE::由helm在pHelmIvP MOOS应用程序的每次迭代上编写,无论helm是否处于DRIVE状态。它可以是“DRIVE”(行驶)或“PARK”(驻车)。这是推荐的MOOS变量,被视为舵的“心跳”指示器。

  • HELM IPF COUNT::在helm的每次迭代中生成。它包含当前迭代中求解器所涉及的IvP函数的数量。

  • CREATE CPU:当前迭代中所有行为用于构造IvP函数的总CPU时间(秒)。

  • LOOP CPU:IvP解算器在当前舵迭代中使用的CPU时间(秒)。

  • BHV IPF:掌舵人将为当前迭代中的每个活动行为发布此变量。它包含由行为产生的IvP函数的字符串表示形式。它用于uFunctionVis应用程序的可视化,以及日志记录和稍后的回放和分析。

  • PLOGGER CMD:该变量以以下值发布,以确保pLogger应用程序记录.bhv文件沿着其他数据日志文件和.moos文件。“复制_文件_请求=文件名.bhv”·所需 :舵面配置中提供的IvPD域中的每个决策变量都有一个单独的位置,该位置由DESIRED(期望速度)预先确定。一个例外是,可变课程将转换为标题的传统原因。

  • BHV WARNING::虽然此变量可能永远不会发布,但它是行为发布警告时使用的默认MOOS变量。警告可能无害,但值得考虑。

  • BHV ERROR:虽然这个变量可能永远不会被发布,但它是默认的MOOS变量,当一个行为发布它认为是致命错误的错误时,它会被使用一个头盔会解释为生成ALL-STOP等效命令的请求。

5.6.2 IvP Helm订阅的变量

  • MOOS MANUAL OVERIDE:当设置为true时(通常由第三方应用程序(如iRemote)或从命令和控制通信中设置),头盔可能会放弃控制。如果舵配置为active start = true,它将不会放弃控制(这可以更改)。
  • HELM VERBOSE:影响舵产生的控制台输出。法律的值为verbose、terse或quiet。
  • HELM MAP CLEAR:收到后,头盔会清除用于抑制重复发布的内部地图。

6 IvP Helm Autonomy

自主舵主要是决策的引擎。IvP Helm使用基于行为的架构来组织其决策,其独特之处在于解决竞争行为之间的竞争–它使用称为区间规划的数学规划模型对它们的集体输出进行多目标优化。这里描述了IvP Helm体系结构,并给出了一组行为和一组使命目标的配置方法。

6.2 Inside the Helm - A Look at the Helm Iterate Loop

pHelmIvP迭代循环:(1)从MOOSDB读取邮件。它被解析并存储在本地缓冲器中以可用于行为,(2)如果在使命行为文件中存在任何模式声明,则在该步骤评估它们。(3)每个行为被查询其贡献,并且可以产生IvP函数和变量-值对的列表以在迭代结束时被发布到MOOSDB,(4)目标函数被解析以产生动作,该动作可被表达为变量-值对的集合,(5)所有变量-值对被发布到MOOSDB以供其他MOOS过程使用。

6.3 Mission Behavior Files

舵主要通过一个或多个任务行为文件(通常带有a .bhv )配置用于特定使命。行为文件有三种类型的条目,通常但不一定保存在三个不同的部分(1)变量初始化,(2)行为配置,(3)层次模式声明。

6.5.3 Behavior Run States


行为状态:在helm Iterate()循环的任何给定迭代中,行为可能处于这四种状态之一。通过检查存储在舵的信息缓冲器中的本地MOOS变量来确定状态。

  • Idle:如果行为没有完成,并且没有满足6.5.1节中描述的运行条件,则该行为是空闲的。helm将调用空闲行为的onIdleState()函数。
  • Running:如果一个行为已经满足运行条件,但还没有完成,那么它就是在运行。操控将调用运行行为的onRunState()函数,从而为行为提供贡献目标函数的机会。
  • Active:如果一个行为正在运行,并且在被提示时确实产生了一个目标函数,那么它就是主动的。运行行为可能不活动的原因有很多。例如,避免碰撞的行为,其中行为的对象是足够远的。
  • completed:当行为本身决定了它是完成的时候,行为就是完成的。实现这一点取决于行为作者,有些行为可能永远不会完成。函数setComplete()通常在行为超类级别定义,供行为作者调用。这提供了一些在完成时要采取的标准步骤,例如张贴结束标志,如下面第6.5.4节所述。一旦行为处于完成状态,它将永久保持该状态。所有行为都有一个定义的持续时间参数,允许在需要时将其配置为超时。发生超时时,行为状态将设置为完成。

6.5.4行为标志和行为消息

  • endflag:当行为进入完成状态时,会发布一次endflag。表示endflag的变量-值对在行为文件的endflag参数中给出。可以为一个行为配置多个结束标志。

- idleflag:当行为进入空闲状态时,helm会发布一个idleflag。表示空闲标志的变量值对在行为文件的idleflag参数中给出。可以为一个行为配置多个空闲标志。·

  • runflag:当行为从空闲状态进入运行状态时,helm会发布一个runflag。当没有传递idleflag时,会正确传递runflag。表示运行标志的变量-值对在行为文件的runflag参数中给出。可以为一个行为配置多个运行标志。
  • activeflag:当行为进入活动状态时,舵会发出活动标志。表示活动标志的变量值对在行为文件的活动标志参数中给出。可以为一个行为配置多个活动标志。
  • inactiveflag:当行为进入非活动状态时,舵会发出非活动状态标志。表示非活动标志的变量值对在行为文件的非活动标志参数中给出。可以为一个行为配置多个非活动标志。
  • spawnflag:当模板化行为产生时,helm会发布一个spawnflag。示例包括碰撞和避障行为。表示spawflag的变量值对在behavior文件的spawnflag参数中给出。可以为一个行为配置多个spawnflag 标志。

7 Properties of Helm Behaviors

本节的目标是描述所有IvP Helm行为的通用属性,描述如何为第三方行为重载标准函数,并提供一个详细的简单行为示例。

7.1简要概述

行为被实现为C++类,其中helm在运行时具有一个或多个实例,每个实例具有唯一的描述符。特定行为的属性和实现的函数部分派生自IvPBhavior超类,如图所示。派生类的is-a关系提供了一种代码重用的形式,以及一个用于构造具有行为的使命文件的公共接口。
![[Pasted image 20221121184503.png]]
IvPBhavior类提供了五个虚函数,它们通常在特定行为实现中重载:

- setParam()函数的作用是:处理参数-值对以配置行为的不同于其超类的唯一属性

  • onRunState()函数:行为实现的主体,当行为满足其运行条件时执行,输出是一个目标函数和一个可能为空的变量值对集,用于发布到MOOSDB。
  • onIdleState()函数:行为在未满足其运行条件时执行的操作。它可能涉及更新内部状态历史、生成变量-值对以发布到MOOSDB,或者完全不涉及。
  • onIdleToRunState()函数:在从空闲状态转换到运行状态时由helm调用一次(与在行为满足其条件的每个helm迭代上调用的onRunState()函数相比)。
  • onRunToIdleState()函数:在从运行状态转换到空闲状态时由helm调用一次(相比之下,onIdleState()函数在行为不满足其条件的每个helm迭代时调用)。

7.2.1全套一般行为参数的总结

  • name:行为 的 名称 - 在 所有 行为 之间 应该 是 唯一 的 。
  • priority:生成的目标函数的优先级权重。预设值为100。行为还可以被实现为根据关于世界的信息来确定其自身的优先权权重。
  • duration:行为在宣告完成之前保持执行的时间(秒)。如果未提供持续时间值,则行为永远不会超时。一旦行为第一次满足其运行条件(变为非空闲),时钟就开始计时。如果行为在运行状态和空闲状态之间切换,则即使在空闲期间,时钟也会保持滴答作响。
  • duration status:如果设置了持续时间参数,则可以通过命名持续时间状态变量来发布剩余的持续时间(以秒为单位)。仅当行为处于运行状态时,才会更新/发布此变量。
  • duration reset:此参数采用一个变量对,例如MY RESET=true。如果设置了持续时间参数,则在将变量以指定值发送到MOOSDB时,将重置持续时间时钟。每次注意到这样的帖子时,持续时间时钟被重置。
  • post mapping:此参数采用逗号分隔对,如WPT STAT、WAYPT STATUS,其中左侧值是通常由行为发布的变量,右侧值是要使用的替代变量名。
  • duration idle decay:如果此参数为假,则当车辆处于怠速状态时,持续时间时钟暂停。预设值为true。
  • condition:此参数指定要激活行为必须满足的条件。在每个控制循环迭代开始时检查每个行为的条件。条件基于当前的MOOS变量,例如STATE = normal或(K〈4)。为方便起见,可提供一个以上的条件,将其共同视为单个合取条件。舵会自动订阅任何条件变量。
  • runflag:此参数指定当行为满足其处于运行状态的所有条件时要发布的变量和值。只有在上一个helm迭代中的行为不处于运行状态时,才会发布该消息。它是一个等间距的对,例如TRANSITING=true。可以提供多于一个的标志。这些可用于满足或阻止其他行为的条件。
  • idleflag:此参数指定行为处于空闲状态时要发布的变量和值。只有在上一个helm迭代中的行为不处于空闲状态时,才会发布此消息。它是一个等间距的对,例如WAITING=true。可以提供多于一个的标志。这些可用于满足或阻止其他行为的条件。
  • activeflag:此参数指定行为处于活动状态时要发布的变量和值。有只有在上一个helm迭代中的行为不处于活动状态时,才会发布该消息。它是一个等间距的对,例如TRANSITING=true。可以提供多于一个的标志。这些可用于满足或阻止其他行为的条件。
  • inactiveflag:此参数指定行为未处于活动状态时要发布的变量和值。只有在上一个helm迭代中的行为处于活动状态时,才会发布该行为。它是一个等间距的对,例如OUT OF RANGE=true。用户可以在行为配置中艾德多个标志。这些可用于满足或阻止其他行为的条件。
  • endflag:此参数指定当行为将completed状态变量设置为true时要发布的变量和值。导致完成的环境是个体行为所特有的。但是,如果行为指定了持续时间,则在超过持续时间时,完成标志将设置为真。此参数的值是一个相等分隔的值对,例如ARRIVED HOME=true。一旦某个行为的完成标志被设置为真,它将在此后保持不活动状态,无论未来发生什么事件,除非舵完全重新启动。
  • updates:该参数指定了一个变量,在初始化行为并在舵启动时配置后,从该变量读取行为配置参数的更新。
  • nostarve:nostarve参数允许行为断言一个或多个MOOS变量的最大陈旧性,即,返回自上次更新变量以来的时间。
  • perpetual:将永久参数设置为true可允许行为继续运行,即使它已完成并发布了其结束标志。
  • templating:模板化参数可用于将行为规范转变成模板,用于在启动舵之后动态地产生新的行为。

7.5.1实现者调用的实用程序函数的摘要

  • void setComplete()函数:一个行为“完整”的含义在很大程度上是一个特定于个体行为的问题。当达到此状态时,可以调用setComplete()并发布结束标志,并且行为将永久进入已完成状态,除非永久参数设置为true。
  • void addInfoVars(string var names):掌舵人将仅在需要的基础上从MOOSDB注册变量,行为有义务通知掌舵人需要某些变量。可以从任何具有行为实现的位置调用addInfoVars()函数来声明所需的变量。这可以是每个变量一次调用,或者字符串参数可以是逗号分隔的变量列表。调用此函数的最常见点是在行为的构造函数中,因为所需的变量通常在实例化时已知。
  • double getBufferDoubleVal((string varname, bool& result):查询info缓冲区以获取由字符串参数命名的给定变量的最新(双精度)值。bool参数指示是否在缓冲区中找到查询的变量。更多信息请参见第7.5.2节。
  • double getBufferStringVal(字string varname, bool& result):查询info缓冲区,以获取由字符串参数命名的给定变量的最新(字符串)值。bool参数指示是否在buer中找到查询变量。
  • double getBufferCurrTime():查询信息缓冲区的当前缓冲器本地时间,相当于自启动头盔以来的持续时间(以秒为单位)。
  • vector(double) getBufferDoubleVector(string var, bool result):在info缓冲区中查询自上次迭代以来对字符串参数命名的变量(类型为double)所做的所有更改。bool参数指示是否在buer中找到查询变量。
  • void postMessage(string varname, string value, string key):在helm迭代结束时,helm可以向MOOSDB发布消息(变量值对)。行为可以通过调用postMessage()函数来请求此类发布,其中第一个参数是变量名称,第二个参数是变量值。可选的key参数与重复过滤器一起使用,默认情况下为空字符串。
  • void postMessage(string varname, double value, string key):与上述相同,但当发布的变量是double类型而不是string类型时使用。可选的key参数与重复过滤器一起使用,默认情况下为空字符串。
  • void postBoolMessage(string varname, bool value, string key):与上面的相同,除了当发送的变量是布尔值而不是字符串时使用。可选的key参数与重复过滤器一起使用,默认情况下为空字符串。
  • void postIntMessage(string varname, double value, string key):与上面的postMessage(string,double)相同,不同之处在于数值输出被舍入为最接近的整数。这一点,再加上掌舵人对重复过滤器的使用,可以减少MOOSDB的帖子数量。可选的key参数与重复过滤器一起使用,默认情况下为空字符串。
  • void postWMessage(string warning msg):与postMessage()函数相同,不同之处在于变量名称自动设置为BHV WARNING。为方便呼叫者和统一监控警告而提供。
  • void postEMessage(string error msg):类似于postWMessage()函数,不同之处在于变量名为BHV ERROR。这种称呼是对更严重的问题所注意到的行为。它还导致内部状态ok位被翻转,这导致舵向致动器发布全停值。
  • void postRepeatableMessage(string varname, string value):一个便利功能。发布postRepeatableMessage(“FOO”,“bar”)等同于发布postMessage(“FOO”,“bar”,“可重复”)。
  • void postRepeatableMessage(string varname, double value):一个便利功能。发布postRepeatableMessage(“FOO”,100)等同于发布postMessage(“FOO”,100,“可重复”)。

9 The Waypoint Behavior

路点行为用于过渡到x-y平面中的一组指定路点。主要参数是航路点组。其他关键参数是每个航路点周围的内半径和外半径,其确定已经满足移动到下一个航路点的条件意味着什么。
![[Pasted image 20221121211404.png]]
路点行为:路点行为的基本目的是遍历一组路点。指定捕获半径以定义已到达路点的含义,指定非单调半径以定义“足够接近”的含义,如果注意到向路点前进会降级。

9.1 Configuration Parameters

9.5 The capture radius and slip radius Parameters


捕获半径和滑移半径:(a)通过实现小于捕获半径的接近度而成功到达航路点。(b)错过的路点可能导致车辆循环返回以再次尝试。©错过了航路点,但当到航路点的距离开始增加且车辆在滑动半径内时,无论如何都宣布到达。

9.7使用引导、引导阻尼器和引导启动参数跟踪线


轨迹线模式:当处于轨迹线模式时,车辆转向轨迹线上的一个点,而不是简单地转向下一个航路点。转向点由导程参数确定。这是从垂直交叉点到下一个航路点的距离。

9.10 The Objective Function Produced by the Waypoint Behavior


航路点目标函数:由航路点行为产生的目标函数在可能的航向和速度值上定义。这里描述的是一个目标函数,它有利于操纵到距离当前车辆位置270度的路点,并有利于接近车辆可行驶速度的中间范围的速度。更高的速度表示为径向远离中心。