这几年做水面无人艇导航系统绕不开的一个硬骨头就是全局路径规划。很多人一上来就盯着局部避碰、动态窗口、模型预测控制这些看起来高级的东西但真到湖上、海上跑起来就发现如果全局规划没做好艇连港口都出不去更别提什么避碰了。我自己的经验是全局路径规划才是整个导航链路里真正决定任务成败的地基而在地基之上铺的第一块砖就是电子海图数据。这个项目做的就是一件事基于电子海图数据为水面无人艇在已知静态环境中搜索一条从起点到终点的安全、可行、符合船舶操纵习惯的全局航线。它解决的核心问题是路在哪里、哪里不能去、怎么走最稳妥输出的不是逐帧轨迹而是一串带语义信息的航路点给后续局部避碰模块当上游参考线。适合正在做无人艇导航、内河/近海测绘任务规划、海事仿真系统以及刚入行想搞懂海图数据到底怎么用的工程师参考。下面我把整个方案的思路、数据解析、算法实现和踩坑经验完整拆开讲。1. 从海图到航线无人艇全局规划到底在解决什么问题1.1 为什么电子海图是全局规划的第一优先级数据源陆地上的机器人导航可以用激光雷达建图无人机可以用航测影像建模但水面无人艇的传感器视角天然吃亏——雷达对小目标不敏感摄像头在开阔水面容易丢特征测深仪只能看正下方一条线。也就是说无人艇对环境的感知是严重受限的。全局规划如果还依赖艇上传感器现场建图安全性完全没有保障。电子海图的优势在于它是一个先验的、已经经过官方测量和审核的静态环境模型。陆地在哪里、港口航道怎么走、哪里有沉船、哪里有暗礁、水深是多少这些信息在出航之前就已经按照统一标准编码好了。拿它做全局规划相当于先给无人艇一份城市地图艇只需要在地图基础上找一条安全路线剩下的动态障碍交给局部规划去处理。用海图做全局规划的另一个好处是语义丰富——它不是一张简单图片而是带属性的矢量数据你可以知道某个区域是干出滩还是深度足够的航道这对安全评估至关重要。1.2 全局规划在导航体系中的定位与任务边界先明确一个容易混淆的概念全局规划和局部避碰不是一回事。在我的项目实践中导航系统通常分三层任务层负责任务点拆分全局规划层基于静态海图生成宏观航线局部避碰层用雷达、AIS等实时数据做短时避让绕开临时出现的渔船、浮标和移动船只。全局规划管的是分钟级到小时级的路径局部避碰管的是秒级的机动。所以这个项目的任务边界很清晰输入是电子海图、起点、终点、艇的吃水深度和安全参数输出是一串结构化的航路点序列每个航路点包含经纬度、航向建议、航段距离等属性。全局规划不需要去管前面100米有条渔船怎么办但必须保证这条航线上的每一个点水深足够、无障碍物、不在禁航区里并且从船舶操纵的角度能走通。这个边界一旦定了后面所有算法选型和数据处理的思路都会变得清爽。2. 电子海图数据解析S-57里到底藏了什么2.1 为什么必须是S-57矢量海图而不是光栅图市面上常见的电子海图分两大类光栅海图和矢量海图。光栅图本质上是扫描后的图片虽然人眼看得清楚但计算机没法直接从里面提取水深、物标类别这些结构化信息。你没法问一张图片这里水深多少除非上OCR或者图像识别这在工程上又慢又不稳定。S-57是国际海道测量组织IHO发布的矢量海图数据交换标准所有官方海道测量机构发布的ENCElectronic Navigational Chart电子导航海图数据都遵循这个标准。S-57把现实世界中的航标、沉船、航道、水深等都抽象为带属性、带几何形状的物标计算机可以直接查询、计算和分析。这个项目我正是用S-57矢量数据作为数据源它天然适合做全局路径规划——因为你需要的环境要素全部是现成的结构化信息。2.2 看懂S-57的物标模型从现实地理到数据编码S-57数据模型的核心是物标Feature。一个物标包含两部分属性描述这是什么、有什么特征几何描述它在哪里、长什么样。举个例子一个港口水域的水深区域DEPARE物标属性里有一个深度范围DRVAL1最浅水深、DRVAL2最深水深几何上是一块多边形。再比如沉船WRECKS物标几何可能是一个点或者一个面属性里会标出沉船类型、是否危险。物标按照几何类型分成点物标、线物标和面物标读取数据的时候要用不同的方式处理。这里有个新手容易忽略的点S-57不是把物体坐标直接存在物标里而是通过空间物标Spatial Object间接引用也就是物标通过指针指向空间物标空间物标才包含坐标序列。代码里处理这种拓扑关系时需要格外小心尤其要处理空间物标被多个物标共享、坐标链断裂等情况。我自己第一次解析S-57时就被这个绕晕过后来干脆封装了一层数据访问接口统一做好拓扑重构。2.3 构建路径规划可用的物标分类体系拿到海图数据后不能一股脑全用必须先做合理的物标分类。海图物标有上百种但真正影响水面无人艇路径规划的就那么几类。按我的经验可以划分成四个大类用表格列出来类别代表物标路径规划语义陆地区域LNDARE陆地、DEPARE水深为负的区域不可通行硬障碍碍航物WRECKS沉船、OBSTRN障碍物、UWTROC暗礁不可通行需安全距离避让水下地形DEPCNT等深线、DEPARE水深区域、SOUNDG水深点决定可通行性需结合吃水判断航行限制区航道边界、锚地、禁航区、港区范围约束通行规则优先/禁止通行划分好类别后我还会做一层语义抽象把物标属性映射成规划用的统一字段比如是否硬障碍最小安全水深禁止通行标志建议通行方向等。这层抽象的价值在于后续做栅格化或搜索时不需要反复去查S-57原始属性表直接在统一模型上计算即可。如果项目中需要支持更多数据源比如本地实测水深插值网格也只要转换成这一套统一字段就行。3. 全局路径规划算法选型与实现要点3.1 从全局规划算法谱系中做取舍路径规划算法很多但在水面无人艇场景里常用的全局规划算法我梳理下来主要就这几个方向基于图搜索的Dijkstra、A*基于采样的RRT系列以及基于智能优化的遗传算法、蚁群算法。每个都有自己的脾气我整理了一个对比表格方便直观感受差异。算法完备性最优性计算开销适用场景Dijkstra完备最短路径高小地图、需要严格最优解A*完备有启发函数时最优中中等大小栅格地图最常用RRT/RRT*概率完备渐进最优低高维空间、快速粗糙路径遗传算法不保证近似最优高多目标、航路点优化在这个项目里我最终选了A作为主搜索算法原因有三。第一海图栅格化后的地图规模通常在千万像素量级以内A在合理的数据结构下能在数百毫秒到数秒内完成搜索实时性完全够。第二A在栅格地图上的完备性和最优性都有数学保证这一点对安全敏感的无人艇场景很重要——我不希望某次规划因为算法本身的随机性给出一个漏掉障碍物的路径。第三A的逻辑直观后续加工程约束、代价函数调优都好改。RRT不是不能用但它的路径通常比较糙转折多、不平滑而且在窄航道场景下采样效率低后处理成本高。遗传算法这种随机优化方法更适合在已有航路点序列上做多目标优化比如同时权衡路程、油耗、风险直接拿来搜全局路径反而效率低。这些算法不是谁替代谁的关系而是放在不同层级配合使用。3.2 A*搜索的工程实现状态空间、邻域和启发函数A*算法虽然是经典算法但工程实现里有很多细节决定成败。首先是状态空间的定义。我做栅格化时把海图切成了均匀网格每个网格是一个状态节点网格的值记录了该位置是否可通行、最小安全水深、物标语义等信息。邻居扩展我采用的是8邻域也就是当前格子周围8个方向的格子都可以进入。8邻域的好处是允许斜向航行更符合船舶实际航向的连续性但代价函数里必须区分直行和对角移动的成本差异。按照我项目的做法直行成本设为1.0对角移动成本设为√2约1.414这样搜索出来的路径不会因为邻域定义产生畸变。启发函数的选择直接关系到搜索效率。我采用的启发函数是欧氏距离实际是大圆距离的平面近似即当前节点到目标节点的直线距离。这个启发函数是可采纳的——它永远不大于实际从当前节点到终点的真实最短距离因此A*保证能找到最优路径。我试过曼哈顿距离做启发函数在允许斜向移动的8邻域地图上会明显高估距离导致搜索扩展的节点变多、路径质量下降。关于这一点建议做水面无人艇规划时直接采用欧氏距离匹配8邻域模型效果最自然。3.3 代价函数里怎么融合海图语义安全、吃水与航行规则A*的搜索效率再高如果代价函数设计不合理找出来的也只是一条几何上最短但航海上不靠谱的路。在水面无人艇场景里代价函数的设计必须融合海图语义。我把代价函数拆成几个部分来设计硬约束速度设置为无穷大代价直接排除不可通行区域。包括陆地、干出滩水深为负值的区域、沉船和暗礁外侧缓冲区、禁航区、已标识的军事演习区如果有该物标等。硬约束是安全底线哪怕路径绕远也必须避开。水深可通行判断这部分是整个海图路径规划最核心的工程逻辑。判断一个栅格能不能走不是简单看有没有标沉船而是要结合无人艇自身吃水信息。我设定的公式是安全水深 静态吃水 富余水深(通常取0.5~1米) 浪高影响量(有海况预报时加上)当栅格的水深值小于这个安全水深时该栅格标记为不可通行。这里的水深都是基于理论最低潮面的基准水深实际规划时如果需要精确到某个出海时刻还得叠加当时的潮高修正这部分后面在问题排查里我会再展开。软惩罚有些区域不是不能走而是走了不太好或者是尽量别走。比如渔栅区、推荐航道外的浅水区、锚地边缘、生态保护区等。我把这些区域的额外代价值设置为基础通行代价的3~8倍A*搜索时会自动避开它们但实在没有别的路时也会选择穿过这样规划结果更灵活不会因为某个软约束把所有可走的路都堵死。这样设计出来的代价函数搜索出来的路径不仅满足几何可达还能自动贴合深水大路规避风险区域。我曾见过有人直接把水深小于3米就标成不可通行结果在浅水港口里规划出一条贴着岸边礁石走的自杀航线就是因为没把艇的吃水和安全余量做参数化建模。4. 实操完整搭建一个海图数据驱动的全局规划流程4.1 环境准备与数据接入这一节我完整写一下我实际项目的搭建过程每一步都可以直接参考。先说环境我用的主力语言是Python主要依赖库是GDAL/OGR读取S-57数据、NumPy栅格矩阵计算、Pyproj坐标投影转换、heapqA*优先队列可视化用的是Matplotlib和QGIS做辅助验证。数据源方面我建议优先接入官方或授权机构发布的S-57格式ENC数据。不同的海道测量机构会发布不同区域的ENC数据包拿到以后注意数据版本。S-57有3.1版和4.0版也就是S-101前的过渡版物标属性名会有些微不同代码里要做兼容处理。对于做算法验证的场景也可以用开放街区和公开航道数据做替代但工程落地一定要用合法授权的ENC数据。实测下来GDAL的OGR模块读取S-57非常方便。from osgeo import ogr ds ogr.Open(enc_folder/, 0) # 0表示只读S-57目录级打开 layer ds.GetLayerByName(DEPARE) # 水深区域物标层 print(水深区域物标数量:, layer.GetFeatureCount()) feature layer.GetNextFeature() while feature: geom feature.GetGeometryRef() drval1 feature.GetField(DRVAL1) drval2 feature.GetField(DRVAL2) # 处理每个面的几何、水深属性 ... feature layer.GetNextFeature()这里有一个关键点OGR打开S-57时数据源路径指向的是包含海图单元格扩展名.000等的目录不是直接指向某个文件。不同版本的GDAL对S-57的支持程度也有差异我建议使用2.4以上版本物标识别和拓扑构建会更稳定。4.2 经纬度到平面坐标投影与栅格化S-57的原始坐标是经纬度经纬度WGS84做栅格搜索之前必须转成平面坐标不然距离计算和栅格划分在纬度高一点的地方会产生不可接受的畸变。我的做法是根据任务区域所在的经度带选取对应的UTM投影带作为工作坐标系。例如在中国沿海某区域可能用UTM 51N带中央经线在123°E附近投影后的单位是米。投影转换用Pyproj库很轻松from pyproj import Transformer transformer Transformer.from_crs(EPSG:4326, EPSG:32651, always_xyTrue) x, y transformer.transform(lon, lat)投影做好后确定栅格地图的边界和分辨率。栅格分辨率的选择是个权衡分辨率太粗窄航道和小障碍物会被糊掉规划容易出现穿岛或擦碰危险分辨率太细栅格矩阵巨大A*搜索时间和内存都会急剧上升。我的经验是对于一艘几米级的小型无人艇栅格分辨率取5~10米足够了再结合船本身的尺寸设置膨胀量。具体来说栅格尺寸小于等于船宽的一半时路径保真度会好一些但地图像素数会多好几倍建议先用10米分辨率做快测确认航路大体合理后再用5米分辨率精算。栅格化时所有面状碍航物和陆地区域在栅格上标记为不可通行同时把区域内最浅水深记录到栅格的值中。这样A*在判断一个格子能不能走时直接查栅格的水深值和障碍标志高效而且内存友好。栅格化后的数据我用NumPy矩阵存一个矩阵存障碍标志一个矩阵存水深值一个矩阵存语义类别编码。4.3 关键环节安全边界膨胀与增益处理栅格化完成之后如果直接拿原始障碍物栅格去跑A*出来的路径会紧贴着障碍物边缘走。这在陆地上也许还能接受但对无人艇来说非常危险——海图误差、水流漂移、定位噪声都会让实际船位偏离规划线一旦偏离就非常容易发生碰撞。所以我必须对障碍物做膨胀处理。膨胀半径的计算不是拍脑袋而是结合多个因素膨胀半径 船体半宽 定位误差(通常取1~2米) 海图误差(不同比例尺海图精度不同取2~5米) 安全余量(至少1米)比如一艘船宽2米的无人艇定位误差取2米海图误差取3米安全余量取1米那么膨胀半径就是1 2 3 1 7米。在栅格分辨率10米的地图上约相当于对每个障碍物格子向外扩1个格子。这个膨胀过程如果用栅格形态学膨胀来做开销很小如果没有现成库也可以对每个障碍物格子周围半径内的格子做标记。但注意膨胀必须只在障碍物可通行边界方向扩散不能覆盖起点和终点区域。膨胀后还应该做一次连通性检查——判断起点和终点是不是被障碍物隔开了。如果隔开说明在当前参数下根本没有可行航线需要提示操作员调整参数或者确认任务可行性。这个检查用泛洪填充或者BFS从起点开始扩展一遍就行成本很低但能在算法运行前就避免一次无意义的搜索。4.4 A*搜索与航路点序列生成膨胀完成后进入核心搜索环节。我实现的A*用的是Python的heapq作为优先队列每个节点记录坐标、g值、启发值、父节点指针。搜索的伪代码逻辑如下import heapq def a_star_search(grid, start, goal): open_heap [] heapq.heappush(open_heap, (0.0, start)) came_from {} g_score {start: 0.0} while open_heap: _, current heapq.heappop(open_heap) if current goal: return reconstruct_path(came_from, current) for neighbor in get_neighbors(grid, current): # 跳过不可通行格子和地图外 if not is_passable(grid, neighbor): continue tentative_g g_score[current] cost_between(current, neighbor) if tentative_g g_score.get(neighbor, float(inf)): came_from[neighbor] current g_score[neighbor] tentative_g f_score tentative_g heuristic(neighbor, goal) heapq.heappush(open_heap, (f_score, neighbor)) return None # 无可行路径搜索完成后得到的是一个密集栅格点序列直接拿去用肯定不行因为点数太多、转折太碎。我会做两步后处理第一步用路径压缩去掉不必要的中间点——从起点开始尝试尽可能远的点能否直线通过且整段都在可通行区域能就跳过中间点第二步用转折点简化去除共线点只保留必要转向点。经过这两步最终输出给下游的通常是几个到十几个航路点的序列每个航路点包含经纬度、预计航向、安全半径等属性作为无人艇航迹跟踪层的参考航线。4.5 路径平滑与操纵性约束的引入A*和路径压缩出来的航路点仍然是折线直接让无人艇跟踪折线每个转角处都需要急转对于舵角有限、惯性大的水面艇来说很难受。因此我在后处理里加了一步平滑。这里我没有直接上复杂的B样条或Dubins曲线而是先采用了更工程化的做法转弯半径约束检查。具体做法是遍历压缩后的航路点计算每个转向点的转角大小如果转弯角度超过了无人艇的最大转向能力比如最大转向角30度就在转角处插入过渡弧线点把一次急转弯拆成几段缓转弯。这个做法的好处是逻辑清晰、不会产生偏离安全区域的路径。对于更高级的平滑需求B样条或者贝塞尔曲线也是好方案但务必要确保平滑后的曲线仍然在安全区域内——我曾经见过有人用B样条平滑结果曲线直接穿过小岛边缘就是平滑时没做碰撞检测。平滑完成后把航路点序列按等间距内插成更密集的航迹点提供给底层航迹跟踪控制器使用。到这里基于海图的全局路径规划流程就走通了。5. 常见问题与排查技巧实录5.1 海图坐标错位、物标丢失怎么办做海图数据解析时最常见的故障原因大多出在坐标基准和拓扑处理上。坐标错位所有人都会遇到一次。S-57原始坐标是经纬度如果你在栅格化之前忘了做投影转换直接拿经纬度当平面坐标用在低纬度也许看不出来但在北方港口会偏出好几公里。排查办法很简单——把解析出来的物标叠加到已知的岸线底图上如果物标和底图上的陆地轮廓对不上先查投影转换再查坐标系基准尤其注意CGCS2000和WGS84混用的问题。物标丢失S-57数据里部分面物标的空间几何非常复杂可能包含岛中湖、多边形带洞等情况。有些解析库处理这类带洞多边形时会把内环丢到下层数据里导致渲染或者栅格化时把岛屿内部识别成陆地。这个问题的排查方法是栅格化后随机挑几个已知的狭长水道验证一下通航性再结合可视化层把物标轮廓画出来比对。我用QGIS叠加验证过之后就再没出过这种问题。5.2 路径穿岛、穿浅滩但明明避开了标注障碍物我在实际测试中碰到过一个十分隐蔽的坑A*给出的路径从纸面看完全绕开了沉船、暗礁等点状障碍物但叠加到海图上发现路径直接横穿了一块浅滩区域。原因是那块浅滩在水深数据集里是没有物标面标识的只有一些离散的水深点SOUNDG物标而我在物标分类时没有把离散水深点纳入栅格水深计算。解决方法很直接把所有水深点数据也参与栅格化插值。我的做法是用反距离加权IDW插值把这些离散水深点加密到栅格矩阵里。更稳妥的方案是在栅格化之前建立水深网格模型比如用线性插值或Kriging把所有离散水深数据组织成连续表面再和面状水深数据融合取保守值取浅的那个。做完这一步之后浅滩区域在栅格地图上就有了真实的水深记录A*结合吃水判断后自然会绕开。5.3 A*搜索耗时太长怎么优化栅格地图一大A*的耗时和耗内存就会起飞。我遇到过一张上万乘上万像素的海图单次搜索耗时好几十秒这在任务规划场景下完全不能接受。优化思路有四个按投入产出比从高到低列出来优先队列用heapq而不是list最基本的性能漏洞。用list加排序函数的A*在大地图下时间会从秒级变成分钟级。把开放列表换成heapq后时间通常能下降一个量级。双向A*搜索从起点和终点同时向中间搜搜索空间从指数级缩小到接近两棵更小的树实践下来时间大约能再降40%。地图分层/缩采样预搜索先用低分辨率栅格跑一次粗糙路径得到一条走廊然后在走廊区域的精细栅格上再精确搜索。这个方案特别适合超大面积海图但工程上稍复杂我是在确定需要时再启用。考虑在栅格化和搜索参数上做保守将栅格做粗一些如20米而不是10米搜索节点少4倍速度提升非常明显代价是路径精细度下降。适合远程快速侦察场景最终接近目标区域再切换高分辨率地图。我最终的方案是heapq加双向搜索10米分辨率、5000×8000像素的地图单次搜索可以稳定在2秒内完成任务规划完全够用。5.4 吃水判断不准导致近岸擦底风险吃水判断这块我前面提过基准面的问题这里展开讲一下。海图上的水深标注是基于理论最低潮面的真实水深 海图水深 当前潮高。如果你的无人艇吃水0.8米安全余量0.5米安全水深是1.3米海图上一个区域标成1.5米按静态判断可以走。但如果当天低潮时潮高为负值比理论最低潮面还低实际水深可能只有1.2米就会擦底。处理方式是引入外部潮汐数据在规划时为安全水深增加一个潮汐修正量。简单做法是加载该海域的潮汐预报站数据在规划时间段内查询预测潮高把最小预期潮高叠加进安全水深公式。如果没有实时潮汐数据我还有一个保守做法——安全水深中额外增加0.3~0.5米的潮汐不确定余量虽然会让路径略微远离浅水区但把擦底风险压到一个极低水平。工程上宁可航线绕远一点也不能让艇去赌水深。5.5 物标语义与航行规则的结合最后一个经验关于海图物标里那些隐含规则。有些区域不是物理障碍而是规则障碍。比如航道FAIRWY有中心线和边界船舶应该沿着航道方向走而不是横穿有些区域是海底管道区PIPELINE虽然水深够、表面没有任何障碍物但抛锚会砸坏管道应该尽量避开。全局规划如果不把这些语义加进去出来的路径虽然物理上是通的但航海上可能违规或者有隐患。我的做法是在代价函数中加入航行规则码字段按照海图物标类别预置规则等级。比如航道边界内的代价基础值较低航道外的近岸区代价高一点管道区设为极高代价军事禁区和生态保护区直接设为硬约束。这样规划出来的路径就会自然地顺着航道走、远离管道区、贴着深水区整体看起来就像一条有经验的船长会走的航线而不是纯粹几何搜索的结果。这个语义层是区分能跑和敢用的关键也是我们从原理样机走向实际作业时收获最大的一块。我在实际项目中体会最深的一点是海图数据是参考不是绝对真实。海图的测量时间、测区覆盖、比例尺精度都会有局限水面环境还会因疏浚、淤积而持续变化。因此全局路径规划只是第一步规划出来的航线在下发执行前最好再结合当时当地的水文气象条件、最新的航行通告和AIS船舶动态做一次人工复核。这也提醒我们任何算法的输出都不能替代安全冗余在无人艇真正大规模投入运营之前人类在环上的监督验证依旧是必不可少的安全阀。最后分享一个实用小习惯每次规划结束后把输入海图、障碍物图层、规划路径、膨胀区域、安全参数一起导出成一张叠加图存档既方便审计也是调试新参数时最快捷的前后对照工具。