飞檐走壁组立体赛道实战：从机械调校到图像识别的完整经验

第一次在备赛群里看到飞檐走壁组的赛道图纸时很多人的第一反应都一样这不就是给传统赛道加了两段坡道吗真正带队跑起来才发现立体赛道带来的问题远不是“爬坡”两个字能概括的。车子在平面赛道上跑得越稳上了坡道往往摔得越惨。这个组别之所以叫“飞檐走壁”是因为它对机械结构、摄像头感知、速度控制三块提出了完全不同于传统平跑组的要求。我们车队从拿到规则到最终稳定完赛前前后后花了将近三个月中间翻车无数也踩了不少规则文档里根本没写的坑。这篇文章就围绕飞檐走壁组立体赛道把我们从机械调校到图像识别、从速度规划到联调排错的完整思路和经验整理出来给准备参加这个组别的队伍一个可以直接参考的路线图。1. 立体赛道不是“加了坡道的平面赛”飞檐走壁组赛道结构拆解飞檐走壁组最核心的区别在于赛道从二维变成了三维。平面赛道上车模绝大多数时间保持在同一高度摄像头看到的画面特征是稳定的而立体赛道引入了坡道段车模的姿态、视野高度、重心位置都会随着坡道角度连续变化。如果不先把赛道结构吃透后面所有的调校都是在盲人摸象。1.1 坡道、十字、环岛在立体化之后发生了什么传统平面赛道的元素无非是十字、环岛、S弯、直角弯这些东西单独拿出来每个组别都有成熟的解决方案。但立体赛道把这些元素和坡道组合在一起之后问题就变了。以最常见的“坡道十字”组合为例。平面赛道上过十字摄像头只需要同时识别左右两侧的赛道边界就能判断十字路口的几何位置。但车模在爬坡过程中车头是抬起的图像传感器看到的画面会发生明显的透视压缩远处的十字路口在图像上会被压缩成一条很窄的区域近处的赛道边界却占据了画面的大部分。这时候如果还用平面赛道的边界提取算法很容易把坡道顶端的十字误判成普通赛道或者把坡道过渡区域当成断头路。环岛的情况更麻烦。平面环岛的关键在于内切和外切两条参考线而立体赛道中的环岛通常会放在坡道的顶端或底部。放在坡顶时车模在爬坡阶段根本看不到环岛的完整入口只能在车头刚越过坡顶的瞬间做决策留给控制算法的时间窗口很短。放在坡底时车模从坡顶冲下来速度往往还没降下来就要在低头俯冲的姿态下识别环岛入口对摄像头安装姿态和前瞻距离的要求都很高。1.2 规则里没有写明白的场地细节与测量方式规则文档里规定的坡道角度、坡长、坡高是必须满足的硬指标但有几样东西规则文字没写清楚实际搭建赛道时却非常影响车模表现。第一个是坡道顶端和底端的过渡曲率。很多队伍自建赛道直接用两块木板斜搭出坡道顶端就是一个折角车模速度稍快就会完全腾空。但实际上比赛场地的坡道顶通常会做一定的小圆角过渡虽然规则不会写这个圆角半径但它决定了车模在坡顶是否会出现短暂的悬空状态。悬空意味着后轮失去抓地力编码器测速会失真摄像头因为车身姿态突变看到的图像也会剧烈跳动。我们后期自建赛道时在坡顶和坡底都加了半径为5到10厘米的圆弧过渡实测下来车模通过坡道时的姿态稳定度好了非常多。第二个是坡道的表面材质。规则规定赛道表面一般是深色喷绘布但坡道部分如果用的不是同一批材料反光特性和摩擦力都会不一样。尤其是比赛现场灯光比较杂的时候坡道斜面的反光角度会导致摄像头拍出来的赛道底色突变。建议备赛阶段就用的比较接近比赛场景的灯光角度去测试坡道段别等到了现场再发现坡道段图像全白。第三个是坡道底部与赛道的拼接缝隙。这个缝隙在平面赛道上基本不影响电磁组但对摄像头组来说拼接缝会造成图像上一条固定的横向边缘干扰很容易被误判成赛道边界或者障碍物。处理办法是拼接处尽量用同色胶带完全覆盖确保摄像头看到的是一整块连续区域。2. 底盘与机械先解决“贴地飞行”的物理基础很多队伍在飞檐走壁组上花最多时间调摄像头例程和控制PID却忽略了机械这个最要命的基础。平面赛道上不明显的重心问题、悬挂问题、底盘高度问题在坡道上会被彻底放大。机械没调好之前任何感知结果和控制参数都不可信。2.1 重心配置与悬挂预紧爬坡不抬头、下坡不栽头立体赛道上坡时车模重心会向后轴转移如果重心本来就偏高车头会明显抬起下坡时反过来重心向前压车头会猛烈下沉。这两种姿态都会让摄像头视野发生突变而且会让前后轮的抓地力分配剧烈变化。从我们实测的经验看飞檐走壁组的车模重心应该比同级别的平跑组更低、更靠前。原因很简单下坡时前轮承受的载荷本来就大如果重心靠后后轮会先失去抓地力车尾甩出去就救不回来。重心靠前之后下坡阶段前后轮的载荷分配更均匀车身姿态稳定性明显提升。我们最后把电池和主控板尽量压在前桥附近重心位置大致控制在轴距中点偏前5%左右。悬挂方面很多队伍用的是硬板车身加四个独立弹簧减震但坡道段需要的不是“软”而是“有阻尼的稳定”。太软的悬挂在坡顶会持续上下振荡好几下摄像头画面也跟着上下摆动图像处理算法根本无法稳定工作。我们的做法是调大减震器的预紧力让悬挂在下压后能快速回位而不是反复弹跳。具体调法就是用手按压车身观察它回位是否干脆如果车身回位后还要晃两三下就继续加大预紧。这个过程很靠手感但效果直观比看参数调可靠得多。2.2 轮胎、差速与底盘高度的取舍立体赛道的抓地力是机械方面最容易低估的一环。坡道上的有效正压力下降轮胎需要的摩擦系数比平面赛道高得多。我们测试过几种轮胎最后发现软质海绵胎在坡道上的表现明显好于硬质橡胶胎但海绵胎磨损很快大约跑十圈就要清理一次胎面的积灰否则抓地力衰减非常明显。底盘高度和差速也是需要重新权衡的。底盘太低坡底和坡顶过渡区容易直接刮到地面底盘太高重心升高坡道上的侧倾风险变大而且摄像头视角稳定性变差。我们在微调底盘高度时发现10毫米左右的离地间隙比较合适既不会刮底也能保证较低的整车重心。需要注意的是赛道布面和木板之间往往有细微的厚度差异实际比赛时如果感觉底盘刮地声频繁可以临时把高度上调几毫米。差速的问题主要出现在环岛和十字的组合段。立体赛道的环岛如果带坡度车模在倾斜的板面上转向内外轮的载荷差异很大。如果差速太松外侧轮会有多余滑动导致转向不足差速太紧内侧轮会拖拽车模在坡道上很容易推头。建议在进入立体元素多的路段之前把差速调得比平面赛段略松一点但不要松到过弯时能听到明显打滑声的程度。2.3 从机械上预防坡顶腾空与测速打滑坡顶腾空是飞檐走壁组最大的翻车原因之一。车速超过一定阈值、坡道顶端过渡半径又比较小的时候车模会在坡顶跳起来四轮全部离地。这时候无论传感器多准、算法多优车模都在做自由落体根本不可控。我们的解决思路是双重限速加下压力优化。双重限速指的是在图像识别到坡道之后以及摄像头在图像中检测到坡顶边缘即将消失的时候分别触发两次减速。第一次减速是为了在接近坡顶前就把速度降下来第二次减速是为了保证真正越过坡顶时速度不会因为重力加速度而累积超标。下压力优化就更机械了我们在车模底板后方加了一块角度可调的尾翼通过调整攻角让车模在高速时获得向下的气动压力。虽然智能车速度和真车相差很远气流下压力效果有限但实测在高速段确实让后轮打滑减少了一些尤其在下坡后的加速段作用比较明显。测速打滑集中在坡道起步和坡顶腾空两个阶段。坡道起步时如果电机扭矩太猛后轮会原地空转编码器记下的脉冲数并不代表实际前进距离坡顶腾空时四轮悬空编码器会因为没有摩擦阻力而突然增速。这两处打滑都会污染速度环的输入导致控制算法算出错误的速度偏差。我们最终采用了一个比较笨但有效的办法在控制周期里检测加速度数值如果加速度超过某个物理上不可能达到的阈值就用前一拍的有效速度做推算值替代当前测量值避免控制量突变。3. 摄像头感知立体赛道的图像变化规律与识别策略飞檐走壁组用摄像头做主传感器的队伍占了大多数因为立体赛道的坡道特征最适合通过视觉来识别。但平面赛道上好用的那套图像处理思路搬到立体赛道上很容易失灵。原因在于摄像头看到的画面不仅取决于赛道画了什么还取决于车模当前相对于坡道的姿态。3.1 坡道引起的透视畸变为什么平面赛道的赛道线提取会失效平面赛道上车模始终保持水平姿态图像中的赛道边界大致满足固定的透视关系——远处的赛道变窄近处的赛道变宽这个关系在静态标定后基本不变。坡道上就完全不一样了上坡时车头抬起摄像头仰视前方远处原本应该是地面上的赛道线在图像里会往画面中心收拢边界线会变得比实际更陡峭下坡时车头下俯近处的赛道在图像中占据的面积突然变大远处的赛道几乎压缩到地平线附近。如果边界提取算法假设赛道边界在图像中的斜率和曲率是连续变化的那么在坡道过渡段就很容易提取到错误的边缘甚至把坡道边缘当成赛道边界。我们最初自建坡道跑的时候车模经常在坡道顶部冲出赛道回放图像才发现算法把坡道的侧边当成左边界了。解决这个问题的思路不是增加多少条赛道线拟合规则而是要先“认出”当前处在坡道的哪个阶段再选择不同的提取策略。我们的做法是先把整帧图像分区域处理近处区域和远处区域分别提取边缘然后再按坡道状态做一个加权融合。在平路上近处和远处的边界按同一套透视模型融合在坡道上近处区域沿用平路模型远处区域改用坡道模型两边的边界在图像中间位置做过渡拼接。3.2 动态前瞻给不同的速度配不同的“看得见的距离”动态前瞻这个概念在智能车竞赛里早就有了但飞檐走壁组对它的需求比传统组别更迫切。平面赛道上前瞻距离主要取决于赛道曲率和当前车速立体赛道上还要叠加一个因素坡道会改变赛道可见区域的长短。上坡时坡顶像是一堵墙摄像头看到的最远点就是坡顶的那条横向边缘前瞻距离会被硬生生截断。这时候如果算法还按全速时的前瞻去规划路径就会去拟合一条根本不存在的远处赛道线结果方向打得很激进。我们后来把动态前瞻改成了双通道方案图像能看到的有效赛道末端距离以及车模当前速度对应的安全制动距离两者取小者作为当前的实际前瞻距离。这样在坡道顶端前瞻距离会自动缩短控制算法就不会因为“看不到远处”而乱打方向。下坡时的情况相反摄像头视野会突然变远能看到很远的赛道元素比如环岛入口但如果车模还在高速下坡真正对控制有用的前瞻范围其实还是近中段的赛道信息。所以我们在下坡阶段会主动把远处区域的信息权重降低避免远处的环岛入口在图里出现得太早让算法过早做出转向决策。3.3 逆光、阴影与去反光坡道场景的成像干扰坡道带来的另一个感知难题是成像干扰。比赛现场的顶灯往往安装在固定高度坡道斜面的角度正好会把部分灯光反射进摄像头镜头形成一条横向亮带严重时整行像素全部过曝。我们第一次在比赛场地的灯光下调试时坡道中段的图像白了一大条赛道线完全消失车模直接冲了出去。去反光这里我们试过几种方案。软件层面最有用的是“多曝光融合”也就是在同一个控制周期内用短曝光图像提取近处赛道近处因为有车模阴影亮度相对低用长曝光图像提取远处赛道远处受反光的影响相对小然后再合成。这个方案能解决一部分问题但计算量偏大对主控性能要求高。另一种更简单的方案是调整摄像头的安装角度让镜头尽量避开坡道反光的主要入射方向。我们在反复测试后把摄像头安装角度往下压了大约8度同时加了一个长条形遮光罩反光问题明显改善。遮光罩是3D打印的成本极低强烈建议每支队伍都试试。阴影问题主要出现在环岛和十字周围的防滑垫或者赛道阴影边缘。坡道高低差会在赛道上投下斜向的阴影图像里阴影边界和赛道边界叠在一起灰度阈值就容易误判。我们最终没有用太复杂的阴影消除算法而是在图像预处理阶段加了一个自适应灰度拉伸按行动态调整二值化阈值让每行图像独立选取阈值。这个方法处理坡道阴影特别有效因为阴影方向通常是固定的斜向按行处理能保留赛道边界的连续性同时把阴影干扰抑制掉。4. 控制与速度规划爬坡降速、下坡限幅、出坡回稳飞檐走壁组的控制难点不在于某一个单独的弯道而在于速度规划要跟着赛道高度变化做连续调整。这里说的“高度变化”不只是坡道本身还包括坡道前后衔接的加速段和过弯段。一条适应立体赛道的速度状态机要比传统平面赛道的状态机多出好几层判断。4.1 坡道识别后的速度状态机我们车队的速度规划最终收敛成了一个有限状态机核心状态包括平路巡航、接近坡道减速、爬坡稳定、坡顶低速过渡、下坡限速、出坡加速恢复。这套状态机切换的核心触发条件是摄像头对坡道的识别结果。接近坡道减速状态的触发条件是摄像头在图像上部检测到明显的横贯赛道边界线并且该边界线上方的灰度区域具有统一的斜面特征。这个判断必须在距离坡道还有大约0.8到1.2米就完成否则减速距离不够。爬坡稳定状态下我们采用定油门控制而不是纯速度PID控制因为坡道的角度和轮胎抓地力状态变化很快速度PID很容易产生振荡。定油门控制是给定一个固定的PWM占空比让车模以相对稳定的小幅加速度持续爬坡到坡顶再切换。坡顶低速过渡状态是整个状态机里最关键的一环。车模越过坡顶的瞬间前轮先落地、后轮后落地抓地力恢复有先后如果此时还有较大的驱动力车模就会因为后轮突然获得抓地力而往前一窜。我们在这个状态下会把驱动力直接降到0让车模完全靠惯性滑过坡顶等图像确认赛道恢复接近水平后再重新起步。4.2 PID在不同坡度下的参数切换策略很多队伍在整个赛道上只用一套PID参数这在平面赛道上跑得通立体赛道上基本不行。坡道上车模的动力学特性发生了根本变化上坡时阻力大幅增加等效于电机负载变大同样的PID参数下纵向速度响应会明显变慢下坡时重力分量变成加速力等效于系统增益变大原参数容易引起超调。我们摸出来的参数切换策略是“坡度分段、参数渐近”。具体做法是根据摄像头识别出的坡度角把赛段分为平路段、缓坡段、陡坡段三类每类赛段对应一套P和I参数。为了避免参数在边界处跳变我们把参数不是直接硬切换而是按坡度角的连续值做线性插值。比如缓坡段和陡坡段的Kp分别是15和11那么当坡度角从缓坡过渡到陡坡时Kp就按角度比例从15平滑过渡到11。这样车模在坡道过渡区不会因为参数跳变而产生顿挫感。方向环同样需要换参数。平面赛道的方向环追求快速响应增益往往调得比较高坡道上方向环增益过高的话车模对图像噪声的敏感度会放大转向舵机会高频抖动。我们最终把坡道段的转向P值降到了平路段的六成左右并且把D值适当调大利用阻尼来抑制抖动和振荡。4.3 下坡与出坡的稳定过程从“摔”到“稳”下坡段最怕的不是速度本身快而是速度在极短时间内从很低飙升到很高让控制算法来不及反应。所以速度规划里下坡段要做的核心动作是“限幅”而且限的是减速度而不是速度——如果单纯限制最大速度车模会在坡顶前疯狂刹车然后把坡底加速段也浪费掉。我们的做法是给下坡段的加速度设定一个负上限也就是允许的最大加速幅度。这个限幅要保证车模在坡底前还能把速度压到一个安全过弯阈值以下。具体计算的话可以根据坡道高度差估算出到达坡底时如果不加控制的速度再反向算出应该限制的加速度上限值。这套逻辑需要在代码里根据当前坡度角实时更新限幅值而不是写死一个常数。出坡回稳阶段最大的问题出现在视觉上。从坡底回到平路的瞬间车模姿态会有一个从低头到水平的快速变化摄像头图像会突然“抬平”远处的赛道线在图像中的位置发生大范围偏移转向控制容易在这时候抽风。我们的经验是在这个阶段对转向输出做一个限速处理路径跟踪给出的目标转角如果前后两帧差得太多就按最大角速度限制它的变化斜率防止舵机猛打。这个限制只在下坡后大约0.4秒内启用过了这个时间窗口就恢复正常灵敏度。5. 实测踩坑从频繁翻车到稳定完赛的排查链路立体赛道的调试过程一定是反复翻车的翻车不可怕可怕的是不知道怎么查。这里把我们车队遇到过的最典型的一个问题完整复盘一遍从现象到根因到修复一条链路拉出来给其他队伍一个排查思路的参考。5.1 现象记录坡顶图像全白与转向甩尾我们在第二版样车上遇到了一个非常奇怪的组合症状正常平路赛段跑得很稳一上坡道车模过了坡顶之后在图像上能看到一大片白色区域紧接着车头就往右侧甩直接冲出赛道。最初我们以为是反光问题但试了角度调整和遮光罩都没根除。然后我们怀疑是转向过载但把转向灵敏度降得很低之后车模确实不甩尾了却在坡顶变成了直行冲出赛道完全没有转向动作。这两个现象叠加在一起指向一个很矛盾的方向一方面控制好像过于敏感甩尾另一方面又好像完全没响应直冲。我们一度陷入困惑翻来覆去调了两天没有进展。5.2 排查顺序先机械后感知再控制后来我们强制自己按“先机械、再感知、后控制”的顺序排查才找到了真正的元凶。机械环节我们先检查了坡顶是否腾空。通过慢动作视频回放确认车模在坡顶会有一个轻微跳起但幅度不大四轮离地时间不超过两个控制周期。这个信息很关键因为这意味着在腾空瞬间车模姿态发生了异常重力让前轮先触地后轮再触地车身会有一个仰-俯的俯仰振荡。感知环节接着检查了俯仰振荡期间的图像。我们发现在车模仰起的那一帧摄像头拍到的画面几乎全部是白色——因为镜头正对着赛道顶部的白色墙面和灯光。在车模前轮先触地俯下的那一帧图像里又只有近处一小块赛道远处全部是白色。本质上不是反光问题而是摄像头视角被俯仰振荡甩出了赛道范围。控制环节再检查和图像错乱匹配的转向输出。由于图像里白色区域被误识别成大面积赛道很多二值化算法会把亮区当成赛道算法的边界提取结果会严重偏向一侧导致转向指令瞬间满偏。这既解释了大角度甩尾也解释了当我们将转向灵敏度降得太低时满偏指令根本无法在有限时间内把舵机打到位车模看起来就像完全没有反应。5.3 根治与验证最终参数与赛道成绩对照根因清楚了修复方案就变得很明确。第一机械上进一步压低了底盘高度同时给弹簧减震加了更厚的阻尼垫片让俯仰振荡的幅度从大约6度降到大约2度以内。第二感知上加了姿态异常的检测逻辑当图像中白色像素占比超过85%并且持续超过3帧时就判定为“坡顶盲区”此时强制保持上一拍的赛道偏差输出而不是把当前帧的错误偏差喂给控制器。第三控制上给转向输出加了变化率限幅即使短期内出现错误的满偏指令舵机也不会瞬间打满。这三项改动落地之后我们在同一段立体赛道上跑了十圈翻车次数从之前平均每圈一次降到了零。完整赛段的成绩也从第一次跑通的14秒8提升到了12秒4其中坡顶段的通过时间从大约1.5秒压缩到了0.8秒。这组数据对比很清楚地说明了问题坡顶腾空导致的姿态突变是核心矛盾图像误识别是次生矛盾转向满偏是最终表现三者要一次性一同解决只调任何一个环节都只会按下葫芦浮起瓢。这是我们在整个备赛周期里踩过的最深的一个坑复盘下来最重要的教训就是当车模出现组合型异常症状时千万不要急着改算法或者调参数先把整个信号链路从机械到感知到控制完整捋一遍定位到根因再动手效率会高得多。6. 备赛节奏与团队协作把立体赛道的调试时间花在刀刃上飞檐走壁组的工程量明显大于传统平跑组机械、感知、控制三条线都要动如果联动不当很容易出现“调试时间黑洞”。我们第一版车花了四个星期才跑完第一个完整的立体赛段后来总结出一套协作节奏整个效率提升了一大截。6.1 分模块开发与联调顺序我们的建议是把队伍拆成三个小组机械组负责底盘、悬挂、减震、轮胎等物理层感知组负责摄像头标定、图像处理、坡道识别等视觉层控制组负责速度状态机、转向PID、参数切换等逻辑层。三个组各自有独立的测试赛道段可以先在自己的“实验室环境”里把模块跑通再进完整赛道联调。联调顺序上有一个关键原则先机械后感知再控制。机械组必须先把坡道段的姿态稳定性调到合格水平感知组才能拿到稳定的图像输入感知组的坡道识别逻辑必须先跑通控制组的速度状态机才有可靠的触发信号。我们一开始跳过机械直接调控制结果控制参数反复被机械抖动干扰白费了将近两周的时间。稳定下来的联调顺序是机械自测通过坡顶俯仰角小于3度→ 感知自测通过坡道识别准确率大于95%→ 控制自测通过速度状态机切换无卡死→ 三人联合在场调试完整赛道。每一层都有明确的验收数据门槛不达标不进入下一层。6.2 仿真环境与实车闭环用数据说话立体赛道参数多、状态切换频繁完全靠真车盲调效率很低。有条件的话建议在主控端实现数据回传协议串口或无线把每帧图像的关键特征量赛道路径偏差量、坡度角估算值、状态机当前状态、电机输出、转向角度和实际车速同步录下来回实验室后用上位机按帧回放。这套做法最大的价值在于它能在“电脑上复盘翻车全过程”而不是“靠肉眼盯车跑”。我们经常在回放数据时发现某个状态切换的触发帧实际上在好几十帧之前就已经应该触发只是因为图像特征不明显被延迟了导致整个坡道段的速度规划整体慢了一拍。这种问题如果不到数据回放里看根本发现不了。仿真上我们用的是最简单的整车运动学模型根据电机输出和转向角度推算下一帧的车速和位置然后用一套简化的图像生成来模拟带坡道的赛道画面。这种仿真的精度不足以指导最终PID参数选型但非常适合用来验证状态机逻辑有没有死锁、模式切换有没有漏触发。仿真的意义在于让逻辑先闭环真车的意义在于校准参数和暴露物理层面的问题两者不能互相替代。6.3 最后两周的优化优先级排序到了比赛前两周千万不要再大改机械结构和核心算法了。这个阶段做的是“减风险”而不是“提性能”。我们当时参考了往届队伍的备赛清单结合自己的情况把优化优先级排成了三层。第一优先级是稳定完赛车模能在立体赛道上连续跑十圈不翻车、不冲出赛道、不宕机。这一层不过关其他都是空谈。第二优先级是适应变化简单更换轮胎、加配重、调整摄像头曝光参数这类小改动可以继续做但每一项改动都必须跑完整圈验证防止引入新问题。第三优先级才是性能优化在稳定完赛的基础上通过微调速度状态机的巡航速度上限、略微压低坡道上下限速阈值等方式把圈成绩从“能跑”提升到“跑得快”。最后两周还应该安排至少两次全程模拟赛完全按比赛流程从检录、发车到连续跑多圈模拟现场的灯光环境、场地干扰和可能出现的突发情况。我们第一次模拟赛时就发现连续跑第五圈之后轮胎积灰导致坡道段轻微打滑后来在比赛现场也遇到了类似情况因为提前模拟过处理起来就从容很多。另外有一点容易被忽略飞檐走壁组因为赛道立体化现场架设发车区和检修区的物理空间比平面组更受限。提前把车模的检修口、拨码开关位置、电源开关位置都设计在顺手的地方比赛现场能省下非常多的调整时间。这些小细节平时不起眼到了现场就是实打实的救命稻草。回顾整个备赛过程飞檐走壁组带给我们的收获不只是一块奖牌更重要的是逼迫我们改变了很多平面赛道上固化的调试思维。立体赛道把“机械-感知-控制”这条链路的每一环都拧得更紧任何一个环节的问题都会被坡道无限放大但也正是这种放大效应让每个问题都更容易暴露、更容易被彻底解决。如果这支文章能让看到这里的队伍少走几步弯路那这个经验分享就值了。