葡萄园里跑自动驾驶过去听起来像概念演示但这几年已经有一批公司在做真正能下地的多机系统。这次我们要看的 Bonsai就是面向果园和经济作物场景的智能农机自动驾驶方案现场演示重点不是单台车能不能跑而是“多台机器同时进同一片葡萄园怎么定位、怎么规划、怎么避让、怎么协同完成任务”。这套东西如果只在小块场地里演示说服力并不强真正有价值的是它把视觉感知、RTK 定位、路径规划、机具控制和任务调度串成了完整闭环。从公开演示和技术架构来看这套系统的核心特点可以概括成几条一是以视觉导航为主不单纯依赖 GNSS 信号能应对葡萄园里藤蔓遮挡、坡度和狭窄行间二是支持多机协同多台农机共享地图和任务队列避免撞车和重复作业三是有任务调度入口可以把喷药、割草、中耕、运输等任务批量下发四是硬件门槛比乘用车自动驾驶低车端算力平台、传感器和线控底盘的组合相对可控。这篇文章会把技术栈拆开讲一遍给你一套从仿真到实车、从单机到多机的验证框架最后重点说明多机任务调度和接口 API 怎么接。如果你正在做农业自动驾驶、智能农机、果园机器人或者要给种植基地做数字化改造可以直接按后面的部署流程和验证清单去对照项目。材料里没有给出完整的官方参数表所以涉及显存占用、API 路径、模型版本的地方我会用“通用验证模板”的方式给出你需要以实际项目文档为准。1. 核心能力速览先把能快速判断的东西放在前面。以下内容基于公开演示和同类系统的一般架构整理具体参数仍需以 Bonsai 官方规格书或项目仓库文档为准。能力项说明项目类型果园/葡萄园场景的多机自动驾驶智能农机系统核心方向视觉导航、多机协同、任务调度、机具作业主要任务割草、喷药、中耕、运输、巡检等感知方式摄像头为主配合 RTK GNSS、IMU、轮速计等多源融合推荐车端算力工业级 GPU 平台常见如 NVIDIA Jetson 系列或 x86 工控机加 GPU具体看算法选型显存占用需按实际视觉模型测试通常在几 GB 量级分辨率与推理框架影响很大支持平台常见工业 Linux、ROS/ROS2 生态启动方式车载程序自启动 远程调度下发任务是否支持 API调度平台一般提供 REST 接口用于任务下发和状态回传需按项目确认是否支持批量任务支持核心价值之一多车多地块任务批量编排适合场景规模化葡萄园、果园、种植基地农机厂商改造农业自动驾驶算法验证这套系统的定位不是“全无人”的乘用车 Robotaxi而是在封闭或半封闭农场环境里做“可落地、可多机、可管任务”的生产工具。理解这一点后面的部署思路就不会走偏。2. 葡萄园自动驾驶解决什么问题葡萄园是一个非常特殊的自动驾驶场景。它的行距通常只有 2 到 3 米藤蔓和支撑结构会对卫星信号形成遮挡地面又有坡度、碎石和松软土壤大型农机在里面转弯、掉头、对齐垄行都比大田要难。更麻烦的是不同生长期葡萄藤的高度、叶幕密度都在变化纯靠 RTK 走固定路线并不够因为作物边界和障碍物可能是动态的。Bonsai 这类方案的核心思路是把“自动驾驶”拆成三个问题来解决第一定位问题。不能只靠卫星要把摄像头看到的垄行、藤蔓、树桩和 RTK 定位、IMU 做融合。视觉的作用不是替代高精定位而是在 GNSS 信号被遮挡时靠图像特征维持车辆在垄行内的横向位置。第二规划问题。葡萄园里的路径是强结构化道路车辆大部分时间沿着垄行直行难点在行尾掉头、断头路、障碍物绕行和多机交会。路径规划要利用“垄行地图”的先验信息再叠加实时感知结果做局部调整。第三协同问题。多台机器同时作业时调度中心要决定哪台车去哪块地、执行什么任务、当前油量电量是否够、两车相遇时谁让谁。这跟工厂 AGV 调度很像但场景从室内变成了室外通信条件、定位精度和环境感知复杂度都上了一个台阶。这套系统适合谁适合有连片种植基地的农场主和种植服务商适合想把传统农机改造成自动驾驶的农机厂商也适合做农业机器人算法和产品化的技术团队。不适合谁如果不具备封闭管理条件、没有安全员机制、地形过于杂乱且缺少基本田间道路直接上多机自动驾驶的成本和风险都会很高。还需要明确边界。农业自动驾驶涉及人员安全、农机控制和农药喷洒实车测试必须有安全员随时接管采集的地块影像、产量数据、作业轨迹都可能包含生产经营信息需要经过地块权利人授权后才能用于模型训练和数据处理对外发布演示视频或商用部署也要确认满足当地农机安全管理和自动驾驶测试的相关规定。3. 系统组成与技术拆解智能农机自动驾驶不是一个单一模型而是一条从传感器到执行器的完整链路。按常见实现方式可以分成五层。3.1 感知层感知层负责回答“车周围有什么”。Bonsai 这类果园方案通常以摄像头为核心因为视觉能提供语义信息哪里是垄、哪里是藤蔓、哪里是人和障碍物。感知任务一般包括垄行检测识别可通行的行间区域输出中心线和边界。障碍物检测识别车辆、人员、石头、树桩、工具等。作物状态理解部分系统还会判断作物密度、是否到喷药位置。视觉模型的选型决定了显存占用和推理速度。如果机载平台是 NVIDIA Jetson 这类设备通常会先把模型转成 TensorRT 引擎再把分辨率控制在合理范围比如 640 到 1280 宽度的输入图以获得稳定帧率。显存占用需要针对模型实测没有一个普适数字。3.2 定位层定位层回答“车在哪”。纯 RTK 在开阔地可以达到厘米级但葡萄园里卫星信号会被遮挡所以需要融合。常见组合是 RTK GNSS IMU 轮速计 视觉特征。RTK 提供绝对位置基准IMU 提供短时姿态和加速度轮速计提供里程约束视觉提供相对垄行的横向偏移修正。定位输出的质量直接决定后续路径跟踪的效果。3.3 决策规划层规划层回答“接下来怎么走”。在垄行结构里规划可以分成两层全局规划根据地块地图和任务点规划出从当前位置到目标地块的行驶路径包括行尾掉头路线。局部规划实时躲避动态障碍物调整车速处理两车交会。这里的代码通常跑在 ROS2 的nav2或者自研规划器上输入是定位结果、地图和感知输出输出是速度指令和转向指令。3.4 执行与控制层控制层把规划结果转成农机动作。线控底盘需要支持转向、油门、刹车和挡位的电控接口机具系统也要能控制升降、喷药开关、割草刀盘等。控制器的难点在于农机是重载车辆转向延迟、地面打滑、坡度都会影响跟踪精度需要做整车动力学标定。3.5 多机通信与调度层多机调度是这套系统的重点。每台车都和一个调度中心保持通信上报自身位置、任务状态、故障信息调度中心维护一个共享任务队列决定任务分配。通信方式可以是 4G/5G也可以是农场本地局域网。网络断开时车辆要能降级为单机作业模式保证安全停车而不是失控。3.6 典型作业任务从演示场景和农业需求看葡萄园自动驾驶主要承载这几类任务任务类型说明对系统的要求割草行间除草保持果园整洁路径一致性要求高不能压藤蔓喷药按需喷洒农药或叶面肥需要机具联动安全要求高中耕行间松土、碎土对垄行对齐精度要求高运输采收季运输葡萄筐、物资需要往返路径规划和装载管理巡检采集作物影像监测长势低速、稳定、影像可回传不同任务对定位精度和控制精度的要求不同。割草和喷药对横向偏差有一定的容忍度但都不能跨垄压苗运输车速度高一些但安全停机距离要留足。4. 环境准备与部署前置条件不管你是要跑仿真还是要改造一台真实农机建议先按下面的清单检查环境。4.1 软硬件清单项目推荐配置说明车端计算平台NVIDIA Jetson Orin 系列或 x86 工控机 NVIDIA GPU以实际算法推理要求为准传感器工业相机可配全局快门、RTK 接收机、IMU、轮速编码器相机要防尘防水适应果园环境线控底盘支持 CAN/线控接口的拖拉机或特种作业车不具备线控接口需要先做改造定位基站RTK 基准站或接入 CORS 服务决定绝对定位精度开发机带 NVIDIA GPU 的台式机或服务器用于模型训练、仿真和日志分析软件栈Ubuntu 22.04 / 24.04ROS2CUDAPyTorchTensorRT具体版本以项目依赖为准仿真环境Gazebo ROS2或 NVIDIA Isaac Sim先仿真后实车降低调试成本4.2 环境检查清单部署前先确认几件事车端工控机的 CUDA 驱动版本和 PyTorch/TensorRT 是否匹配。ROS2 的domain_id在多车场景下是否有冲突。RTK 基站是否已架设基站坐标是否固定。相机内外参是否标定完成。线控底盘的控制指令协议是否打通。场地地图是否已经有高清底图或垄行分布数据。这一步如果有一个环节没确认后面联调会花大量时间排查。更稳妥的做法是先做一张“环境自检表”逐项打勾再启动实车测试。4.3 数据准备视觉感知模型需要训练数据。果园场景建议采集不同光照、不同生长期、不同天气条件下垄行和障碍物图像并做标注。数据采集时注意隐私和合规只采集已授权地块的影像。数据组织建议dataset/ images/ row_001.jpg row_002.jpg labels/ row_001.json row_002.json每张图像对应的标注文件里至少要包含垄行中心线、障碍物框、可通行区域多边形等信息。5. 仿真环境搭建与实车部署流程部署顺序建议是仿真先跑通再上真机。这样可以省掉大量现场调试时间。5.1 搭建仿真环境以 Gazebo ROS2 为例先建立一个简化葡萄园场景一排排垄行中间是可通行行间行端留出掉头空间。车辆模型用阿克曼转向模型传感器至少包含一个前视相机和一个 IMU。# 启动仿真世界具体命令以你的工作空间为准 cd ~/orchard_ws source install/setup.bash ros2 launch agri_sim orchard.launch.py启动后可以另开终端用ros2 topic list检查相机、里程计、GPS 话题是否都在正常发布。仿真环境的价值在于验证“感知-规划-控制”闭环能不能转起来能不能从 A 点沿着垄行走到 B 点并在行尾掉头。5.2 视觉模型训练与推理部署视觉模型的开发流程和普通目标检测、分割任务一样分三步走。第一步训练。准备好标注数据用 PyTorch 训练垄行分割和障碍物检测模型。训练脚本的输入输出可以做成通用模板# train.py 示意 from model import OrchardPerceptionModel model OrchardPerceptionModel(pretrainedTrue) train_loader build_loader(./dataset/images, ./dataset/labels) optimizer torch.optim.AdamW(model.parameters(), lr1e-4) for epoch in range(50): for images, targets in train_loader: loss model.compute_loss(images, targets) loss.backward() optimizer.step()第二步导出。把 PyTorch 模型转成 TensorRT 引擎保证车端推理帧率稳定。这里要注意转换时输入分辨率和batch_size要与车端运行配置一致。# 导出示例具体参数需要按模型结构调整 trtexec --onnxorchard_model.onnx --saveEngineorchard_model.engine \ --fp16 --workspace2048第三步接入 ROS2 节点。推理节点订阅相机图像发布垄行中心线和障碍物结果供规划器使用。5.3 地图与垄行路径录制地图和路径是葡萄园自动驾驶的关键先验。部署时一般先把地块垄行信息录进系统。常见做法有两种手动录制由人工驾驶农机走一遍全部垄行记录 RTK 轨迹生成标准垄行路径。地图标注在高分辨率正射影像上手工标出垄行中心线生成任务路径。录制完成后要生成一份包含垄行编号、起点、终点、作业宽度的地块配置文件。这样调度中心才能把“喷药第 3 到第 10 垄”翻译成具体的行车轨迹。5.4 实车部署步骤实车部署要严格按阶段推进每个阶段都有明确出口标准。第一阶段遥控验证。人工遥控车辆在线控模式下行驶确认转向、刹车、速度指令响应正常。第二阶段定位验证。打开 RTK 和 IMU 融合让车辆在田间行驶检查定位轨迹是否平滑是否有跳变。第三阶段单机自动驾驶。沿着已录垄行路径自动驾驶速度从低速开始逐步提高重点看垄行对齐精度。第四阶段机具联调。接入割草或喷药机具测试自动驾驶过程中机具的联动控制。第五阶段多机协同。两台以上车辆同时作业验证调度中心的分配和避让逻辑。每个阶段都必须有安全员在车上或旁边随时准备接管这不仅是安全要求也是调试效率要求。一旦车辆失控没有安全员接管损失的不只是设备还有整个团队的信心。5.5 多机联调多机联调的第一步是用共享地图。所有车辆必须使用同一套坐标系和同一份垄行地图否则调度中心分配的任务会错位。第二步是确认通信。每台车以固定频率向调度中心上报vehicle_id、pose、task_id、state调度中心再做统一规划。第三步是设置互斥区。同一垄行同一时间段只允许一台作业车进入行尾掉头区要广播占位信息。这些规则一开始用简单链表或查表实现都可以关键是先把交互逻辑跑通。6. 多机任务调度与接口 API 设计多机调度是葡萄园自动驾驶从“演示”走向“可用”的分水岭。单台车自动驾驶再顺滑如果调度中心无法把任务批量发下去生产价值就有限。6.1 调度中心模型调度中心通常维护三张表表内容作用车辆表车 ID、位置、电量/油量、状态、当前任务掌握车况任务表任务 ID、类型、地块、垄行范围、优先级、状态掌握任务作业记录每台车每个任务的起止时间、面积、异常用于统计和结算一个简单的调度逻辑是车辆空闲时向调度中心请求新任务调度中心按优先级和车辆当前位置分配最近任务车辆任务结束后上报结果并请求下一个任务。6.2 REST 接口调用示例调度中心一般最基础的一对接口是“下发任务”和“上报状态”。下面给出通用调用模板实际路径和字段需要按项目接口文档调整。import requests import json base_url http://schedule-server-ip:8080/api # 1. 下发任务给指定车辆 task_payload { vehicle_id: v001, task_type: spray, field_id: A-03, row_ids: [r03, r04, r05], priority: 1, params: { speed: 1.2, spray_on: True } } resp requests.post( f{base_url}/tasks, jsontask_payload, timeout10 ) print(resp.status_code, resp.json()) # 2. 查询车辆实时状态 state_resp requests.get( f{base_url}/vehicles/v001/state, timeout10 ) print(state_resp.json())接口返回值建议统一成下面这种结构方便批量任务对接{ code: 0, message: success, data: { task_id: t20250101-0001, vehicle_id: v001, status: accepted } }6.3 批量任务文件与队列设计多车大规模作业时人工一条条调接口不现实。更合理的做法是先把任务清单写成文件再由一个批量下发脚本读入并提交。{ tasks: [ { vehicle_id: v001, task_type: mow, field_id: A-01, row_ids: [r01, r02, r03, r04], priority: 2 }, { vehicle_id: v002, task_type: transport, field_id: B-02, source: gate-b, target: warehouse, priority: 1 } ] }调度中心收到任务后要维护一个任务队列。建议按优先级、任务距离和车辆电量做综合排序不要让某一台车长期空转。任务执行失败时不要立刻无限重试要先回传失败原因由调度端决定是否换车执行或人工介入。# 批量下发脚本用法示意 python batch_dispatch.py --config tasks.json --base-url http://server:8080/api6.4 多机防冲突与断网处理接口能下发任务只是第一步。多机真正跑起来后冲突不可避免需要提前设计策略。垄行互斥调度中心记录每个垄行当前占用车辆防止两车对向驶入同一行。行尾协调掉头区域空间有限要约定“谁先进入、谁等待”的规则通常优先级低的车让行。断网降级车辆离线时如果正在作业应完成当前垄行后安全停车而不是原地急停或继续全速行驶。日志回补网络恢复后车端要把离线期间的作业轨迹和任务状态批量回传到调度中心。7. 现场演示效果怎么看与技术验证看智能农机演示不能只看“车动了”。要从演示里观察技术真假和成熟度。7.1 单机验证指标指标判断标准观察方式垄行对齐精度横向偏差尽量控制在十几厘米内看车轮是否压苗或直接看屏幕上的偏差曲线掉头流畅度行尾掉头不用人工接管观察掉头弧线是否连续避障反应遇到人、车、障碍物能减速或停车现场放锥桶测试速度稳定性直线行驶速度不波动过大看速度曲线安全接管异常时安全员能一键接管确认急停开关位置7.2 多机协同观察点多机演示最值得观察的是“协同”不是单台车。第一看共享地图是否一致。两台车屏幕上的垄行编号、障碍物位置是否一致。如果一台车看到的“垄 3”和另一台车的“垄 3”不是同一条线调度就会乱。第二看相遇避让逻辑。两车在行尾相遇时谁停、谁走、是否能自动恢复任务。凡是靠人工模拟遥控避让的演示都还不算多机协同。第三看任务抢占和取消。调度中心下发紧急任务时正在作业的车辆能否在安全位置暂停并让出垄行。第四看断网恢复。现场可以问一句如果其中一台车通信断开系统会怎么处理。真正可靠的多机系统一定有不依赖调度的安全策略。7.3 环境鲁棒性验证农业场景不是干净的实验室。如果条件允许可以要求演示方测试这些情况逆光太阳低角度时摄像头是否还能看清垄行。扬尘和雾气能见度降低时是否会触发安全停止。坡度车在坡道上是否溜车定位是否有漂移。地面湿滑轮胎打滑时路径跟踪是否仍能恢复。这些场景不需要全部在演示现场复现但要在技术方案里看到对应的处理策略而不是只有晴天平地的演示数据。8. 资源占用与性能观察方法农业自动驾驶对资源的敏感度很高因为车端工控机供电有限散热条件差不可能拿一台桌面级 GPU 塞进拖拉机。部署时要重点观察四类资源。8.1 车端算力占用视觉得到 GPU 占用规划和控制吃 CPU定位融合也吃 CPU 和 IMU 频率。观察方式是在车端工控机上实时打印监控信息# 查看 GPU 占用 nvidia-smi # 查看 CPU 和内存占用 htop # 查看 ROS2 节点频率 ros2 topic hz /perception/row_center关键指标有三个一是感知节点频率是否稳定二是 GPU 显存是否长期接近上限三是整体 CPU 占用有没有在规划模块高峰时冲满。显存占用与模型分辨率、batch size 和 TensorRT 优化有关需要按你实际跑的模型测量不要照搬别人的数字。8.2 网络与通信开销多机系统还要观测通信带宽和延迟。每台车周期性回传位置、任务状态正常来说不会消耗大量带宽但如果要回传高清视频流做云端监控带宽和延迟问题就会凸显。建议在现场用类似ping、ifstat的方式记录基线数据确认基站覆盖范围内不存在频繁断连。8.3 降低资源占用的思路如果实测发现资源吃紧优先从这几个方向调降低相机输入分辨率只对关键区域做高分辨率推理。使用 TensorRT 或 ONNX Runtime 等加速框架替代原始 PyTorch 推理。降低回传图像的帧率例如从 30 FPS 改为 5 FPS 事件触发回传。把规划和控制频率分开控制高频执行规划低频更新。给多车调度使用轻量协议避免大字段 JSON 高频传输。9. 常见问题与排查方法把部署和调试中容易踩的坑整理成一张排查表。问题现象可能原因排查方式解决方案定位轨迹跳变RTK 信号丢失、IMU 未校准查看 RTK 状态和卫星数量检查基站做 IMU 静置标定视觉检测频繁漏检逆光、尘土遮挡、模型过拟合保存并回放相机帧检查推理结果扩充训练数据做数据增强车辆偏离垄行垄行中心线发布不稳定查看感知话题频率和输出值降低模型推理延迟增加滤波多车同时进入同一垄行调度互斥逻辑未生效查看调度中心日志和任务分配增加垄行占用表强制互斥掉头时卡住掉头空间不足、规划器参数不合理在仿真里回放同场景调整掉头半径和路径点网络频繁断开基站覆盖不足、天线安装位置不佳用终端 ping 车端 IP调整天线增加本地缓存和断网降级API 下发任务失败调度服务未启动、参数格式不对curl 单条请求测试检查服务状态和 payload 格式批量任务卡住一辆车故障阻塞队列查看队列状态和失败重试次数增加超时跳过和人工干预入口显存不足模型太大、分辨率太高观察 nvidia-smi减小输入分辨率切换 TensorRT FP16排查问题的核心原则是先看日志再看话题最后猜原因。不要上来就改代码。农业现场环境复杂很多问题看起来是算法问题实际是传感器安装松了、网线接头进水、或者 GPS 天线被藤蔓挡住了。10. 最佳实践与安全合规建议从工程化角度给几条可以落地的建议。第一永远保留一个最小可运行配置。不管代码怎么迭代都要有一份“加载固定地图、沿固定垄行走、安全员接管可用”的版本。这样现场出问题时可以随时回退到基线验证硬件链路是否正常。第二先小参数、小场地验证。第一次实车测试不要直接上大面积地块。先录一行垄让车反复走直线和掉头确认定位和控制的闭环稳定了再扩展任务范围。这种做法不是保守而是能最快定位问题的工程方法。第三车辆、地图、任务做好版本管理。地图会随着作物生长变化垄行边界和路径点要支持更新。更稳妥的做法是把地图也做成任务参数的一部分调度中心下发任务时同时下发对应的地图版本避免车端使用过期地图。第四日志和数据闭环必须做。每台车都要记录完整作业日志包括传感器帧、控制指令、调度消息和异常事件。日志不只用于排错也是后续训练感知模型、优化路径规划的数据来源。第五安全机制要有多层兜底。急停开关、遥控接管、自动停车、断网降级缺一不可。第六合规提醒只在关键处重复一遍使用人脸识别、声音或地块影像等数据前必须获得明确授权农药喷洒作业要遵守当地农资使用管理规定自动驾驶农机上路或跨地块转移要确认符合当地农机管理和道路安全要求。技术演示再漂亮也不能绕过安全和合规这两条底线。11. 总结与下一步Bonsai 这类葡萄园多机自动驾驶系统最值得关注的不是某一台车跑得多快而是它把“视觉感知、RTK 定位、垄行规划、多机调度、任务接口”整合成了一个能面向真实生产场景的闭环。从演示效果看方向是对的以视觉为主的导航更适合果园这种卫星信号遮挡严重的环境多机协同和批量任务调度则决定了系统能不能真正替代人工管理。如果你准备在自己的项目里验证这套思路建议按以下顺序推进先在仿真环境里跑通单机视觉导航闭环再录一块真实地块的小范围地图实车测试单机自动驾驶最后才做多机调度和批量任务。最容易踩的坑有三个一是跳过仿真直接上真机现场问题被传感器、定位、通信多种因素混在一起根本没法定位二是忽视地图和任务版本的一致性多机联调时各跑各的坐标三是没有设计断网和紧急接管机制一旦出问题就是安全事故。后续可以继续扩展的方向包括把作物检测和产量预估接入自动驾驶平台形成“感知-作业-数据回传”的数字农业闭环优化多机调度算法让任务分配不只是按距离最近而是按电量、作业时长、垄行状态综合规划把地块历史数据和实时遥感影像结合让自动驾驶农机不只是执行任务还能参与种植管理决策。先把单机走稳再把多机跑顺这套系统才真正具备颠覆传统种植管理的潜力。