这次我们看的是一个很具体的发明案例:明尼苏达的一位发明家,把 AI 摄像头识别、机械执行和蒸汽加热结合起来,做成了一台不依赖化学除草剂的除草机器人。这个项目在公开材料里的信息不算多,但它的技术路线很值得拆解:Ubuntu 系统负责控制逻辑,摄像头负责采集田间图像,AI 模型负责区分“这是作物还是杂草”,最后把识别结果转成蒸汽发生器和喷头的动作。任何一个环节断掉,整台机器都没法工作。
这篇文章不打算把样机参数写死,因为目前没有足够的公开材料支撑具体数字。我更想做的,是把这套系统里最容易复现、也最关键的“Ubuntu + 摄像头 + AI 杂草识别”部分拆开讲清楚:需要什么硬件、装哪些组件、代码怎么写、识别结果怎么用、遇到问题怎么排查。如果你正在做农业机器人、自动化除草、嵌入式视觉或者边缘 AI 部署,这篇可以直接按步骤走一遍。
另外多说一句:蒸汽除草不是新概念,但“用 AI 判断该对哪里喷蒸汽”才是这台机器真正值钱的地方。传统做法是整片地撒药或整片加热,耗能高也不环保;加了视觉识别以后,蒸汽只对准杂草喷,效率和安全边界都不一样了。下面就从技术栈开始逐步展开。
1. 核心能力速览
先给一张速览表,把项目的技术特征和落地门槛列清楚。表格里凡是公开材料没写死的参数,我会明确标注“需按实际环境测试”或“需确认”,不编造数字。
| 能力项 | 说明 |
|---|---|
| 项目类型 | AI 视觉 + 农业机器人,蒸汽除草方向 |
| 核心链路 | 摄像头采集 → AI 目标检测 → 蒸汽执行 |
| 识别平台 | Ubuntu 系统,兼容常见 USB / CSI 摄像头 |
| 视觉方案 | 摄像头实时采集 + 目标检测模型(可换 YOLO 系列) |
| 除草方式 | 蒸汽加热杀灭杂草,替代化学除草剂 |
| 是否支持 CPU | 轻量模型可以纯 CPU 推理;大模型需要 GPU |
| 显存需求 | 取决于模型选型,无法给固定值;建议实测 |
| 是否支持 API | 公开材料未明确,需按实际工程方案自建 |
| 是否支持批量任务 | 田间连续作业场景,需要自建任务队列和日志 |
| 适合场景 | 试验田、家庭农场、生态农业、AI 教学项目 |
从这张表能看出,这台机器的重点是“识别”而不是“喷蒸汽”。蒸汽生成和喷头控制属于机械电气部分,而 AI 识别决定了蒸汽该往哪里去、喷多久、什么时候停。所以下面内容会以视觉识别链路为主,机械部分只做边界说明。
2. 蒸汽除草机器人的技术路线拆解
一台完整的 AI 蒸汽除草机器人,可以拆成五个子系统:
- 感知子系统:摄像头采集田间图像,可能还包含光照补偿、图像去抖、镜头清洁。
- 识别子系统:AI 模型对图像做目标检测,区分作物与杂草,输出类别和位置。
- 决策子系统:根据识别结果,结合机器人行进速度、喷头位置,计算蒸汽喷射的时机和时长。
- 执行子系统:蒸汽发生器、电磁阀、喷嘴、运动底盘。
- 控制子系统:Ubuntu 主机 + 单片机,负责各子系统之间的通信和时序控制。
从实际落地角度看,最难的不是训练一个能识别杂草的模型,而是“识别到杂草之后怎么办”。摄像头的视野、喷头的位置、机器人前进的速度,三者之间存在坐标转换和时序延迟。如果摄像头看到杂草后,机器已经往前走了几十厘米,蒸汽喷头再动作就晚了。所以工程上一般会做两件事:一是将摄像头安装位置与喷头位置做硬性固定,二是根据底盘速度计算机器人从“看到”到“执行”的延迟补偿。
另一个容易被忽略的点是田间光照。室外环境的光照变化非常大,早晨、中午、傍晚的光线完全不同,阴天和晴天的对比度差异也很明显。直接拿室内训练的模型跑到农田里,识别准确率大概率会下降。这也是为什么这类项目通常要做数据增强,把亮度变化、模糊、角度旋转、阴影都加进训练数据里。
至于蒸汽本身,它的作用是让植物细胞受热破裂,从而杀死杂草。蒸汽温度一般能达到 100 摄氏度以上,对杂草的杀灭效果和化学除草剂比,优势在于无残留、不污染土壤,劣势在于能耗高、速度慢。所以 AI 识别在这里的价值不仅是环保,更是省能量:只对杂草加热,而不是对整片土地加热。
3. 环境准备与前置条件
想在 Ubuntu 上复现一台类似的识别系统,不需要一开始就买昂贵的机器人底盘。先用普通电脑 + 一个摄像头,就能把“识别链路”跑通。下面是通用的环境准备清单,具体版本号要以你手上的硬件和系统为准。
3.1 操作系统与硬件
推荐使用 Ubuntu 20.04 或 22.04 的 64 位版本。旧版本也可以,但摄像头驱动和 Python 依赖的安装会稍微麻烦一些。
硬件方面:
| 硬件 | 最低要求 | 推荐配置 | 说明 |
|---|---|---|---|
| CPU | 4 核 | 6 核以上 | CPU 直接决定推理速度 |
| 内存 | 8GB | 16GB | 多进程 + 图像缓冲会吃内存 |
| GPU | 可没有 | NVIDIA 显卡 | 显存决定能否跑大模型 |
| 摄像头 | USB 摄像头 | USB 3.0 / CSI 摄像头 | 分辨率建议不低于 1280x720 |
| 存储 | 20GB | 50GB | 模型文件、数据集、日志都很占空间 |
如果你只有 CPU,不要灰心。YOLOv5s、YOLOv8n 这类轻量模型在 CPU 上也能运行,只是帧率会低一些,做离线图片识别完全够用。
3.2 系统基础检查
装完系统后,先做三件事:更新软件源、确认摄像头被识别、确认 GPU 驱动状态。
# 更新软件源 sudo apt update && sudo apt upgrade -y # 查看摄像头设备 ls /dev/video* # 查看 GPU 与 CUDA 状态,如果没有 NVIDIA 显卡,这步会报错,不影响 CPU 推理 nvidia-smi/dev/video0表示系统已经找到了摄像头。如果你接了两个摄像头,会看到/dev/video0和/dev/video1,后续代码里可以通过传入不同设备号来选择。
3.3 Python 虚拟环境
Python 项目最怕依赖冲突。建议新建一个虚拟环境,把 OpenCV、PyTorch、Ultralytics 等库装在里面。
# 创建虚拟环境 python3 -m venv weed_env # 激活虚拟环境 source weed_env/bin/activate # 升级 pip pip install --upgrade pip# 安装核心依赖 pip install opencv-python numpy torch torchvision ultralytics这里要注意,PyTorch 的安装命令需要根据你的 CUDA 版本去官网查。如果只是 CPU 推理,安装 CPU 版即可,体积更小,也不会因为驱动版本不对而报错。
4. 摄像头接入与图像采集
摄像头是整套系统的眼睛。这块踩坑最多,先说排查思路,再给代码。
4.1 摄像头驱动排查
很多人在 Ubuntu 上插了摄像头却没反应,主要原因有两个:一是设备权限不够,二是摄像头被其他进程占用。
- 权限问题:把当前用户加入
video组,然后重新登录。
sudo usermod -a -G video $USER进程占用:如果你同时打开了浏览器或会议软件,摄像头可能已经被它占用了。关掉所有用摄像头的应用再试。
硬件问题:用
dmesg查看内核日志,确认 USB 设备是否被枚举成功。
dmesg | grep -i camera4.2 用 OpenCV 做图像采集
下面这段代码是通用模板,功能是打开摄像头、显示实时画面、以及保存一帧截图。你可以直接复制保存为capture.py运行。
import cv2 capture = cv2.VideoCapture(0) if not capture.isOpened(): print("无法打开摄像头,请检查设备号或驱动") exit(1) # 设置分辨率,不同摄像头支持的范围不同 capture.set(cv2.CAP_PROP_FRAME_WIDTH, 1280) capture.set(cv2.CAP_PROP_FRAME_HEIGHT, 720) while True: success, frame = capture.read() if not success: print("读取视频帧失败") break cv2.imshow("Camera", frame) key = cv2.waitKey(1) & 0xFF if key == ord('s'): cv2.imwrite("test_frame.jpg", frame) print("截图已保存") elif key == ord('q'): break capture.release() cv2.destroyAllWindows()运行方式:
python capture.py预期结果:屏幕上出现摄像头实时画面,按s保存截图,按q退出。如果画面黑屏或报错,优先检查设备号和上一节提到的权限问题。
4.3 图像预处理
田间图像直接送给模型,效果通常不稳定。一个简单的预处理流程包括:
- 缩放:把图像缩放到模型输入尺寸,比如 640x640。
- 转颜色空间:OpenCV 读进来的是 BGR,PyTorch 模型一般需要 RGB。
- 归一化:像素值除以 255,把范围映射到 0 到 1。
- 数据增强:训练阶段加随机亮度、对比度、翻转、裁剪,提升模型在室外的泛化能力。
下面是一个预处理函数示例:
import cv2 import numpy as np def preprocess(image, input_size=640): img = cv2.resize(image, (input_size, input_size)) img = cv2.cvtColor(img, cv2.COLOR_BGR2RGB) img = img.astype(np.float32) / 255.0 return img5. AI 杂草识别模型部署
这一段是整个系统的核心。我以 YOLO 系列为例,因为它对硬件要求相对友好,社区生态成熟,也是这类视觉识别项目最常用的方案之一。
5.1 数据集准备
模型能不能识别杂草,取决于训练数据。你至少需要两类标注数据:
- 作物:比如玉米苗、番茄苗、生菜苗。
- 杂草:不同生长阶段的杂草图片。
采集图片时要注意覆盖不同光照、土壤背景、杂草密度和生长阶段。用 LabelImg 或 Roboflow 标注成 YOLO 格式,一个类别一个文件夹,标注文件是.txt,记录目标框的中心坐标、宽度、高度和类别 ID。
5.2 模型训练
如果你用 Ultralytics 提供的 YOLOv8,训练命令可以直接在终端完成:
# 以 yolov8n 为例,显存不够时用小模型 + 更低分辨率 yolo detect train data=weed_dataset.yaml model=yolov8n.pt epochs=50 imgsz=640 batch=8weed_dataset.yaml的内容类似:
train: ./datasets/train val: ./datasets/val nc: 2 names: ['crop', 'weed']如果训练数据量不够,可以先下载预训练权重,再用自己的数据微调。不要从零训练,既慢又容易不收敛。初次验证时,50 个 epoch、640 分辨率、batch 8,是一个相对稳妥的起点。
5.3 推理脚本
训练完成后,会生成best.pt权重文件。下面是一个推理脚本模板,功能是加载模型、输入图片、输出所有检测框和置信度。
from ultralytics import YOLO model = YOLO("best.pt") results = model("test_frame.jpg", conf=0.4, verbose=False) for result in results: boxes = result.boxes for box in boxes: cls_id = int(box.cls[0]) conf = float(box.conf[0]) xyxy = box.xyxy[0].tolist() class_name = model.names[cls_id] print(f"类别: {class_name}, 置信度: {conf:.2f}, 坐标: {xyxy}")运行后看到类似输出,说明识别链路已经通了:
类别: weed, 置信度: 0.87, 坐标: [172.5, 301.2, 205.8, 388.9] 类别: crop, 置信度: 0.92, 坐标: [500.3, 220.1, 540.6, 310.4]判断识别是否成功的标准,不只是“有没有框出来”,还要看:
- 置信度是否稳定在 0.5 以上。
- 杂草和作物是否被准确区分,有没有很高比例的误报。
- 同一目标在不同光照下是否能重复检测出来。
- 单帧推理时间是否匹配机器人的行进速度。
5.4 识别结果的可视化
部署阶段,建议把模型输出的框画到原图上,保存成一段带标注的视频,方便后续人工检查。
import cv2 from ultralytics import YOLO model = YOLO("best.pt") cap = cv2.VideoCapture(0) while True: success, frame = cap.read() if not success: break results = model(frame, conf=0.4) annotated = results[0].plot() cv2.imshow("Weed Detection", annotated) if cv2.waitKey(1) & 0xFF == ord('q'): break cap.release() cv2.destroyAllWindows()results[0].plot()会自动画出检测框、类别标签和置信度,不需要自己写绘图逻辑。
6. 蒸汽执行机构联动
识别模型跑通之后,下一步是把识别结果变成执行动作。这个环节直接关系到田间作业能否真正落地。执行系统一般由单片机控制电磁阀,Ubuntu 主机通过串口发送指令。
6.1 决策逻辑
不能一检测到杂草就立刻喷蒸汽。因为摄像头看到的位置和喷头的位置存在物理距离,机器人是在移动的。所以需要把识别框的中心坐标换算成世界坐标,再结合行进速度做一个延迟。下面是简化的决策示例:
import time def shoot_steam(result_boxes, robot_speed): """ 根据检测结果决定是否启动蒸汽喷射。 这里只做演示,实际需要结合喷头物理位置和延迟补偿。 """ for box in result_boxes: cls_id = int(box.cls[0]) if cls_id == 1: # 假设 weed 类别的 ID 是 1 x_center = (box.xyxy[0][0] + box.xyxy[0][2]) / 2 if x_center < 320: # 目标在画面左侧,可能需要等待一定时间后再打开阀门 # send command to arduino via serial print("触发蒸汽喷射") return True return False真实项目比这个复杂得多:需要做相机标定、坐标变换、速度传感器数据融合、阀门开启时间控制等。但最小验证可以按这个思路做:先判断杂草是否进入了执行区域,再向单片机发送喷射指令。
6.2 串口通信示例
Ubuntu 主机与 Arduino/STM32 之间通常用串口通信。后端发送一个简单字符,单片机收到后控制继电器和电磁阀。
import serial ser = serial.Serial('/dev/ttyUSB0', 9600, timeout=1) def fire_steam(duration_ms=500): ser.write(b'1') time.sleep(duration_ms / 1000) ser.write(b'0')单片机端的伪代码可以这样写:
void loop() { if (Serial.available() > 0) { char cmd = Serial.read(); if (cmd == '1') { digitalWrite(VALVE_PIN, HIGH); } else if (cmd == '0') { digitalWrite(VALVE_PIN, LOW); } } }在接入真实蒸汽设备之前,建议先接一个 LED 或继电器控制的小水泵做模拟测试,确认整条链路逻辑正确,再上蒸汽系统。
6.3 安全边界
蒸汽温度超过 100 摄氏度,存在烫伤风险。做真实样机时,一定要在蒸汽发生器、管路、阀门处加温度传感器和压力传感器,并在主程序里做超温、超压自动停机保护。任何情况下,都不应该在人员密集区域进行蒸汽喷射测试。这是安全底线,不是可选项。
7. 功能测试与效果验证
把识别系统和执行系统都装好以后,按照下面这个顺序做功能测试。每完成一步,确认无误后再进入下一步。
7.1 摄像头采集测试
测试目的:确认摄像头能被系统识别,画面清晰,帧率稳定。
操作步骤:
- 运行
capture.py。 - 观察画面是否有异常颜色、黑屏、闪烁。
- 在弱光和强光下各拍一张,看曝光是否自动调整。
判断标准:画面连续稳定 10 分钟不掉帧,截图保存无报错。
常见失败原因:摄像头设备号错误、USB 供电不足、摄像头被其他进程占用。
7.2 模型推理测试
测试目的:验证模型能否正确识别杂草并输出坐标。
操作步骤:
- 准备 10 张以上包含杂草和田地背景的图片。
- 运行推理脚本,输出检测框和置信度。
- 人工核对每一张图的检测结果。
判断标准:整体准确率不低于 80%,没有把作物大面积误判为杂草。具体数值因数据集而异,需要你自己定一个可接受阈值。
7.3 实时视频测试
测试目的:验证模型在连续帧上的稳定性。
操作步骤:
- 打开摄像头,运行实时检测脚本。
- 缓慢移动手机或植物,观察检测框是否抖动、闪烁。
- 记录推理帧率。
判断标准:检测框能稳定跟随目标,不出现频繁丢失和误检。如果帧率太低,换更小的模型,或者降低输入分辨率。
7.4 执行联动测试
测试目的:确认识别结果能触发蒸汽执行动作。
操作步骤:
- 用一个 LED 作为执行器,代替真实蒸汽阀门。
- 让摄像头对准杂草图片,观察 LED 是否被点亮。
- 把植物移出画面,确认 LED 熄灭。
判断标准:检测到杂草时 LED 亮,没有杂草时 LED 灭,亮灭切换延迟不超过 2 秒。
7.5 田间小规模测试
如果有条件,可以做田间小规模测试。重点观察:
- 自然光下识别准确率是否有明显下降。
- 机器人行进速度对识别延迟的影响。
- 蒸汽喷嘴与识别框之间的空间对齐是否准确。
- 长时间运行后 CPU/GPU 温度、内存占用是否处于安全范围。
道面、尘土、镜头起雾,都会影响识别。建议在测试前给摄像头加一个防护外壳,并准备备用镜头布。
8. 接口 API 与批量任务
如果这台除草机器人的识别能力要复用到多台设备,或者要给上位机、手机 App 提供识别能力,就需要把模型封装成 API 服务。这个思路和单机运行不同,更适合多机协作场景。
8.1 用 FastAPI 封装识别接口
下面是一个通用 API 示例,接口接收图片,返回识别结果。实际部署时,路径和参数需要按你的模型调整。
from fastapi import FastAPI, UploadFile from ultralytics import YOLO import cv2 import numpy as np app = FastAPI() model = YOLO("best.pt") @app.post("/detect") async def detect(file: UploadFile): content = await file.read() image = cv2.imdecode(np.frombuffer(content, np.uint8), cv2.IMREAD_COLOR) results = model(image, conf=0.4, verbose=False) detections = [] for result in results: for box in result.boxes: detections.append({ "class": model.names[int(box.cls[0])], "confidence": float(box.conf[0]), "bbox": box.xyxy[0].tolist() }) return {"detections": detections}启动服务:
uvicorn api_server:app --host 0.0.0.0 --port 8000用 curl 测试:
curl -X POST -F "file=@test_frame.jpg" http://127.0.0.1:8000/detect8.2 批量任务设计
多台除草机器人同时作业时,需要任务队列。最简单的方式是:
- 每台机器有一个唯一 ID。
- 任务调度系统维护一个字段块或地块队列。
- 每台机器完成一个地块后,上报结果,领取下一个任务。
- 识别日志和蒸汽执行日志统一存储,方便事后分析。
批量任务最容易踩的坑是“任务中断后不知道做到哪儿了”。建议每处理完一行或一块地,就写一条状态记录。这样即使断电或模型崩溃,也能从最近的状态恢复,不用重新开始。用日志和失败重试兜底,是农业机器人项目里最基本也是最实用的工程习惯。
9. 资源占用与性能观察
无论你做的是单机原型还是多机部署,都要时刻关注资源占用。这里给出一套可执行的观察方法。
9.1 系统资源监控
Ubuntu 下用htop看 CPU 和内存,用nvidia-smi dmon看 GPU 占用和显存,用nvidia-smi看温度。
# 看 CPU 和内存 htop # 看 GPU 实时状态 nvidia-smi dmon -c 109.2 影响性能的关键因素
- 输入分辨率:分辨率越高,推理越慢。从 1280x720 降到 640x640,帧率能提升数倍。
- 模型大小:YOLOv8n 和 YOLOv8x 的推理速度差别非常大。
- 批量大小:服务端做批量推理时,适当增大 batch,能提高吞吐量,但会占用更多显存。
- 摄像头采集帧率:采集端太慢,识别端再快也没用。
- 图像编码解码:频繁在 JPEG 和 OpenCV 图像之间转换,也会消耗 CPU。
9.3 如何降低资源占用
如果资源紧张,优先做三件事:
- 换轻量模型,比如 YOLOv8n 或 MobileNet 系列的检测模型。
- 降低输入分辨率,训练和推理都用 416x416 或 320x320。
- 控制帧率,不需要每帧都做推理,每秒处理 3 到 5 帧就足够满足除草应用,能显著降低 CPU/GPU 占用。
显存占用要以你本机实际测试为准,不要轻信网上的固定数字。因为同样的模型,在不同分辨率、不同 batch、不同 TensorRT 优化下,显存占用差距很大。
10. 常见问题与排查方法
下面整理了一份排查清单,覆盖从系统到模型的常见问题。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 摄像头打不开 | 设备号错误或权限不足 | ls /dev/video*,检查是否在 video 组 | 更换设备号,执行usermod授权 |
| 画面黑屏 | 摄像头被其他进程占用 | 关闭浏览器/会议软件 | 重启后只保留采集程序 |
| CUDA 不可用 | 驱动与 PyTorch 版本不匹配 | nvidia-smi查看驱动,python -c "import torch; print(torch.cuda.is_available())" | 按官网命令重新安装对应 PyTorch |
| 模型识别率低 | 训练数据过少或场景差异大 | 统计各类别样本数,查看失败样本 | 增加不同光照、不同背景的训练数据 |
| 推理速度太慢 | 模型过大或分辨率过高 | 用计时模块打印单帧耗时 | 换轻量模型或降低分辨率 |
| 检测框抖动严重 | 置信度阈值过低 | 观察置信度输出 | 提高conf,增加帧间过滤逻辑 |
| 端口被占用 | 其他服务占用了 8000 | `netstat -tulpn | grep 8000` |
| 蒸汽不触发 | 串口通信失败或决策条件太严 | 查看串口日志和识别日志 | 检查串口设备号,放宽触发区域 |
| 批量任务卡住 | 任务队列没有断点恢复 | 查看任务状态表 | 增加状态记录和失败重试机制 |
依赖安装失败也是高频问题,尤其是 PyTorch 和 CUDA 的组合。给你一个稳妥建议:不要一次装一大堆库,先装 PyTorch,验证 CUDA 能不能用,再装 OpenCV 和 Ultralytics。这样出了问题,知道是哪个环节的锅。
11. 最佳实践与合规提示
这个项目最大的价值,是把环保理念和技术路径结合了起来。但任何 AI 硬件项目,都不只存在技术问题。最后说几点工程和合规上的建议。
11.1 工程化建议
第一,第一次跑通时,用小模型、小分辨率、短时测试。不要一上来就追求最高精度,先把链路跑通,再逐步优化。
第二,模型文件、训练数据、日志、输出结果,分目录管理。目录结构建议:
project/ ├── datasets/ # 训练数据 ├── weights/ # 模型权重 ├── scripts/ # 推理和工具脚本 ├── logs/ # 运行日志 └── outputs/ # 识别结果第三,批量作业必须要有日志和失败重试。一台机器人在地里工作几小时,如果中途断电或死机,没有断点恢复会非常痛苦。
第四,接口服务要限制访问范围。如果部署在局域网里,不要直接暴露到公网;如果必须暴露,加身份验证和访问白名单。
11.2 合规与安全边界
涉及真实蒸汽设备和田间环境时,注意以下几点:
- 蒸汽温度很高,必须有温度、压力保护装置。
- 田间测试要避开人员活动区域。
- 如果这台设备会采集农田图像,要明确图像数据的用途和保存期限,避免隐私合规风险。
- 如果你想识别特定作物或特定区域,需要确保训练数据来源合法。
- 商用落地前,要对识别准确率、误喷率做系统评估。误喷意味着蒸汽可能打到了作物上,造成经济损失。
从项目定位来看,这类设备替代的是化学除草剂,环保价值很明显。但“环保”不能替代“安全”。任何打着环保旗号的自动化设备,同样要遵守安全标准和合规要求。
12. 总结与下一步
这台明尼苏达发明家的 AI 蒸汽除草机器人,值得关注的不是蒸汽本身,而是它把 AI 视觉、边缘计算和农业机械结合到了一起。如果你想做一个同类项目,最值得先跑通的功能是:Ubuntu 下摄像头采集 + YOLO 杂草识别 + 结果可视化。这一步跑通,整个项目的地基就算打好了。
最容易踩的坑有三个:摄像头驱动不识别、模型在田间光照下准确率下降、识别到执行之间延迟补偿没做。前两个在开发阶段就能排查,第三个必须在真实环境下测试才能暴露。
下一步可以按这个顺序扩展:
- 先做图片识别,整理自己的作物和杂草数据集。
- 再做实时视频识别,观察帧率和稳定性。
- 然后用 LED 或小水泵模拟蒸汽执行,验证联动逻辑。
- 最后再做田间小规模测试,采集实际场景的数据,反向优化模型。
如果你正在做类似的农业机器人项目,建议把这篇文章的测试流程和排查方法收藏备用。它的技术栈不复杂,但每个环节都需要耐心调优。
文章的内容到这里就结束了。如果你已经按流程跑通了识别链路,接下来要做的就是把它装到一台真实底盘上,开始积累田间数据。机器人除草这件事,离真正大规模铺开还有距离,但技术方向已经越来越明确:不用化学药剂,用视觉和热量解决问题。