尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
四足机器人爬楼梯控制方法与系统实现
简介一份发明专利申请公开文本主题为四足机器人爬楼梯控制方法及系统面向机器人运动控制、步态规划及嵌入式系统开发等方向的工程师与研究人员。该发明针对现有四足机器人爬楼梯控制方式复杂、成本偏高的问题提出通过识别台阶参数、调整四足机器人相对位置与姿态、再计算落足点位置与身体位置的分层控制方案并具体公开了各控制步骤的参数获取方式、运动控制器指令生成逻辑以及对应的第一识别模块、第二识别模块和调整模块等系统组成。文档共1个PDF文件大小约412KB包含权利要求书、说明书及附图属于完整的专利全文资料既可作为技术方案学习的原始材料也可用来参考发明专利的撰写结构与权利要求布局。目前已有84人浏览学习适用于需要了解四足机器人台阶感知、落足规划或控制系统设计的读者。1. 四足机器人爬楼梯为什么这事比想象中难得多四足机器人的宣传视频里爬楼梯往往是最帅的那几秒——四肢交错、机身平稳几步就上了一层楼。但真自己上手调过才会知道这玩意儿是“从入门到放弃”的高发区。原因不复杂平地上跑靠的是动力学和步态规划而楼梯把地形从连续变成了离散每一级台阶都是对感知、规划、执行三套系统的连环拷问。四足机器人爬楼梯控制方法及系统相关的方案核心要解决的就是“看见台阶、踩稳台阶、不倒着摔下来”这三件事。这个标题背后其实是一个完整的控制系统设计不是某个单一算法能糊弄过去的。适合谁看打算在四足平台上做复杂地形运动控制的开发者、研究机器人步态的学生、以及想评估“这平台能不能自己上下楼”的集成工程师。读完你会知道一套能跑的爬楼梯方案最少需要哪几个模块、每个模块各自做什么、参数调哪些、哪些坑是躲不开的。2. 爬楼梯的底层逻辑从步态时序到状态机2.1 为什么平地步态直接挪到楼梯上会翻车四足机器人平地上最常见的步态是 trot对角小跑四条腿两两一组对角的腿同时迈。这种步态在平地上效率高、稳定性好但放到楼梯上问题很大trot 步态迈步时重心基本在支撑多边形中间而楼梯台阶的支撑面是离散的一条腿踩到上一级台阶、另一条还在下一级时支撑多边形会变得很窄稍微一晃就出界。另一个问题是高度差。台阶高度通常在 15 到 25 厘米之间而四足机器人的髋关节到脚底的距离可能也就三四十厘米。抬腿高度必须精确覆盖台阶高度抬低了绊脚抬高了重心起伏过大、消耗额外扭矩。平地步态里根本不会精确控制脚底轨迹的最高点只关心落脚点到了楼梯上必须把“脚底轨迹形状”提到和“落脚点”同等重要的位置。常见的做法是上楼梯时切换成类似 walk 的静态步态保证任意时刻至少三条腿着地下楼梯时则相反利用重力但控制冲击。步态切换不是手动触发而是由状态机根据楼梯检测结果自动完成。核心原则是在离散地形上支撑面积小、稳定性储备低必须牺牲速度换稳定。2.2 控制架构感知→规划→执行的三级流水线一套能用的爬楼梯系统我习惯把它拆成三层每层之间有明确的接口定义第一层是感知层。负责回答“楼梯在哪里、台阶多高多宽、当前机器人相对楼梯的角度和距离”。注意这里不是“检测到楼梯”就完事而是输出一个结构化的楼梯模型台阶数量、每级的高宽、楼梯的倾斜角度、机器人在楼梯坐标系中的位姿。第二层是规划层。拿到楼梯模型后先做落脚点规划确定每条腿每一步踩在哪一级台阶的什么位置。接着做身体轨迹规划也就是机器人躯干在爬楼过程中的三维路径。最后是步态时间规划决定哪条腿什么时候抬、什么时候落。第三层是执行层。把规划出的脚底轨迹和躯干轨迹变成关节角度指令交给底层关节控制器。这一层还要做稳定控制实际走得和规划偏了怎么拉回来。三层之间的数据流是有讲究的。感知层输出的是“楼梯模型 位姿估计”规划层输出的是“落脚点序列 躯干轨迹 步态相位序列”执行层接收的则是“关节角度/力矩指令”。我见过不少团队把感知结果直接接到关节控制上中间没有规划层结果就是机器人跟喝醉了一样每步都在纠正上一步的误差越纠越乱。2.3 状态机设计平地、接近、攀爬、跨越、过渡爬楼梯不是一个连续过程而是五个阶段的串联用状态机管理最稳妥平地行走阶段机器人正常 trot不断检测前方地形。接近阶段确认楼梯参数并生成攀爬计划同时调整自身位置和朝向正对楼梯。攀爬阶段一步一台阶地爬升躯干保持水平或略微前倾。过渡阶段到达楼梯顶部后最后一步往往是高度落差最大的一步从最高一级到平地容易踩空或重心冲过头。下楼梯阶段同理但台阶检测的方向和步态相位相反。每个阶段切换需要一个清晰的条件。我常用的做法是接近阶段的条件是“楼梯模型置信度超过阈值且距离小于某个值”攀爬阶段的切换条件是“前腿已经踩上第一级台阶且后腿离开平地”过渡阶段的切换条件是“前腿踩到楼梯顶平面且台阶数计数达到预期”。状态机的好处是每个阶段的控制参数可以单独调不会因为平地参数带入攀爬阶段导致异常。坏处是状态切换瞬间可能产生指令跳变所以每个状态切换时要做轨迹的“连续性处理”——简单说就是切换后第一帧的躯干期望位姿要和切换前最后一帧尽量接近防止速度突变。3. 把楼梯变成模型感知与状态估计的实现要点3.1 台阶检测点云分割还是单线激光雷达楼梯检测有一个很实际的取舍用深度相机做点云分割还是用单线激光雷达做扫描匹配。深度相机的优点是能直接得到三维几何信息但室内外光照变化、玻璃台阶、深色台阶都会让点云质量变得很不稳定。单线激光雷达在结构化环境里非常可靠但只扫一个平面需要配合机器人俯仰角来推算台阶距离。我实际更推荐两者结合单线激光雷达负责测距和台阶边缘的精确位置深度相机负责确认台阶立面和平面之间的夹角关系避免把坡道误判成楼梯。如果算力有限只选一个选单线激光雷达因为爬楼梯这事距离信息的可靠性比三维完整性重要得多。台阶建模的核心是“从点云或扫描数据中提取出周期性的高度突变”。单线扫描的数据是一条二维曲线楼梯会表现为一个阶梯状的折线。可以用差分法相邻扫描点的 z 值差超过阈值就认为是一个台阶边缘点。连续检测到 N 个等间距、等高度差边缘点就拟合出楼梯模型。// 台阶边缘检测伪代码Python风格 def detect_stair_edges(ranges, angles, step_height_min, step_height_max): edges [] for i in range(1, len(ranges)): delta_z ranges[i] * sin(angles[i]) - ranges[i-1] * sin(angles[i-1]) delta_x ranges[i] * cos(angles[i]) - ranges[i-1] * cos(angles[i-1]) if abs(delta_z) step_height_min and abs(delta_z) step_height_max: edges.append({ x: delta_x, # 相对机器人的水平距离 z: delta_z, # 高度差 confidence: 1.0 }) return group_and_fit(edges) # 聚类直线拟合得到台阶参数这段代码的逻辑是把激光扫描点从极坐标转成笛卡尔坐标相邻两点的垂直高度差如果在合理范围内就标记为候选台阶边缘。后续的group_and_fit会把相邻的候选点聚类成一条条台阶边缘线再做拟合得到每级台阶的深度和高度的平均值。关键参数是step_height_min和step_height_max。这两个值决定了系统能识别的最小和最大台阶高度。我给一般设定 10cm 和 30cm低于 10cm 的坡道会被忽略高于 30cm 的会报警“地形不可通行”。如果你用的平台腿长不一样这两个值要按“机器人最大抬腿高度 × 0.6”到“最大抬腿高度 × 0.9”来标定。3.2 位姿估计IMU里程计在楼梯场景下的坑爬楼梯时机器人的位姿估计知道自己在哪、姿态如何有一个常见误区直接用轮式或平面机器人那套“航迹推演dead reckoning”。问题在于楼梯场景下脚底与地面之间存在打滑和冲击腿式里程计的积分误差会快速累积尤其是沿重力方向的高程误差可能比水平误差大一个量级。我常用的方案是IMU 提供高频姿态角roll、pitch腿部关节编码器提供每条腿末端在机体坐标系下的位置再用一个扩展卡尔曼滤波器EKF把两者融合得到机体的三维位姿估计。爬楼梯时还要额外引入“台阶约束”当某条腿接触上一级台阶时脚底高度已知这个信息直接作为测量更新能非常有效地抑制高程方向的漂移。接触检测怎么判断看关节力矩当某条腿的足底力或力矩超过阈值就认为触地。触地后把该脚的位置在 z 方向锁定到当前台阶高度。注意这个操作要加死区不然触地瞬间的冲击噪音会让锁定值抖动。姿态估计的另一个坑是楼梯上的俯仰角变化。上楼梯时机器人躯干可能在每一级台阶过渡瞬间出现小幅俯仰震荡前腿抬高时躯干后仰后腿抬高时躯干前倾。如果直接用 IMU 的原始俯仰角做控制反馈这个震荡会被放大。正确做法是控制回路里用低通滤波后的俯仰角滤波时间常数取 0.2 到 0.5 秒同时用带通滤波把震荡频率段提取出来做阻尼补偿。3.3 楼梯模型校验置信度与超时机制感知系统不能只给一次结果就完事。机器人从“看到楼梯”到“走到楼梯跟前”往往要一两秒这期间机器人自身在运动楼梯的相对位置在变化感知结果必须持续更新并做一致性校验。我常用的做法是维护一个“楼梯模型缓冲区”连续 N 帧检测结果里如果台阶高度和宽度的方差小于阈值就认为模型稳定置信度升高如果某帧检测结果和当前模型差异过大就舍弃该帧连续舍弃 M 帧才重置模型。这样既不会因为一两帧抖动导致模型跳变也不会在楼梯发生变化比如走到楼梯转角时反应太慢。超时机制也很重要如果机器人已经进入攀爬状态但连续 2 秒没有检测到新的台阶边缘说明传感器可能被遮挡或台阶比预期少应该立即触发安全停止而不是盲目继续迈步。这个“安全停止”不是原地急停而是缓慢降低躯干高度、降低步态频率找一个稳定的静平衡姿态站住。4. 落脚点规划与重心轨迹爬楼梯的“几何约束求解”4.1 落脚点可行域每一条腿能踩哪里爬楼梯时落脚点规划不是“哪里能踩就踩哪”而是要考虑每条腿的运动学可达范围、干涉规避和稳定性贡献三个约束。运动学可达范围简单说就是髋关节到脚底的几何边界。在机体坐标系里每条腿的脚底位置有个球形或立方体可达域。台阶越高身体离台阶越远时前腿的可达域就越紧张。干涉规避则是指左前腿和右前腿在同时跨越两级台阶时它们的脚底轨迹不能让两条腿在空中交叉碰撞。稳定性贡献是说在静态步态里“支撑三角形”要尽量覆盖重心投影。上楼梯时身体重心会自然偏向后腿因为前腿在攀登落脚点规划时要有意识地把后腿往后放、扩大支撑面积。一个实用性技巧把每条腿在每一级台阶上的可行落脚区域离散成网格然后用“加权评分”选点。评分函数包含到默认步态落点的距离越小越好、支撑三角形面积贡献越大越好、台阶边缘距离离边缘越远越好防滑。权重根据机器人的状态动态调整——机身俯仰角偏大时增加稳定性权重离楼梯边缘近时增加边缘距离权重。4.2 躯干轨迹规划不是简单保持水平很多人以为爬楼梯时躯干全程保持水平就对了实际不是。上楼梯躯干应该有一个很轻微的前倾2 到 4 度把重心稍微往前带给前腿减负下楼梯躯干略微后倾3 到 5 度防止重心过早前移导致翻滚。这个角度不是固定的而是随台阶高度变化的台阶越高前倾/后倾角越大但都有上限超过了会恶化腿部运动学条件。躯干的 z 方向轨迹才是关键。理想情况下躯干高度的变化应该是一个平滑的“锯齿波”每上一级台阶躯干升一个台阶高度然后在台阶面上保持水平移动再升下一级。如果躯干轨迹和腿的摆动轨迹耦合不好会出现“身体先升、腿还没跟上”的悬空感或者“腿已到位、身体还在顶”的顿挫感。我用五次多项式插值来生成躯干轨迹边界条件包括起点位置、终点位置、起终点速度为零因为每级台阶之间躯干会短暂停顿或低速起终点加速度为零。这样能保证节奏平稳。插值时长就是单步周期的一半——先是支撑相换腿后是躯干提升。import numpy as np def quintic_trajectory(t, t0, t1, p0, p1): 五次多项式插值位置从 p0 到 p1起止速度/加速度为0 tau (t - t0) / (t1 - t0) # 五次多项式系数满足边界条件 a 10 * (p1 - p0) b -15 * (p1 - p0) c 6 * (p1 - p0) return p0 (p1 - p0) * (a * tau**3 b * tau**4 c * tau**5)这里的a, b, c是根据边界条件解出来的。用五次多项式而不是三次是因为它能把加速度也约束到零避免躯干在切换点出现冲击。调用时每个控制周期算一次t是当前时间。p0是当前台阶的躯干高度p1是下一级台阶的躯干高度t1-t0通常取 0.4 到 0.6 秒。4.3 步态相位摆动腿时序怎么定上楼梯时四条腿的摆动顺序直接影响稳定性。我见过两种流派一种是“对角线同步”左前右后同时摆效率高但窄支撑面上稳定裕度小另一种是“同侧前后交叉”左前→右后→右前→左后每一步都有三条腿支撑安全但速度慢。爬楼梯我推荐后者而且是改良版先摆前腿然后摆同侧后腿再摆另一侧前腿最后摆另一侧后腿。这个顺序保证了任意时刻至少有三条腿在地面而且在“两条腿同时离地”的阶段也就是前一条腿刚落、后一条腿刚离地的瞬间支撑三角形依然覆盖重心投影。为了避免四条腿之间互相绊我还会做“相位锁定”每条腿进入摆动相之前检查前一条腿是否已经完成触地并稳定支撑足底力超过阈值持续 50ms 以上是才允许进入摆动。这个检查在代码里就是一个信号量把步态时序和实际动力学反馈耦合起来。5. 避坑指南爬楼梯控制的五个血泪教训5.1 抬腿高度设成“台阶高度固定余量”会翻车现象机器人上楼梯时腿抬得不够高脚尖刮到台阶边缘导致身体前冲摔倒。原因很多人把抬腿最大高度设成“台阶高度 2cm”看起来合理但忽略了两个因素——机身俯仰角变化会让实际脚底高度变低以及腿部关节在接近极限位时轨迹会压缩。特别是电池电量下降后关节响应变慢实际轨迹跟不上规划轨迹抬腿高度瞬间不够。解决把抬腿最高点设为“台阶高度 最大俯仰角补偿 5cm 安全余量”。比如台阶 20cm最大俯仰角 3 度机身长 60cm 时单端升降约 3cm那抬腿至少 28cm。宁可看起来夸张一点也别刮台阶。5.2 触地检测只用关节力矩阈值会有电噪声误触发现象程序以为腿已触地实际还在空中下一级台阶的轨迹就被提前执行导致身体悬空。原因关节力矩传感器或者电流采样转力矩在运动过程中会有很大的动态噪声。特别是摆动腿高速运动时惯性力会被力矩传感器捕捉到误判为触地。解决触地判断加双重条件力矩阈值 关节速度为零或接近零。具体实现连续 30ms 力矩超阈值且同时段关节角速度小于某个小值比如 0.1 rad/s才判定触地。还要加一个“不可触发期”在摆动相前 100ms 内不响应触地信号避免刚离地瞬间的冲击干扰。5.3 下楼梯冲击过大导致躯干前滚翻现象下楼梯时前腿先下到下一级台阶巨大的冲击力传递到躯干接着后腿跟进时身体发生前滚。原因下楼梯本质上是“重力势能转化为动能再耗散”的过程。如果执行层只做了位置控制硬性跟踪轨迹冲击能量没有地方去就全砸在结构上了。而且下楼梯时躯干重心本来就偏前冲击会加剧这个趋势。解决下楼梯的支撑相不要用刚性位置控制改用“位置阻抗控制”在垂直方向把刚度调低一些比如减到上楼梯时的 60%阻尼调高让腿在触地瞬间像弹簧一样吸收冲击。同时在下楼梯的躯干轨迹里主动加一个“下沉动作”前腿触地后躯干主动下沉 1~2cm 再继续迈步把冲击转化为可控的下沉位移。5.4 楼梯模型更新不及时最后一级台阶踩空现象机器人爬完了规划好的台阶数但最后一步踩空导致身体前扑。原因感知层规划的台阶数和实际不一致。常见原因是楼梯转角处有平台平台被错误识别为一级台阶或者台阶间有防滑条、磨损区域导致高度检测偏差。解决攀爬过程中每上一级台阶都用实际触地信息修正“剩余台阶数”。当检测到连续两次触地高度差小于台阶高度的一半时认为楼梯已到尽头提前进入过渡状态。另外在楼梯模型里加一个“平台识别”如果水平距离超过正常台阶深度 2 倍且高度差接近零判定为平台不算台阶。5.5 摆动腿轨迹与躯干轨迹耦合不当迈步时身体晃动现象机器人在台阶上行走时躯干左右晃动剧烈甚至出现侧翻倾向。原因摆动腿的横向摆动y 方向会改变重心投影。如果躯干轨迹没有同步补偿 y 方向的质心偏移左右方向就没有“动态平衡”的裕度。更隐蔽的是同一侧的前后腿同时摆动比如左前和左后会把整个身体的重量压到右侧两条腿右侧关节容易过载。解决把步态相位改成“对角-对角”的静态版本并给躯干轨迹加横向补偿项。补偿量 摆动腿质量 × 摆动腿横向位移 / 机器人总质量。这个项在实时控制里就是查表或直接计算成本很低但能明显减少横向晃动。6. 参数调优的顺序从“能走”到“走得稳”的实操技巧爬楼梯控制系统的参数多到让人怀疑人生步态周期、摆动高度、躯干前倾角、阻抗系数、DCM 带宽如果用了、步距规划权重……如果一股脑乱调只会越调越乱。我自己的习惯是分四个阶段每个阶段只动一小拨参数验证通过了再进下一个阶段。第一阶段静态参数标定。用遥控器手动操作机器人摆出各种姿态标定腿部运动学参数、关节零位、IMU 安装偏差。这一步不跳过我之前有一次 IMU 的 pitch 方向装反了导致上楼梯时机器人拼命往前栽。标定时注意关节零位必须在机器人“标准站立姿态”躯干水平、四条腿垂直下标定。第二阶段单步调试。不连续爬楼只让机器人执行“抬腿-迈步-落下”的单步动作。观察摆动腿轨迹是否平滑、触地冲击是否在可接受范围。这里要调的两个核心参数是摆动腿最高点高度和摆动时间。摆动时间决定腿部速度太短冲击大太长重心不稳。我的经验值20cm 台阶摆动时间设 0.6 到 0.8 秒比较合适。第三阶段连续爬楼调试。让机器人连续爬 4 到 5 级台阶关注躯干高度轨迹的平滑度。如果躯干在每一步切换时有明显顿挫说明五次插值的时间参数没匹配好如果躯干全程有持续晃动说明姿态滤波带宽太低或步态频率和目标动力学有冲突。这里通常要回看日志里的躯干实际轨迹和规划轨迹偏差偏差超过 2cm 就要检查执行层的跟踪性能。第四阶段鲁棒性测试。改变台阶高度在安全范围内、改变机器人前进速度、让机器人斜着接近楼梯故意给一个 10 度以内的偏航角观察系统是否还能稳定运行。这一步会暴露感知层的脆弱性比如斜着接近时楼梯边缘在激光雷达扫描里会糊掉。代码层面有一个我每次必加的“安全网”在控制循环里加一个期望轨迹与实际状态的偏差监控偏差超过阈值就触发“紧急停机”。# 安全监控控制循环内每个周期执行 def safety_check(robot_state, plan_state): pos_err np.linalg.norm(robot_state.position - plan_state.position) orient_err np.linalg.norm(robot_state.orientation - plan_state.orientation) if pos_err 0.05: # 位置偏差超过5cm return halt if orient_err 0.15: # 姿态偏差超过8.6度 return halt # 躯干高度低于预期超过3cm说明腿可能没撑住 if plan_state.height - robot_state.height 0.03: return halt return nominal这个检查的核心是“不要让机器人带着错误状态硬走”。位置偏差 5cm 和姿态偏差 8.6 度是经验阈值我在不同平台上都用过属于安全范围的下限再小容易误触发再大就离翻车不远了。触发停机后怎么处理不急着站起来先把躯干高度缓慢降到最低位然后四肢撑地等待人工接管。最后说一个习惯每轮调参我都会把日志里的“规划轨迹、实际轨迹、支撑腿数量、触地置信度”四个信号画在同一张图上。很多问题根本不用猜看图就能定位——比如触地置信度频繁掉到零说明接触检测参数要调规划轨迹和实际轨迹分离说明执行层跟踪有延迟。用数据说话比拍脑袋调参数快得多也少了很多无头苍蝇式的翻车。爬楼梯控制这套东西说难不难但每一步都做对了才能让它稳稳当当。希望帮到你。本文还有配套的精品资源点击获取
RELATED

相关推荐

Go unsafe包深度解析:指针操作、内存布局与零拷贝实践

Go unsafe包深度解析:指针操作、内存布局与零拷贝实践

在Go社区里,unsafe包一直是个自带争议的话题。有人把它当成“禁区里的核按钮”,有人把它当成“性能优化的万能钥匙”。我自己的态度是:它更像一把手术刀——用对了能精准切到病灶,用错了就得自己承担后果。这篇文章我会从指针操作…

📅 2026/10/13 5:07:19
OneLive实时数据聚合实战:架构选型、核心实现与踩坑排查

OneLive实时数据聚合实战:架构选型、核心实现与踩坑排查

1. 从"OneLive"这个名字说起:一个被低估的命名逻辑第一次看到"OneLive"这个标题的时候,我脑子里冒出来的第一个念头不是"这是个什么产品",而是"这个名字起得挺讲究"。做项目做久了你会发现&#xff…

📅 2026/10/13 5:07:19
STM32+HX711智能体重秤设计:从信号采集到标定的完整方案

STM32+HX711智能体重秤设计:从信号采集到标定的完整方案

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📅 2026/10/13 5:07:19
MORE NEWS

更多资讯

📰

Qt Core 模块深度解析:元对象系统、事件循环与多线程实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

FMEA失效模式分析:原理、应用与行业实践

1. 失效模式与影响分析(FMEA)概述失效模式与影响分析(Failure Mode and Effects Analysis,简称FMEA)是一种系统化的可靠性分析方法,最早由美国军方在20世纪40年代开发用于武器装备的质量控制。如今它已成为…

📰

国内环境快速部署Dify:镜像拉取与docker-compose改造指南

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

WSL下STM32烧录难题:ST-Link USB直通与OpenOCD实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

低功耗气体传感模组物联网设计:从选型到功耗优化的实战解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

CH379M双通道读卡器方案:SD/TF卡并行读写与国产化迁移实践

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬