UT Austin Villa 2012 代码发布:助力机器人足球与研究
1. 代码发布背景与概述
在标准平台联赛(SPL)中,所有参赛队伍都使用相同的 Aldebaran Nao 人形机器人,这本质上是一场软件竞赛。这种形式允许各队伍分享想法和代码,以加速开发更强大、智能的机器人。UT Austin Villa 自 2008 年 Nao 机器人引入以来,每年都参加标准平台联赛。到 2012 年,他们积累了大量的机器人足球代码基础设施,并凭借此赢得了当年的冠军。此次发布的代码包括软件架构、简化的视觉处理、定位、定位模拟器、踢球引擎和调试工具等,但省略了高层策略和行为代码。
2. 代码使用与适应新情况
要使用发布的代码并使其适应新情况,可参考代码中包含的 README 文件和注释。以下是一些关键步骤:
-
视觉系统颜色表生成
:视觉系统基于颜色进行物体检测,通过颜色表来解释颜色。可使用提供的 UTNaoTool,结合在图像上绘制颜色和标注物体的方法来生成颜色表。
-
复杂行为创建
:当前代码中的行为仅能直接走向并踢球,需要使用 Lua 编写的任务层次结构来创建更复杂的行为,以实现快速开发和测试。
代码的主要组件位于 core 目录,模块分别存放在各自的目录中,行为代码则在 lua 目录。主要的模块访问点是 processFrame 函数,视觉和认知过程的主要控制由 lua/init.lua 文件中的 processFrame 函数处理,运动过程的主要控制由 MotionCore.cpp 中的 processFrame 函数处理,NaoQi 接口主要在 interfaces/nao/src/naointerface.cpp 中。
2012 年,UT Austin Villa 在墨西哥城举行的第 16 届国际机器人足球世界杯比赛中赢得了标准平台联赛冠军。此次代码发布让新队伍能够借助经过验证可支持机器人足球世界杯冠军的模块快速起步。而且,这些代码原则上可用于机器人足球世界杯之外的项目,以及除 Nao 之外的其他机器人。其中基于颜色的视觉工具易于使用,定位算法具有通用性,可扩展用于其他类型的地标,同时还能与其他机器人进行协作。此外,内存和模块的通用基础设施是最有用的工具,它允许以简单且可定制的方式创建和重放日志,这对理解和调试机器人行为至关重要,还能在保持良好计算性能的同时实现代码模块的解耦。
3. 软件架构
在处理机器人代码时,代码的易调试性和可测试性非常重要。该代码的设计关键在于将环境接口和逻辑分离,所有通信通过共享内存进行。接口仅负责将传感器数据提取到内存中,并向关节发送命令,无论系统是机器人、模拟器还是调试工具,都可应用相同的逻辑。
为了实现更好的模块化,逻辑被组织成多个模块,每个模块负责特定的功能。内存被划分为多个内存块,用于分组相关信息,方便分析哪些模块依赖哪些信息。模块之间通过内存块进行通信,例如高层策略行为通过运动请求块与行走和踢球引擎通信,并通过信息块获取里程计和踢球状态信息。
代码的执行被分为三个独立的进程:
1.
接口进程
:以 100 Hz 的频率运行,由 naoqi(或模拟器)调用,将当前传感器信息复制到内存中,并输出当前的运动命令。
2.
运动进程
:以 100 Hz 的频率运行,将高层命令转换为电机的直接命令。
3.
视觉进程
:以 30 Hz 的频率运行,处理传入的图像并选择高层命令。
将执行分为三个进程的好处是可以重启崩溃的进程,分别调试每个进程,并且在修改运动和视觉进程的代码时,无需缓慢重启机器人上的 NaoQi 接口。不过,这种设计需要将内存结构存储在共享内存中,大部分信息在每个进程中是分开的,只有在将本地信息复制到共享块时才需要互斥锁。
以下是软件架构的 mermaid 流程图:
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
A(接口进程 100Hz):::process -->|传感器数据| B(共享内存):::process
C(运动进程 100Hz):::process -->|高层命令转换| B
D(视觉进程 30Hz):::process -->|图像处理| B
B -->|运动命令| A
B -->|信息| C
B -->|高层命令| D
4. 视觉系统
视觉系统的主要任务是在相机图像中检测球、球门、场线和机器人,并报告它们相对于机器人的相对距离和方位。该团队的视觉系统将物体检测任务分为四个阶段,每个阶段在两个相机上都要执行:
1.
分割
:读取原始图像并使用颜色表进行分割。
2.
斑点形成
:使用水平和垂直扫描线扫描分割后的图像,形成“斑点”以便进一步处理。
3.
物体检测
:将斑点合并成不同的物体。
4.
变换
:利用机器人的姿态信息生成检测到的线段的地面平面变换。
视觉分析系统还提供了用于调试和调整颜色校准的关键功能,特别是日志注释和颜色表生成功能,可用于创建和分析具有可测量精度的颜色表。由于视觉系统基于分割图像,因此正确构建颜色表对其有效性至关重要。
视觉系统依赖于以下几个主要类:
-
TransformationProvider
:将身体位置估计转换为用于将像素值映射到世界位置以及反之的变换。
-
Classifier
:按颜色对像素进行分类,并构建连续颜色的垂直和水平运行,这是分割阶段。
-
BlobDetector
:将相邻的相同颜色运行合并成多个斑点,这是斑点形成阶段。
-
[Line,Ball,Goal,Cross,Robot]Detector
:这些检测器类按顺序运行,将斑点转换为完整的物体检测。每个检测器负责找到相关的斑点,进行合理性检查,并将结果指示给全局世界对象数组,同时还会存储各种统计信息,如方位和图像位置。
需要注意的是,十字检测器仅用于守门员的定位辅助,负责识别球门框正前方的十字。由于遮挡问题,一般很难将十字与场地上的其他线条区分开来,但在守门员的情况下,可以对十字的定义施加更严格的假设。其他场线过于模糊,无法为守门员提供足够的位置确定性,球门柱虽然是很好的定位锚点,但通常不在守门员的视野范围内,需要完全转头才能保持位置确定性,而十字则克服了这两个缺点,为守门员和主要比赛区域之间提供了一个独特的定位锚点。
视觉系统还实现了基于子采样像素值的选择性高分辨率扫描,这在远距离定位球时最为有效。在正常操作中,每个物体检测器依赖于 320x240 的子采样分割图像,以确保视觉处理以硬件强制的 30 Hz 帧率运行。检测器可以随时请求对顶部相机图像的特定颜色进行高分辨率扫描,分类器将使用 640x480 的全分辨率对检测到颜色的子采样像素周围的所有区域进行重新分类。通常只对图像的小区域进行重新分类,因此在几乎不影响性能的情况下提供了全分辨率图像的优势。通过这种技术,能够可靠地检测到距离达 5 米的球,比子采样图像的检测距离提高了一倍。同时,也启用了对球门的高分辨率扫描,同样提高了球门的检测距离。
以下是视觉系统处理流程的表格:
| 阶段 | 描述 |
| ---- | ---- |
| 分割 | 读取原始图像并使用颜色表分割 |
| 斑点形成 | 扫描分割图像形成斑点 |
| 物体检测 | 合并斑点成物体 |
| 变换 | 利用机器人姿态生成地面平面变换 |
5. 定位系统
在所有机器人任务中,跟踪机器人的位置都非常重要,在机器人足球领域更是如此。定位系统的目标是接收视觉系统检测到的物体信息,并输出机器人、球、队友和对手的位置。拥有这样一个良好的世界模型能使机器人在比赛中做出明智的战略决策。
自 2011 年起,和许多其他参赛队伍一样,采用了多模态 7 状态无迹卡尔曼滤波器(UKF)进行定位。与蒙特卡罗定位等其他方法相比,UKF 具有计算效率高的优点,并且便于队友之间共享和整合球的信息。
2012 年机器人足球标准平台联赛的一个挑战是球场上没有独特的标记。因此,机器人必须很好地整合里程计和视觉对地标的估计,同时从碰撞、摔倒和被“绑架”(位置突然改变)所带来的噪声中恢复。由于球场是对称的,机器人自身无法确定其朝向。为了解决这个问题,机器人会利用队友的共享信息,检查队友认为球是在相同位置还是对称的相反位置。重要的是要参考多个队友的信息,以避免一个走错方向的队友误导整个团队。这个功能在
localization/UKFModule.cpp
文件中的
processSharedBall
和
checkSharedBallForFlips
函数中实现。
然而,使用完整的机器人团队进行定位测试和调试非常具有挑战性。因此,编写了一个定位模拟器来实现、测试和调试解决方案。该模拟器可以从代码发布中包含的工具的世界窗口运行。它利用了代码的模块化特性,不与感知和电机命令层的代码进行交互,而是用视觉模块的模拟输出填充代码,然后使用代码对踢球和行走模块的输出来移动模拟中的机器人。这个模拟器不仅对定位测试有用,还可用于测试各种策略和行为。
定位模块的主要接口是
localization/UKFModule.cpp
文件中的
processFrame
函数,观测更新由
processObservations
函数处理。UKF 有许多影响其处理观测和里程计更新的参数。这些参数最初使用机器人观测和运动的大量长日志进行优化,然后在测试比赛中发现问题时进行手动调整。
以下是定位系统处理流程的 mermaid 流程图:
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
A(视觉检测):::process --> B(UKF 模块):::process
C(里程计信息):::process --> B
B --> D(机器人位置输出):::process
B --> E(球位置输出):::process
B --> F(队友位置输出):::process
B --> G(对手位置输出):::process
H(共享信息):::process --> B
6. 踢球引擎
代码发布中包含了静态站立踢球引擎,位于
motion/KickModule.cpp
文件中。这个踢球引擎利用一系列关键帧状态,机器人在指定时间内依次通过这些状态。对于每个状态,需要定义状态时间、关节移动时间、期望的质心在 x、y、z 空间的位置以及期望的踢球脚在 x、y、z 空间的位置。这些值在
lua/cfgkick.lua
文件中为每个状态进行定义。机器人的关节通过逆运动学进行控制,以在分配的关节移动时间内达到每个期望状态。
以下是踢球引擎使用的状态表格:
| 状态 | 描述 |
| ---- | ---- |
| Stand | 站立高度与行走时相同 |
| Shift | 将质心移离踢球脚 |
| Lift | 抬起踢球脚 |
| Align | 对齐踢球脚 |
| Spline | 使踢球脚通过球摆动 |
| ResetFoot | 将踢球脚重置到身体下方居中位置 |
| FootDown | 将踢球脚放回地面 |
| ShiftBack | 将质心移回身体中心 |
| FinishStand | 站立高度与行走时相同 |
在 Spline 状态中,使用样条曲线来计算踢球脚向前穿过球时的路径。使用样条曲线是为了让踢球脚获得平滑的轨迹,因为非正式实验表明,平滑的踢球脚轨迹能使踢球更加一致。
需要注意的是,
lua/cfgkick.lua
文件中还定义了两个额外的状态 —— Kick1 和 Kick2,但它们的状态时间设置为 0,因此目前踢球引擎并未使用这两个状态(不过 Spline 状态结束时的目标使用了为 Kick2 状态定义的期望摆动脚位置)。如果将 Spline 状态的状态时间设置为 0,并为 Kick1 和 Kick2 状态设置正的状态时间,就可以获得不使用样条曲线计算踢球脚路径的踢球方式。
踢球引擎通过控制 Spline 状态中移动脚所需的时间来获得期望的踢球距离。在 2012 年的机器人足球世界杯中,机器人使用的静态站立踢球只有 1.5 米到 3.5 米之间的直线踢球。因此,3.5 米的踢球在 Spline 状态中花费 190 毫秒,而 1.5 米的踢球在 Spline 状态中花费 300 毫秒。踢球引擎会根据期望的踢球距离和当前球相对于踢球脚的位置,改变踢球引擎的 Align 和 Spline 状态中期望的摆动脚位置。
7. 总结
此次发布的是 2012 年机器人足球世界杯标准平台联赛冠军 UT Austin Villa 的部分代码库,包括软件架构、简化的视觉处理、定位、定位模拟器、运动引擎和调试工具等,但省略了踢足球的策略和高层行为代码。重要的是,所有代码都是在之前开发的灵活架构上进行的,这使得代码易于测试和调试。
对于任何参加机器人足球世界杯标准平台联赛的队伍,以及使用 Nao 机器人或类似平台的研究人员来说,这次代码发布都可以作为一个有用的基础。它提供了一系列经过实践验证的模块和工具,有助于加速机器人足球相关项目的开发和研究。
超级会员免费看
39

被折叠的 条评论
为什么被折叠?



