当前位置:首页 >> 机械/仪表 >>

浙江大学RoboCup校内赛技术手册


浙江大学RoboCup校内赛技术手册 校内赛技术手册 浙江大学 校内赛技术
更新时间:2005-9-1 更新时间:

1. 介绍
我们现在处于RoboCup的初级阶段,还有半个世纪的路要走,那时我们可以“建立一支仿人 机器足球比赛队伍,并且战胜人类的足球世界冠军队”。这个目标带来的挑战是巨大的,而且吸 引了全世界数以百记的研究者和他们的学生

长年的投身于RoboCup。RoboCup是作为教育目标 的和应用领域相平行的一个研究挑战, 也用于激励公众对机器人技术的兴趣和人工智能的发展。 从1997年开始的每一年,世界各地的研究者聚集讨论,进行机器人的世界杯足球比赛。 本指南的目的是引导仿真组队伍的最初工作,对熟练使用者是一本对server的参考指南。 1.1 背景 Mackworth 提出了进行机器人足球比赛的想法。不幸的是,这个想法并没有得到恰当的反 响,直到Kitano, Asada, 和Kuniyoshi在日本提出名为Robot J_League的研究领域时,他们补充修 几个美国研究者对Robot J_League发生了兴趣, 于是就变成了Robot 改了这个想法。 在1993年夏, World Cup,简称为RoboCup。RoboCup有时也指RoboCup挑战或是RoboCup领域。 1995年,Kitano et al.[8]提出在1997年举行第一届机器人世界杯足球比赛和会议。RoboCup 的目标是为AI和机器人技术提供一个新的标准问题,继深蓝后AI的又一个课题。RoboCup和AI 中以前研究的问题不同,因为它致力于分布式解决方案,而不是集中式控制,而且研究的不仅 仅是AI相关的传统领域,还包括以下范围:机器人技术,社会学,实时任务的关键系统,等等。

2.0 简介
2.1 开始
这个部分快速的介绍了RoboCup仿真组的主要部分。 对于介绍的每一部分, 你都会在本手册 的以后内容得到详细的信息(如:参数配置,运行的选择项等等) 。 2.1.1Server Server是能使不同的队伍进行足球比赛的系统。因为比赛是以client/server方式进行的, 所 以 对 球 队 的 开 发 编 译 没 有 任 何 限 制。 仅 要 求 球 队 的 开 发 工 具 提 供 通 过 UDP/IP 连 接 的 client/server支持。这是因为server和每个client之间的通讯都是通过UDP/IP端口实现的。每 个client都是独立的进程, 通过给定的端口和server连接。 一支球队可以有最多11个client (或 者说是球员) 。当球员和server连接上后,所有的信息都通过这个端口传递。球员发送他们下一 步要做的动作请求给server(如踢球kick,转身turn,run等) 。Server接收到这些消息后,执 行请求,并相应的更新环境。另外,server向所有的球员提供感知sensory信息(如:关于足球, 球门和其他球员的位置可视信息) 还有相当重要的一点, 。 server是以离散的时间间隔 (或周期) 工作的实时系统。每个时间周期都有确定的分时,为了在某个周期执行,动作必须在正确的间 隔到达server。因此,缓慢的反应会对球队的性能产生很大的影响,它会造成丢失执行动作的 机会。 2.1.2Monitor Monitor是一个可视化的工具,允许人们观看比赛时server到底发生了什么事情。在monitor上 显示的信息包括比分, 球队名字, 所有球员和足球的位置。 Monitor也提供了一个很简单的server 接口。如:当两支球队都连接上后,在monitor上的“Kick-Off”按钮允许人类裁判开始比赛。 在server上进行比赛,monitor并不是必需的。如果有需要的话,可以同时和server连上很多的 monitor。

2.1.3Logplayer Logplayer记录比赛情况,是用来进行重现比赛的工具。运行server时,可以加上一些选项,那 么server就会将比赛的所有数据都存储在硬盘上。 (很像在录像机上按下录制按钮) 。然后,和 monitor连接在一起的logplayer就可被用来重现比赛。这在进行球队的分析或者发现球队的强 处和弱点时是很有用的。和录像球员差不多,logplayer也有开始play,停止stop,快进fast forwar和后退rewind按钮。而且logplayer也允许你跳到比赛的任一个周期(如你仅仅希望看到 进球部分) 。 2.2比赛规则 在比赛中,由server中的自动裁判和人类裁判来共同执行大量的规则。这节就是解释这些规则 是如何工作,它们是怎么影响比赛的。 2.2.1由自动裁判裁决的规则 开球Kick-Off 在kick off之前(比赛开始前,和进球后) ,所有的球员都必须在她自己的半场。在每次进球得分 后,比赛挂起5s时间。在这个间隔中,球员可以使用move命令移动到某点。如果在5s结束后, 球员还呆在对方的半场,裁判会把她移到她们自己半场的随机位置。 进球Goal 如果一个球队进球得分,裁判要作很多事情。首先,她向所有的球员广播进球信息。然后更新 比分,将球移到中点,并把比赛模式置为kick_off_x(x是left或right,代表左半场球队或右半场 球队) 。最后,她将比赛挂起5s,在此期间球员回到自己的半场(如在“开球Kick-Off”节所 述) 。 出界Out of Field 当足球出界时,裁判把足球放到一个合适的位置(边线,角球区或球门区)并且把比赛模式置 为界外球kick_in,角球coner_kick,或者球门球goal_kick。如果是角球的话,裁判将把足球放到 场内正确的角球区坐标(1m,1m)处。 清场Player Clearance 当比赛模式是开球kick_off,界外球kick_in,或角球corner_kick时,防守队员移出以足球为圆心, 9.15m为半径的圆形区域。被移出的球员随机放置在圆形区域的周围。如果比赛模式是越位 offside,所有的进攻球员被移回到没有越位的位置。这种情况下的进攻球员是指在越位范围内 的所 有球 员以 及位于以足 球为圆心9.15m 为半径的圆形区域内。如果比赛模 式是 球门球 goal_kick,所有的进攻球员会被移到罚球区外。当球门球发生时,进攻球员不能重新进入罚球 区。当足球被踢出罚球区后,比赛模式马上被设置为正常play_on。 比赛模式控制Play-Mode Control 当比赛模式是开球kick_off,界外球kick_in,或者角球corner_kick时,裁判在足球因为kick命令 产生移动时,马上把比赛模式设置为正常play_on。 中场时间和终场时间Half_Time and Time_Up 当上半场或下半场结束时,裁判暂时挂起比赛。每个半场的默认值是3000个仿真周期(大约5 分钟) 。 2.2.2人类裁判裁决的规则 某些故意犯规动作,如故意阻挡等,很难由裁判(referee)自动判断,因为它与球员的意图有 关。因此,server 为通过人来判断这些犯规动作提供了一种方式。人类裁判可以挂起比赛,赋

予某个球队任意球。下面简单介绍一下此类犯规动作: 1 故意包围足球(Surrouding the ball) 2 故意用多名队员阻挡球(Blocking the goal with too many players) 3 故意长时间持球(Not putting the ball into play after a given number of cycles) 4 故意阻挡其他队员的移动(Intentionally blocking the movement of other players) 5 守门员滥用 catch 命令(守门员不允许在罚球区内重复使用 kick 和 catch 命令,因为这样 为移动足球提供了安全的方式) 6 向 server 发送过多命令 Flooding the Server with Messages 每个 Client 在一个仿真周期内不能发送超过 3 或 4 个命令。过多的命令会使 server 阻塞。 如果 server 发生阻塞,将在赛后进行检查。 7 不恰当的行为 Inappropriate Behaviour 如果显而易见的, 一个球员以一种不恰当的方式干扰了比赛, 那么人类裁判可以挂起比赛, 并给对方球队一个任意球。 1. Linux 下 Server 的安装和简单使用 需要补充

2. Soccer Server 4.1 对象 Objects

UML diagram of the objects in the simulation 4.2 协议 4.2.1client 命令协议 连接,重新连接, 连接,重新连接,断开

如果 client 成功的连接或重新连接,server 将发送以下的消息:一个包括 server 参数的消息,一 个包括球员 player 参数的消息和一个包括球员类型的消息。格式如下所示。

client 控制

server 可能会返回命令的出错信息:
(error unknown command) (error illegal command form)

4.2.2client 感知协议 Client 具有听觉、see 和 sensebody 等感知信息。但是一般来说我们不需要太关心消息的格式, 因为底层代码对消息的处理已经做的比较完善了。

4.3 感知模型 每个智能体有三种不同的感知。听觉感知检测裁判发送的消息。视觉感知检测场上的可视信息, 象球员当前可视范围内的对象的距离和方向。视觉信息很象一个传感器,可以“见到”在球员 身后的附近对象。自身 body 感知检测球员的当前物理状态,象它的体力 stamina,速度 speed 和头颈角度 neck angle。这三种感知联合给智能体提供了环境的一个较好的图景。

4.3.2视觉感知模型 视觉感知报告球员当前所能看到的对象。在每个sense_step(目前等于150ms)内,视觉信 息被自动的发送到球员处。 从server发送的视觉信息遵循下面的基本格式: (see ObjName Distance Direction DistChng DirChng BodyDir HeadDir) 其中

Distance,Direction,DistChng和Dirchng按如下方式计算出来的:

其中 ( Pxt , Pyt ) 是目标的绝对位置坐标, ( Px 0 , Py 0 ) 是接收视觉信息的队员自己本身的绝对坐标,

(v xt , v yt ) 是目标的绝对速度, (v x 0 , v y 0 ) 队员自己的绝对速度。 a0 是队员所面向的绝对方向。
球员面向的绝对方向是球员的自身角度 BodyDir 和头部角度 HeadDir 的之和。另外 ( Prx , Pry ) 和

(vrx , v ry ) 表示目标的相对位置和相对速度。 (erx , ery ) 表示平行于相对位置向量的单位向量。如
果被观察者是球员的话,才会有 BodyDir 和 HeadDir,分别是被观察球员相对观察者的身体和 头部的相对角度。如果两个球员的身体都是相同的角度,那么 BodyDir 就等于零。HeadDir 也 一样。 对象(goal r)表示右半场球门线的中点。 c)是场上中心的一个虚拟标记。。。。。 (f 。。。。

对于对象(l …) ,Distance 是视角的平分线和边线的交点到球员的距离。Direction 则是到 边线的方向。

4.3.3自身感知模型Body Sensor Model 自身感知返回球员当前的物理状态。每隔sense_body_step(目前使用100ms) ,就会自动的向球 员发送自身感知信息。 自身感知消息的格式如下: (sense_body Time (view_mode ViewQuality ViewWidth) (stamina Stamina Effort) (speed AmountOfSpeed DirectionOfSpeed) (head_angle HeadDirection) (kick KickCount) (dash DashCount) (turn TurnCount) (say SayCount) (turn_neck TurnNeckCount) (catch CatchCount) (move MoveCount) (change_view ChangeViewCount))

ViewQuality的取值是high或low。(由于我们现在是完全视觉,这项可以忽略) ViewWidth取值是narrow,normal,wide。(由于我们现在是完全视觉,这项可以忽略) AmountOfSpeed是球员速度的近似值。 DirectionOfSpeed是球员速度的近似方向。 HeadDirection是球员头部的相对方向。 变量Count是由server执行的对应命令的总量。如:DashCount=134说明球员其时已经执行 了134次dash命令。

参数的意义在它们使用的场合会做出说明的。对自身感知有影响的server参数见表4.3。

4.4运动模型 在仿真周期内,对象的移动按如下公式进行计算: ( u x , u y )=( v x , v y )+( a x , a y ) :accelerate ( p x , p y )=( p x , p y )+( u x , u y ) :move ( v x , v y )= decay × (u x , u y ) :decay speed ( a x , a y )=( 0,0 ) :reset acceleration 其中, p x , p y )和( v x , v y )分别表示 t 时刻物体的位置和速度。Decay 是一个参数,分 ( 别由 ball-decay 和 player-decay 控制。 a x , a y )表示对象的加速度,可以通过 dash(针对队员) ( 和 kick(针对足球)的 Power 参数计算得到: ( a x , a y )= Power×power_rate × (cos(θ ), sin(θ ))
t t
t t
t t t +1 t +1 t +1 t +1 t +1 t +1 t t t t

(4.18)

t +1

t +1

t

t

t +1

t +1

t +1

t +1 t

t

t

t

其中 θ t 表示对象 在 t 时刻的前进方向,power_rate 就 是 dash_power_rate 或者是 kick_power_rate(见 4.53.) 。如果对象为球员,它的方向就是球员脸朝向的方向。 对于足球,其方向的计算方法是:
t t θ ball = θ kic ker + Direction

其中 θ ball 和 θ kic ker 表示球和踢球队员当前的方向,而 Direction 是 kick 命令中第二个参数。
t t

4.4.1 运动噪声模型 为了反映出实际比赛中球及球员运动的不确定性,server 在球及球员的运动过程中以及一些命 令的参数中加入了一定的干扰因素。 首先考虑运动,干扰是以如下方式加入的:

~ ( u x , u y )=( v x , v y )+( a x , a y )+( rr max , ~ max ) rr
t +1 t +1 t t t t

~ 为属于 [? max, max] 的随机数。rmax 的定义为: rr max
t rmax = rand ? ( v x , v ty )

rand 是 player-rand 和 ball-rand 的参数。 命令中的 Moment 和 Power 参数的干扰为: (用 argument 表示)

arg ument = (1 + ~ ) ? arg ument rrand

4.4.2冲撞模型 在每个仿真周期的末尾,如果有两个对象相撞,那么会把对象后移使其不再重叠。然后两者的 速度都乘以-0.1。注意,足球有可能穿过球员,只要在周期的末尾,足球和球员没有冲撞就行 了。

4.5动作模型 4.5.1Catch抓球模型 守门员是唯一能执行catch命令的球员。守门员可以从任何方向抓到足球,只要足球在可抓范围 。如果守门员以δ角度去catch足球,那么可 内,守门员在罚球区内,且比赛模式是“play_on” (见图4.4) 如果足球在这个 。 抓范围是长宽分别是catchable_area_l和catchable_area_w的矩形区域 矩形区域内,能够被抓到的可能性是catch_probability,在外面则不能被抓到。目前使用的关于 catch的参数值见表4.4。

如果catch命令没有执行成功,那么要catch_ban_cycle后才能进行下一次的catch命令(在此 期间的catch命令将不会发生任何效果) 如果守门员成功的抓球, 。 比赛模式将在一个时间周期内 先变为‘goalie_catch_ball_[l|r]’ ,再成为‘free_kick_[l|r]’ 。一旦守门员成功抓球,他就可以在 罚球区范围内执行move命令。在kick踢球前,守门员最多可以执行goalie_max_moves次move命 令。更多的move命令将不起任何作用,同时server返回(error too many moves)。请注意,如果 catch到足球,然后move,再kick足球很少的一段距离,接着马上重新catch….一旦move的次 数超过了goalie_max_moves,会被认为是“非君子”的玩法。

4.5.2Dash Model Dash Model 命令dash给予球员一个加速度,和他身体朝向同向。命令dash的参数是power。值的范围见 server.conf文件中的minpower和maxpower。目前dash模型使用的参数值见表4.5。 注意:校内比赛球员没有体力限制,通过修改下面的参数来实现: (每周期体力增加1000) /* The maximum player stamina increament */ #server::stamina_inc_max = 45 server::stamina_inc_max = 1000 每个球员都有一定的体力stamina,会因为dash命令而消耗。在上下半场开始时,球员体力 ,体力值降低power。如果是向后加速,体 被置为stamina_max。如果球员向前加速(power>0) 力值降低2倍power。如果dash需要的power超过了球员的体力值,那么power就会降低。 降低体力值后,server计算dash命令中power的有效部分。命令dash的有效部分edp(effective dash power)是由dash_power_rate和球员当前的effort决定的。球员的effort是介于effort_min和 effort_max之间的值,受球员的体力管理决定(见下所述) 。 edp = effort * dash_power_rate * power (4.19) (校内比赛effort恒为effort_max) edp和球员的当前身体方向被转化成向量,再加到球员当前的加速度 a n 。 从仿真周期n转换到仿真周期n+1时, a n 的使用如下: 1. a n 被规格化到最大是player_accel_max的一个值。 2. a n 被加到球员的当前速度 v n 。 v n 将被规格化到最大是player_speed_max的一个值。 3. 噪声 n 会影响 v n 。噪声在server.conf文件中定义。和噪声有关的参数是player_rand。噪 声向量的方向和大小介于-| v n | * player_rand和| v n | * player_rand之间。 4. 球员的新位置 pn +1 是原先的位置 pn 加上速度 v n (如:两个仿真周期间球员的最大距离 改变是player_speed_max) 。 5. player_decay被应用到球员的速度中: v n +1 = v n * player_decay。加速度 a n +1 被设为 零。

4.5.3Kick Model 命令kick有两个参数,踢球力量(介于minpower和maxpower之间)和球员踢球的角度。 。 角度以度数表示,并介于minmoment和maxmoment之间(现在使用的参数值见表4.6) 一旦命令kick到达server端,只要球员没有被置为越位,而且足球在可踢范围内,那么kick 就会被执行。如果足球和球员之间的距离在0到kickable_margin之间,那么足球对这个球员来说 就是可踢的。本节我们讨论的距离是指两个对象(如足球和球员)的外圈间的距离,就是说我 们讨论的距离是足球的中心到球员中心的距离减去足球的半径和球员的半径。首先要计算的是 踢球的有效力量ep(effective kick power) : ep = kick power * kick_power_rate (4.20) 如果足球不在球员的正前方,那么根据足球相当球员的位置,踢球有效力量将会减去 某个数值。所以角度和距离都是很重要的。 如果足球相对球员身体角度是0°,就是说足球在球员面前,有效力量将不会改变。角 度越大,有效力量将会减少的越多。最差的情况是足球在球员身后(180°):有效力量将 会减少25%。 有效力量的第二个重要变量是足球到球员间的距离:因为要执行kick命令,所以足球 到球员的距离介于0到kickable_margin之间。 如果距离是0, 那么有效力量将不会再被减少。 两者间的距离越大,有效力量减少的越多。如果距离等于kickable_margin,那么有效力量 将会减少原来踢球力量的25%。 最坏的情况是足球在球员的后方最远处: 将会使用50%的踢球力量。 我们使用公式4.21 来计算踢球有效力量(dir_diff是足球和球员身体的相对角度,dist_diff是足球和球员的相对 距离)。

踢球的有效力量被用来计算加速度 a ni ,这个加速度在周期n中加到足球的全局加速度

a n 上(我们讨论的是多智能体系统,在同一个周期,可能有好几个球员踢球) 。
在从仿真周期n到仿真周期n+1的转换中,加速度 a n 被应用如下:
1. a n 被规格化为最大是baccel_max的一个值。目前的server版本中,最大的加速度等于踢 球有效力量的最大值。 2. a n 被加到足球的当前速度 v n 。 v n 将被规格化到最大是ball_speed_max的一个值。 3. 噪声 n 会影响 v n 。噪声在server.conf文件中定义。和噪声有关的参数是ball_rand。噪声 向量的方向和大小介于-| v n | * ball_rand和| v n | * ball_rand之间。 4. 足球的新位置 pn +1 是原先的位置 pn 加上速度 v n (如:两个仿真周期间足球的最大距离 。 改变是ball_speed_max) 5. ball_decay被应用到足球的速度中: v n +1 = v n * player_decay。加速度 a n +1 被设为零。

在当前的设置下,一次最佳踢球可以滚动距离为45。最佳踢球后53个周期,足球移动距离 是43,其时速度小于0.1。而在15个周期内,则可以达到距离27-28,速度降为略大于1。 踢球模型和现在的参数设置暗示复合踢球也是有用的,如:停住足球,将球踢到可踢范围内的 一个更有利的点,然后踢往一个希望的方向。使用复合踢球的第二个可能是不用将足球移动相 对位置(0,0°)处,而能将足球加速到最大速度值。

4.5.4Move Model 命令move可以把球员移动到场上的任何一个地方。在正常比赛期间是没有效果的。在上下半场 开始前(比赛模式是‘before_kick_off’)以及进球后(比赛模式是‘goal_r_n’和‘goal_l_n’) 才可以使用move命令。在这种情况下,只要比赛模式没有改变,球员可以被移动到自己半场的 任何地点(就是说x<0),而且可以被移动任意多次。如果球员还在对方半场的话,那么将会被 server移动到己方半场的随机位置。 使用move命令的第二个目的是当守门员成功抓到足球后,可以在罚球区内移动。(亦见 4.5.1)。如果守门员成功抓到了球,就可以在罚球区内和足球一起移动。在他踢球前可以移动 goalie_max_moves次。更多的move命令将不起任何作用,而且server返回 (error too many moves)。

4.5.6 Turn Model 命令dash用来在球员的身体朝向上给予一个加速度,命令turn用来改变球员的身体朝向。命令 turn的参数是moment;moment的有效值介于minmoment和maxmoment之间。如果球员是没有 运动,那么他转过的角度将等于moment的值。然而,如果球员在运动,由于惯性的作用使其转 身较为困难。球员真正转过的角度如下所示: actual_angle = moment/(1.0 + inertia_moment * player_speed) (4.22) inertia_moment在文件server.conf中的默认值是5.0。因此(使用默认值),如果球员的 速度是1.0,他能够做到的有效转身角度最大是 ± 30 。但是,因为球员不可能在同一个周期 执行dash和turn命令,因此球员执行turn后最大速度是player_speed_max * player_decay, 这就意味着默认球员的有效转身角度(使用默认值)是 ± 60 。

4.7 Referee Model 自动裁判发送消息给球员,这样球员能够知道当前的比赛模式。自动裁判的规则和行为见2.2.1。 球员用hear接收裁判消息。球员能在每个仿真周期听到裁判的消息。 4.7.1 Play Modes and referee message比赛模式和裁判消息 比赛模式的改变由裁判宣布。裁判还有宣布其他的一些事情,象进球或者犯规。如果你读一下 server的源代码,就会发现还有其他一些比赛模式现在没有使用。比赛模式和裁判消息通过 (referee String )宣布,String是比赛模式或者是消息字符串。比赛模式见表4.12,消息字符串 见表4.13。

4.8 足球仿真 在4.4中,我们描述了根据对象的速度和加速度的运动情况。在本节,我们讨论在仿真时,速度 和加速度应用于哪个时刻。 4.8.1 仿真法则的描述 在server处,时间是以离散步骤进行更新的。每个仿真步骤是100ms。在每个仿真步骤之内,对 象(就是球员和足球)停在原先的位置。如果球员在某个仿真步骤内想有所动作的话,那么此 动作会在仿真周期向下一个周期转换时应用到球员和足球上。基于比赛模式,并不是允许球员 执行所有的动作(如:在‘before_kick_off’模式下,球员只能turn和move,而不能dash) ,因 此只有允许的动作会被执行并产生作用。 如果在一个步骤内,有好几个球员踢球,那么所有的效用将被相加,最后得出一个加速度。

如果这个加速度大于足球的最大加速度,那么就会被量化到它的最大值。移动了对象后,server 检查冲撞,如果冲撞发生,就更新速度(亦见4.4.2) 。 对对象应用加速度和速度时,它们的顺序是随机的。改变对象的位置,更新它们的速度、 加速度后,自动裁判检查场上情况,改变比赛模式或者对象位置(如果有必要的话) 。比赛模式 的改变会被马上宣布。最后,更新每个球员的体力。 3. Soccer Client 6.1 协议 本节讨论client和server间的协议的基本情况。更多的细节见server小节。 注意初始化和重新连接命令将被送到运行server机器的球员UDP端口(默认是6000) ,得到 响应后,该球员就和server分配的端口绑定,以后的信息也发送到这里。Server从这个端口发送 初始化响应信息(参见1.2.1) 。所有发送到server和从server端接收的命令都是普通字符串。

6.1.1 初始化和重新连接 每个要和server连接的球员都要首先介绍自己。这就好像是次握手,在开始时进行一次,在 你希望重新连接时随意进行。 初始化 球员要以下面的格式来发送init命令: (init TeamName [(version VerNum)] [(goalie)]) 守门员必须在init命令中包括“(goalie)”,这样server才会运行抓球或做其他守门员 才能做的动作。请注意每个球员只能有一个守门员或者没有守门员(没有规定必须要有一 个守门员)。 Server用如下格式的消息来响应你的初始化消息: (init Side UniformNumber PlayMode) 或者是出错消息(如果出错的话,就是说你初始化了不止两支队伍,一支球队的人数 超过了11个,或者一支球队中使用了不止一个守门员): (error no more team or player or goalie) Side是你球队比赛时的标示,一个字母,l(left)或者是r(right)。UniformNumber是球员 的球员号(球员通过它们的球员号被识别)。PlayMode是表示一个有效比赛模式的一个字 符串。 如果你和server版本是7.00或更高的连接, 你会接收到更多的server参数, 球员参数和球 员类型信息(最后两个是关于异构球员的特性)。精确的格式见附录A。 (server_param Parameters . . . ) (player_param Parameters . . . ) (player_type id Parameters . . . ) 到此握手结束,你的球员被作为有效球员识别了。 重新连接 重新连接是很有用的,因为无需重启比赛就可以修改球员的程序。只能在非PlayOn的比赛 模式中使用(如:在半场时间)。 使用下面的格式进行重新连接: (reconnect TeamName UniformNumber) 你将会得到下面格式的响应: (reconnect Side PlayMode) 如果在PlayOn比赛模式,则返回: (can't reconnect)

如果因为某种错误,没有球员可以重新连接,则返回: (error reconnect) 如果球队名字出错,也会返回: (error no more team or player or goalie) 在这里,如果你是和server版本是7.00或更高的连接,也会返回更多的server参数,球员 参数和球员类型信息。 断开连接 在你断开之前,你可以发送给server一个bye命令。这个命令将会把球员从场上移出。 (bye) 将不会用server的返回信息。
6.1.2 控制命令 所有球员的运动行为都是由几个命令组成的,这几个命令前面已经有所谈及。 这些命令的结果有些复杂,并且依赖于很多仿真因素。对每个命令的执行细节见serer小节。

(turn Moment) Moment介于-180到180之间。这个命令将在球员当前身体角度的基础上转过Moment 度角。 (dash Power) 这个命令给予球员一个加速度,和球员身体朝向同向(不一定就是当前的速度方向)。 Power介于minpower和maxpwer之间,现在这两个值是-100,100。 (kick Power Direction) 在Direction方向用Power给足球加速。 Direction是相对于球员当前身体方向的相对角度, power是介于minpower和maxpower之间。 (catch Direction) 守门员的特有命令:以Direction方向去试图抓球,direction是相对球员当前身体方向的 相对角度。如果命令被成功执行,在守门员踢球kick前,足球将一直被守门员控制。 (move X Y) 这个命令仅能在开球前或是进球后执行。它将球员在一个周期内移动到绝对坐标(x,y) 处,x介于-54到54之间, y介于-32到32之间。在开球前,这是很有用的。 (这个命令也可以 在守门员catch到足球后,在罚球区内进行―――译者注) 。
注意,在一个仿真周期内,只能执行上述五个命令中的其中一个。 (也就是说,如果球员 在一个周期里面发送以超过一个命令,那么就会被随机执行其中的一个命令,通常情况下是先 到达的那个) 。

6.1.3 感知信息 感知信息被有规律的发送给所有的球员(如每个周期或者是每1.5个周期) 。所以没有必要向 server发送命令请求得到这些信息。 所有感知返回的信息都有时间戳(Time) ,表明该数据被发送时server端的周期数。这个时 间是很有用的。 视觉感知

视觉感知是最重要的感知器,但是有一点复杂。这个感知返回球员能够见到的对象信息(就是 说在视角范围,又不很远的对象) 信息的主要格式如下: (see Time ObjInfo ObjInfo . . . ) ObjInfo是如下的格式: (ObjName Distance Direction [DistChange DirChange [BodyFacingDir HeadFacingDir]]) 或 (ObjName Direction) 注意返回的对象信息和他的距离有关。对象相距越远,得到的信息越少。更多的信息 参见附录。 ObjName是下面的一种: (p [TeamName [Unum]]) (b) (f FlagInfo) (g Side) p表示球员,b表示足球,f表示标志,g表示球门。 Side是l表示左半场或者是r表示右半场。关于FlagInfo更多的信息参加附录。 自身感知 自身感知返回球员的所有状态,如体力,视觉模式,球员在每个周期刚开始时的速度:

最后8个参数是接收到命令的计数值。使用这个计数值用来寻找丢失或延误的消息。

6.2 如何编写 clients 如何编写 本节简要的描述了编写 client 的首要几个步骤。 6.2.1 Sample Client server 发布版本包括了一个很简单的 client 程序,叫 sampleclient。在“sampleclient”的目录下, 当你编译 server 时,sampleclient 也自动被编译。 Sampleclient 不是一个独立的 client: 它仅仅是一个简单的 “管道” 将标准输入命令 , (键盘) 送到 server 端,将从 server 过来的信息显示在标准输出(屏幕) 。因此当我们调用 sampleclient 时是不会有任何反应的。使用者要从键盘输入命令,读取显示在终端上的感知信息。 (其实是很 难读取感知信息的,因为 server 每秒种要发送大约 17 个感知信息。 为了理解 client 应该做什么,将会从 server 接收到什么,Sampleclient 是非常有用的。 如何使用 sampleclient 这里是 sampleclient 的典型使用方法。 1. 在 sampleclient 目录下调用 client

SERVERHOST 是运行 server 的 hostname 如果端口有变化,则使用:

2. 从键盘输入初始化 init 命令 MYTEAMNAME 是想使用的球队名字 然后场上就会出现一个球员。同时,程序开始将 server 发送来的感知信息显示到终端。这 里是一个典型的输出:

解释略 3. 输入 move 命令移动球员到初始位置。球员原先出现在场外。使用者需要用如下的命令 将球员移到它的初始位置: 然后球员就会移到点(-10,10) 。 刚才说道 client 的输出信息是无穷的,因此使用者不会看到他们输入的字符串。所以他们 必须进行盲打输入。 (注:也可以使用“%client SERVERHOST > /dev/null” ,这样丢掉返回的感 知信息。利于命令的输入) 。 4. 点击 server 上的“Kick-Off”按钮,然后比赛就开始了。使用者会看到每个感知信息的 时间数在不断的增加(是 see 和 sense_body 信息的第一个数字) 。 5. 然后,使用者就可以输入任何正常命令 turn,dash,kick 等等。如:使用者可以输入下 面的命令将球员转到右方。

球员也可以全力向前冲: 如果球员离足球足够近,他就可以用 power=50 将球踢往左边: 再次提醒一下,因为感知输出是无穷的,所以必须进行盲打输入命令。 Sampleclient 的总体结构 1. 打开一个 UDP socker,和 server 端口连接。 (init_connection()) ,在此,有两个进程被平行执行。 2. 进入一个 real-write 循环(message_loop) 读 取 用 户 输 入 的 命 令 ( 通 常 是 从 键 盘 输 入 ) 然 后 将 其 发 送 到 server ,

(send_message( )) 。 接收从 server 过来的感知信息(receive_message()) ,并将其送到标准输出(通常 是终端) 。 为了实现平行执行,samplecliet 使用了 select()函数。该函数使在一个单独的进程中等候 socker 和 stream 的多重输入。当 select()被调用时,它一直等待,直到其中一个 socket 和 stream 得到输 入数据, 并分辨出是哪个 socket 或 stream。 关于 select()的跟多用法, 请参考 man 页或用户文档。 Sampleclient 中的一个重要提示是当他从 server 接收到信息后,必须修改 server 的端口号。 因为当 server 接收到一个 init 命令后,它为这个申请的球员新建了一个端口。在“lient.c”中的 : 下面部分实现(大约在 147 行)

6.2.2 Simple Clients 为了开发一个完整的 clients,用户必须写出代码,实现在接收的感知信息的基础上产生需要进 行的命令字符串。 当然这不是个简单的任务(所以很多研究者将 RoboCup 作为一个研究项目) ,有很多种方 法可以实现。简单的说,为了开发 clients,用户需要了解下面的部分: 〔Sensing〕分析感知信息:正如以前章节叙述的,server 以 S-expression 方式发送不同的感 〕 知信息。因此,client 需要分析 S-expression。然后,client 进行分析信息得到一个 内部描述。如:client 需要分析视觉信息来估计球员位置和场上状态,因为视觉信 息仅包含了场上标记是移动对象的相对位置。 〔Action Interval〕控制发送命令的时间间隔:因为 server 每隔 100ms 接收一次身体命令 〕 (turn,dash,kick) ,client 在发送命令前需要等待恰当的时间间隔。 并行的执行感知和动作进程: 因为 server 异步的发送感知信息和命令, client 〔Parallelism〕 〕 需要执行感知进程来出来感知信息,同时也要执行一个动作进程,平行的控制发 送命令。 球员规划: 在使用感知信息的基础上,client 需要产生比赛的恰当的命令序列。 〔Planning〕 〕 当然,这就是开发 client 的最后目标! ! 这里是“独立”stand-alone 球员的两个简单的例子,sclient1 和 sclient2,仅仅是追逐足球 然后踢到对方的球门中。源码可以在这里找到: ftp://ci.etl.go.jp/pub/soccer/client/noda-client-2.0.tar.gz 在这些例子中,上面列的部分的实现如下所述: 接下去是 sclient1 和 sclient2 的简要分析,无很大意义。略。 6.2.3 Tips 我们收集了一些开发 client 程序的小技巧和提示 调试是在开发过程中的最大问题,所以尽可能的找到简单的调试方法。 察看在某一个条件下,程序中的变量情况的一个有效的简单方法是使用 abort()命令或者一 些断点,迫使程序产生 core-dump;然后使用 gbd 来调试产生的 core 文件。 记录发送给 server 以及从 server 接收的每一条消息。这样对调试是很有帮助的。 如果你是一个新手,那么使用现成的 socket 和分析问题的库函数是很有帮助的。 记住在发送 init 命令时,要带有版本号。虽然这是个可选项,但是默认值是 3.00,并不是 我们希望的。 即使你的抓球能力是 1.00,也有可能不能成功抓球,因为返回的位置信息可能有错误。 你碰到的第一个难点将是时间问题。有很多方法可以使你的 client 的时间和 server 的时间

进行同步。其中一个简单方法就是使用接收到的 sense_body 信息。 小心低速网络。如果你解决时间问题不是非常有效,那么在一个拥挤或低速的网络中,你 的 client 将会有不正常表现,或者他们将会没有运行需要的资源(如:你在一台低配置机 。在这种情况下,他们可能见到旧的位置信息,然后在那个条件下进 器上运行很多 client) 行动作,这样就会造成混乱(如:他们绕着自己转圈) 。 标记的主要用途是帮助球员找到自己在场上的正确位置。你的第一个 client 可以忽略标记, 使用系统的相对位置。但是不久后,你就会需要有一个位置模型。 在分析感知信息时,程序应该检查缓冲区的结尾。感知信息使用 S-expression。但是如果感 知数据比缓冲区要大的话,expression 可能还没有完全结束,主要就会丢失东西。如果还用 原先的方法去分析的话。可能会造成程序 core-dump。


相关文章:
浙江大学RoboCup类人组足球机器人介绍
浙江中控 SR-H100 类人组足球机器人介绍 一﹑详细技术参数表高度 尺寸 重量 ...。 错误 RoboCup 类人组的比赛场地(未按比例) 场地规格(单位:cm) A B C ...
robocup竞速标准赛技术报告
robocup竞速标准赛技术报告_调查/报告_表格/模板_应用文书。2014 中国机器人大赛...浙江大学RoboCup校内赛技... 22页 免费 RoboCup机器人足球仿真比... 3页 2下载...
2014年中国机器人暨RoboCup公开赛总决赛获奖名单_图文
RoboCup 中型组技 术挑战自选项目比 赛 RoboCup 标准平台 组标准平台技术挑...大学足 球机器人团队 浙江工业大学新 青年队 中南大学 CSU_Yunlu 西北工业大学...
RoboCup双足竞步交叉足冠军比赛程序
RoboCup双足竞步交叉足冠军比赛程序_电子/电路_工程科技_专业资料。2012RoboCup公开赛机器人双足竞步(冠军)比赛程序#include <avr/io.h> /* IO 关联 */ #incl...
更多相关标签:
浙江大学校内网 | 浙江大学校内邮箱 | 浙江树人大学校内网 | 浙江海洋大学校内地图 | 浙江理工大学校内网 | 浙江大学校内转账 | 浙江大学校内论坛 | 浙江大学校内宾馆 |