匆匆翻译没有校正,错误难免,阅读时请以英语原文为准,此翻译仅作参考用-----------郭叶军
用户手册
RoboCup Soccer Server
V7.06
1. 介绍
我们现在处于RoboCup 的初级阶段,还有半个世纪的路要走,那时我们可以“ 建立一支仿人机器
足球比赛队伍,并且战胜人类的足球世界冠军队” 。这个目标带来的挑战是巨大的,而且吸引了
全世界数以百记的研究者和他们的学生长年的投身于 RoboCup 。RoboCup 是作为教育目标的和
应用领域相平行的一个研究挑战,也用来刺激公共对机器人技术的兴趣和人工智能的发展。从
1997 年开始的每一年,世界各地的研究者聚集讨论,进行机器人的世界杯足球比赛。尽管机器
人技术还是相当平常的,这个事情还是吸引了越来越多人的兴趣。
本指南的目的是引导仿真组队伍的最初工作,对熟练使用者是一本对server 的参考指南。
1. 1
背景
Mackworth 提出了进行机器人足球比赛的想法。不幸的是,这个想法并没有得到恰当的反响,
直到Kitano, Asada, 和Kuniyoshi 在日本提出名为Robot J_League 的研究领域时,他们补充修改了
这个想法。在1993 年夏,几个美国研究者对Robot J_League 发生了兴趣,于是就变成了Robot
Wo rl d Cup,简称为RoboCup。RoboCup有时也指RoboCup挑战或是RoboCup领域。
1995年, Kitano et al. [8]提出在 1997年举行第一届机器人世界杯足球比赛和会议。 RoboCup
的目标是为AI 和机器人技术提供一个新的标准问题,继深蓝后AI 的又一个课题。RoboCup 和AI
中以前研究的问题不同,因为它致力于分布式解决方案,而不是集中式控制,而且研究的不仅
仅是AI 相关的传统领域,还包括以下范围:机器人技术,社会学,实时任务的关键系统,等等。
......
2.0 简介
1开始
2.
这个部分快速的介绍了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 命令移动
到某点,而不是跑向这个点,这样会既费时又费体力stamina 。如果在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 为通过人来判断这些犯规动作提供了一种方式。人类裁判可以挂起比赛,赋
予某个球队任意球。下面简单介绍一下此类犯规动作(在 RoboCup 2000 比赛时使用):
1 故意包围足球 (Surrouding the ball)
2 故意用多名队员阻挡球 (Blocking the goal with too many players)
3 故意长时间持球 (Not putting the ball into play
4 故意阻挡其他队员的移动(Intentionally blocking the movement of other players)
5 守门员滥用 catch 命令(守门员不允许在罚球区内重复使用 kick 和 catch 命令,因为这样
为移动足球提供了安全的方式)
6 向 server 发送过多命令
每个 Client 在一个仿真周期内不能发送超过 3 或 4 个命令。过多的命令会使 server 阻塞。
如果 server 发生阻塞,将在赛后进行检查。
7 不恰当的行为 Inappropriate Behaviour
如果显而易见的,一个球员以一种不恰当的方式干扰了比赛,那么人类裁判可以挂起比赛,
并给对方球队一个任意球。
3. 开始
本节包括关于得到足球比赛服务端 Soccer Server 源码文件和安装这个软件的所有相关信息。下
面讲述的步骤是在运行 GNU/Linux 2.2.17(用 uname -sr 检查版本号)和 egcs 2.91.66(用 which
g++检查版本号)的机器上测试通过的。当然如果进行了升级的话,也是可以的。在下面列出的
命令中,假定->是命令行提示符。
3.1 得到并安装 server
1.从下面的 Soccer Server 网站得到源码文件:
http://ci.etl.go.jp/~noda/soccer/server/ (Japan)
Flooding the Server with Messages
after a given number of cycles)
http://www.robolog.org/server/ (Germany)
。。。。。。
4. Soccer Server
4.1 对象 Objects
4.2 协议
4.2.1client 命令协议
连接,重新连接,断开
UML diagram of the objects in the simulation
如果 client 以大于等于 7.0 版本的协议成功的连接或重新连接,server 将额外发送以下的消息:
一个包括 server 参数的消息,一个包括球员 player 参数的消息和一个包括球员类型的消息。格
式如下所示。最后,球员将会接收到关于变换球员的消息(见 Sec.4.6 )???
(server_param gwidth inertia_moment psize pdecay prand pweight pspeed_max paccel_max
stamina_max stamina_inc recover_init recover_dthr recover_min recover_dec effort_init effort_dthr
effort_min effort_dec effort_ithr effort_inc kick_rand team_actuator_noise prand_factor_l
prand_factor_r kick_rand_factor_l kick_rand_factor_r bsize bdecay brand bweight bspeed_max
client 控制
server 可能会返回命令的出错信息:
(error unknown command)
(error illegal command form)
4.2.2client 感知协议
4.3 感知模型
每个 RoboCup 智能体有三种不同的感知。听觉感知检测裁判,教练和其他球员发送的消息。视
觉感知检测场上的可视信息,象球员当前可视范围内的对象的距离和方向。视觉信息很象一个
传感器,可以“见到”在球员身后的附近对象。自身 body 感知检测球员的当前物理状态,象它
的体力 stamina ,速度 speed 和头颈角度 neck angle 。这三种感知联合给智能体提供了环境的一
个较好的图景。
4.3.1 听觉感知模型
当球员或教练发送 say 命令时,server 就会发送听觉消息。裁判的调用也被作为听觉消息接收?。
所有的消息都会被马上接收到。
从 server 发送的听觉消息的格式如下:
(hear Time Sender "Message")
Time:指示当前时间。
Sender:如果是其他球员发送的消息,那么是发送者的相当方向,否则就是下面的选项:
self:发送者是自己本人。
referee:裁判是发送者。
online_coach_left 或者 online_coach_ringt:发送者是在线教练。
Message 就是消息内容。最长 say_msg_size 个字节。裁判发送的消息的格式见 4.7.1 所示。
影响听觉感知的 server 参数见表 4.1 所示:
听觉感知的能力
当球员的听力起码是hear_decay 时,该球员才会听到一条消息。当球员听到一条消息后,听觉能
力是以hear_decay 下降的。每个周期球员的听力以hear_inc 增长。听力的最大值是hear_max 。为
了避免球队阻塞信道使对手的交流失效,我们将球员的两支球队的听觉能力分离。现在的
server.conf文件显示每个球员在每两个仿真周期内能从每支球队接收到一条消息
hear at most one message from each team every second simulation cycle.
如果在同一时刻有更多的消息到达,那么球员真正接收到的消息是不确定的。(现在是根据
消息到达的顺序来选择)。这条规则不包括裁判和球员自身发送的消息。换而言之,在一个时间
周期内,一个球员能够发送一条消息同时接收其他球员的一条消息。
交流范围
仅仅在audio_cut_dist米的范围内,消息才能被传送到。如:在己方球门边的防守队员可以听到
守门员发送的消息,但是在对方球门边的进攻球员是不可能听到这个消息的。裁判发送的消息
能被所有的球员接收。
听觉感知例子???
。
a player can
This example should show which messages get through and how to calculated the hear
capacity.
Example: Each coach sends a message every cycle. The referee send a message every
cycle. The four players in the example all send a message every cycle. Show which
messages gets through during 10 cycles (6 might be enough).
4.3.2视觉感知模型
视觉感知报告球员当前所能看到的对象。在每个sense_step (目前等于150ms )内,视觉信
息被自动的发送到球员处。
从server 发送的视觉信息遵循下面的基本格式:
(see ObjName Distance Direction DistChng DirChng BodyDir HeadDir)
其中
Distance,Direction, DistChng和 Dirchng按如下方式计算出来的:
其中
v v 是目标的绝对速度, ) , (
yt xt
球员面向的绝对方向是球员的自身角度 BodyDir 和头部角度 HeadDir 的之和。另外
v v
ry rx
是目标的绝对位置坐标,
) , (
P P
yt xt
) , (
表示目标的相对位置和相对速度。
) , (
v v 队员自己的绝对速度。
0 0 yx
是接收视觉信息的队员自己本身的绝对坐标,
) , (
P P
0 0 yx
是队员所面向的绝对方向。
a
0
表示平行于相对位置向量的单位向量。如
) , (
e e
ry rx
) , (
P P 和
ry rx
果被观察者是球员的话,才会有 BodyDir 和 HeadDir ,分别是被观察球员相对观察者的身体和
头部的相对角度。如果两个球员的身体都是相同的角度,那么 BodyDir 就等于零。HeadDir 也
一样。
对象(goal r )表示右半场球门线的中点。(f c )是场上中心的一个虚拟标记。。。。。。。。。
对于对象(l … ),Distance 是视角的平分线和边线的交点到球员的距离。Direction 则是到
边线的方向。?
视野范围
球员的可视部分依赖于几个因素。首先是 server 上的参数 sense_step 和 visible_angle,决定了视
觉信息的时间间隔,以及球员正常视角时的角度。现在使用的是 150ms 和 90°。
球员通过改变 ViewWidth 和 ViewQuality 也可以改变视觉信息的频率和质量。
view_frequency 和 view_angle 由 4.13 式和 4.14 式计算得出。
view_frequency = sense_step * view_quality_factor * view_width_factor (4.13)
这里若 ViewQuality 是 high ,那么 view_quality_factor 等于 1;若 ViewQuality 是 low,
那么 view_quality_factor 等于 0.5 。如果 ViewWidth 是 narrow ,那么 view_width_factor 等于
2 ;如果 ViewWidth 是 normal ,那么 view_width_factor 等于 1 ,如果 ViewWidth 是 wide ,
那么就等于 0.5 。(质量越高,视角越小,发送时间间隔越大)
view_angle = visible_angle * view_width_factor (4.14)
这里若 ViewWidth 是 narrow ,那么 view_width_factor 等于 0.5 ,若 ViewWidth 是 norrow ,
则 view_width_factor 等于 1 ,若 ViewWidth 是 wide ,则 view_width_factor 等于 2 。
球员能够“看到”在他领域内的对象(以visible_distance 为半径的圆周)。如果某一对象在此范
围内,但是不在球员的视野范围内,那么球员只知道对象的类型(足球,球员,球门或者是标
记),而不知道对象的确切名字。就是说使用
“B”, “P”, “G” 和“F”来作为对象的名
字,而不是使用“b”, “p”,“g ”和“f ”。
图4.3 表示了view_angle 的意思。图中的观察球员由两个半圆组成,空心的半圆表示球
员的前部。全黑的圆周代表场上的对象。只有在view_angle°/2的角度范围内,而且在
visible_distance 的距离范围内的对象才能被看到。因此,对象b和g 是不可见的,其他的对象
都是可见的。
对象f 在观察者的正前方,它的角度被认为是0 °。对象 e 会被 认为是-40 °,而对象d
则会被认为是大约20°。
请参考图 4.3 的标志,球员所获得的视觉信息和距离的相关程度很大。对于近距离球员,
它既可以看到它所属的球队同时也可以看到他的球员号码。然而,随着距离的增加,首先消失
的是球员的号码。然后距离的增加还会导致球员的队别也分不清楚了。在服务器端假定这些距
离是
≤
这里假定 dist 是球员和自己的距离,那么:
z 如果
z 如果
号码有一定的概率看不到。这个概率根据 dist 是线性的从 1 到 0 减少的
z 如果
z 如果
可见,概率是随着 dist 的减少从 1 到 0 线性的递减的。
z 如果
length far unum _ _ dist ≤ ,那么球员号码和球队名称都可见
length far too unum _ _ _ dist ength unum_far_l ≤ < ,那么队名是可见的,但是队员
length far too unum _ _ _ dist ≥ ,那么球员号码是不可见的。
length far too team _ _ _ dist ength team_far_l ≤ < ,那么队名也存在一定的概率不
length far _ _ team_too dist ≥
,那么队名是不可见的
ar_length team_too_f ength team_far_l ar_length unum_too_f ength unum_far_l
图 4.3
举例说明:根据图 4.3 ,假想根据所有的球员周围的环,对于球员 c 可以识别球队名称和号
码,球员 d 可以识别除队名,而且有大概 50% 的机会识别出号码;球员 e 则有 25% 的机会
识别出队名。对于球员 f 恐怕只能识别为一个匿名的球员了。