1. 现场初印象轮腿穿越组的赛道比想象中更“立体”总决赛场馆里轮腿穿越组的赛道大概是我见过最有立体感的一条正常路段、独木桥、台阶、还有需要“迈”过去的障碍。和传统竞速组那种贴地飞行的感觉不同轮腿车跑起来车身是带着俯仰动作的——过桥时车身立起来、轮子精准压上窄桥面下桥时重心后移、前轮又轻巧落回地面。边上第一次来看比赛的人问了一句“这到底是车还是机器人”其实这就是最近几年智能车竞赛里讨论度很高的“轮腿”形态。很多人听到“英飞凌轮腿穿越组”第一反应是“英飞凌是不是提供了什么东西”。确实如此。英飞凌作为这个组别的合作伙伴从主控芯片、驱动方案到调试工具链都给了参赛队一套完整的硬件和软件支撑。但更核心的问题是轮腿穿越这个命题本身到底在考学生的什么能力我在现场蹲了大半天采访了十几支队伍看了几十圈调试感触很深。这篇文章主要想写几个层面的东西一是轮腿穿越组区别于其他组别的技术重点在哪里二是英飞凌的生态在这个项目里具体作用在哪些环节三是我在现场看到的各车队方案差异和实战中的坑四是如果你准备参加下一届哪些地方值得提前准备。内容不吹不黑都是这次现场采访整理出来的实际操作经验。2. 轮腿穿越组到底考的是什么不是“跑得快”是“过得好”2.1 从“平衡”到“跨越”命题思路的升级早几年智能车竞赛里有平衡组车的形态是两个轮子夹一个车身靠倒立摆原理保持直立跑起来像平衡车。那类车的问题是悬空的前后两端让它在平地上如鱼得水但只要遇到坡道、沟坎尤其是需要“上车身”而不能靠惯性冲过去的情况就会很尴尬。轮腿穿越组本质上把“平衡”升级成了“移动形态切换”既要能在平地上高效滚动又要在需要时像腿一样迈过障碍。我在现场听到一个比较形象的比喻纯轮式结构的地图是“有没有路”纯腿式结构的地图是“能不能踩”轮腿结构的地图是“轮子能滚则滚、滚不过去就抬腿”。这种思路等于逼着参赛队同时解决两套问题一套是动态平衡的稳定性另一套是姿态规划和障碍跨越的决策逻辑。2.2 赛道元素拆解每个障碍对应一种控制难题虽然每年的具体赛道元素会有些调整但轮腿穿越组里几类典型障碍基本是固定的我按现场观察总结一下独木桥桥面宽度通常只比单侧轮稍宽一点车身上桥那一刻必须保证轮子落点精准。这里考验的不是PID的响应速度而是编码器里程计和陀螺仪数据的融合质量。车身只要歪1-2厘米上桥瞬间就偏出去了。台阶台阶的高度对轮腿来说属于“可以抬上去”的级别但难点是在抬腿过程中另一侧轮子仍然在驱动车身前进两个动作必须解耦。很多队伍在低阶台阶上能过到了高阶台阶就翻车本质是俯仰角速度和前进速度的同步没有做好。十字坑/沟槽这种障碍轮子没法直接滚过去必须把重心先移到一个轮子上另一个轮子悬空跨越。我采访的一支队伍告诉我说这个动作本质上是一种“半静态的步态规划”车要先停稳、再抬腿、再跨、最后落腿全过程中车身倾角要控制在很窄的范围内。这些元素放在一起其实已经把比赛考察的方向写得很清楚了低速高精度的位置控制、多姿态切换的稳定性、以及机械结构设计的冗余度。光会调一个速度环在轮腿组里是不够的。2.3 为什么很多控制方法在仿真里好用、上了赛道就废这个问题我在现场问了不止一支队伍得到的高频回答是仿真里的摩擦力、地面刚度、车体形变都是理想化的而实际赛道的地面是拼接的、桥面是有缝隙的、轮胎是打滑的。轮腿车做动作时重心高度变化大转动惯量也随着姿态变化很多在固定工况下调好的控制参数换个障碍就失效。有个队讲了一个很典型的例子他们在调试台阶动作时用的是一块自带的木板摩擦力偏大结果到了总决赛赛道上场地那种略带光滑的表面让轮子在抬腿瞬间轻微打滑整个车就歪了。这让我意识到轮腿穿越组与其说是算法竞赛不如说是系统鲁棒性竞赛——所有环节都要接受真实环境的不确定性。3. 英飞凌在这条赛道上提供了什么从芯片到工具链的完整闭环3.1 TC264和TC377为什么参赛队普遍选AURIX现场看了一圈轮腿穿越组的主控芯片集中在英飞凌AURIX家族的TC264和TC377上。这两颗芯片有一个共同特点多核TriCore架构单个核既能跑通用计算又能做实时控制在跑姿态解算的同时还能生成PWM。对轮腿车这种“算力需求不算极端但任务种类多”的场景这种架构很合适。TC264是很多队伍的入门选择三个核的分工可以做得非常清晰一个核跑IMU姿态解算和平衡控制一个核跑路径规划和障碍识别逻辑另外一个核跑通信和交互任务。TC377的资源更充裕我采访的一支队伍把它用在更复杂的传感器方案上其中一个核专门跑摄像头数据的预处理。选型逻辑其实很简单先用TC264把基本功能跑通如果发现中断塞车或者内存不够再往上换TC377代码迁移成本在AURIX家族内部是可接受的。3.2 ADS、iLLD和GTM这几个东西分别解决什么问题很多第一次接触英飞凌的同学会被ADS、iLLD、GTM这些名词搞晕。我大概梳理一下它们的分工ADSAURIX Development Studio英飞凌官方的集成开发环境基于Eclipse国内同学用得比较多的是它的免费版本不需要额外注册复杂的License装完就能建工程。对认真准备竞赛的队伍来说这个工具链的易上手程度直接影响前期进度。iLLD底层驱动库相当于芯片的“驱动全家桶”。PWM、ADC、SPI、CAN这些外设的初始化不用自己对着寄存器手册翻直接调用接口。不过我看了一些队伍的代码发现他们并不是无脑用iLLD在PWM占空比更新这类对时间敏感的地方还是选择自己写寄存器级别的操作减少一层函数调用的不确定延迟。GTM英飞凌的通用定时器模块英文全称Generic Timer Module。它在我采访的队伍里被高频提到主要用来做PWM生成和输入捕获。轮腿车需要精确控制两个轮子的驱动占空比同时要捕获编码器脉冲GTM可以把这些时间关键任务从CPU里解放出来让三核有机会去跑更上层的逻辑。3.3 PMSM驱动方案轮毂电机背后的FOC另一件在现场听到最多的东西是“英飞凌PMSM驱动系统解决方案”。轮腿车用的驱动电机多数是无刷直流/永磁同步电机也就是PMSM。和我们熟悉的直流减速电机不同PMSM的控制必须做磁场定向控制FOC也就是实时跟踪转子位置把电流矢量解耦成交轴和直轴分量再分别控制。这个过程牵扯到三相PWM互补输出、母线电流采样、转子角度估算复杂度比普通直流电机高一个数量级。英飞凌在这个方案里提供了参考设计包括功率板、栅极驱动芯片和基于AURIX的FOC算法框架。我和现场一支队伍的交流结果是他们并没有从头写FOC而是从英飞凌的参考方案改造来的替换了控制参数、加入了针对轮腿车低速工况的保护逻辑这让整个项目节省了至少三周时间。对目标不是研究电机控制本身、而是把轮腿车整体做好的队伍来说这套方案几乎是必经之路。提示如果你是第一次做PMSM驱动不要一上来就自己搭逆变器和写电流环。先把官方的参考方案跑起来再逐步替换里面的参数和策略这样踩坑量至少减半。4. 采访中看到的三种典型技术路线各有取舍各有风险4.1 路线A双轮自平衡抬腿动作这是最多队伍选择的路线。车常态保持轮腿姿态两个驱动轮在车身中部偏后位置前部有一段悬臂结构通过舵机或丝杆改变前臂的角度相当于“腿”。行驶时靠后轮驱动维持平衡遇到障碍时改变前臂角度把车身顶起来让障碍跨过去。优点是很直观控制逻辑接近已经成熟的平衡车方案上手快。缺点是机械结构冗余不够——整台车的重心在后轮附近前臂其实承担了很大的压力一旦前臂结构刚度不足抬腿时车身会发生肉眼可见的抖动。现场有队伍的前臂是碳纤维板加金属关节有的则是3D打印件后者的故障率明显更高。4.2 路线B多姿态轮腿轮子内嵌在腿末端另一种方案是把轮子装在腿的末端腿部可以在一定范围内摆动相当于每个轮子都是腿脚一体的结构。正常行驶时四个轮子着地稳定性和负载能力都优于双轮方案遇到台阶时前腿抬起、跨上、后腿跟上动作幅度比路线A大。这种路线在机械设计上最复杂但控制上反而比双轮自平衡简单——因为不需要时刻维持动态平衡跨障碍时可以进入一种准静态状态。参赛队反复调试的主要是步态规划也就是四条腿什么时候抬、抬多高、前进多少配合车身俯仰传感器做闭环。问题在于机械件受力复杂现场就能看到有几支队伍因为连杆断裂退赛。4.3 路线C混合感知策略的差异轮腿组的感知方案不像视觉组那么卷但也已经出现了明显分化。基础方案是编码器IMU完全靠里程计推算位置遇到障碍靠固定位置的开关或红外触发进阶方案是加摄像头或激光测距提前识别障碍类型动态调整跨越策略。从现场来看纯编码器方案的稳定性和赛道环境强相关一旦轮胎打滑或者机械有微小的扭曲里程计就会漂移。加摄像头的队伍又普遍面临一个调度难题图像识别要占算力姿态控制也要占算力两件事协调不好就会卡顿。这也是前面提到TC264/TC377多核优势最能体现的地方。4.4 一张表看清三种路线的取舍对比维度路线A双轮自平衡路线B多姿态轮腿说明机械复杂度中高路线B的关节多装配公差要求高平地速度高中路线A的姿态可压低风阻障碍跨越能力中高路线B能应付更高更大的障碍控制难度高动态平衡中准静态步态路线A全时段不能出大偏差调试成本中高路线B的步态参数组合爆炸参赛队选用量多少路线B对机械加工要求高这个表格不是在分优劣而是想说明现场真正跑出成绩的队伍往往是把某一条路线的短板用其他方式补上了。比如有些走路线A的队伍把自平衡只作为低速状态的一种姿态高速时直接进入抱死平衡模式用机械结构撑着跑反而把稳定性拉上去了。5. 实战调试的坑那些代码注释里不会写的经验5.1 机械重心永远排在调参前面这个问题我每一届比赛都会反复看到很多队伍花大量时间调PID但车就是抖、偏、翻最后发现是电池放的位置不对、车架左右质量不对称。轮腿车在抬腿动作中重心变化对控制的影响比普通两轮平衡车更大因为姿态角度变化范围大重心的力臂也在变。一个可靠的做法是在开始调控制算法之前先把电池、主控板、电机驱动板都固定好然后把车放在平面上手动测量静态倾角下的力矩分布。有条件的话可以在车架上标出重心位置确保它在车体对称面附近。现场有一支队伍在电池安装位置上做了滑轨通过微调电池前后位置来改变动态响应的“手感”这个思路很聪明相当于在机械层面给控制参数增加了一个可调旋钮。5.2 IMU数据不是“读了就能用”零漂和滤波才是关键采访中好几个队伍都提到过同一种崩溃瞬间静止平放的时候车显示的角度数据一直在缓慢漂移跑起来之后融合出来的姿态角有高频毛刺导致PWM也在高频抖动。这是IMU原始数据的典型问题——加速度计对振动敏感陀螺仪有零漂直接拿原始值做控制几乎没有能稳的车。处理办法通常分两步第一步是陀螺仪零偏标定上电后静止采样几百个点取平均作为初始零偏在后续计算中减掉第二步是加速度计和陀螺仪的融合可以用互补滤波也可以用卡尔曼滤波。现场队伍里两种都有互补滤波调好了一样能用卡尔曼滤波的参数更少但实时性要自己测。我特意观察了一下真正跑得稳的队伍IMU的采样频率和PWM的更新频率之间是经过计算的。一个比较常见到组合是IMU 500Hz采样经过滤波后输出100Hz左右的姿态角PWM更新频率在10kHz以上。三者之间用异步方式协同避免在中断处理里做太多浮点运算导致时序抖动。5.3 中断优先级和任务调度三核也怕“挤牙膏”英飞凌的三核架构看着资源很够但其实每个核上要跑的任务稍微一多中断设计如果粗糙照样会卡。最常见的错误是把所有传感器数据读取都放在同一个定时中断里一次中断里既读IMU又读编码器还读摄像头数据处理时间超过了定时周期系统就开始累积延迟车就会出现间歇性抽搐。比较好的做法是把不同频率的任务分层高频的电流环、PWM更新放最低级别中断或交给GTM中频的姿态解算固定在IMU就绪中断里低频的路径逻辑放到主循环轮询。三核之间的数据交换尽量用英飞凌的片内邮箱机制避免用共享内存加野锁的方式后者的总线竞争问题在某些状态下非常难查。5.4 现场突发状况的处理留好“安全模式”是最被低估的设计总决赛现场每支队伍的调试时间很紧张车在赛道上出现异常姿态的频率也远高于训练场。我在看台边注意到一个有意思的细节不少成绩不错的车队车上有一个紧急复位按键同时软件里做了一个“自动跌落保护”逻辑——当检测到车身倾角超过某个阈值并且持续一段时间就立即停止输出而不是继续试图拉回来。这类逻辑看似和成绩无关却直接决定了在总决赛环境下车是稳一下还是飞出去。这块属于典型的“平时用不上、关键时候救命”设计。我建议所有准备下一届的队伍在代码里强制做一个安全状态机正常控制、启动保护、急停锁死三个状态之间的切换逻辑必须在赛前反复验证触发条件避免在关键时刻因为误判反而让车失控。6. 写在下一届出发前来自总决赛现场的几个实用建议看完整个总决赛回到准备阶段我想把现场观察到的、能够真正落地执行的建议整理一下。如果明天你就要带队准备轮腿穿越组下面这几件事优先级最高第一尽早把机械结构定型。轮腿车的机械迭代周期比电控长得多3D打印虽然便宜但每改一版结构都要重新调重心、重新标定传感器。现场成绩好的队伍花的机械调试时间普遍比代码调试时间更长。第二选型尽量贴近官方方案。英飞凌的AURIX开发环境和PMSM参考设计覆盖了从底层驱动到电机控制的完整链路。自己从头造轮子也许能学到更多但竞赛的决赛时间是公平的把时间花在更有区分度的地方才能走得更远。第三老老实实把自己的调试数据记录下来。每个障碍的通过参数、每组PID的响应曲线、不同摩擦系数下的表现都记下来。现场有不少队伍的失利不是因为方案不行而是因为赛中调整之后无法快速回退到之前验证过的最优参数。轮腿穿越组这个赛项明年大概率还会继续出现。它的难度不在于某个单一领域而是在于它逼着你在机械、控制、算法、电子四个方向上做到基本没有短板。这也是为什么我每次看这个组别的比赛都觉得收获很大。希望这篇现场采访整理对正在准备的同学有帮助。