尧图网页设计 
简介面向TonyPi人形机器人障碍跑比赛开发与备赛者这是一套覆盖比赛全流程的代码仓库集成机器人运动控制、传感器数据处理、路径规划、实时避障及比赛规则适配等核心模块同时附带嵌入式底层驱动与外设配置资料可帮助理解从硬件初始化到上层决策的完整链路。压缩包共7个文件以Python程序为主配合说明文档、Markdown笔记、附赠Word资料以及开源协议与版本管理配置文件整体仅47KB结构紧凑适合快速阅读和二次开发。目前已有186人学习下载适用于机器人竞赛学生、嵌入式开发人员及相关研究人员。通过该仓库可获得可运行的障碍跑比赛代码框架学习人形机器人步态控制、环境感知与动态避障的实现思路并结合底层驱动配置资料掌握TonyPi平台的调试与部署方法为独立完成赛题迁移或功能拓展提供实用参考。 比赛前夜我把代码仓最后一次push到远程心里其实没底。TonyPi这台双足人形机器人赛道上要完成跨障碍、绕桩、坡道行进这些动作光是让它稳定走完一圈不摔就已经够折腾了。但正是这个项目让我把人形机器人的运动控制、传感器数据处理、路径规划算法和实时避障逻辑完整地串了一遍最后还在障碍跑比赛里拿了个不错的名次。这篇文章就把这个代码仓库项目的完整思路、模块拆解和实测心得端出来给正在做类似比赛项目或想入门人形机器人开发的朋友一个可参考的路线。我尽量不讲虚的直接从“为什么这么设计”和“实际跑起来什么样”两个角度来说。1. TonyPi平台选型与工程框架的搭建思路1.1 为什么选TonyPi而不是轮式或四足平台市面上做障碍跑比赛的机器人平台大多会选轮式小车因为底盘稳定、控制简单一个PID就能把速度调得很顺。但TonyPi这类双足人形平台完全不一样它靠12路总线舵机驱动双腿每个跨步都是一次动态平衡过程控制难度直接上了一个数量级。我选它的原因很直接比赛规则里有人形机器人加分项而且人形结构的越障能力上限比轮式高——跨栏、过桥、上下台阶这些动作轮式车基本做不了双足结构天生就是为这种场景设计的。TonyPi的硬件基础是树莓派做主控通过串口或I2C控制舵机驱动板搭载摄像头、超声波传感器和IMU姿态传感器。这个配置在比赛场景里够用而且开源性好SDK覆盖了基础运动API能让我们把精力放在算法层而不是底层驱动上。1.2 一个按模块拆分的工程目录调试时才不抓狂刚拿到板子的时候我犯了绝大多数人都会犯的错把所有控制代码写在一个几十行的循环里摄像头读一帧、算一次距离、转一次舵机角度看着简单跑起来一塌糊涂——某一个传感器卡住整个运动线程就阻塞机器人在赛道上直接僵住。后来我把整个工程按功能拆成了六个模块每个模块独立成目录、独立跑线程或用消息队列通信tonypi_obstacle_race/ ├── hardware_interface/ # 舵机、超声波、IMU的硬件抽象层 ├── motion_control/ # 步态控制、速度匹配、动作库 ├── perception/ # 视觉识别、距离测量、姿态解算 ├── planning/ # 全局路径规划算法 ├── decision/ # 实时避障逻辑、状态机 ├── competition_adapter/ # 比赛规则配置、赛道元素映射 └── main.py # 主入口串联所有模块这个拆分思路的核心是“硬件抽象”。hardware_interface下的每个传感器和执行器都有统一接口比如read_distance()不管底层是超声波还是红外都返回米制距离set_velocity(vx, vy, yaw_rate)把运动控制接口统一成速度指令。这样一来planning模块和decision模块根本不需要关心舵机角度怎么换算只需要处理“往哪走”和“避开什么”职责清晰调试时也能单独跑每个模块。2. 运动控制模块步态、舵机校准与速度匹配2.1 步态参数是怎么调出来的人形机器人运动控制和轮式机器人最大的差别在步态。轮式车给个速度就直接走人形机器人你需要告诉它步频多快、抬脚多高、跨步多远、身体重心怎么偏移。这些参数共同决定了一个步态周期。我实测下来的经验是步频在0.8到1.2赫兹之间比较稳太快了舵机响应跟不上身体姿态发散太慢了比赛时间扛不住。抬脚高度是障碍跑里最关键的参数。跨栏障碍高度通常在2到4厘米我把抬脚高度设置在略高于最大障碍的前提下尽量压低比如3厘米障碍就抬4厘米。抬太高有两个坏处一是重心波动大落地容易重心不稳二是舵机从最高点到落地的行程变长单步耗时增加。2.2 舵机校准这件事比写算法还重要这是我踩过最大的坑。TonyPi出厂时所有舵机有一个初始零位但这个零位和“机器人站直”的物理零位往往有偏差。如果不同步零位就跑机器人会站成一种微妙的“外八字前倾”姿势走几步就开始斜着偏。校准方法不复杂但必须细致让所有舵机回到中位值然后逐个关节对照机器人的物理直立状态把偏差值记录到配置文件里。比如右腿髋关节舵机ID为3回中时实际偏了5度那就在配置文件里把该关节的零点偏移值设为-5。这个偏移是静态补偿加在协议层发送的舵机角度上。注意舵机协议帧里控制指令是一组ID目标角度速度缓启动时间。校准偏移值必须在这个层面做补偿而不是在UI界面或算法层做否则步态算法里算出来的所有角度都会跟着错位。2.3 从运动指令到坐标位置不只是正运动学path planning算法算出来的输出是一串目标点位比如“前进0.5米右转30度”。但人形机器人和轮式机器人不同它没有轮式里程计那种天然精确的位移编码器底部舵机的角度变化不等于实际位移。这里我做了两步通过正运动学模型根据各关节角度推算髋关节位置和躯干姿态变化。用IMU的加速度计数据做积分和运动学推算结果互相校验。实测下来单纯靠舵机角度推步幅误差累积很快走20步以后位置偏差能到10厘米以上这个误差在绕过障碍物时是致命的。所以运动控制模块必须向外输出“带不确定性的位姿估计”决策模块根据这个估计量来判断是否需要修正。3. 传感器数据处理从零散读数到可用数据的融合3.1 三种传感器各司其职别指望一种搞定所有场景TonyPi基础版自带的传感器是单目摄像头、超声波测距模块、IMU三轴加速度计三轴陀螺仪。三种传感器的特性差异非常大传感器优势劣势适合场景摄像头信息量丰富能识别颜色、形状、赛道标志受光照影响大处理延迟高识别障碍物类型、赛道线、目标标记超声波测距直接响应快波束角大小物体测不准近距离障碍物检测5-40cmIMU姿态感知灵敏不受外部环境影响存在零漂积分会累积误差平衡状态估计、转向角度判断在实际比赛场地里光照条件和反射面是最大的变量。我试过纯视觉识别障碍物结果模拟赛道光线稍微暗一点摄像头识别帧率掉到5帧以下机器人都快到跟前了才反应过来避障根本来不及。后来把策略改成视觉做“目标识别”知道前方是什么障碍物超声波做“距离触发”多近时必须开始规避IMU做“状态反馈”避障动作完成后身体是否回正。三路数据各管一段反而比强行融合更稳。3.2 数据预处理滤波不是炫技是保命传感器原始数据直接喂给算法是不行的哪怕是短暂的一帧抖动都可能让决策状态机误判。比如超声波模块偶尔会跳一个极端大值声波打到斜面上的反射丢失如果不清洗避障逻辑会以为前方空旷直接全速冲过去。这一步我用了通用且有效的处理组合中值滤波滑动平均。超声波连续取5个读数去掉最大值和最小值再对剩余3个求平均。IMU的角速度数据做滑动窗口平均窗口长度10个采样点能明显去掉步态周期带来的高频振荡。另一个关键点是时间同步。三个传感器的采样频率不一样摄像头约30帧/秒超声波约20次/秒IMU约100Hz。如果不做时间对齐决策模块拿到的“同一时刻”的数据实际上是错位的极端情况下会产生“视觉已经看到障碍物但超声波还在报告空旷”的冲突状态。我在感知模块里给每个数据打时间戳决策模块只读取最新一帧打包好的同步数据。4. 路径规划算法全局搜索与局部窗口的配合4.1 全局规划把障碍跑赛道当成带约束的图搜索问题比赛之前赛道的基本布局是固定公布的包括障碍物种类、赛道宽度、各路段顺序。这意味着我们可以提前做一次全局路径规划生成一个粗略的“路线走廊”而不是完全靠实时感知比赛。TonyPi比赛场地通常是一个8字形或S形赛道路径规划可以抽象成“在一张栅格地图上从起点走到终点经过若干必经点位”。我用的是A算法做基础搜索。栅格分辨率设为2厘米一格每一个障碍物占用的栅格向外膨胀5厘米作为安全边界。A的代价函数里不只用欧氏距离还要叠加一个转向惩罚项——因为人形机器人转弯比直行慢得多同样长度的路径拐弯多的那条实际耗时更长。启发函数我采用了曼哈顿距离的变体四方向搜索时为曼哈顿距离八方向搜索时用切比雪夫距离保证启发式的一致性。提示障碍跑场景里不必追求全局路径的绝对最短而应该追求“转向次数最少路径长度可接受”。我在实现里给每次转向加了0.8m的等效距离惩罚效果很不错机器人路径看起来像人在走路而不是折线追击。4.2 局部规划动态窗口法在实际场地里更实用全局路径解决“大方向”的问题但比赛过程中障碍物可能有微小移位比如跨栏被前面选手碰歪了或者临时出现掉落物。这时候需要局部规划实时修正路径。我参考了DWA动态窗口法的思路在速度空间中进行采样模拟未来一段时间内机器人位置的轨迹然后根据“避开障碍物靠近全局路径”两个目标打分选出最优速度指令。DWA很适合人形机器人因为TonyPi的底盘控制本质上仍是双足交替前行速度指令被限制在一个很窄的动态窗口里加速度有限、最大步频有限DWA天然把这种运动学约束包含在搜索空间里。实现时要注意模拟轨迹的步数不能太长TonyPi单步周期约1秒模拟3-5个步态周期足够再长就会因为位姿估计误差太大而失去参考意义。4.3 借鉴改进冲突搜索的思路处理多任务冲突比赛过程中真正难的不是单台机器人绕障而是两台机器人在狭窄赛段相遇时的避让策略。我在全局规划层做了简化版的冲突搜索机制把赛道分成若干路段每台机器人通过特定路段的时间窗提前排好。如果两个时间窗重叠就对其中一台机器人的路径做延迟或局部绕行调整。这个方法参考了张洪琳等人关于改进冲突搜索的多机器人路径规划思路——把“规避冲突”从实时反应层提升到了“预判调整”的规划层比赛时稳定性明显提升。5. 实时避障逻辑状态机驱动的分层决策5.1 状态机比端到端神经网络更适合比赛场景很多刚入门的同学一听到“实时避障”就想着上深度学习、端到端神经网络但比赛场景里这其实不是最优解。障碍跑的障碍物类型是有限的、预知的跨栏、立柱、坡道、弯道、减速带。与其用一个难以解释的黑箱模型不如设计一个显式的状态机把比赛过程拆成清晰的状态FORWARD # 正常前进 OBSTACLE_DETECTED # 检测到前方障碍物 SLOW_DOWN # 减速准备规避 AVOID_CROSS # 跨栏动作 AVOID_LEFT # 从左侧绕过立柱 CLIMB_RAMP # 上坡动作 REALIGN # 回归全局路径 FINISH # 到达终点状态机的核心是转移条件。比如从FORWARD转移到OBSTACLE_DETECTED条件是超声波距离小于40cm且视觉识别判定前方是障碍物从OBSTACLE_DETECTED到SLOW_DOWN条件是距离小于25cm从SLOW_DOWN到AVOID_CROSS条件是视觉识别出是跨栏类障碍且当前步态支持跨栏动作。5.2 安全优先级永远把“不摔倒”放在“完成时间”前面这是我在比赛复盘后总结出来的最重要经验。刚开始调试时我的决策逻辑为了追求速度在接近障碍物前才触发规避动作结果跨栏时重心还没稳定就做下一个转向机器人直接侧倒。后来我把决策模块的安全优先级改为防摔倒 避障成功 速度效率。具体的实现方式是给“避障动作启动距离”设置了一个动态下限根据当前IMU的俯仰角变化率来判断姿势稳定性如果身体晃动幅度大就把避障触发距离拉长15%到20%。换句话说这个状态不是固定的而是会根据实时姿态动态调整的安全阀门。最终比赛时机器人一次没摔这个设计功不可没。5.3 回归全局路径的时机也很讲究避障动作完成后机器人并不会自动回到全局路径上——必须有一个“REALIGN回归”状态。开始时我只做了平移回归让机器人横向挪回原路径但人形机器人横向平移是很别扭的需要在两个方向上交替调整重心反而容易摔倒。后来改成了“先原地转向让正前方对准全局路径的下一个航点然后直行靠近”的方式速度更快也更稳。6. 比赛规则适配模块把赛道策略做成可配置的6.1 每条比赛规则都在变硬编码等于废代码比赛规则每年都在变有的要求按顺序通过5个障碍物有的允许自选路线、按通过障碍物数量计分障碍物间距、跨栏高度也会调整。如果把这些逻辑硬编码进决策模块规则一变整个代码都要重写。我在competition_adapter模块里做了一个规则配置层用JSON文件描述赛道布局和规则参数{ track_name: obstacle_race_2024, course_order: [start, hurdle_low, curve_left, pillar, ramp, finish], obstacles: { hurdle_low: {type: cross, height_cm: 3, trigger_distance_cm: 40}, pillar: {type: bypass, direction: left, bypass_distance_cm: 25} }, scoring: {required_order: true, time_bonus: true} }决策模块运行时只读取这个配置文件根据course_order决定当前目标点根据obstacles里的类型决定触发哪个避障动作。规则变了只需要改JSON策略代码逻辑一行不动。6.2 这个模块帮我省了大量赛前调试时间赛前最紧张的一小时里主办方临时通知“第四关的立柱往右又移了10厘米”。当时周围几台机器人的队伍都在现场改代码有的直接改坐标硬编码手忙脚乱。我这边只改了一行JSON里的bypass_distance_cm参数重启程序就完成了适配。这个模块看似不起眼却是整个项目里性价比最高的一部分投资。6.3 配置项也要做合法性校验这里补充一个实战里的注意点配置模块不能只做读取还要做基本的合法性校验。比如course_order里最后一个点必须是finishhurdle_low的height_cm不能超过机器人最大抬脚高度我设置的是5cm。我加了一个启动时校验函数配置不合法会输出明确错误日志而不是等机器人走到障碍物面前才暴露问题。7. 实测中踩过的坑和最终复盘7.1 坑一舵机过热导致的步态漂移连续调试超过20分钟后TonyPi的腿部舵机明显发热步态开始变得迟钝、发抖。一开始我以为是代码逻辑出了问题查了半天才意识到是舵机温度升高后响应变慢。解决办法有三个方向避免连续高负载测试、增加静止待机动作让部分舵机卸力、在步态参数里加超时保护如果舵机没达到目标角度就触发重试而不是继续走下一步。比赛时我选择保守策略每次跑完一圈让机器人休息几分钟确保舵机温度可控。7.2 坑二摄像头白平衡被赛道红色地垫带偏模拟赛道的红色地垫导致TonyPi摄像头的自动白平衡错误把原本醒目的黄色立柱识别成了接近背景的颜色视觉识别一度失灵。这个问题的根源是自动白平衡对大面积单色场景的敏感。解决方式是锁死白平衡参数使用固定色温模式然后把视觉识别的颜色空间从RGB转到HSV降低光照变化的干扰。此外在比赛前增加了一段白平衡自动校准流程上场前让机器人对着赛道地面原地转一圈手动锁定当前光照条件下的白平衡参数。7.3 坑三DWA局部规划在窄通道里不断重规划当赛道同时出现“两侧障碍窄通道”时DWA容易在通道入口处来回打转因为模拟轨迹里前方和左右都被障碍物占据可行的速度组合很少评分函数来回横跳。这个问题的根因是全局路径的目标点离得太远局部评分里“向目标前进”的权重占比不够。修复方式是在窄通道入口处临时把局部目标点替换成通道中点的投影点并提高“朝目标前进”这一项的权重系数同时降低“保持高速”的权重。调参后机器人过窄通道丝滑了很多。7.4 比赛当天的一个小技巧把传感器预热时间写进主程序比赛当天场地温度和调试房间不一样IMU陀螺仪的零点会漂移一截。如果上场后立刻跑程序转向误差会明显增大。我的做法是在主程序里加了20秒的预热阶段机器人原地站立连续采样IMU数据把前10秒的平均值作为新的零偏基准。这个小技巧让机器人在比赛日的转向精度和调试时保持了一致水平。回头看这个项目最深的体会是人形机器人障碍跑比赛技术难点从来不在某一个单独模块而在于所有模块之间的协调。运动控制、传感器处理、路径规划、实时避障、规则适配每一层都有各自的坑但它们的接口设计决定了整个系统能不能稳定跑完一圈。代码仓库里的结构、模块划分和配置化思路都是在一次次试错中沉淀下来的。如果你也在做类似的比赛项目我建议从一开始就按模块来写把规则参数外置把安全逻辑放在最优先的位置这些看似琐碎的工程习惯最后都会变成赛场上的稳定性。本文还有配套的精品资源点击获取 TonyPi人形机器人障碍跑实战：从运动控制到避障算法全解析
简介面向TonyPi人形机器人障碍跑比赛开发与备赛者这是一套覆盖比赛全流程的代码仓库集成机器人运动控制、传感器数据处理、路径规划、实时避障及比赛规则适配等核心模块同时附带嵌入式底层驱动与外设配置资料可帮助理解从硬件初始化到上层决策的完整链路。压缩包共7个文件以Python程序为主配合说明文档、Markdown笔记、附赠Word资料以及开源协议与版本管理配置文件整体仅47KB结构紧凑适合快速阅读和二次开发。目前已有186人学习下载适用于机器人竞赛学生、嵌入式开发人员及相关研究人员。通过该仓库可获得可运行的障碍跑比赛代码框架学习人形机器人步态控制、环境感知与动态避障的实现思路并结合底层驱动配置资料掌握TonyPi平台的调试与部署方法为独立完成赛题迁移或功能拓展提供实用参考。 比赛前夜我把代码仓最后一次push到远程心里其实没底。TonyPi这台双足人形机器人赛道上要完成跨障碍、绕桩、坡道行进这些动作光是让它稳定走完一圈不摔就已经够折腾了。但正是这个项目让我把人形机器人的运动控制、传感器数据处理、路径规划算法和实时避障逻辑完整地串了一遍最后还在障碍跑比赛里拿了个不错的名次。这篇文章就把这个代码仓库项目的完整思路、模块拆解和实测心得端出来给正在做类似比赛项目或想入门人形机器人开发的朋友一个可参考的路线。我尽量不讲虚的直接从“为什么这么设计”和“实际跑起来什么样”两个角度来说。1. TonyPi平台选型与工程框架的搭建思路1.1 为什么选TonyPi而不是轮式或四足平台市面上做障碍跑比赛的机器人平台大多会选轮式小车因为底盘稳定、控制简单一个PID就能把速度调得很顺。但TonyPi这类双足人形平台完全不一样它靠12路总线舵机驱动双腿每个跨步都是一次动态平衡过程控制难度直接上了一个数量级。我选它的原因很直接比赛规则里有人形机器人加分项而且人形结构的越障能力上限比轮式高——跨栏、过桥、上下台阶这些动作轮式车基本做不了双足结构天生就是为这种场景设计的。TonyPi的硬件基础是树莓派做主控通过串口或I2C控制舵机驱动板搭载摄像头、超声波传感器和IMU姿态传感器。这个配置在比赛场景里够用而且开源性好SDK覆盖了基础运动API能让我们把精力放在算法层而不是底层驱动上。1.2 一个按模块拆分的工程目录调试时才不抓狂刚拿到板子的时候我犯了绝大多数人都会犯的错把所有控制代码写在一个几十行的循环里摄像头读一帧、算一次距离、转一次舵机角度看着简单跑起来一塌糊涂——某一个传感器卡住整个运动线程就阻塞机器人在赛道上直接僵住。后来我把整个工程按功能拆成了六个模块每个模块独立成目录、独立跑线程或用消息队列通信tonypi_obstacle_race/ ├── hardware_interface/ # 舵机、超声波、IMU的硬件抽象层 ├── motion_control/ # 步态控制、速度匹配、动作库 ├── perception/ # 视觉识别、距离测量、姿态解算 ├── planning/ # 全局路径规划算法 ├── decision/ # 实时避障逻辑、状态机 ├── competition_adapter/ # 比赛规则配置、赛道元素映射 └── main.py # 主入口串联所有模块这个拆分思路的核心是“硬件抽象”。hardware_interface下的每个传感器和执行器都有统一接口比如read_distance()不管底层是超声波还是红外都返回米制距离set_velocity(vx, vy, yaw_rate)把运动控制接口统一成速度指令。这样一来planning模块和decision模块根本不需要关心舵机角度怎么换算只需要处理“往哪走”和“避开什么”职责清晰调试时也能单独跑每个模块。2. 运动控制模块步态、舵机校准与速度匹配2.1 步态参数是怎么调出来的人形机器人运动控制和轮式机器人最大的差别在步态。轮式车给个速度就直接走人形机器人你需要告诉它步频多快、抬脚多高、跨步多远、身体重心怎么偏移。这些参数共同决定了一个步态周期。我实测下来的经验是步频在0.8到1.2赫兹之间比较稳太快了舵机响应跟不上身体姿态发散太慢了比赛时间扛不住。抬脚高度是障碍跑里最关键的参数。跨栏障碍高度通常在2到4厘米我把抬脚高度设置在略高于最大障碍的前提下尽量压低比如3厘米障碍就抬4厘米。抬太高有两个坏处一是重心波动大落地容易重心不稳二是舵机从最高点到落地的行程变长单步耗时增加。2.2 舵机校准这件事比写算法还重要这是我踩过最大的坑。TonyPi出厂时所有舵机有一个初始零位但这个零位和“机器人站直”的物理零位往往有偏差。如果不同步零位就跑机器人会站成一种微妙的“外八字前倾”姿势走几步就开始斜着偏。校准方法不复杂但必须细致让所有舵机回到中位值然后逐个关节对照机器人的物理直立状态把偏差值记录到配置文件里。比如右腿髋关节舵机ID为3回中时实际偏了5度那就在配置文件里把该关节的零点偏移值设为-5。这个偏移是静态补偿加在协议层发送的舵机角度上。注意舵机协议帧里控制指令是一组ID目标角度速度缓启动时间。校准偏移值必须在这个层面做补偿而不是在UI界面或算法层做否则步态算法里算出来的所有角度都会跟着错位。2.3 从运动指令到坐标位置不只是正运动学path planning算法算出来的输出是一串目标点位比如“前进0.5米右转30度”。但人形机器人和轮式机器人不同它没有轮式里程计那种天然精确的位移编码器底部舵机的角度变化不等于实际位移。这里我做了两步通过正运动学模型根据各关节角度推算髋关节位置和躯干姿态变化。用IMU的加速度计数据做积分和运动学推算结果互相校验。实测下来单纯靠舵机角度推步幅误差累积很快走20步以后位置偏差能到10厘米以上这个误差在绕过障碍物时是致命的。所以运动控制模块必须向外输出“带不确定性的位姿估计”决策模块根据这个估计量来判断是否需要修正。3. 传感器数据处理从零散读数到可用数据的融合3.1 三种传感器各司其职别指望一种搞定所有场景TonyPi基础版自带的传感器是单目摄像头、超声波测距模块、IMU三轴加速度计三轴陀螺仪。三种传感器的特性差异非常大传感器优势劣势适合场景摄像头信息量丰富能识别颜色、形状、赛道标志受光照影响大处理延迟高识别障碍物类型、赛道线、目标标记超声波测距直接响应快波束角大小物体测不准近距离障碍物检测5-40cmIMU姿态感知灵敏不受外部环境影响存在零漂积分会累积误差平衡状态估计、转向角度判断在实际比赛场地里光照条件和反射面是最大的变量。我试过纯视觉识别障碍物结果模拟赛道光线稍微暗一点摄像头识别帧率掉到5帧以下机器人都快到跟前了才反应过来避障根本来不及。后来把策略改成视觉做“目标识别”知道前方是什么障碍物超声波做“距离触发”多近时必须开始规避IMU做“状态反馈”避障动作完成后身体是否回正。三路数据各管一段反而比强行融合更稳。3.2 数据预处理滤波不是炫技是保命传感器原始数据直接喂给算法是不行的哪怕是短暂的一帧抖动都可能让决策状态机误判。比如超声波模块偶尔会跳一个极端大值声波打到斜面上的反射丢失如果不清洗避障逻辑会以为前方空旷直接全速冲过去。这一步我用了通用且有效的处理组合中值滤波滑动平均。超声波连续取5个读数去掉最大值和最小值再对剩余3个求平均。IMU的角速度数据做滑动窗口平均窗口长度10个采样点能明显去掉步态周期带来的高频振荡。另一个关键点是时间同步。三个传感器的采样频率不一样摄像头约30帧/秒超声波约20次/秒IMU约100Hz。如果不做时间对齐决策模块拿到的“同一时刻”的数据实际上是错位的极端情况下会产生“视觉已经看到障碍物但超声波还在报告空旷”的冲突状态。我在感知模块里给每个数据打时间戳决策模块只读取最新一帧打包好的同步数据。4. 路径规划算法全局搜索与局部窗口的配合4.1 全局规划把障碍跑赛道当成带约束的图搜索问题比赛之前赛道的基本布局是固定公布的包括障碍物种类、赛道宽度、各路段顺序。这意味着我们可以提前做一次全局路径规划生成一个粗略的“路线走廊”而不是完全靠实时感知比赛。TonyPi比赛场地通常是一个8字形或S形赛道路径规划可以抽象成“在一张栅格地图上从起点走到终点经过若干必经点位”。我用的是A算法做基础搜索。栅格分辨率设为2厘米一格每一个障碍物占用的栅格向外膨胀5厘米作为安全边界。A的代价函数里不只用欧氏距离还要叠加一个转向惩罚项——因为人形机器人转弯比直行慢得多同样长度的路径拐弯多的那条实际耗时更长。启发函数我采用了曼哈顿距离的变体四方向搜索时为曼哈顿距离八方向搜索时用切比雪夫距离保证启发式的一致性。提示障碍跑场景里不必追求全局路径的绝对最短而应该追求“转向次数最少路径长度可接受”。我在实现里给每次转向加了0.8m的等效距离惩罚效果很不错机器人路径看起来像人在走路而不是折线追击。4.2 局部规划动态窗口法在实际场地里更实用全局路径解决“大方向”的问题但比赛过程中障碍物可能有微小移位比如跨栏被前面选手碰歪了或者临时出现掉落物。这时候需要局部规划实时修正路径。我参考了DWA动态窗口法的思路在速度空间中进行采样模拟未来一段时间内机器人位置的轨迹然后根据“避开障碍物靠近全局路径”两个目标打分选出最优速度指令。DWA很适合人形机器人因为TonyPi的底盘控制本质上仍是双足交替前行速度指令被限制在一个很窄的动态窗口里加速度有限、最大步频有限DWA天然把这种运动学约束包含在搜索空间里。实现时要注意模拟轨迹的步数不能太长TonyPi单步周期约1秒模拟3-5个步态周期足够再长就会因为位姿估计误差太大而失去参考意义。4.3 借鉴改进冲突搜索的思路处理多任务冲突比赛过程中真正难的不是单台机器人绕障而是两台机器人在狭窄赛段相遇时的避让策略。我在全局规划层做了简化版的冲突搜索机制把赛道分成若干路段每台机器人通过特定路段的时间窗提前排好。如果两个时间窗重叠就对其中一台机器人的路径做延迟或局部绕行调整。这个方法参考了张洪琳等人关于改进冲突搜索的多机器人路径规划思路——把“规避冲突”从实时反应层提升到了“预判调整”的规划层比赛时稳定性明显提升。5. 实时避障逻辑状态机驱动的分层决策5.1 状态机比端到端神经网络更适合比赛场景很多刚入门的同学一听到“实时避障”就想着上深度学习、端到端神经网络但比赛场景里这其实不是最优解。障碍跑的障碍物类型是有限的、预知的跨栏、立柱、坡道、弯道、减速带。与其用一个难以解释的黑箱模型不如设计一个显式的状态机把比赛过程拆成清晰的状态FORWARD # 正常前进 OBSTACLE_DETECTED # 检测到前方障碍物 SLOW_DOWN # 减速准备规避 AVOID_CROSS # 跨栏动作 AVOID_LEFT # 从左侧绕过立柱 CLIMB_RAMP # 上坡动作 REALIGN # 回归全局路径 FINISH # 到达终点状态机的核心是转移条件。比如从FORWARD转移到OBSTACLE_DETECTED条件是超声波距离小于40cm且视觉识别判定前方是障碍物从OBSTACLE_DETECTED到SLOW_DOWN条件是距离小于25cm从SLOW_DOWN到AVOID_CROSS条件是视觉识别出是跨栏类障碍且当前步态支持跨栏动作。5.2 安全优先级永远把“不摔倒”放在“完成时间”前面这是我在比赛复盘后总结出来的最重要经验。刚开始调试时我的决策逻辑为了追求速度在接近障碍物前才触发规避动作结果跨栏时重心还没稳定就做下一个转向机器人直接侧倒。后来我把决策模块的安全优先级改为防摔倒 避障成功 速度效率。具体的实现方式是给“避障动作启动距离”设置了一个动态下限根据当前IMU的俯仰角变化率来判断姿势稳定性如果身体晃动幅度大就把避障触发距离拉长15%到20%。换句话说这个状态不是固定的而是会根据实时姿态动态调整的安全阀门。最终比赛时机器人一次没摔这个设计功不可没。5.3 回归全局路径的时机也很讲究避障动作完成后机器人并不会自动回到全局路径上——必须有一个“REALIGN回归”状态。开始时我只做了平移回归让机器人横向挪回原路径但人形机器人横向平移是很别扭的需要在两个方向上交替调整重心反而容易摔倒。后来改成了“先原地转向让正前方对准全局路径的下一个航点然后直行靠近”的方式速度更快也更稳。6. 比赛规则适配模块把赛道策略做成可配置的6.1 每条比赛规则都在变硬编码等于废代码比赛规则每年都在变有的要求按顺序通过5个障碍物有的允许自选路线、按通过障碍物数量计分障碍物间距、跨栏高度也会调整。如果把这些逻辑硬编码进决策模块规则一变整个代码都要重写。我在competition_adapter模块里做了一个规则配置层用JSON文件描述赛道布局和规则参数{ track_name: obstacle_race_2024, course_order: [start, hurdle_low, curve_left, pillar, ramp, finish], obstacles: { hurdle_low: {type: cross, height_cm: 3, trigger_distance_cm: 40}, pillar: {type: bypass, direction: left, bypass_distance_cm: 25} }, scoring: {required_order: true, time_bonus: true} }决策模块运行时只读取这个配置文件根据course_order决定当前目标点根据obstacles里的类型决定触发哪个避障动作。规则变了只需要改JSON策略代码逻辑一行不动。6.2 这个模块帮我省了大量赛前调试时间赛前最紧张的一小时里主办方临时通知“第四关的立柱往右又移了10厘米”。当时周围几台机器人的队伍都在现场改代码有的直接改坐标硬编码手忙脚乱。我这边只改了一行JSON里的bypass_distance_cm参数重启程序就完成了适配。这个模块看似不起眼却是整个项目里性价比最高的一部分投资。6.3 配置项也要做合法性校验这里补充一个实战里的注意点配置模块不能只做读取还要做基本的合法性校验。比如course_order里最后一个点必须是finishhurdle_low的height_cm不能超过机器人最大抬脚高度我设置的是5cm。我加了一个启动时校验函数配置不合法会输出明确错误日志而不是等机器人走到障碍物面前才暴露问题。7. 实测中踩过的坑和最终复盘7.1 坑一舵机过热导致的步态漂移连续调试超过20分钟后TonyPi的腿部舵机明显发热步态开始变得迟钝、发抖。一开始我以为是代码逻辑出了问题查了半天才意识到是舵机温度升高后响应变慢。解决办法有三个方向避免连续高负载测试、增加静止待机动作让部分舵机卸力、在步态参数里加超时保护如果舵机没达到目标角度就触发重试而不是继续走下一步。比赛时我选择保守策略每次跑完一圈让机器人休息几分钟确保舵机温度可控。7.2 坑二摄像头白平衡被赛道红色地垫带偏模拟赛道的红色地垫导致TonyPi摄像头的自动白平衡错误把原本醒目的黄色立柱识别成了接近背景的颜色视觉识别一度失灵。这个问题的根源是自动白平衡对大面积单色场景的敏感。解决方式是锁死白平衡参数使用固定色温模式然后把视觉识别的颜色空间从RGB转到HSV降低光照变化的干扰。此外在比赛前增加了一段白平衡自动校准流程上场前让机器人对着赛道地面原地转一圈手动锁定当前光照条件下的白平衡参数。7.3 坑三DWA局部规划在窄通道里不断重规划当赛道同时出现“两侧障碍窄通道”时DWA容易在通道入口处来回打转因为模拟轨迹里前方和左右都被障碍物占据可行的速度组合很少评分函数来回横跳。这个问题的根因是全局路径的目标点离得太远局部评分里“向目标前进”的权重占比不够。修复方式是在窄通道入口处临时把局部目标点替换成通道中点的投影点并提高“朝目标前进”这一项的权重系数同时降低“保持高速”的权重。调参后机器人过窄通道丝滑了很多。7.4 比赛当天的一个小技巧把传感器预热时间写进主程序比赛当天场地温度和调试房间不一样IMU陀螺仪的零点会漂移一截。如果上场后立刻跑程序转向误差会明显增大。我的做法是在主程序里加了20秒的预热阶段机器人原地站立连续采样IMU数据把前10秒的平均值作为新的零偏基准。这个小技巧让机器人在比赛日的转向精度和调试时保持了一致水平。回头看这个项目最深的体会是人形机器人障碍跑比赛技术难点从来不在某一个单独模块而在于所有模块之间的协调。运动控制、传感器处理、路径规划、实时避障、规则适配每一层都有各自的坑但它们的接口设计决定了整个系统能不能稳定跑完一圈。代码仓库里的结构、模块划分和配置化思路都是在一次次试错中沉淀下来的。如果你也在做类似的比赛项目我建议从一开始就按模块来写把规则参数外置把安全逻辑放在最优先的位置这些看似琐碎的工程习惯最后都会变成赛场上的稳定性。本文还有配套的精品资源点击获取