0、GameController（裁判盒）下载

前提

电脑已安装nodejs  npm  Rust

检查安装

node -v

npm -v

rustc -V  #大写V

安装nodejs

  1. 访问Node.js官网：https://nodejs.org/（推荐LTS长期支持版），下载安装windows安装程序

  2. 运行安装包，务必勾选“Add to PATH”选项（默认会勾选，不要取消），然后按提示完成安装。

  3. 安装完成后，重新打开命令行窗口输入 npm -v，能显示版本号即安装成功。

如果Node.js已安装，但npm仍提示找不到，需要手动将Node.js的安装路径添加到系统环境变量：

  1. 找到Node.js的安装路径（默认路径通常是：C:\Program Files\nodejs\ 或 C:\Users[你的用户名]\AppData\Roaming\npm）。

  2. 打开环境变量配置界面，在“系统变量”中找到Path，点击“编辑”：

  - 点击“新建”，粘贴Node.js的安装路径（比如 C:\Program Files\nodejs\）

  1. 点击“确定”保存所有设置，必须关闭所有命令行窗口并重新打开，环境变量才会生效。

安装Rust

  1. 打开浏览器访问：https://www.rust-lang.org/zh-CN/tools/install；

  2. 点击“下载Rustup-init.exe”（一般是x64版本），运行该安装程序；

  3. 安装过程中会弹出命令行窗口，直接按回车选择默认安装；

  4. 等待安装完成，安装器会自动配置环境变量，但需要重启命令行生效。

注意：安装时可能会提示缺少C++编译工具（如MSVC），按提示安装即可（通常会引导你安装Visual Studio Build Tools），这是Rust编译本地依赖必需的。

安装裁判盒

  1. 安装libclang (for bindgen)
winget install LLVM

set LIBCLANG_PATH 'C:\Program Files\LLVM\bin\'
  1. 克隆代码&编译
git clone https://github.com/RoboCup-HumanoidSoccerLeague/GameController.git

cd frontend
npm ci
npm run build

cargo build -r

启动裁判盒子

cargo run

一、裁判盒使用方法

支持平台：windows / ubuntu / mac 均可

比赛准备阶段

点开 GameController，进行如下配置：

  • Competition：分为Small，Middle，Large三个分组，其中每个分组都有Foudation和Advanced两种模式。 Small-Foudation：4v4 Small-Advanced：7v7 Middle-Foundation:3v3 Middle-Advanced:5v5 Large-Foundation:3v3 Large-Advanced:5v5 ！！注意：只有双方都同意才可以选择Advanced模式，若一方机器人不足或要求选择Foudation模式，则必须选择Foudation
  • Invisibles：选择双方队伍信息
  • Color：选择不同队伍的颜色。 分为Field Player Color和Goalkeeper Color 双方不得有相同颜色，但是同一只队伍中，守门员和其他球员的颜色可以相同
  • Mirror（home team starts on right side）：左右互换，为了将屏幕上的队伍与场地上的队伍对应起来 注意：只是“显示界面”中进行互换，而不是实际比赛中互换（只是为了在比赛时双方交换场地的时候以方便在裁判盒中更好对应双方队伍）
  • Fullscreen：选择裁判盒是否按照全屏模式启动
  • Interface：一定要选择电脑的无线网口！！
    • Windows 电脑选择 WLAN
    • Ubuntu 通过 ifconfig 指令查询网口
  • Testing和Casting：这两个是高级设置，不需使用

然后点击 Start 进入比赛界面。 必须确认机器人颜色和编号：刚进入时两边都是默认按照1234的顺序，但假如实际上守门员是5号，就要先点击substitute按钮，选择要替换的机器人。

  • Timeout 在比赛开始前，双方可以通过timeout来增加5分钟准备时间。 比赛双方在整场比赛中各有一次timeout机会，可以延长上下半场前的任意一个等待时间，双方也可以在同一个等待时间里同时使用timeout，此时延长时间就可以叠加变成10分钟。 如果双方提前准备好，比赛就可以提前开始。

  • Pick-up 如果双方有在场边等待的机器人，就要对其进行Pick-up处理

  • 与裁判盒建立连接 比赛开始前双方机器人后面都有一个“叉”，这个“X”表示机器人没有与裁判盒建立连接。 比赛开始前，裁判盒处于Initial界面，双方在场边启动机器人，启动后，红色的叉变成绿色对勾，表明成功建立连接 裁判盒会不断向机器人发送initial状态下的消息，机器人里面负责处理裁判盒消息的程序就会识别这一状态而不直接进场，在场边等待和扫描场地

  • 入场 若双方机器人均准备就绪，裁判员会说一声“Ready”，并吹哨一声，此时机器人走入场地

  • 开球准备 –开球方机器人：可以走入己方半场任意位置，也可以进入中圈 –非开球方机器人：不可进入中圈，若进入，会被判处Illegal position从而被罚下 –ready过程为45秒，时间到后自动按下set键，主裁判吹哨一声，说“set”，同时将球放在中圈中央 –若set状态下机器人发生移动则会被判处motion in set处罚 –机器人均处于set状态后，裁判员吹哨并说“play"，然后比赛正式开始 –开球方具有根据哨声检测提前开球的能力，但如果开球方不具备哨声检测功能，那么裁判盒会在比赛开始10秒后向双方机器人同时发生比赛开始的命令。开球同时，裁判员说“Ball free”（Ball free按钮会被按下或者10秒后自动按下）

  • 备注：哨声检测：机器人需要有哨声检测功能才可以在开球时的play具有优势，要是没有此功能，则机器人会在play的10秒后进入比赛状态

  • 裁判盒“误操作”处理机制：若不慎点击错误的按钮，可以在底部点击误操作的按钮从而撤回操作。必须从右到左依次点击才可以依次撤销。

比赛开始阶段

  • 点击 Playing 按钮比赛开始
  • 当有一方进球时，裁判会点击 Goal 按钮计分，随后机器人会回到己方半场开球时的等待位置
  • 如果机器人提前到达指定位置，裁判依然可以通过点击 Set 按钮结束等待时间，再点击 Playing 继续进行比赛
  • 计时结束后点击 Finish 按钮结束比赛
  • 遇到特殊情况机器人失去自主行动能力时，裁判员可以点击 Pick Up / Incapable 按钮再点击对应的机器人序号，将机器人罚下。机器人检修完毕后，裁判员再次点击对应的机器人序号结束罚下指令，10 秒倒计时结束后可自动上场参加比赛。
  • 一方进球后，点击Goal，机器人才会回场（没有自动装置检测求越过球门线）
  • 球出界时，有Throw-in，Goal Kick和Corner Kick三种球重新进场的方法，分别对应边线球、门球和角球（和真实足球比赛完全相同）

常见犯规类型

注：以下几种犯规的具体的定量的标准，在规则手册中可以查阅，这里只做简要介绍

  • Pushing：指的是将对面机器人从侧面或者背后推倒
  • Incapable Robot：指的是机器人在摔倒后，不能自己爬起或者倒在地面一段时间无法自己行动
  • Leaving the Field：机器人有明显向场地外侧移动的趋势，走出场地范围，以至于离开草皮
  • Motion in Set：机器人在set状态下持续移动
  • Illegal Position：包含对方开球时己方进入中圈，或者对方任意球时，己方处于距离球过近的距离等不正确的机器人站位情况，具体的所有情况请参阅规则手册
  • Ball Holding：指的是机器人双脚将球夹持长达一定时间
  • Local Game Stuck：指的是机器人在距离求很近的一个范围内没有表现出任何对球进行操作的迹象。机器人会被发下
  • Arms/Hands：手球
  • Pick-up：指的是机器人在会对自己的身体造成损害的时候，比如在地上反复挣扎、勾在球门上向球网冲击等等不安全的情况，在每个队伍的Handler向裁判员发出请求后，比如向裁判员说“Blue 4 picked up”（颜色+号码），裁判员同意请求后，重复说一句“Blue 4 picked up”，然后裁判盒操作员也重复一遍“Blue 4 picked up”并点击“Pick-up”键后选择相应机器人使其处于Pick-up状态，此时相应队伍的Handler可以将这台机器人拿下场地

场下机器人重新上场

  • （以Blue 4机器人为例）当该机器人在场边准备就绪后，Handler不对机器人再做任何的人为干预，并对主裁判说“Blue 4 ready”，然后主裁判重复一遍“Blue 4 ready”，裁判盒操作员也重复一遍“Blue 4 ready”同时点击Pick-up，然后该机器人的Pick-up状态会处于30s倒计时
  • 倒计时快结束时，裁判盒界面会闪烁，提醒裁判盒操作员及时操作。倒计时结束时操作员必须马上点击闪烁的黄色按键对相应机器人解除判罚状态。无人对操作员提示，这意味着操作员必须密切关注闪烁的黄色按键，不得耽误
  • 30s倒计时过程中也可以对机器人进行其他判罚。比如该机器人向场边走去的话，就可以对其进行判罚“Blue 4 leaving the Field”
  • 如果被判处其他处罚，则会又有30s倒计时

临时暂停

  • 当比赛出现特殊情况时，比赛可以临时暂停
  • 此时，场上倒计时暂定
  • 待裁判做出正确处理后，吹哨并说“Resume play”，同时裁判盒操作员点击Resume Play，比赛倒计时继续

Global Game Stuck

  • 指的是长达30s内，场上所有机器人都没有表现出识别到球的迹象，那么全局比赛卡住
  • 主裁判说“Global game stuck”，同时裁判盒操作员重复“Global game stuck”并点击Global Game Stuck按钮，其作用和进球后点击的Goal按钮效果相同，每个机器人都会走回开球前的等待状态
  • 但不同之处是，Global Game Stuck是对双方的惩罚性质的开球，双方都处于不开球的状态，都不能基于哨声检测提前移动，都必须等待set之后的10s倒计时结束，重新进入比赛状态

二、Monitor 使用方法

主要参考 VSCode 中 readme 部分，重点注意 teamID 部分。

⚠️ 注意：先打开 Monitor 软件，再在机器人上点 launch。先后顺序不要弄反，否则无法接收裁判盒指令。

点击 launch 后将机器人放在己方半场两条边线中的任意一边。此时机器人的头会转动寻找场地的特征点初始化自己的定位，但是不会移动。

等待裁判点击 Ready 后，在倒计时内机器人走到场内 yaml 文件中设定的开球位置，到达指定位置后点击 Set 按钮提前结束倒计时，接下来将足球放在场地中间，准备开始比赛。

Configuration（配置文件）

Monitor 支持通过配置文件过滤特定队伍的机器人显示。程序启动时会自动读取可执行文件同级目录下的 config.json。

文件位置：与可执行文件 dmonitor_node 同级（如 build/ 目录），文件名称：config.json

使用示例，新建 config.json 并写入以下内容：

{
    "team_id": 1
}

参数说明：

  • team_id：
    • 设置为特定整数（如 1）：仅显示 Team Number 为该数字的机器人
    • 设置为 -1（默认）：不进行过滤，显示所有接收到的机器人数据

编译过后会生成一个 build 文件夹，在 build 中新建上述 config.json 并写入队伍编号 team_id，这样就会防止不同队伍间产生干扰。

三、机器人对应参数修改

机器人编号修改

机器人的编号要在 .bashrc 文件中的 ZJUDANCER_ROBOTID 一行中修改：

export ZJUDANCER_ROBOTID=1

global.yml 配置

文件路径：RoboCup_Workspace/core/src/dconfig/global.yml

本次比赛能设置的 role 只有三个：Striker、Defender、GoalKeeper

⚠️ 注意：如需听裁判盒指令，要在对应 role 的名字前面加上 GC，例如 GCStriker

⚠️ 注意：UseGameController 要和 GC 同时改，控制是否听取裁判盒。

配置示例：

ZJUDancer:
  Simulation: false
  OfflineRecord: false
  OfflineReplay: false

  Role: GCStriker

  AttackRight: False
  AlongGrass: False

  UseGameController: True
  GameControllerAddress: 192.168.1.84
  TeamNumber: 17
  TeamCyan: true

  MotionSimdelay: 5000
  udpBroadcastAddress: "255.255.255.255"
  BroadcastMVInfo: False
  VisionOnlyMode: False
  • AttackRight：True 为进攻右侧球门；False 为进攻左侧球门
  • GameControllerAddress：裁判盒 IP，在使用裁判盒的电脑上查询并填写
  • TeamNumber：应该是裁判盒启动时选择的两个队伍的 ID 之一

role.yml 位置坐标配置

文件路径：dbehavior/config/role.yml

该文件包含不同角色的机器人放在场边的位置坐标 start_pos。

dbehavior:
  role:
    striker:
      start_pos: [-75, -300, 90]
      init_pos: [-90, 0, 0]
      kickoff_pos: [-75, 0, 0]
      patrol_pos_a: [150, -130, 0]
      patrol_pos_b: [300, -130, 180]
      team_radius: 100
    supporter:
      start_pos: [-75, -300, 90]
      init_pos: [-150, 150, -45]
      kickoff_pos: [-75, 150, 0]
      patrol_pos_a: [150, 130, 0]
      patrol_pos_b: [300, 130, 180]
      team_radius: 150
    defender:
      start_pos: [-300, -300, 90]
      init_pos: [-250, 0, 90]
      patrol_pos_a: [-200, -200, 90]
      patrol_pos_b: [-200, 200, -90]
      team_radius: 200
      defend_radius: 100
    goalkeeper:
      start_pos: [-300, -300, 90]
      init_pos: [-400, 0, 0]
      patrol_pos_a: [-400, -130, 90]
      patrol_pos_b: [-400, 130, -90]
      team_radius: 200
    penaltykicker:
      start_pos: [-300, 0, 180]
      init_pos: [-300, 0, 180]
      patrol_pos_a: [0, 0, 0]
      patrol_pos_b: [0, 0, 0]
      team_radius: 200
    others:
      start_pos: [-450, 0, 0]
      init_pos: [-450, 0, 0]
      patrol_pos_a: [-150, 150, 0]
      patrol_pos_b: [-150, -150, 180]
      team_radius: 200

坐标系说明：

  • 机器人进场时面朝的方向为 y 轴正方向，右侧为 x 轴正方向，坐标系原点为球场中心
  • kickoff_pos 是进场后要走到的位置

⚠️ 注意：坐标设置要在己方半场，不能超出范围。

坐标翻转机制：在己方半场两条边线上放置的机器人对于场地上同一个点的坐标描述是相反的，两台机器人认为的坐标值刚好关于原点对称。两台机器人在相互通信时，从不同边线放置的机器人之间有一个位置的翻译机制，在 dbehavior/src/dbehavior/core/dblackboard.py 中的 update_teaminfo 函数中。

role.yaml 以上的 pos 是默认按照我方半场是左半场（AttackRight=True），机器人放在左下边线去写的。dbehavior 在读取这些 pos 时，设置为 AttackRight=True 的机器人会把 start_pos 关于 y 轴对称，其他 pos 关于原点对称处理，进行这些处理的代码也在 dbehavior/src/dbehavior/core/dblackboard.py 中。