Python多形态机器人协同探测与太阳能回收利用实践

1. 为什么把Python、多形态底盘、太阳能和回收利用放进同一个系统里

很多人第一次看到“Python先进技术全面发展微波扫雷群机器人各种各样结合体研发开发重要性智能化系统化武器多样化太阳能利用回收利用可再生能源”这个题目，第一反应是“塞得太满了”。我当初也是这个感觉。但真正在野外做过一段时间地表异常目标探测——也就是用机器人去识别地下金属异物、浅层空洞、废弃管线残段这类东西——之后，我反而觉得这个题目虽然表述粗糙，但把野外工程作业的核心矛盾基本都点到了：单台机器干不完、干不久、干不准，而且作业环境往往没有电网。

所以这篇文章我想讲清楚的事情是：用Python作为主控层语言，把轮式、履带式、轻量足式这几种不同形态的平台组成一个可以协同作业的群体，用微波段与毫米波段雷达加金属感应线圈做浅层目标探测，用太阳能加电池组构成能源闭环，并且在设备退役之后把电池、结构件、电机重新回收利用。这套东西解决的是野外长时间、大范围、重复性排查任务的自动化问题，适合做机器人系统集成的工程师、做野外勘探设备的技术人员，以及想入门多机协同的高校实验室同学参考。

先把定位说清楚：这不是一个实验室里的演示系统，我关注的是“能不能在野外连续跑三天、坏了一个模块能不能现场换、太阳够不够用、电池报废之后怎么处理”这类非常土的问题。先进技术如果落不到这些土问题上，就只是论文里的先进。下面按设计思路、感知识别、集群协同、能源闭环、部署实操、故障排查六个部分展开，每一部分我都会给出参数选择和实测记录，能抄的直接抄。

2. 整体架构与技术路线拆解

2.1 为什么主控层选Python而不是全部用C++

这是一个被争论过无数次的问题。我的结论很明确：运动控制回路用C/C++，感知、决策、任务调度、数据处理全部用Python。理由不是“Python简单”，而是整个系统的迭代频率分布不均匀。底层电机驱动、IMU采样、力矩环这些东西，代码写完基本不动，改了就要重新做整机标定，这部分用C++跑在实时内核上是合理的；但上层的东西——目标检测模型、任务分配策略、能源调度逻辑、日志分析——每天都在改，用Python能把“改一行、跑一次”的周期从半小时压到三分钟。

具体分工我采用的是三层结构：最底层是运行在实时内核上的运动控制节点，负责轮速闭环、履带差速、足式步态相位；中间层是通信与状态管理层，用Python写，负责传感器时间戳对齐、状态机管理、异常上报；最上层是决策层，用Python写，跑检测模型、跑任务分配、跑能源预测。三层之间用消息总线解耦，中间层向上只暴露“当前位姿、当前能量、当前检测候选”这几个话题，上层向下的指令只允许“目标点、速度上限、作业模式”三种。这种约束看起来死板，但它救过我好几次——上层代码写崩了，机器人还能自己停下来待命，不会失控。

这里有个坑必须提前说：Python的GIL在真正多传感器高频采集时会咬人。我最初把雷达数据解析、图像推理、串口读取全塞在一个进程的多线程里，结果图像推理一跑，串口数据就开始丢包，表现出来是“机器人偶尔莫名其妙刹停”。后来改成多进程架构，每个传感器一个独立进程，进程间用共享内存传大块数据（图像、点云），用小消息队列传控制指令，问题就消失了。共享内存这块我用的是Python标准库的multiprocessing.shared_memory，配合一个环形缓冲区，实测图像传输延迟从8ms降到1.2ms。

注意：不要用Python线程去处理任何带硬件时序要求的任务。哪怕你觉得“这个串口读取很简单”，也请放到独立进程或者交给C++节点。我踩过最惨的一次是日志写入阻塞导致串口解析延迟，机器人把一个已经确认过的目标区域又扫了一遍。

2.2 轮式、履带、足式三种形态怎么分工

“各种各样结合体”这个词虽然不专业，但背后的需求是真实的：野外地形不是均质的。我最终确定的配置是三台轮式、两台履带、一台轻量足式，不是因为想炫技，而是按通过性和能效排出来的。

轮式平台负责大面积平坦区域的快速覆盖。它的单位距离能耗最低，实测在硬化土面上每米耗电约0.42Wh，速度可以跑到1.2m/s。缺点是过不去20cm以上的垂直障碍和松软沙地。所以轮式机器的任务永远是“网格化普查”，把大范围先过一遍，把可疑点标出来。

履带平台负责可疑点复核和复杂地形。它能过25cm台阶、能爬30度坡，但能耗是轮式的2.3倍，而且转向时对地表破坏大。所以履带机器只在轮式标记出候选点之后出动，做近距离确认。这个“普查-复核”的两级策略把整体能耗压下来将近40%，是我认为整个系统里性价比最高的一个设计决定。

足式平台只做定点精细作业。它走得不快、续航也短，但在碎石堆、台阶边缘、管线沟槽这种地方，轮式和履带都进不去。我给它配的是轻量四足，负载能力只有3kg，刚好够挂一个金属感应线圈加一个近景相机。它不承担覆盖任务，只负责“最后半米”。

三者的协同不是靠统一调度器硬指派，而是靠能力声明加任务认领：每台机器启动时广播自己的能力向量（可通过地形等级、最大速度、剩余能量、搭载载荷），任务池里的任务带着地形要求标签，匹配得上的机器才能认领。这样做的直接好处是，新加一台不同形态的机器不需要改调度器代码，只需要如实声明能力。

2.3 能源闭环的整体设计思路

野外作业最怕的不是任务难，是干到一半没电。我见过太多项目在实验室跑得好好的，拉到野外半天就趴窝。所以能源这块我一开始就是按“离网自持”设计的，整体分四层：

第一层是光伏补能。每台机器顶部铺柔性光伏板，轮式和履带用100W-160W，足式用30W。这里的关键不是板子多大，而是板子的朝向和遮挡。我最初把板子平铺在顶部，结果机器人作业时相机云台、天线、机械臂全都投下阴影，实测发电量只有标称值的55%。后来改成把光伏板做成可抬升的“小棚子”，作业时抬起来15度，避开了大部分自身遮挡，发电量恢复到标称的78%左右。

第二层是电池组与充放电管理。我用的48V磷酸铁锂，标称20Ah，约960Wh。选择磷酸铁锂而不是三元锂，主要考虑循环寿命和热稳定性，野外夏季舱内温度能到55度，三元锂在这个温度下的衰减和风险都不能接受。代价是低温性能差，零下10度容量只剩七成，所以冬季作业要配保温棉和自加热片。

第三层是能耗预测与任务裁剪。系统不是等电量低了才报警，而是持续预测“按当前任务队列还能不能干完”。预测不准是常态，所以我用的方法是滚动预测加保守折扣：按最近30分钟的实际功耗外推，再乘1.25的安全系数，如果预测剩余电量不足以完成队列前60%的任务，就主动裁剪任务并把结果上报。

第四层是退役回收。这个话题在工程文章里很少有人写，但我觉得很重要。电池容量掉到80%以下就不适合继续做动力电池了，但完全可以降级做地面储能站，配合光伏给备用机器和地面站供电。结构件里的铝合金和3D打印件、电机、驱动器、雷达模块，我建立了一套编号登记和寿命记录制度，哪台机器的哪个模块跑了多少小时、什么原因换下来的，全都有记录，能修的修、能拆的拆。这套制度看起来像后勤工作，但它让整个系统的单位作业成本降了将近三成。

3. 感知与目标识别的核心细节

3.1 多传感器的时间同步与标定，别在这里省钱

识别精度上不去，十次里有七次不是模型问题，是同步和标定问题。我的配置是：可见光相机、微波段浅层探测雷达、金属感应线圈、激光雷达、IMU、轮速计。这六路数据如果不做严格的时间对齐，融合出来的结果就是错的，而且错得很隐蔽——你会以为是模型漏检，其实是雷达数据和图像差了80ms，机器人走快了半米。

时间同步我分两级做。硬件级用脉冲每秒信号给相机和激光雷达打时间戳，精度能到微秒；软件级给串口类的传感器（金属线圈、部分雷达）打到达时间戳，再用最近邻匹配对齐。这里必须提醒：串口数据的“到达时间”不等于“采样时间”，中间有协议解析和缓冲的延迟。我的做法是在固件里让传感器自己在数据包末尾带上自己的采样计数，收到之后用计数差反推延迟，长期运行下来把这个延迟拟合成一个常数偏移量，实测能把对齐误差从60-90ms压到8ms以内。

标定分三步走。相机内参用棋盘格，这个没什么好说的，注意多拍几张不同距离的，别只在0.5米处拍一组。相机与激光雷达外参用带孔标定板，先粗对齐再点云优化，我一般做三组取平均，组间差异超过2cm就重做。线圈与车体位姿最容易被忽略——线圈装在车头前方0.8米处，车体俯仰角变化1度，探测点的地面投影就偏移1.4cm，在密集排查时这个误差足以让两个候选点合并成一个。我的处理是在线圈支架上装了个小IMU，实时补偿俯仰和横滚，代码里就是一个旋转矩阵的事，但漏了它结果就是错的。

实操心得：标定不要只在冷机状态做。电机运行后车架会有微小形变，热机状态下外参会漂。我现在的流程是让机器空跑20分钟再标定，标完存成“热态参数”，冷机启动时用热态参数，误差反而比冷态标定小。

3.2 微波段雷达加线圈的双模探测链路

单一传感器在野外基本不可靠。金属线圈对铁磁性材料灵敏，但对不锈钢、铝这类弱磁材料响应很弱；微波段浅层雷达对非金属和空洞敏感，但受土壤含水量影响巨大，湿土里信号衰减能到干土的三倍。两个都用，互相补。

数据链路是这样的：线圈输出的是连续模拟信号，采样率1kHz，先做50Hz工频陷波（野外到处是干扰），再做滑动窗能量积分，窗口长度按行进速度自适应——速度0.6m/s时用120ms窗，对应7cm空间分辨率。雷达输出的是B-scan图像，我做的是抽取9个通道的A-scan幅度特征，加上双程旅行时，组成一个特征向量。图像这边用轻量检测网络输出候选框和置信度。

融合策略我用的是分级加权而不是直接投票。具体是：线圈置信度高（信号强度超阈值3倍以上）时，直接判定为T2级候选，不需要图像确认；线圈信号中等时，要求雷达特征或图像检测至少有一路支持；线圈无信号但雷达有强反射、图像有异常时，判为T1级（需复核）。这个分级把现场误报率从初版的每小时11次压到了每小时2.3次。

分级阈值不是拍脑袋定的。我采集了约1400个真实目标点和2600个背景点的数据，画了ROC曲线，取等错误率点附近的阈值，再往保守方向挪10%。这套数据现在还在用，每次换场地都会补采200个点左右重新校一次阈值，因为土壤条件变了，绝对阈值不能照搬。

3.3 误报抑制与置信度分级的具体做法

野外最大的敌人是误报。误报多了，操作员就不信任系统，最后变成“机器报它的，人干人的”，系统价值归零。我用了三个手段压误报。

第一是多帧一致性确认。单个目标必须在连续N帧中被检出，且帧间空间距离小于阈值，才算有效。N我取3，距离阈值取行进距离的1.5倍。这个简单规则能干掉大部分随机噪点。

第二是空间排他。两个候选点距离小于15cm就合并，保留置信度高的。这里有个细节：合并时不是简单取最大，而是把两个点的特征向量取加权平均，因为很多时候是同一个目标被两次探测从不同角度看到，平均之后的特征反而更接近真值。

第三是负样本回灌。系统会把所有T1级（需复核）的候选点连同周边2米范围的原始数据打包存下来，操作员复核之后标记为真或假，这些数据每周回灌一次训练集。这套机制运行四个月之后，同一个场地的T1候选数量下降了62%，因为模型逐渐学会了这片场地的“背景长相”。

置信度分级我定成三档，对应不同处置：T0是背景，不记录；T1是需要人工复核或者派出履带机器人近距离确认；T2是高度确信，直接标记坐标并记录完整证据包（图像、雷达B-scan、线圈波形、位姿）。T2的判定要求双模同时高置信，宁可少判也不滥判。

4. 集群协同与任务调度的落地实现

4.1 通信拓扑与断连降级策略

野外通信是最容易翻车的地方。我试过三种方案：中心基站加星型、全互联mesh、以及分层混合。最后用的是分层混合——地面站作为弱中心，机器之间可以直连，但所有状态同步都通过地面站汇总再广播。这么做是为了避免mesh网络里状态不一致导致的“两台机器抢同一个任务”。

通信距离实测：开阔地带2.4GHz能到600米，有灌木遮挡降到220米，沟槽地形只有80米。所以我把作业区域按通信质量切成若干子区，机器人不跨区作业，跨区由地面站重新指派。这个约束牺牲了一点调度灵活性，但换来了稳定性，我认为值得。

断连降级是必须做的。策略是三级：一级是通信正常，全功能；二级是失联超过5秒，机器进入本地自治，继续执行当前任务但不能认领新任务，同时降低速度到50%；三级是失联超过60秒，停止作业，回到最后一个通信良好的位置待命，并且每30秒发一次信标。这套逻辑我用一个状态机实现，状态迁移条件全部写成可配置参数，方便不同场地调整。

# 通信状态机（简化版） from enum import Enum import time class LinkState(Enum): NORMAL = 0 DEGRADED = 1 LOST = 2 class LinkGuard: def __init__(self, t_degrade=5.0, t_lost=60.0): self.t_degrade = t_degrade self.t_lost = t_lost self.last_rx = time.monotonic() self.state = LinkState.NORMAL def on_rx(self): self.last_rx = time.monotonic() if self.state is not LinkState.NORMAL: self.state = LinkState.NORMAL self._on_recover() def tick(self): dt = time.monotonic() - self.last_rx if dt > self.t_lost and self.state is not LinkState.LOST: self.state = LinkState.LOST self._on_lost() elif self.t_degrade < dt <= self.t_lost and self.state is LinkState.NORMAL: self.state = LinkState.DEGRADED self._on_degrade() def _on_degrade(self): # 降速至50%，禁止认领新任务 ... def _on_lost(self): # 停止作业，返回最后已知良好位置，周期发信标 ... def _on_recover(self): # 上报离线期间缓存的事件，等待重新同步 ...

4.2 任务分配：用拍卖算法而不是贪心

任务分配的朴素做法是“谁近谁去”，这在多机场景下会出问题——三台机器同时冲向同一个近点，远处的任务没人认领。我一开始用的就是贪心，实测任务完成时间比预期长了将近一倍。

后来换成拍卖算法。思路很直白：地面站把待分配任务广播出去，每台机器根据自己的位置、剩余能量、载荷能力、地形通过性算一个出价，出价最低的赢。关键是出价函数要设计好，我用的是加权和：

def bid(robot, task, w=(1.0, 2.5, 1.5, 3.0)): # 距离代价：预计到达时间 t_travel = estimate_travel_time(robot, task) # 能量代价：完成任务预计耗电占剩余电量比例 e_cost = estimate_energy(robot, task) / max(robot.battery_wh, 1e-6) # 能力惩罚：地形等级差超出能力则重罚 cap_penalty = 0.0 if robot.terrain_level >= task.terrain_req else 10.0 # 载荷惩罚：所需载荷未搭载 pay_penalty = 0.0 if task.payload in robot.payloads else 8.0 return (w[0] * t_travel + w[1] * e_cost + w[2] * cap_penalty + w[3] * pay_penalty)

权重的确定不是调参调出来的，是排优先级排出来的：载荷不匹配的惩罚最高（w[3]=3.0），因为跑过去也干不了活，纯浪费；其次是能量（w[1]=2.5），因为能量耗尽的代价是整机停机；地形惩罚1.5，距离1.0。这个权重顺序我调整过三次，目前的版本在实测里任务完成率是94%，平均空驶距离比贪心低37%。

还有个细节：拍卖要设保留价。如果所有机器的出价都超过某个阈值，说明这个任务当前没人适合做，就暂缓分配，等状态变化。不设保留价的话会出现“能量只剩8%的机器硬着头皮接远程任务”这种蠢事。

如果任务规模小（同时待分配任务少于8个），我干脆用匈牙利算法求全局最优，scipy.optimize.linear_sum_assignment一行搞定，比自己写快得多。

4.3 覆盖路径规划与重叠率控制

普查任务的路径规划，我用的是往复式（俗称“之字形”）覆盖，这是农业和测绘领域最成熟的做法。核心参数有三个：条带间距、重叠率、转弯半径。

条带间距不能大于有效探测宽度。我的轮式平台线圈有效宽度是0.55米，雷达有效宽度约0.8米，取小的那个0.55米作为基准。为了补偿定位漂移和姿态误差，加15%重叠，实际间距取0.47米。这个15%不是随便定的——实测GPS加IMU融合的横向定位误差标准差是4.2cm，3σ就是12.6cm，占0.55米的23%，但线圈信号本身有约5cm的横向衰减容忍度，两者相抵之后15%够用。

转弯半径影响效率。条带间距0.47米的情况下，如果机器人转弯半径大于0.24米，就转不过来，必须做“跳行”处理——走完一条隔一条再回来走，代价是整体路径长度增加约18%。所以我把轮式平台的转向机构最小转弯半径压到了0.21米，刚好能做连续往复。履带平台转弯半径大，就老老实实跳行，反正它不做普查任务。

覆盖过程中还要处理边界和障碍。我的做法是先用激光雷达建一张2D占据栅格，用形态学膨胀把障碍外扩一个机器人半径，再在可行区域内生成之字路径，最后用简单的视线检查把能直连的路径点合并。这套流程在Python里用numpy加一个自己写的栅格遍历就能实现，不需要上重型规划库。

import numpy as np def boustrophedon(free_grid, spacing_cells, start_left=True): """free_grid: bool 2D array, True 表示可通行""" h, w = free_grid.shape path = [] rows = np.arange(0, h, spacing_cells) for i, r in enumerate(rows): seg = np.where(free_grid[int(r), :])[0] if len(seg) == 0: continue # 取该行最长的连续可通行段 splits = np.split(seg, np.where(np.diff(seg) > 1)[0] + 1) longest = max(splits, key=len) left_to_right = (i % 2 == 0) if start_left else (i % 2 == 1) pts = [(r, c) for c in (longest if left_to_right else longest[::-1])] path.extend(pts) return path

这段代码不到20行，但它是整个普查任务的地基。实际部署时我在后面接了一层平滑和速度规划，让机器人在长直段跑全速（1.2m/s），在换行处降到0.3m/s。

5. 太阳能供电与能源管理的工程实现

5.1 功耗预算与光伏板功率的完整计算过程

这部分我写得细一点，因为太多人在这里拍脑袋，结果野外半天就没电。

先算日耗电。轮式平台实测各模块功率：行走电机平均32W（含启停和爬坡加权），主控与感知计算18W，雷达与线圈9W，通信6W，照明与其他3W，合计平均68W。但这个平均值只在行走时成立，待机时降到14W。按每天作业6小时、待机18小时算：68×6 + 14×18 = 408 + 252 =660Wh/天。

再看光伏能发多少。取当地年均峰值日照小时数3.5小时（这个数据要查当地气象资料，不能瞎估），系统综合效率按0.72算（含灰尘、温升、MPPT效率、线损、遮挡），那么每100W光伏板日发电量是 100 × 3.5 × 0.72 = 252Wh。

需要的板子功率 = 660 / 252 × 100 ≈262W。

但这是“当天发当天用光”的理论值，实际还要考虑连续阴天。我按2天自持设计，光伏板就要能覆盖2天平均消耗的一半加上当天消耗的一半，更简单的做法是：电池容量覆盖2天消耗，光伏板覆盖1.3倍日消耗。这样得到：

• 电池需求：660 × 2 = 1320Wh，考虑放电深度不超过80%，实际配置 1320 / 0.8 =1650Wh。我用的是48V 35Ah（1680Wh），配两块，一块主用一块热备切换。
• 光伏需求：660 × 1.3 / 252 × 100 ≈340W。

340W的柔性板铺在轮式平台顶部，面积约2.1平方米（按160W/㎡算），确实有点大。所以我把光伏拆成两部分：车顶固定板200W加一个可展开的侧翼板140W。侧翼只在驻车充电时展开，行进时收起。这个设计让行进时的风阻和重心都不至于太糟。

注意：光伏板标称功率是在25度、1000W/㎡标准条件下的值。夏天板面温度能到70度，功率系数按-0.35%/度算，70度时功率只剩标称的84%。这个衰减一定要算进去，不然永远达不到预期。

5.2 MPPT策略与电池管理的关键参数

MPPT本身用现成模块就行，我要说的是策略层的两个细节。

第一个是充电窗口的选择。不是有太阳就充。锂电在0-45度充电是安全的，但野外夏季午后舱内温度经常超过50度，这时候充电会加速衰减。我的策略是：舱内温度超过45度就停止充电，只做放电；同时用风扇强制通风把温度压下来。这套逻辑用一个简单的状态机实现，温度阈值是可配置的。实测下来这个策略让电池年衰减从预估的8%降到5.2%。

第二个是充电电流的分配。当光伏功率不足以同时供负载和充电时，优先供负载，剩余才充电，且充电电流限制在0.3C以内。35Ah电池对应10.5A上限。如果负载突然增大（比如雷达启动），充电电流立刻降到0，避免把MPPT模块拉进保护状态。

电池管理的核心是SOC估算。库仑计加开路电压修正是我用的方案：行进中用库仑计积分，静置超过30分钟时用开路电压查表修正。磷酸铁锂的电压平台很平，2.9V到3.3V之间对应了10%到90%的SOC，所以单纯靠电压估不准，必须靠库仑计。但库仑计有累积误差，每天静置时修正一次是必要的。

class EnergyManager: def __init__(self, cap_wh=1680, dod=0.8, t_charge_max=45.0): self.cap = cap_wh self.usable = cap_wh * dod self.t_max = t_charge_max self.soc = 1.0 self.history = [] # 最近30分钟 (t, power_w) def can_finish(self, task_wh, confidence_factor=1.25): """判断剩余电量能否完成指定任务""" remain = self.soc * self.usable return remain > task_wh * confidence_factor def predict_endurance(self): """按最近30分钟平均功耗外推可用时长（小时）""" if len(self.history) < 10: return float('inf') p_avg = sum(p for _, p in self.history) / len(self.history) if p_avg <= 1e-6: return float('inf') return (self.soc * self.usable) / p_avg def charge_allowed(self, cell_temp): return cell_temp < self.t_max and self.soc < 0.98

5.3 退役电池与模块的回收再利用

这部分是我认为最应该有更多人写、但实际很少有人写的内容。一堆电池用到80%容量就报废，太浪费了。我的做法是把退役动力电池降级做地面储能，配光伏给备用机器、地面站、通信中继供电。

具体流程分四步。第一步是筛选，逐节测容量（0.2C恒流放电到截止电压）、测内阻、看自放电率，容量保持率在70%-80%之间的降级使用，低于70%的拆解回收材料。第二步是配组，同一组电池的容量差控制在5%以内、内阻差控制在10%以内，否则充放电时会互相拖累。这一步必须做，偷懒的后果是整组提前报废。第三步是配保护板，降级电池的内阻大、发热多，保护板要留足余量。第四步是记录，每块降级电池编号、记录原始来源、当前容量、配组信息，这套记录后来帮了大忙——有两组电池在储能柜里出现异常发热，靠记录追溯到了是同一批次、同一批次的某几节内阻偏大，及时换掉了。

除了电池，其他模块的回收利用也做了。电机拆下来测绕组电阻和轴承间隙，达标的做备件；雷达和相机模块做清洁和重新标定后进备件库；铝合金结构件熔了重铸成支架；3D打印件粉碎后重新挤出成耗材（这个我试过，打印质量下降明显，只能做非受力件）。整体算下来，备件自给率从0提到约45%，一年省下的成本能覆盖两个技术人员的部分工时。

6. 从样机到野外连续运行的部署实录

6.1 硬件选型与装配的几个关键决定

硬件我踩过的坑比软件多。先说底盘：轮式选的是四轮差速，没有用麦轮，因为麦轮在土面上打滑严重，而且麦轮的辊子缝里塞满泥之后基本报废。差速转向在土面上虽然效率低一点，但可靠。履带选的是橡胶履带，不要用钢履带，钢履带在硬化路面上会把路面刮坏，而且噪音大到通信受干扰。

计算平台我用的是两块：一块低功耗单板机跑感知和通信（功耗约7W），一块带独显的嵌入式计算模块跑检测模型（功耗约25W，峰值40W）。为什么不合成一块？因为峰值功耗太吓人，合并之后要么散热压不住，要么功耗常年顶在峰值。分开之后，检测模块可以按需休眠——没有可疑目标时降到5W，检测到候选点时唤醒。这个设计让感知部分的日均功耗从31W降到17W。

传感器安装位置有几个反直觉的经验。雷达天线不能装得离电机太近，电机换向时的电磁干扰会在B-scan上产生规律性条带，我最初装的位置离驱动电机只有18cm，噪点严重，挪到车头前方之后明显干净。金属线圈不能贴着金属车架，会引入固定偏移，我用的是非金属支架，把线圈前伸到车头外0.8米。相机要有遮光罩，野外逆光太常见，没有遮光罩时自动曝光会疯狂抖动，检测全废。

装配上我最看重的是模块化快拆。所有传感器模块用统一的快拆接口，两根线（电源加数据），徒手能拆。这个设计听起来是锦上添花，实际是雪中送炭——野外传感器进水、进灰、被树枝刮坏是常态，能五分钟换掉就意味着任务不中断。

6.2 软件部署与容器化

软件部署我用容器，但不是全部都容器化。底层运动控制和硬件驱动跑在宿主机上，因为要访问实时内核和GPIO；上层逻辑全部容器化，包括检测、任务调度、日志、通信管理。镜像基于精简的Linux，单个镜像约1.2GB，里面塞了模型和依赖。

容器化带来的最大好处是现场回滚。野外出了问题时，最怕的是改代码改出新问题。我的流程是：任何改动必须在本地跑通48小时仿真加2小时实测才能打标签，标签镜像上传到地面站的本地仓库，现场出问题就回滚到上一个标签。这套流程我把“现场修bug”的时间从平均4小时压到20分钟。

配置管理用的是YAML加分环境，同一套镜像在轮式、履带、足式上都能跑，差异全在配置里：传感器话题名、底盘参数、能力向量、功耗模型。这样避免了“三套代码三个bug”的经典灾难。

日志是重点。我要求所有关键决策必须留痕：为什么把这个点判为T2、为什么把这台机器派去这个任务、为什么拒绝了这次充电。日志格式统一为结构化JSON，每台机器本地存7天，汇总到地面站存90天。这套日志后来成了最有价值的资产，几乎所有疑难问题都是靠翻日志定位的。

6.3 野外实测记录与数据

最近一次连续运行测试，场地是一个约4.2万平方米的待整理地块，地形混合了硬化土面、杂草区、碎石堆和一条干涸沟槽，一共布设了86个模拟目标点（金属块、塑料管、空洞模拟件），目标是评估系统的检出率和作业效率。

分工是这样：两台轮式做普查，覆盖了3.1万平方米，平均速度0.85m/s，效率约每小时1150平方米，两块电池轮换，靠光伏补能实现了不依赖外部电网连续作业。轮式一共标记出T2候选点91个、T1候选点237个。两台履带随后复核T1，其中49个升级为T2，188个判为背景。足式平台负责沟槽内和碎石堆下的12个点，全部完成探测。

最终检出：86个目标点中检出81个，检出率94.2%。漏检的5个里，3个是埋在湿黏土里的塑料管（雷达衰减严重），2个是深度超过0.7米的件（超出有效探测深度）。误报情况：最终判定为T2的140个点中，真实目标79个，误报61个，精确率56.4%。这个精确率不算高，但配合人工复核的流程是可接受的——关键是召回率94.2%，漏掉目标比多报目标的代价大得多。

能耗数据：轮式平台平均68W，6小时作业加充放电循环，日耗电约640Wh，光伏日均补能约410Wh（测试期间有两天多云），缺口靠备用电池补。履带平台平均142W，日耗电约890Wh，光伏补能约480Wh，能量缺口明显，所以履带只做短时复核任务。足式平台平均46W，日耗电约310Wh，30W光伏不够用，只能靠轮换电池。

提示：这套配置下，如果连续阴雨超过三天，必须收缩作业范围，只做T2复核不做普查。我在测试第四天遇到连续阴天，靠缩减到单机作业撑了过去。

7. 常见问题与排查技巧速查

7.1 故障现象与处置对照

下面这张表是我这一年多攒下来的，几乎每个都真实发生过不止一次。

7.2 几条用教训换来的避坑心得

第一条：不要在野外现场改代码，只回滚。我吃过这个亏。现场改了三十行，当时问题解决了，回去之后发现引入了两个更隐蔽的问题，查了三天。现在我的规矩是现场只做三件事：换硬件、改配置、回滚镜像。改代码一律回实验室。

第二条：给所有“看起来不会坏”的东西准备备件。螺丝、卡扣、线缆、密封圈，这些便宜东西坏了能让整机停摆。我现在的备件包里，线缆按1:3备，密封圈按1:10备，快拆接口按1:2备。成本增加不到两千，但节省的停机时间无法估算。

第三条：日志里一定要记录“没做什么”和“为什么”。大部分日志只记做了什么，出问题时你根本不知道当时为什么没做另一件事。我把所有被拒绝的任务、被跳过的充电、被判为背景的目标全部记下来，附上判断依据。这套日志的价值在第二次、第三次野外作业时才体现出来——你能回答“上次在这个位置为什么判成背景”这种问题。

第四条：能源预测永远要留余量，而且要让操作员看得见。我一开始只在内部用预测值做决策，操作员看不到，结果操作员凭感觉判断“还能再干一会儿”，最后推着机器回来。现在预测剩余作业时长直接显示在地面站界面上，操作员的判断立刻变保守了。

第五条：多机系统的调试从两台开始，不要一上来就六台。两台机器的时候，协同问题暴露得慢但不难查；六台一起上，问题交织在一起，你根本分不清是通信、调度还是感知的问题。我的顺序是：单机跑通、双机跑通、三机跑通，然后才扩到六台。这个顺序看起来慢，实际快得多。

我自己在这个系统上最大的体会是，先进技术的价值不在于用了多少新框架，而在于它能不能让系统在没人管的情况下多跑一天。Python让迭代变快、太阳能让作业脱离电网、回收利用让成本降下来，这些都是很朴素的目标，但把它们组合到一个能跑起来的系统里，中间要填的坑远比想象中多。如果让我重新做一遍，我会把时间分配改成三成做感知、三成做能源、四成做可靠性和运维——因为真正决定这套东西能不能用的，从来不是模型精度多两个点，而是它会不会在第三天早上莫名其妙趴窝。