漫巡：六足机器人自主能力架构设计

平台定位与设计边界

漫巡是基于现有六足平台二次开发的融合多模感知与异构通信的多功能具身智能六足机器人。本体重约 4 kg，直径 420 mm，六条腿、18 个关节，Jetson Nano 主控，500 万像素摄像头，YDLIDAR G4 激光雷达。铝合金、碳纤维和 POM 机身以及原厂舵机、步态固件保留，二次开发集中在感知、决策、通信、操作入口和安全层。

原厂手柄和 APP 能完成基本行走与姿态调整，但原厂控制链路只覆盖本体：没有定位、环境感知和任务层，系统无法判断自身位置和前方障碍，也无法把“去门口看看”拆成可执行动作。漫巡的二次开发围绕这些缺口，将多模感知、异构通信和高层决策接入原有运动平台。

官方手册覆盖开机、手柄、APP、ROS 连接、gmapping、单点导航、YOLO 目标检测和网页调用大模型，可以复现 demo。手册没有定义系统架构、入口冲突的处理方式，也没有说明 YOLOv5 之后的模型替换策略。

下面按控制链路讨论设计取舍：串口协议、ROS 与步态、操作入口仲裁、SLAM、视觉、模型路由、语音、通信和 VR 遥操作。重点放在模块边界、失败模式和目标方案。

范围说明：本文给出目标架构、设计参数、接口约束和失效模式。机器人本体的时序、功耗和链路按设计值讨论；Qwen 的视觉能力测试引用控制机侧模型数据；整机时序按设计推演。除特别注明外，文中的延迟、带宽和资源数字均为预算或目标值，不代表整机测量结果。

一、串口协议与控制链路

串口链路的首要问题是读写时序。若写命令时没有排空返回帧，控制板状态回包会在缓冲区累积，下一次读取可能得到数百毫秒前的姿态，表现为机器人间歇停顿并补走。示波器波形可能正常，故障位于主机侧的读取逻辑。

1.1 帧格式与载荷解析

控制协议的一帧数据为 6 + N 字节：两字节起始位 0x56 0x4B，两字节消息类型（消息 ID + 命令 ID），一字节长度，N 字节内容，最后一字节校验和。校验和是“消息类型 + 长度 + 内容”逐字节求和后取反，不是 CRC，也不带序号。

消息 ID 只有四类：0x01 读写参数，0x02 非步态模式下的动作组，0x03 步态模式下的运动控制，0x04 是控制板的返回。步态模式下，0x03/0x03 控制运动方向，0x03/0x04 设速度，0x03/0x05 设机身高度，0x03/0x06 设抬腿高度，0x03/0x07 设步长，0x03/0x09 开关平衡模式。读电池是 0x01/0x04，读舵机位置是 0x01/0x07，LED 是 0x01/0x06，GPIO 和 I2C 扩展在 0x01/0x0D 到 0x01/0x12。

一个容易忽略的错误是把校验和写成 sum(payload) ^ 0xFF。小数据量下可能不会出错，但设置机身高度时参数一旦进位，校验和就会与固件对不上。控制板对坏帧静默丢弃，不回 NACK；机器人不动，日志也没有记录。

def pack_frame(msg_id, cmd_id, payload=b""):
    body = bytes([msg_id, cmd_id, len(payload)]) + payload
    checksum = (~sum(body)) & 0xFF
    return bytes([0x56, 0x4B]) + body + bytes([checksum])

# 读的时候必须按长度字段收满，不能假设一次 read() 就是一帧
def read_frame(ser):
    head = ser.read(2)
    if head != b"\x56\x4b":
        return None
    meta = ser.read(3)          # msg_id, cmd_id, length
    payload = ser.read(meta[2])
    tail = ser.read(1)[0]
    if tail != (~sum(meta + payload)) & 0xFF:
        return None
    return meta[0], meta[1], payload

驱动层固定三条规则。第一，所有写操作走单独的串口线程，命令队列有界，队列满时丢最旧的命令，不阻塞控制循环。第二，每条命令带本地序号，120 毫秒内没有等到对应的 0x04 返回就重发一次；重发两次仍失败，把这一帧记为丢失，交给上层降级。第三，相对增量命令全部改为绝对状态命令：机身高度和速度直接设置目标值，不发送相对增量。协议没有序号，重发相对命令会导致机器人重复执行。

1.2 命令映射与速率

协议只规定字节，不规定调用频率。系统设计需要给每条命令分配速率和优先级，否则高频速度帧会挤掉模式查询和电池状态。下表的速率是设计上限，不是固定轮询周期；状态量在变化时发送，周期量按表中频率发送。

1.3 串口时序与带宽预算

115200 波特率、8N1 的理论吞吐约 11.5 KB/s，按 80% 有效载荷估算约 9 KB/s。一帧长度是 6 + N 字节，速度帧的 N 只有几个字节；即使控制环运行在 50 Hz，命令与返回数据也远低于链路容量。主要约束为队列延迟和读取阻塞，带宽本身不是瓶颈。

1.4 链路状态机

串口链路按四个状态管理，避免“能发但不可信”的灰区：

• OPEN：端口已打开，尚未收到合法返回帧。只允许查询，不发送运动命令。
• READY：连续收到合法返回帧，模式查询通过。允许运动命令，正常更新看门狗。
• DEGRADED：重发两次仍失败或返回帧超时。冻结步态，保留查询，尝试重连。
• FAULT：端口消失、校验连续错误或控制板无响应。发零速，等待人工处理。

二、ROS 接入与运动接口

漫巡的 ROS 软件包包括：vkhexbot_serial 负责底层控制板通信，vkhexbot_bringup 负责底盘启动，vkhexbot_teleop 提供键盘遥控。节点订阅 /cmd_vel，将 geometry_msgs/Twist 转换为步态控制帧；同时发布 /imu_data、/scan 和由控制指令推算的 /odom。其中 /odom 是后续定位与建图的主要误差来源。

2.1 足式平台的里程计来源

轮式底盘可以用编码器测量轮速，六足没有轮子。它的 /odom 由速度和持续时间积分得到，属于开环估计。脚会打滑，步态换向时机身会产生晃动，地毯和瓷砖上的位移也不一致。手册因此专门设置了线速度和角速度校准。

校准过程：原地旋转 360°，通过 rqt_reconfigure 调整 odom_angular_scale_correction，使实际转角与指令一致；直线行驶 1 米并测量实际距离，调整 odom_linear_scale_correction。将系数写回 bringup.launch 的 angle_z_scale 和 linear_x_scale。如果指令 360° 只转了 324°，系数应取 1.11，而 launch 文件里的默认值通常是 1.0。

1.11 的误差会沿路径累积。建图时每过一个 90° 的弯，地图少转 9°，四个弯后走廊尽头与起点可能差出半米，回环检测难以闭合。系数修正后可消除方向偏差。定位与建图精度主要受输入里程计误差限制。

2.2 IMU、TF 与 yaw 漂移

机身上的 IMU 是 MPU6050 模块，串口挂在 /dev/vk_imu，115200 波特率，每 10 毫秒出一帧加速度、角速度和角度。节点启动时会先发 0xFF 0xAA 0x52 做 Z 轴归零，等五秒，再发 0xFF 0xAA 0x67 做加速度校准，再等五秒。这十秒用于消除固定偏置；跳过校准后，roll 和 pitch 会保留固定误差，静止时 TF 中的机身姿态也会倾斜。

IMU 的 yaw 不适合作为长期航向基准。MEMS 陀螺零偏随温度变化，连续运行十分钟时航向角可能漂移一两度；六足步态冲击也会给角速度带来周期尖峰。设计上只用 IMU 补充短时 roll/pitch，yaw 由激光扫描匹配和 AMCL 估计，融合权重按运动状态切换：直行时提高陀螺权重，原地转向时提高激光权重。TF 树中 base_link → laser 的外参需要用卷尺和水平仪测量；外参误差 1 厘米会直接反映为地图墙体偏移，并随距离放大。

2.3 下视 ToF 与底盘感知改造

原厂平台提供 USB、I2C、串口、十路 GPIO 和总线舵机接口，顶部多孔板可安装树莓派、雷达或机械手。下视感知需要补充：激光雷达扫描水平面，摄像头朝前，而六足抬腿时，台阶、桌沿和门槛位于现有传感器的视野盲区。

方案在机身前后左右各加一颗 VL53L1X 下视 ToF，量程 1.2 米，采样 50Hz，通过 I2C 多路复用器接到 Nano。正常站在地面时，四颗都应看到 0.1 到 0.3 米的回波；任意一颗跳到 1 米以上，说明那一侧地面消失，应立即冻结步态并后退 10 厘米。这个逻辑的设计目标是覆盖实验台边缘和楼梯口。

供电设计需要单独处理舵机浪涌。机器人本体是 8.4V 9600mAh 电池，给舵机供电没有问题；如果雷达和额外计算板共用同一路 5V，舵机换向的浪涌会让 5V 轨瞬间掉压，雷达的 USB 转串口可能重新枚举，/scan 中断后 gmapping 会将该段走廊记录为空白。设计对策是：雷达和 ToF 用独立 5V 降压板，从电池直接取电；USB 数据线串 ADuM3160 隔离器；所有地线只在电池负极单点汇合。

2.4 TF 树与话题接口

六足的 TF 树比轮式底盘更容易出错，因为机身高度和姿态一直在变。设计上把 map → odom → base_link 分开维护：AMCL 只发布 map → odom，里程计发布 odom → base_link，雷达、IMU、相机的外参用静态变换固定。任何一层频率下降，下游只能看到 TF 超时，不会把错误姿态当成真实姿态。

2.5 速度整形与步态约束

cmd_slew 需要结合当前步态相位，不能只按低通滤波实现；否则支撑腿换向时足端可能产生地面滑移。设计上把速度拆成线速度、角速度和方向三类，分别限幅；反向命令必须等当前步态周期结束；超过看门狗时间没有新命令，直接覆盖为零速。

def slew(cmd, last, dt, gait_done):
    max_dv = 0.2 * dt
    max_dw = 0.5 * dt
    v = clamp(cmd.v, last.v - max_dv, last.v + max_dv)
    w = clamp(cmd.w, last.w - max_dw, last.w + max_dw)

    # 方向反转必须等一个完整步态周期
    if sign(v) != sign(last.v) and not gait_done:
        v = 0.0
    return v, w

这条整形逻辑只处理连续速度。技能层调用 NAV_TO 时，仍然走 move_base 的输出，不直接写 /cmd_vel；VR 手柄和语音也不直接写。所有速度最终都经过同一层整形和看门狗，避免不同入口给出互相矛盾的加速度。

2.6 电源与接口预算

六足的舵机是脉冲负载，平均电流不高，换向瞬间的浪涌很大。设计上把舵机、雷达、主控和通信模块分到不同支路，避免一次换向把 USB 设备重新枚举。下表只列机载电源预算。控制机使用独立电源，不计入机器人电池负载。

三、操作入口与控制权仲裁

行走链路确定后，需要统一操作入口。系统包含手柄、手机 APP、PC 上位机、ROS、网页控制台和语音六个入口，另有一个自主任务层。各入口均可产生运动指令并维护各自状态，入口数量增加会带来控制权冲突。

漫巡的设计前提是受控环境。方案首先要定义控制权分配。

3.1 控制入口与输入设备

手册定义了完整的操作方式。手柄有五种模式：行走、姿态调整一、姿态调整二、单腿、动作组；行走模式里还有三角八步、涟漪、三角十六步、波浪四种步态。START 键在“步态”和“非步态”之间切换，L1/L2 进姿态调整，R1 调抬腿高度（40/60/80 毫米），R2 调步长（63/127 毫米）。动作组模式有六组动作，单腿模式支持单腿位置保持，协议里还有一个平衡模式开关；这些用于调试和演示，仲裁器在 AUTO 下禁用。这些按键直接改变底层控制语义。

手机 APP 有蓝牙和 ROS 两条连接路径：蓝牙适合近距离手动控制，ROS 连接可查看地图、切换单腿和动作组、启动视频、控制灯环。PC 上位机负责动作组编排、舵机零位校准和下载/擦除，属于装配和调试工具，不是运行时入口。ROS 侧是 /cmd_vel、键盘遥控、gmapping、导航和摄像头。网页端是自建控制台，自然语言先转换为任务图，再由路由器分派模型。语音入口采用机载 ASR；官方 APP 的在线识别只作为可选路径，不作为运动控制的依赖。

六个入口之外还有 P2 自主任务层：它接受任务图、调用技能并写回执行日志，不属于手册中的手动入口。

“步态/非步态”代表两套控制语义：非步态模式下，底层只接受动作组、单腿和姿态指令；只有步态模式接受 /cmd_vel。仲裁器启动时先读 0x01/0x03 确认当前模式，每次人工接管之后再读一次。否则上层会在动作组模式中持续发送速度帧，底层不响应，日志中仅记录超时。

3.2 控制权仲裁规则

所有入口统一接入仲裁器，按优先级排队，不直接写串口。优先级从高到低：

• P0 · 反射层：急停、悬崖 ToF、500 毫秒看门狗、机身倾角超过 25°。这一层不经过任何模型，直接冻结步态。
• P1 · 人工接管：手柄、APP 和控制机。手柄接收器始终由底层供电，不经过控制机；控制机操作员可以通过有线、光纤或 WLAN，在控制台按接管键、使用控制机手柄或键盘随时接管。接管请求走独立通道，不经过 Laya、Qwen 或 DeepSeek。同一优先级内，物理手柄优先于控制机操作员，控制机操作员优先于 APP。
• P2 · 自主执行：move_base 的 /cmd_vel、VLA 的技能、自主任务。它们只能在 P0/P1 都空闲时运行。
• P3 · 任务建议：语音和云端大模型。它们只能提交任务图，不能直接写 /cmd_vel；任务图通过 schema 和安全校验之后，才进入 P2。

状态机有五个状态：IDLE、MANUAL、AUTO、ASSIST、FAULT。AUTO 下推手柄，立即切到 MANUAL，取消当前技能并停稳。松开手柄不会自动恢复 AUTO；必须在 APP 或网页控制台重新使能，并重新规划路径。人工接管通常意味着环境或任务状态已经变化，因此不设计自动恢复。

3.3 命令总线与租约机制

所有入口不直接写串口，也不直接写 /cmd_vel。每个入口发布一条命令请求，字段包括来源、序号、优先级、有效时间和负载；仲裁器按优先级发放短租约，租约到期自动收回。这样即使某个入口无响应，该入口持有的命令也不会永久生效。

{
  "source": "vr",
  "seq": 10241,
  "priority": "P1",
  "ttl_ms": 500,
  "kind": "velocity",
  "payload": {"v": 0.08, "w": 0.2}
}

3.4 人工接管与重新使能

人工接管需要按固定顺序完成状态迁移，并确保自主任务不再持有有效租约。

• 检测接管：手柄、APP 或控制机操作员产生有效接管请求，仲裁器立即把当前 P2 租约标记为取消。
• 确认模式：读取 0x01/0x03，确认底层处于步态模式；如果不在，先切回步态模式。
• 清零速度：向 /cmd_vel 发布零速，等待一个步态周期，确保腿不再处于摆动相。
• 切换状态：进入 MANUAL，取消当前技能，停止任务队列，保留地图与定位。
• 重新使能：退出 MANUAL 必须人工确认并重新规划路径；不自动恢复之前的自主任务。

3.5 控制机接管

控制机作为运行时接管入口，同时承担状态监视。操作员在控制台按接管键，或使用控制机手柄、键盘，通过有线、光纤或 WLAN 发出 P1 接管请求；请求包含操作员 ID、链路类型、时间戳和 deadman 状态，走独立命令通道，不经过任何模型。

仲裁器收到请求后取消 P2 租约、停止当前技能、清零速度并切到 MANUAL。控制机接管使用 200 毫秒租约，操作员持续心跳续租；500 毫秒没有心跳，机载看门狗直接停车。有线优先，WLAN 作为移动接管路径；WLAN 延迟升高时只允许降速和停车，不开放高速运动。退出 MANUAL 仍然需要人工重新使能。

四、SLAM 建图与导航

六足平台直接建图时，扫描数据会因机身晃动产生畸变，表现为墙体弯曲、边长不一致或走廊尽头重影。gmapping 默认按轮式底盘的刚体变换处理扫描，未计入六足步态引起的姿态变化。

4.1 激光雷达数据与预处理

YDLIDAR G4 装在机身顶部、摄像头后面，360° 扫描，一圈 1440 个距离值，角度分辨率 0.25°，发布在 /scan 上，消息类型是 sensor_msgs/LaserScan。它标称量程十几米，室内可用距离约 6 到 8 米，更远处会混入玻璃、白墙和阳光噪声。十米见方的实验室可以使用，但需要保证雷达供电和安装稳定。

六足平台对雷达安装和运动约束的要求高于轮式底盘。轮式底盘以平移为主，雷达扫描平面基本不变；六足每走一步，机身会产生几毫米到一厘米的起伏，转向时姿态也会先下沉再回转。gmapping 按刚体变换匹配每帧扫描，机身姿态变化会使墙体在图上增厚。墙体增厚会提高 AMCL 漂移风险，并导致导航在宽走廊中反复制动。

4.2 gmapping、hector 与 AMCL 的职责

官方教程提供两种方案：gmapping 和 hector。gmapping 使用 Rao-Blackwellized 粒子滤波，依赖里程计，适用于长走廊和回环；hector 使用扫描匹配，不依赖里程计，适用于小房间，但对扫描频率和初始位姿更敏感。方案选择是：建图用 gmapping，对照用 hector，定位用 AMCL。

gmapping 参数取保守值：粒子数 30，地图分辨率 0.05 米，更新间隔放慢，线性更新阈值 0.5 米，角度更新阈值 0.25 弧度。建图速度上限 0.08 米每秒，转弯前停一秒，等机身姿态稳定后再转。建图分两轮：第一轮覆盖主要区域，第二轮补测桌底和门后盲区；最后用 map_saver 保存为 gmapping_123，官方导航 launch 默认读取该名称。

4.3 导航栈与步态参数化

导航使用控制机上的 ROS1 move_base：全局规划 Navfn，局部规划 DWA，代价地图的膨胀半径 0.35 米，机器人足迹按 0.26 米的外接圆处理。最大线速度 0.12 米每秒，最大角速度 0.3 弧度每秒，加速度限得很低。这些数字偏保守，原因是六足的速度不连续。

底层步态引擎接受离散档位：步长 63 毫米或 127 毫米，抬腿高度 40、60、80 毫米，速度分档。输入 0.07 米每秒的 /cmd_vel 时，内部会量化为最接近的步态参数，因此实际速度与指令速度存在小偏差。换向时，如果支撑腿尚未完成支撑周期就收到反向命令，足端会在地面产生滑移，里程计会记录额外位移。

因此在 move_base 和 vkhexbot_serial 之间加了一个 cmd_slew 节点。它限制线加速度到 0.2 米每二次方秒、角加速度到 0.5 弧度每二次方秒；每条命令至少保持一个完整步态周期（约 0.9 到 1.2 秒）才允许反向；超过 500 毫秒没有收到新的 /cmd_vel，就发零速并保持。最后一条用于断链保护：控制链路断开时，控制机的 move_base 不一定能及时报告失联，机载 cmd_slew 的看门狗提供最终保护。

4.4 地图与导航参数

导航参数按六足的速度上限和机身尺寸取值。地图分辨率不追求过细，0.05 米足够表达门框和桌腿；代价地图的膨胀半径要覆盖机身外接圆和步态摆动，否则规划器会给出贴墙的路径。

4.5 建图质量与评估

地图质量评估不采用目视判断，至少检查四项：回环闭合误差、墙体重影厚度、定位跳变次数、同一路线重复建图的一致性。前两项用地图工具量，后两项从 rosbag 里重放 AMCL 位姿和 TF 时间戳。评估时把里程计系数、步态、速度作为变量，固定路线重复采集，才能判断误差来自传感器、标定还是步态。

转向速度对六足建图影响最大。原地转向时足端会打滑，角速度积分误差大于直行；建图时应限制原地转向角速度，并将转向动作拆分为“停稳、转向、停稳”三步。代价是建图速度降低，但回环闭合更稳定。

4.6 3D SLAM 与无 GNSS 扩展

2D 激光雷达只能表达一个水平面。管廊、塌方空间和矿井需要 3D 点云，设计上可加 3D LiDAR 或 RGB-D 相机，采用 LIO-SAM 或 RTAB-Map 做激光、视觉和 IMU 的里程计融合。关键约束是时间同步和运动畸变：六足转向时机身姿态变化快，点云如果按帧拼接而不做去畸变，墙面会出现明显分层。

无 GNSS 时，3D SLAM 的输出既是地图也是定位源。设计上需要把点云地图降采样后用于全局定位，把原始点云留给离线测绘；在线导航只保留局部子图，避免机载 Nano 或控制机的内存被完整点云占满。

五、视觉感知与场景理解

视觉栈基于官方目标检测示例：YOLOv5 负责固定类别检测，HSV 阈值用于红绿灯，图生文模型作为补充。三类任务的运行频率不同，不宜放在同一推理循环。设计上将检测器换为 YOLO26，红绿灯改为检测器加七帧投票；检测器负责固定类别，VLM（视觉语言模型）负责对象状态、空间关系和关键帧复核。

5.1 YOLO26 检测与推理路径替换

手册提供的是 YOLOv5s 的 .wts → TensorRT .engine 路径，并配套自维护的 C++ 后处理。该路径的主要维护成本在 letterbox、anchor 解码、NMS 和类别映射。Ultralytics 当前稳定版本是 YOLO26（2026 年 1 月发布）；YOLO27 已在 2026 年 9 月的 YOLO Vision 亮相，但权重尚未发布，暂不纳入方案。因此选择 YOLO26n/s。

YOLO26 的结构变化包括：移除 DFL 回归，检测头更轻；支持可选的 NMS-free 端到端推理（nms=False），后处理减少一个分支；训练侧使用 STAL 改善小目标标签分配，并使用 MuSGD 优化器；导出到 TensorRT/ONNX 的链路也更简洁。官方给出的 YOLO26n 指标为 2.4M 参数、5.5 GFLOPs、COCO 40.9 mAP、T4 上 1.7ms。Nano 的性能低于 T4，但模型本身已不是主要瓶颈；图像预处理、内存拷贝和 ROS 消息转换开销更高。

pip install -U ultralytics

# PyTorch -> TensorRT；Nano 先用 FP16，INT8 需要校准集
yolo export model=yolo26n.pt format=engine imgsz=640 half=True device=0

# 推理；端到端头可加 nms=False
yolo predict model=yolo26n.engine source=... conf=0.35

NMS-free 头需要按场景选择。官方 e2e 头的 COCO mAP 比默认 one-to-many 头略低（40.1 对 40.9），但延迟更稳定、后处理更简单。巡查场景目标稀疏，使用 e2e；远处反光标识或小物体保留默认头，以少量 NMS 开销换取召回率。INT8 需要额外校准：Nano 的 INT8 需要数百张校准图，漏检代价高于节省的数毫秒，因此先用 FP16。

保留 YOLOv5 的成本主要在维护：C++ 推理程序需要实现 letterbox、anchor 解码、NMS 和类别映射。换到 YOLO26 后，这些由 Ultralytics 的导出和运行时接管，NMS-free 还少一个后处理分支。旧路径保留在 legacy/ 做对照；如果 Nano 上遇到不支持的算子，回退顺序是 YOLO11 → YOLOv8，不再回到 v5。

模型切换后，前后处理也要同步。YOLO26 的输出布局与 v5 不同，ROS 节点里的解码、置信度过滤和框坐标变换需要重写；可复用的部分是 sensor_msgs/Image 到 GPU 的拷贝与预处理 kernel，输出张量解析按 YOLO26 格式实现。

检测器只在训练分布内可靠。白色路障在窗边逆光时可能形成高光区域，置信度降到 0.3 附近；走廊尽头的小物体只占十几个像素，可能直接漏检。HSV 红绿灯阈值对曝光更敏感，背景照度变化时容易失准。设计上采用“检测器 + 七帧投票”：连续七帧里至少五帧判成同一种颜色才采纳，再加 300 毫秒迟滞，避免机器人在红绿灯前反复起步停车。

5.2 Qwen3.8 9B 与 DeepSeek 的视觉复核边界

Qwen3.8 9B 和 DeepSeek-Flash 的主要角色是自主决策中的慢思考层，负责任务理解、任务分解、失败分析和长程规划；图像理解只是它们的多模态输入之一。本节讨论视觉复核，因为这一环节最容易与 YOLO 的职责混淆；视觉并不是模型的主用途。

在视觉任务里，YOLO 负责底层识别：常驻 Nano，输出类别、框和置信度，速度快，但仅支持训练过的类别。Qwen3.8 9B 和 DeepSeek-Flash 接管高难度、高精度复核：训练集外目标、细粒度缺陷、文字与标识、复杂空间关系，以及安全关键场景的二次确认。

Qwen3.8 9B 是多模态慢思考模型，视觉只是输入之一。Q6_K 量化后约 8.5GB，运行在控制机 GPU 上；控制机显存要求不低于 11GB；RTX 2080 Ti 仅为本文测试配置，不是硬性要求。测试中它与 Laya 服务共用控制机。模型侧测试记录显示：港口场景描述输出 58 个 token，耗时 1.77 秒，速度 42.37 token/s；这个延迟适合关键帧复核，不进入 10Hz 控制。DeepSeek-Flash 是云端多模态模型，网络良好时用于更难的开放场景，延迟 2–6 秒，不参与实时控制。

触发条件有五类：YOLO 置信度低于 0.6；出现未训练类别；需要读取文字、铭牌或裂纹等级；需要描述目标之间的空间关系；安全层准备放行但场景不确定。默认仅机载 YOLO 常驻；控制机 Qwen 和云端 DeepSeek 按关键帧调用。其余时间摄像头数据只在机载环形缓冲区滚动，关键帧按需上传到控制机。

视觉模型的输出必须结构化。固定 JSON schema 只允许填字段，不允许自由发挥：

{
  "scene": "indoor corridor, glass partition on the right",
  "objects": [
    {"label": "glass door", "bbox": [0.61, 0.18, 0.94, 0.86], "attributes": ["transparent", "closed"]}
  ],
  "hazards": ["transparent obstacle not visible to lidar"],
  "actionable": true,
  "confidence": 0.78
}

映射到地图坐标是另一项处理。相机没有深度，只能基于地面平面假设做单应变换：取 bbox 底边中点，按相机内参和安装高度反投影到 z = 0 平面，再用同一方位上的激光距离修正。三米以内误差可接受，五米以外只能作为方向性提示。台阶和斜坡会破坏该假设；涉及高度的判断不单独交给视觉模型。

5.3 玻璃门场景

玻璃门应列为典型失败模式。激光雷达可能输出一条连续直线：905 nm 激光几乎穿过玻璃，回波弱到被滤除。代价地图为空时，move_base 会规划穿过玻璃的路径。设计上应让关键帧模型返回“右侧有一扇关闭的玻璃门，金属边框可见”，再由安全层把前方 1.2 米标成致命障碍并停车。

玻璃门场景的设计对策是贴四个 ArUco 标记，检测到标记就按实体墙处理。VLM 的输出不能当作稳定测量，但可以补上激光雷达对透明物体的盲区。

镜面是另一个误报源。走廊尽头的镜子可能使 VLM 报告“前方有一台六足机器人”，而目标实际是自身。在提示词中增加“忽略镜像与屏幕中的同一台机器人”，并在预处理中对镜面区域做掩码，可以降低这类误报。

5.4 数据集与训练策略

YOLO 只负责底层类别，数据集按任务拆分：人员、车辆、设备、玻璃门框、台阶、坑洞、通道障碍。每类定义明确的标注规则，例如遮挡超过 50% 不标、远距离小于 12 像素不标、镜面反射不标。训练集、开发集、测试集按场景分组，避免同一段视频的相邻帧同时出现在训练和测试里，否则指标会虚高。

5.5 视觉链路中的模型分工

在视觉链路里，三类模型的职责不能混。YOLO 负责机载常驻检测，Qwen 负责控制机侧高难度复核，DeepSeek 负责云端开放场景。选择依据是延迟、隐私、输入复杂度和是否需要语言解释，而不是模型参数量。离开视觉任务后，Qwen 和 DeepSeek 仍承担 6.3 的慢思考与决策。

5.6 视觉失败模式

5.7 地形、对象状态与场景图

YOLO 输出检测框，Qwen 和 DeepSeek 输出语义与关系。世界理解分三层：检测层输出目标类别，对象层输出目标状态，场景层输出对象关系和可通过性。

{
  "terrain": {"step_cm": 12, "slope_deg": 3, "surface": "dry_tile", "free_width_m": 0.8},
  "objects": [
    {"label": "person", "state": "crouching", "distance_m": 4.0},
    {"label": "box", "state": "fixed", "blocks": "right"}
  ],
  "relations": ["person left of doorway", "box narrows passage"],
  "traversability": "caution",
  "uncertainty": ["step_height_estimate"]
}

本地 Qwen 负责控制机在线时的场景理解，云端 DeepSeek 负责开放世界、长尾对象和复杂关系；两者都输出结构化场景图，再和激光、位姿、局部地图做几何校验。VLM 没有可靠深度，不能单独给出台阶高度或净宽；测距仍以激光和点云为准。世界理解的输出是用于规划的语义地图，不作为完整物理世界模型。

场景图必须带时间维度：每个目标有 track_id、last_seen 和置信度衰减；遮挡超过 1 秒标记为 stale，不能把“暂时看不见”当成“可以通行”。多帧确认后再更新地图，规划器把 stale 区域按未知处理，不按空闲处理。

下面的 JSON 是语义与几何融合后的场景图，不是单帧 VLM 的原始输出；`step_cm` 和 `free_width_m` 已经过激光/点云校验。

5.8 可通过性阈值

世界理解最终用于判断是否可通过以及采用何种步态。下表为设计阈值，不是实测值；台阶、坡度、沟宽都要结合当前步态、载荷和地面材质修正。

12 cm 台阶属于“谨慎”上限，必须降到低速、增大抬腿高度并逐腿确认；超过阈值时，系统直接停车、后退或换路，不再调用模型判断。可通过性判断输出 safe / caution / stop 三档，规划器只接受 safe 和带速度限制的 caution。

六、VLA 与三层模型路由

端到端 VLA（Vision-Language-Action，视觉-语言-动作）在六足上难以直接采用。18 个关节的连续动作空间大，真机演示少，模型出错后没有二次确认机会。方案把动作空间压到技能原语，模型只输出技能和参数。

6.1 动作空间与技能定义

动作层拆分为技能原语，不直接输出关节角。控制机上的技能层负责把“往北门走两米”转换为路径、步态和串口帧；模型只决定当前技能及参数。动作空间因此从 18 维连续量缩减为十几个离散技能加少量参数，降低数据需求并明确安全边界。

{
  "skill": "NAV_TO",
  "params": {"target": "north_door", "standoff_m": 0.8, "timeout_s": 60},
  "preconditions": ["localized", "battery_gt_20", "path_exists"],
  "on_failure": "REPORT"
}

技能库设计为：NAV_TO、LOOK_AT、SCAN_AREA、APPROACH_AND_PHOTO、SET_BODY_HEIGHT、STEP_OVER、BACK_OFF、TAKE_PHOTO、SAY、STOP。每个技能都有前置条件、参数范围、超时和失败返回。模型无需接触步长、抬腿高度等步态参数，只需输出目标语义和技能选择。

技能接口按 VLA 设计，最终方案没有采用端到端 VLA。18 个关节的连续动作需要大量真机演示，而六足的接触和打滑很难仿真；技能层的确定性代码更便宜，也更容易检查。VLA 因此被简化为技能选择问题，交由三层模型架构处理。

6.2 Laya 与 System 1 决策模型

Laya 是 Jev 类的 System 1 决策模型。System 1 在这里指快速、单次前向的判断层，与多步推理的 System 2 相对。这里的“Jev 类”指模型类别，不是 Jev 的分支，也不表示两者有代码依赖。它不生成动作序列，也不是 JEPA 式潜空间世界模型；它做的是非自回归判断：输入一段状态和一组类型化问题，单次前向给出选择、分数或“是/否”概率。

Jev 是 TypeSafe 提供的闭源托管模型。它的能力边界是对预先定义好的问题做类型化判断：把状态归入几个选项、给指标打分、输出是否升级给慢思考；输出形式分别是选项概率、分数和“是/否”概率，在 Laya 接口里对应 choice、score 和 noul。它不负责开放式对话、长文本生成或关节控制。Laya 是同一类思路的开源实现，接口和输出形式接近，但不是 Jev 的官方复刻，精度也不保证与 Jev 相同。公开对比中，Jev 在多标签和复杂判断上更强，Laya 在单题延迟和控制机本地运行上更有优势。因此 Laya 只用于选项少、领域固定的判断，不用于开放域推理。

Jev 是闭源托管的能力上限参照，Laya 是控制机上的低成本快判断模型。漫巡不部署 Jev，因为它依赖外部托管服务，状态和图像需要离开控制机，链路和隐私不可控；Laya 可以在控制机本地运行，适合低基数判断。两者只做类型化判断，不构建世界模型；地形、对象状态和空间关系由 5.7 的 Qwen 或 DeepSeek 处理。

它有三个 checkpoint：英文的 laya（ModernBERT-large，421M）、多语言的 laya-multilingual（mmBERT-base，322M，100+ 语言）和面向类型化决策微调的 laya-typed-decisions。内置 Router 会按语言和脚本自动选 checkpoint；这里的 Router 只负责选择 Laya checkpoint，不参与系统级模型路由。官方在 T4 上测得单问题 33 毫秒，批处理 7.2 毫秒/题；方案是在控制机上以 ONNX/INT8 运行多语言模型，单次判断约几十到一百多毫秒，足以放进控制回路外围。离线使用时用 Router(models={...}) 指向控制机上的 checkpoint。

Laya 在漫巡中的职责范围很窄：判断语句是命令还是闲聊；判断异常是玻璃、人员还是误报；选择当前技能；判断置信度是否足够、是否升级给慢思考。它不输出关节角，也不直接写 /cmd_vel。下面是一个判断调用示例：

from laya import Router

router = Router(preload=True)
result = router.predict(
    {"body": "前方玻璃门，激光无回波，视觉置信度 0.74，任务为通道巡查"},
    {
        "hazard": {
            "type": "choice",
            "instructions": "这是什么类型的风险？",
            "criteria": {"glass": "透明障碍", "person": "人员", "none": "无"},
        },
        "escalate": {
            "type": "noul",
            "instructions": "是否需要慢思考模型复核？",
        },
    },
)
print(result["answers"]["hazard"]["choice"])
print(result["answers"]["escalate"]["noul"])  # P(true)

它和 VLA 的区别在输出：VLA 将视觉与动作端到端连接，Laya 只做判断，判断对象可以是文本、传感器摘要、任务状态，甚至另一段模型的输出。

6.3 Qwen3.8 9B 与 DeepSeek-Flash 的路由规则

慢思考分为两级：控制机 GPU（不低于 11GB 显存）运行 Qwen3.8 9B，负责不依赖公网的任务理解、任务分解、失败分析和长程推理；网络条件允许时，路由到云端 DeepSeek-Flash，获得更广的知识覆盖和开放场景表达。两者的主要职责是自主或受命决策，图像理解只是其中一种输入。Qwen 用 Q6_K 量化，约 8.5GB，保留比 4-bit 更好的视觉细节；DeepSeek 只处理关键帧，不参与实时控制。

路由按问题类型、置信度、延迟预算和网络质量决定。核心路由逻辑如下：

def route(task, net):
    # 1. 类型化判断先交给 Laya，几十到一百多毫秒
    if task.kind in {"intent", "hazard", "skill", "escalate"}:
        r = laya.predict(task.state, task.questions)
        if r.confidence >= 0.65 and not r.escalate:
            return r

    # 2. 网络好、任务允许上云：DeepSeek-Flash 做开放场景思考
    if net.rtt < 80 and net.loss < 0.01 and task.allow_cloud:
        return deepseek_flash.plan(task)

    # 3. 断网或隐私受限：控制机 Qwen3.8 9B
    return qwen38_9b.plan(task)

除伪代码外，路由还包含以下规则：涉及人脸、原始图像的请求默认不上云；控制环内的反射控制不经过任何大模型；云端超时 3 秒时转交控制机 Qwen；控制机 Qwen 也超时，则退回 Laya 的类型化判断加规则任务图。路由器根据延迟、隐私、断网风险和结果质量选择当前最合适的模型。

6.4 数据、微调与安全约束

Laya 不需要动作演示数据。训练样本是类型化判断：每条样本由一段状态和一个问题组成，标签为选项、分数或“是/否”。例如“这句话是否升级给慢思考”“这个异常是玻璃还是人影”“当前应调用 NAV_TO 还是 BACK_OFF”。每个判断先标注几百条样本，再用仓库自带的微调流程校准置信度；模型本身支持零样本使用，微调用于加入实验室术语和边界条件。

安全闸门是独立于所有模型的确定性代码，任何模型输出都必须通过它：技能名必须在白名单内；参数必须在物理范围内；前置条件必须满足；执行前再次检查代价地图和悬崖传感器；执行中每 200 毫秒接收一次心跳，超时即急停；机身倾角超过 25° 时冻结步态。模型输出不直接作为安全依据。

6.5 路由状态机与熔断

路由是状态机，不是单次函数调用。Laya 先输出类型化判断；置信度足够则结束。置信度处于中间区间时，交由控制机 Qwen 复核；Qwen 仍无法决定，再根据网络条件决定是否上云。任何一层超时或连续失败都触发熔断，避免请求在模型间反复排队。控制链路中断时，Laya 与 Qwen 都不可达，机载规则层直接接管，不排队等待模型。

6.6 Laya 的输入输出约束

Laya 只接受文本或结构化状态，不直接读图。图像必须先由 Qwen 或 DeepSeek 转成场景摘要、目标列表或缺陷描述，再交给 Laya 做类型化判断。视觉模型输出观测内容，Laya 负责分类和升级判断。

使用限制也要写进设计：选项数控制在 10 个以内，选项顺序固定或做多排列投票，置信度按 max(p) 重新计算，不直接使用模型自带的置信字段。Laya 对长文本和大标签集不如 Jev，因此只用于领域固定、选项少的判断。

6.7 评估指标

模型层评估不限于准确率。设计上跟踪五项：技能选择正确率、人工接管率、安全闸门拦截率、升级到慢思考的比例、端到端延迟。前四项用离线回放和仿真场景统计，延迟在目标硬件上测。对同一段输入重复运行多次，检查输出稳定性和置信度校准，避免模型在边界样本上随机跳变。

整机评估还包括失败恢复：模型给出错误技能时，安全闸门是否能拦住；拦截后，系统是否能回到可执行状态；人工接管后，是否能重新使能。任何一项不通过，都不应进入自主模式。

七、语音识别与意图解析

官方 APP 的语音控制是在线识别，依赖网络。网络变差时，识别延迟和失败率都会上升；录音上传云端并等待文本返回，不适合作为“让机器人往前走”的控制链路。

7.1 机载 ASR 链路

设计链路是：麦克风阵列 → 16kHz 单声道 → 降噪与高通 → VAD 断句 → 机载 ASR → 文本规整 → 意图解析。VAD 使用 Silero，断句阈值取保守值，以约 200 毫秒的额外等待换取完整语句。ASR 用两个模型分工：命令词走 FunASR 的 Paraformer 流式模型，延迟低，中文短句准；自由表达走 Whisper-small 的 INT8 版本，慢一些，但抗噪和长句更好。

声学环境比模型更决定识别效果。十八个舵机同时换向时，机身内部噪声是宽带的，麦克风贴在机身顶部时信噪比会明显下降。设计上采用带指向性的 MEMS 阵列，加物理减振，并在音频前端做 120Hz 高通和谱减；USB 声卡容易把舵机 PWM 啸叫和电源工频引入底噪，不作为首选。

7.2 意图、槽位与澄清

ASR 输出的是文本，执行器需要意图和参数。命令词用文法解析：方向、距离、目标、动作，各占一个槽位，距离统一换算成米，角度统一换算成度。文法覆盖不到的句子再交给控制机 Qwen3.8 做函数调用，输出仍然要落回同一套 schema。两条路径都失败时，系统进入澄清流程，不进行猜测。

中文同音字是意图解析的主要歧义源。例如“门口”被识别成“门扣”时，文法里的地点槽匹配失败；语言模型可以纠正，但纠正结果的置信度可能低于阈值。此时系统不应猜测方向，而应复述并请求确认，例如“北门还是南门”，确认后再进入技能执行。

7.3 意图 schema 与澄清策略

意图解析的输出必须是 schema，而不是一段自然语言。schema 至少包含意图、槽位、置信度和原始文本；执行器只读意图和槽位，原始文本只进日志。这样即使 ASR 输出异常语句，也不会绕过技能白名单。

{
  "intent": "NAV_TO",
  "slots": {"target": "north_corridor", "standoff_m": 0.8},
  "confidence": 0.91,
  "raw_text": "去北边走廊看看"
}

澄清策略按置信度分级：高于 0.8 直接执行；0.6 到 0.8 复述确认；低于 0.6 或槽位缺失时反问。反问不能无限循环，同一句话两次澄清失败就退出语音模式，转为手动。

7.4 语音三级路由

语音识别统一在机载完成，路由的是 ASR 之后的文本和上下文。短命令由机载文法处理，复杂句由控制机 Qwen3.8 处理，开放域或长尾表达由云端 DeepSeek 处理；“停”不参与路由，直接进入安全校验。

路由判据包括文法命中、ASR 置信度、句长、槽位完整度、任务风险、控制链路 RTT / 丢包和隐私等级。机载优先，控制机次之，云端最后；控制链路断开时只保留机载，云端超时则退回 Qwen，Qwen 超时再退回机载文法加反问。任何一层都只能输出技能和参数，不能直接写 /cmd_vel。

7.5 音频延迟预算

语音不作为实时控制通道。一句“停”从说完到机器人收到零速，预算约 1 秒；急停必须由手柄、物理按钮或看门狗触发，不能依赖语音。

八、三层算力与任务分工

模型服务全部自行配置。Laya、Qwen3.8 9B 与 DeepSeek-Flash 共用一套请求 schema：输入任务类型、状态、问题列表和网络条件，输出结构化 JSON 或类型化判断，后端不做字符串拼接。

服务入口用 FastAPI/HTTP 和 WebSocket。ROS 节点只接受 schema，不依赖模型名。路由器根据问题类型、置信度、延迟预算和网络质量分派到 Laya、控制机 Qwen3.8 9B、DeepSeek-Flash；文本、语音和图像共用同一路由，图像只是其中一种请求。换模型不需要改执行层；模型服务不可用时退回 Laya 和规则任务图。

8.1 算力分层与链路约束

本地算力分两级：机载负责实时控制与基础感知，控制机负责决策、规划与 VR 桥接；云端只做开放场景。控制机需要不低于 11GB 显存的 GPU 用于本地模型，GPU 安装在控制机内；具体型号不限。数据通过 PoE 网线、光纤或 WLAN；供电通过 PoE、轻型电源缆或混合缆。电源缆本身不传数据。

分工原则是：越靠近执行器，越不允许阻塞。 云端调用预算约 6 秒，控制机 Qwen 约 8 秒，Laya 约 100 毫秒，但 /cmd_vel 的看门狗必须每 500 毫秒收到一次心跳。云端返回任务图：目标、检查项、停止条件和失败上报对象。任务图在控制机和机载侧逐条校验，校验不通过则拒绝执行。

8.2 超时、降级与云端边界

云端调用有两档超时：软超时 3 秒，触发 TTS 播报“正在处理”，避免交互停顿；硬超时 8 秒，直接放弃，转给控制机 Qwen3.8 9B，或者退回 Laya 的类型化判断加规则任务图。这些调用在异步线程中执行，控制循环不依赖云端状态。

降级路径提前定义：DeepSeek-Flash 不可用 → 控制机 Qwen3.8 9B；Qwen 超时 → Laya + 规则任务图；Laya 无法判断 → 只执行避障和返回起点；控制链路中断或定位丢失 → 原地停、鸣笛、闪灯、等人工接管。每一层降级都有明确的触发条件和恢复条件，恢复之后不会自动跳回最高层，必须经过一次人工确认。

隐私策略如下：默认只上传降采样后的 512 像素关键帧，人脸区域先做模糊；原始 rosbag 不出内网。语音默认机载识别；需要云端慢思考且隐私策略允许时，只上传文本和必要上下文，不上传音频。全量上传会增加带宽、延迟和审计负担。

8.3 日志与可观测性

每次决策都会写一条结构化日志：时间戳、指令原文、ASR 文本、VLM 摘要、路由结果、技能与参数、安全闸门判定、执行结果和端到端耗时。传感器数据用 rosbag 滚动保存，只保留最近三十分钟；关键事件前后的三十秒单独归档。所有日志进一张 SQLite 表，按日期分库。

日志主要用于定位误报。例如 VLM 可能把消防栓影子判成“倒地的人”，安全闸门收到 hazard 后冻结步态。设计上通过回放关键帧、重新运行提示词确认误报，再调高“人影”类别阈值，并增加“静止目标连续三帧才确认”的规则。缺少日志时，只能观察到机器人停止，无法定位原因。

8.4 服务拓扑与模型仓库

模型服务与机载控制层分开运行。机载控制层只保留串口、步态、传感器和看门狗；规划、模型服务与 VR 桥接在控制机，通过 HTTP / WebSocket 提供能力，不直接访问串口。模型服务重启不会影响机载控制环，控制环也不依赖模型版本。

8.5 超时、重试与熔断

重试只对幂等请求生效。图像识别、任务规划可以重试；速度命令、模式切换、动作组运行不能盲目重试。连续两次失败后进入熔断，熔断期间只走机载规则，恢复后也不自动回到之前的自主任务。

8.6 资源与功耗预算

8.7 显存与算力预算

显存预算需要按最坏组合计算。Q6_K 权重约 8.5GB，视觉投影器 1–2GB，KV/上下文 0.5–1.5GB，4K 全景拼接 0.5–1GB，再加系统和驱动，总量可能到 11–13GB。不能在 VR、360 拼接和 Q6_K 同时开满的情况下假设 11GB 够用。

运行策略：VR/360 模式默认 Q5_K_M，4K 拼接放在 Quest 3 shader；桌面高精度模式才用 Q6_K，同时关闭控制机 4K 拼接或缩短上下文。不在运行中动态换模型；显存不足时先降上下文和码率，再降量化，不能静默 OOM。

九、通信链路与供电

拒止环境里，通信链路决定哪些数据能回来、哪些控制能出去。控制机通过 PoE、光纤或 WLAN 传输数据，通过 PoE、轻型电源缆或混合缆供电；电源缆本身不传数据。4G 用于公网回传，Mesh 用于多机与中继，GNSS 提供有天空时的绝对位置。链路按任务切换，不能互相替代。

9.1 链路类型与有线模式

4G 负责广域覆盖。遥测、语音文本、云端慢思考走 4G，带宽和延迟受基站与拥塞影响，不用于反射控制和 VR。链路用独立 APN 或 VPN，1Hz 心跳，断线后指数退避重连。

有线分三类：PoE 网线、光纤、轻型电源缆；混合缆是后两者的组合，不是第四种独立链路。PoE 网线模式使用 Cat5e/6 千兆网线：100BASE-TX 只占用 1-2、3-6 两对线，4-5、7-8 四根线作为 48–56V 供电，也就是 2 正 2 负；数据链路为百兆，供电与数据分开。这种接法属于 100M 下的 PoE Alternative B 思路，不是千兆 PoE。标准 802.3af/at 的 15.4W / 30W 只能承担机载电子或充电，整机舵机峰值仍由电池缓冲。

光纤模式不提供供电。光纤直径小、重量轻、带宽大于 1Gbps、免疫电磁干扰，机器人由自身电池供电，适合 4K 视频、点云和长距离。绞盘按张力放线、收线，前进时自动放线，后退时自动收线；缺点是转弯处易磨损、易缠绕，线缆不得对机器人形成持续拖拽载荷。

供电核算按平均 50–70W、短时峰值 120–150W 估算。48V 下 60W 对应 1.25A 总电流，2 正 2 负四根线各承担约 0.63A，略高于标准 PoE 的 0.6A/对，需要按被动 PoE 配专用注入器；30 米 Cat6 的回路电阻约 2.1Ω，压降约 2.6V，线损约 3.3W，可以接受。120W 时总电流 2.5A，每根线约 1.25A，30 米压降约 5.3V、线损约 13W，已经明显超出标准 PoE 的单对电流范围，需要限流、温升和专用注入器。100 米、120W 时回路电阻约 7Ω，压降约 17.5V、线损约 44W，不适合由两对线承担。

结论：用 Cat5e/6 千兆网线的四根线供电、四根线跑百兆在 30 米以内可行，但链路是百兆，不是千兆；PoE 适合承担机载电子和充电，舵机峰值由电池缓冲。机载端需要隔离 DC-DC、缓启动、保险丝和反接保护，不能把 48V 直接接到 5V 轨或电池。30 米以内可用 Cat6；30 米以上一律光纤，200 米级用 600V 光纤混合缆。若坚持四对线 PoE，数据会占用全部线对，不能再保留独立的四线百兆。

第三种是轻型电缆或混合缆。短距离版本用 48V；200 米版本把供电电压提高到 600V DC，导体取 2×0.5mm²，数据走光纤。0.15mm² 满足载流要求，但机械强度不足，比网线芯线更细，不适合做拖曳线；0.5mm² 是机械和载流的折中。千兆网线在 200 米不能保证 1Gbps，Cat6 的链路上限是 100 米，所以 200 米混合缆必须是光纤加电源线，而不是网线加电源线。

200 米、0.5mm² 铜芯的回路电阻约 14Ω。48V 下 150W 需要 3.13A，压降 43.8V，线损 137W，不能工作；110V 下 1.36A，压降 19.1V，线损 26.0W，效率太低；400V 下 0.375A，压降 5.25V，线损 1.97W；600V 下 0.25A，压降 3.5V，线损 0.875W，约占输出功率的 0.6%。方案取 600V DC，200 米、150W 平均功率，峰值由电池缓冲。

200 米混合缆的结构是：2 芯单模光纤、2×0.5mm² 电源线、芳纶加强件和薄壁 PUR/PTFE 护套，直径约 8–10mm，重量约 25–30g/m，200 米约 5–6kg。连接器用带高压联锁的混合接头，IP67，先接地后通电，断线先断电。控制机侧或绞盘端提供 600V DC，机载端先用 600V→48V 隔离模块，再降到 12V 和 8.4V/5V；双源 OR-ing，电池缓冲瞬时峰值；600V 侧限流 1A，并加预充、保险丝、绝缘监测和急停回路。600V 不属于 SELV 或 PoE，需要按高压直流维护。

双源策略：低功耗时电缆供电子系统并给电池补电；瞬时高功耗时电池补足差额，电缆电流被限流，类似笔记本适配器加电池。短距离仍可用 48V 轻型电缆或 PoE；30 米以内可用 Cat6，30 米以上数据一律走光纤，200 米以上不再使用供电拖缆。

拖曳能力需要单独核算。4 kg 六足在普通地面的牵引力约 24N；5–6 kg 电缆按 0.3–0.5 的拖曳系数需要 15–30N，已经接近或超过牵引力；十几 kg 电缆需要 35–74N，超出牵引能力。因此 200 米方案不能由机器人承担整根电缆的拖曳：控制机侧或绞盘端放线，机器人只拖 2–3 米低张力回路，张力限制在 8–10N，超限即停并断开。没有绞盘时用小车或滑橇承载电缆，不能直接拖 200 米。

9.1.1 线缆管理、地面站与 600V 安全

线缆管理是独立子系统。控制机侧放置 600V 电源、恒张力绞盘、光纤/PoE 交换机和 UPS；UPS 只保控制机和绞盘控制，不保机器人舵机。机器人只承受低张力回路，绞盘负责放线、收线和张力限幅。

600V 安全清单：接地故障/漏电保护、电缆破损检测、断电后 5 秒内放电到安全电压、IP67 与爬电距离、连接器高压联锁、维护挂牌上锁。任何一项未通过，不允许上电。

供电为可选配置，默认由机载电池供电。8.4V 9600mAh 电池约 80.6Wh；按设计任务组合，约 80% 的短程巡查、拍照和避障任务由电池独立完成，不带任何供电缆。只有连续高负载、长时间值守或边充边用时才接外部供电。不同距离的方案如下：

电池任务谱按设计功耗估算，80% 的边界定义为“单次不超过 60 分钟、平均不超过 60W”。超过这个边界才接外部供电；约 80% 的短任务不需要拖缆。

超过 100 米时数据必须换光纤，Cat6 只保证 100 米内千兆。200 米是有线模式的上限，超过 200 米不再使用供电拖缆，改用电池、换电或中继。600V 供电只在超过 30 米的供电缆方案里使用，短距离仍用 48V 或 PoE；如果任务只靠电池，不接任何缆，系统按无缆构型运行。

Mesh 负责无基站区域。多台机器人或地面中继组成无中心网络，某个节点失效后自动重路由。5GHz Wi-Fi 在 1–2 跳内可用，跳数增加后带宽下降、抖动上升，不适合长链路 4K 或 VR。Mesh 适合编队、跨楼宇和临时救援网。

GNSS 只在有天空视图时有效。它提供绝对位置和航向初始化，进入室内、管廊或茂密树冠后交给 SLAM 与 IMU。链路管理器读取 fix type、卫星数和 HDOP，低于阈值就标记为不可信，不能把 4G 基站定位当作 GNSS。

9.2 链路选择与切换

链路管理器每 500ms 采样 RTT、丢包、抖动、RSSI 和接口状态，按任务打分：4K 视频、点云和 VR 优先光纤；控制、遥测和低码率视频可走 PoE；持续供电优先轻型电缆或混合缆；移动场景用 Mesh；遥测和语音文本可以走 4G；急停与速度指令同时走两条可用链路，收到一条就执行。切换带 2 秒迟滞，避免在临界点反复跳变。

切换期间保持最后一条安全速度或直接停车，不让控制环等待网络恢复。业务链路和安全链路分开：视频断了只影响观察，控制链路断了必须触发看门狗。

安全上，4G 走 WireGuard 或专网 APN，Mesh 用 WPA3，服务端做设备证书和命令序号校验；控制帧带时间戳，过期帧直接丢弃。公网裸 UDP 不用于运动控制。

9.3 链路预算

9.4 切换评分与状态机

链路选择用加权评分，而不是单一信号强度。评分项包括可用带宽、RTT、丢包、抖动、任务允许上云、隐私等级和链路费用。分数只在采样窗口内有效，切换后重新评估；连续两个窗口低于阈值才降级，避免在临界点反复跳变。

def score(link, task):
    if not link.up:
        return -inf
    s = link.bandwidth / task.need_bw
    s -= link.rtt / task.max_rtt
    s -= link.loss * 20
    s -= link.jitter / task.max_jitter
    if task.private and link.cloud:
        return -inf
    return s

状态机分为 NORMAL、HANDOVER、DEGRADED、ISOLATED 四个状态。HANDOVER 期间保持最后一条安全速度，超时未完成则直接停车；ISOLATED 状态下只允许本地自主和物理手柄，不接受云端任务。

9.5 多机器人 Mesh

多台六足或地面中继组网时，拓扑和维护开销会迅速上升。设计上限制最大跳数，按区域划分信道，避免所有节点在同一信道上广播；遥测采用周期性汇总，视频按需拉流，不允许每台机器人持续上传高码率视频。

时间同步是 Mesh 的关键问题。多机共享地图和任务时，事件时间戳必须统一到同一时钟源；没有 GNSS 时用本地时钟加 NTP 或 PTP 主节点，云端只做参考，不能假设所有节点都能访问公网。

十、VR 遥操作与 360° 全景

光纤、混合缆、PoE 和 5GHz Mesh 可以承载 Quest 3 串流；高码率画面优先光纤、混合缆或 Wi-Fi 6。VR 除相机画面外，还提供视觉随动、姿势随动和 360° 全景模式；头姿可驱动云台、机身转向、底盘高度和步态，手柄用于多动作映射。所有输入仍经过 P1 仲裁。

10.1 串流链路

机载相机先由 Nano 采集并做轻量压缩，通过光纤、PoE 网线、混合缆或 WLAN 送到控制机；控制机完成画面合成，再用控制机 GPU 的硬件编码器（如 NVENC）编码为 H.264/H.265，通过 WebRTC 或 RTP 送到 Quest 3 的 Unity/Unreal 客户端。光纤优先承载高码率视频，PoE 用于控制与低码率视频，移动时用 5GHz Wi-Fi 6；控制机到头显用 Wi-Fi 6 或 USB-C Link，4G 不参与 VR。目标是单眼 2064×2208、90Hz、码率 50–150Mbps、运动到成像低于 100ms。

头显姿态以 90–120Hz 通过 WebRTC DataChannel 或 UDP 回传，机器人状态以 30–50Hz 回传。两端用同一时间戳对齐，客户端做短时姿态预测；丢包超过 200ms 就冻结画面并提示，不继续接受运动指令。

10.2 视觉、姿势与全景随动

头显姿态提供多条映射路径。系统包含视觉随动、姿势随动、全景随动和混合模式，默认只开视觉随动；姿势随动需要显式启用，并且只在低速或静止时生效。

视觉随动：水平与俯仰先经过低通和限速，再映射到二自由度云台。云台水平 180°、俯仰 180°（各 ±90°），由两个总线舵机驱动；机身不动，适合观察和精细操作。

姿势随动：头向左看超过阈值，机身向左转；头显高度下降，机器人降低底盘；起立则升高底盘；前倾或后仰映射为小步前后移动，头部 roll 映射为机身侧倾。所有动作有角度、速度和高度限幅，且只在 deadman 按住、速度低于 0.05 米每秒、代价地图和悬崖检查通过时执行。

全景随动：360° 相机覆盖四周，头显转动只改变全景视口，不驱动云台或机身，因此不引入机械延迟；适合先环视，再切换到视觉随动或姿势随动。

模式切换必须先回中并降到零速；姿势随动不能和自动任务同时启用，P1 接管、急停、悬崖或倾角超限都会立即退出姿势随动。头部姿态只作为目标，不直接写关节角。

进入姿势随动时记录操作员的中立高度 h0；头显高度变化先过 5cm 死区，再映射到底盘高度。操作员坐下、弯腰或重新站起后需要按一次“姿势回中”，否则新的站姿会被误判为下降指令。握把是姿势离合，不按住不执行底盘和步态动作。

VISUAL   --(grip+B, v=0)------------------> PANORAMA
VISUAL   --(double A, v=0, deadman)-------> POSTURE
POSTURE  --(release deadman / P1 / limit)-> VISUAL
ANY      --(e-stop / link loss)-----------> SAFE

视频和云台控制分开走：画面走 WebRTC，云台指令走 UDP 或串口。云台失联时自动回中，机器人停止；头显摘下有 0.5 秒超时，同样触发停车。

10.3 360° 全景相机

方案是在机身上加装两个 180° 半球摄像头，背对背刚性安装，覆盖水平 360°、垂直约 180°。每个镜头 1920×1080 或 2560×1440，硬件同步触发，拼接重叠区保留 10–20%。输出一路 4K30 等距柱状全景，供控制机实时查看和 Quest 3 全景随动；4K60 需要 150–200Mbps，默认不开启。

两个镜头必须锁曝光、锁白平衡，并做内参、外参和接缝标定；否则中间会有一条亮度或颜色接缝。机身振动和温度漂移会让外参变化，标定参数需要版本化，并在启动时做一次快速校验。

标定流程：单目标定内参和鱼眼畸变，双目标定外参与接缝，锁定曝光/白平衡，检查重叠区亮度差；装机后做振动复标，启动时用棋盘格或标定板快速校验。机身和腿会遮挡下视区，下视盲区由 ToF、激光和局部地图补，不把全景当作完整球面感知。

数据路径是：双 180° 相机 → 机载 Nano 采集/轻量编码，或直接走 USB/以太网 → 控制机；控制机用 GPU 去畸变、拼接为 4K 等距柱状画面，控制台可以实时拖拽查看，Quest 3 则按头姿取视口。低延迟版本可以把双鱼眼画面和标定参数直接送到头显，由 Quest 3 的 shader 拼接视口，控制机只做录制和监控。

10.4 手柄多动作映射与安全限制

手柄映射分为基础层、模态层和组合键三层。同一个摇杆在不同模式下可以控制机身、云台或底盘高度；扳机和握把通过组合键扩展，但急停始终是独立按键，不参与组合。

多动作映射按状态机解释：先判断当前模式，再判断组合键，最后做安全校验。模式切换必须先回中、零速并松开扳机；冲突时安全层优先，P1 人工接管优先于任何自动动作。VR 运动限制在最大线速度 0.12 米每秒、角速度 0.3 弧度每秒，不做快速机身旋转。

设计目标是头到云台低于 80ms、运动到成像低于 100ms、跟踪保持时间不少于 30 分钟。云台结构件和固件处于设计阶段，串流链路覆盖光纤、PoE 与 Mesh。

10.5 Quest 3 串流预算

10.6 云台控制律与姿势随动

视觉随动的云台角要经过限幅、低通和限速，不能把头显抖动直接放大到舵机。姿势随动则把头部 yaw、头显高度、前后倾和 roll 分别映射到机身转向、底盘升降、小步前后和侧倾；俯仰优先分配给云台，只有明确切到姿势随动时才驱动底盘。

pan  = clamp(k_yaw * yaw, -90, 90)
tilt = clamp(k_pitch * pitch, -90, 90)

# 姿势随动：头低下 -> 降底盘
crouch = clamp((h0 - head_y) / 0.3, 0, 1)
body_height = h_nominal - crouch * (h_nominal - h_low)

# 向左看 -> 向左转；只在零速/低速且路径安全时
if posture_mode and abs(yaw) > 30 and speed < 0.05 and path_clear:
    body_yaw_rate = clamp(0.2 * sign(yaw), -0.2, 0.2)

# 前倾 -> 小步前进，后倾 -> 小步后退
if posture_mode and abs(lean) > 0.08 and standstill:
    step_vector = clamp(lean, -0.15, 0.15)

姿势随动有四道门：头显跟踪有效、deadman 按住、速度低于 0.05 米每秒、代价地图与悬崖检查通过。云台角度、舵机速度、底盘高度、机身倾角和步长都有限幅；任何一道门触发，退出姿势随动并保持当前位置，不继续跟随头部。P1 接管和急停始终优先。

VR 验收指标按可测量项定义，不采用主观评价：

10.7 VR 失效模式

十一、端到端时序与失效模式

设计场景是一条自然语言指令：在受控环境入口对漫巡说“去北边走廊看看能不能通行，有没有人或者障碍”，目标是在设计预算内返回一张可用照片。下面的 T+ 时间和状态值是设计推演，不是运行日志；失败项是设计审查中需要覆盖的模式。

11.1 设计时序

设计阶段更值得先列清楚失败模式：

11.2 失效模式与严重度

11.3 实时与资源预算

11.4 测试层级

测试按代价从低到高分层，前一层不通过不进入下一层。单元测试覆盖帧解析、校验和、状态机；硬件在环检查串口时序和看门狗；受控环境测试建图、导航和视觉触发；最后才是完整任务链。每一层都记录版本、配置和失败样例，避免把环境问题误判成算法问题。

十二、后续工作

当前架构覆盖的能力边界是：在一张预先建好的二维地图里，按技能组合完成巡查、拍照、避障和简单人机对话。爬楼梯、草地行走、台阶可通过性判断和摔倒后自行站起不在本期设计范围内。以下是后续设计项和开放问题。

• 足端力觉：机载目前只有下视 ToF 和 IMU，无法直接测量接触力。后续设计在六只脚上加 FSR 或薄膜压力片，用 ADC 读取接触力，做落脚点估计和打滑检测。接触力是地形自适应和负载转移的前提。
• 动态步态：三角八步稳定但速度低。后续设计包括基于倒立摆模型的动态步态，或用强化学习在仿真中学习落脚策略。六足接触模型难以精确仿真，sim2real 风险高，因此列为研究项，不进入本期实时控制。
• 慢思考下沉：把 Qwen3.8 9B 的常见任务模板和失败模式蒸馏为 Laya 的类型化判断，减少断网时对 9B 的调用。复杂场景仍保留 9B，快路径可以覆盖更多固定判断。
• ROS 2 迁移：ROS1 的 move_base 和 actionlib 可用，但生命周期管理和多机通信能力有限。迁移到 ROS 2 可以改善节点重启、QoS 和实时性，代价是整套 launch 与驱动需要重写。
• 多机协同：官方手册提到集群协同，但两台六足如何共享地图、如何避免互相把对方当成障碍，尚无成熟方案。多机之后，通信一致性和任务分配比单机模型推理更难。
• 3D 感知：当前以 2D 雷达为主。管廊、塌方空间和矿井需要 3D LiDAR 或 RGB-D，配合 LIO-SAM / RTAB-Map 做点云建图。难点在时间同步、运动畸变和机载算力，算法选型只是其中一部分。
• 热与电流：18 个舵机在高负载下工作，电流和温度比位置更容易暴露故障。设计上应把电流、温度、堵转次数纳入遥测，并实现过载降额和负载转移。
• 评测与数据闭环：需要固定的场景库、故障注入脚本和回放工具，才能比较不同模型、不同步态和不同链路配置。统一评测是参数迭代和模型替换的前提。

结论：系统闭环与模型边界

系统能力主要受闭环完整性限制，参数量不是主要变量。串口校验、里程计校准、代价地图膨胀半径、看门狗、反问规则和可回放日志缺一不可；任何一项缺失，都会在特定场景导致任务中断。

模型会继续更新，但系统仍需判断脚是否踩实、前方是否有玻璃、电量是否足够、网络断开后如何处理。这些判断依赖传感器、状态机、安全层和日志，不能由模型参数量替代。

设计目标是在一张二维地图里完成巡查、拍照、避障和简单对话，离全地形自主还有距离。设计优先级是保证闭环完整，再扩展模型能力。