电子海图与无人艇全局路径规划：从数据解析到航线生成

如果把水面无人艇比作一个人那电子海图就是它眼睛里的纸质地图全局路径规划就是出发前在脑子里先想好的那条“大路”。真正做过这个方向的人都会有一个共识——基于电子海图的水面无人艇全局路径规划难点从来不在“算法跑通”本身而在于怎么把海图里那些矢量要素、水深点、碍航物、航道边界翻译成路径规划算法真正能消费的地图数据。这一步没做好后面哪怕用再高级的算法规划出来的航线也没法用轻则绕远路重则直接穿过岛屿或者搁浅。这篇文章我想从工程实现的角度把整套链路完整拆开讲一遍电子海图的数据格式与解析思路、从矢量海图到栅格地图的转换方法、规划算法的选型与参数标定、路径平滑与约束处理以及我在实际调试中踩过的那些坑。适合正在做无人艇路径规划、或者想了解船用电子海图如何跟智能决策系统对接的开发者阅读无论你是刚入门还是已经跑通过基础demo应该都能从中找到一些可以落地的参考。1. 先看清整套链路从海图到航线到底要经过哪几步1.1 电子海图在无人艇系统中的角色定位水面无人艇USV的自主航行系统从功能上分通常可以切成感知、决策、控制三层。感知层负责通过雷达、AIS、摄像头、激光测距等手段获取周围环境信息决策层负责根据任务目标规划出可行航线并实时处理突发障碍物控制层负责把航线转化成舵角、油门指令。而电子海图在这套体系里承担的是先验地图的角色也就是决策层做“全局规划”时依赖的静态环境模型。这个定位很重要因为它决定了电子海图数据要怎么处理它不是拿来给人看的而是拿来给算法算的。海图里包含的水深、岸线、碍航物、航道边界、锚地等信息最终都要变成算法能够做碰撞检测和代价评估的空间数据。换句话说电子海图在无人艇系统里不只是“显示底图”更是“安全的数学底座”。1.2 全局路径规划在完整规划体系中的位置无人艇的路径规划一般分成全局规划和局部规划两层。全局规划解决的是“从A点到B点在大尺度地图上怎么走”的问题它面对的是相对静态的先验信息比如海图里的岛屿、暗礁、浅水区局部规划解决的是“当前视野范围内出现了突然的障碍物怎么躲”的问题它面对的是传感器实时数据。两者是接力关系全局规划输出一条参考路径局部规划沿着这条参考路径作局部的避让修正。为什么需要把全局路径规划单独拎出来做基于电子海图的设计因为海图提供了全局最优的安全走廊。如果没有电子海图只依赖传感器感知无人艇的视野最多覆盖几百米到了狭窄水道才看到岸线再转向就来不及了。有了海图可以在出发前就把航线算好做到“先看地图再上路”。1.3 海图数据与规划算法之间的接口设计从工程角度看海图数据和规划算法之间需要一层“编译器”。海图原始数据是矢量格式的包含点、线、面三类要素以及它们的水深、类型、属性等字段而大多数路径规划算法尤其是栅格化的A*、Dijkstra需要的是规则网格地图每个格子代表一片水域并且标出可通行/不可通行/代价多少。这个接口层的设计好坏直接决定了规划效果的上限。我见过很多团队花大量时间调算法参数最后发现问题是海图转栅格的时候水深阈值设错了导致大片可航水域被判为不可进入——这就好比算法再聪明拿到一张把路都涂黑的“地图”也规划不出好路线。所以这篇文章里我会花大量篇幅讲清楚这个“翻译”过程里的关键细节。2. 海图数据处理这一步直接决定规划效果的上限2.1 S-57格式与要素分类先知道海图里有什么当前船用电子海图使用最广的规范是IHO国际海道测量组织发布的S-57标准它定义了电子航海图ENC的数据编码方式。S-57数据里最基本的概念是要素Feature和空间对象Spatial Object。要素描述“这是什么”比如“这是一个灯塔”“这是一块浅滩”空间对象描述“它在哪里”用点、线、面来表示。从路径规划的角度我们对S-57里的要素要“挑着用”。重点关注这几类水深点SOUNDGGPS点坐标加水深值是判断可航性的基础数据。等深线DEPCNT连接相同水深点的线能直接看到浅水区边界。岸线COALNE与陆地LNDARE明确哪些区域绝对不能进。碍航物OBSTRN、WRECKS沉船、礁石等必须做膨胀处理。航道FAIRWY与推荐航线CRSROU可用于约束规划代价让航线优先走航道。锚地ACHBRT、海底电缆CBLSUB有些区域虽然水深够但不宜锚泊或抛锚可以标为高代价区域。很多人一开始拿到S-57数据会有点懵因为它是二进制编码直接用文本编辑器打开全是乱码。实际开发时更多是用现成的库来做解析比如GDAL、OpenCPN的底层库或者一些商用的海图SDK。但不管用什么库理解要素分类是最关键的因为后续怎么设置栅格地图里的障碍物完全取决于你从海图里提取了哪些要素。2.2 栅格化把矢量海图变成算法能“吃”的地图路径规划里最常见的解算空间是栅格地图。所谓栅格化就是把连续的经纬度空间划分为规则的网格每个格子记录一个状态值可通行、不可通行、或者介于两者之间的代价。这个过程看似简单但有几个关键参数必须根据无人艇的物理特性来定。第一个参数是栅格尺寸。栅格太小地图数据量爆炸搜索效率低栅格太大会丢失狭窄水道的信息导致明明能通过的航道被栅格化之后堵死。我做项目时的经验是栅格大小取无人艇船长的1/2到1/3比较合适。比如一条7米长的无人艇栅格取2到3米比较合适再小就是浪费算力。不过如果你用的是可扩展的A变体比如跳点搜索、分层A栅格可以适当细一点靠算法效率来补偿。第二个参数是可通行判断。栅格化时每个网格要么落在陆地、要么落在水域、要么跨在岸线上。跨在岸线上的格子怎么办按照保守原则一律标记为不可通行。原因很简单岸线数据的精度本身就有几米到十几米的误差无人艇在水上是不会精确贴边行驶的保守处理能避免规划出来的路径离岸太近导致搁浅。第三个参数是障碍物膨胀。无人艇不是质点它有自己的长宽和旋回半径。路径规划时如果只是把障碍物占据的格子标为不可通行那么算出来的路径可能会贴着障碍物边缘走实际执行时根本转不过去或者刮蹭到。所以必须对障碍物区域做形态学膨胀膨胀半径取艇宽的一半加上安全余量。这个安全余量我一般取3到5米具体根据航行水域的拥挤程度调整。2.3 安全水深阈值一条写错的数字可能让航线绕出十海里水深数据的处理是电子海图转栅格地图中最容易出错也最要命的环节。很多刚接触这个方向的同学会想当然地认为只要水深大于船体吃水就是可航的。这个认知在实际航行中会出大问题。船舶航行有一个概念叫富余水深Under Keel ClearanceUKC指的是船底到海底之间的最小距离。这个值必须覆盖波浪导致的船体垂荡、船体下沉squat、航速引起的动态吃水变化、以及水深数据本身的误差。实际工程里可航水深的判断标准通常不是“大于吃水”而是“大于吃水 安全余量”这个余量一般取吃水的15%到20%或者直接取固定的0.5米到1米。举个例子一条吃水1.5米的无人艇如果你直接把水深大于1.5米的区域全部标为可通行那么海图上水深1.6米、1.7米的地方也会被算进去。但实际航行时这些区域稍微有点风浪、船身一垂荡就可能触底。所以我会先把水深值统一处理成“等效可航水深”判断标准取吃水的1.2倍也就是1.8米以上才算可航。这个系数可以根据航行海域的实际环境调但低于1.15就不太安全了。还有一个很多人忽略的细节栅格化时的水深取值。海底地形不是平的一个栅格里可能同时包含多个水深点有的点水深够、有的点不够。这时候应该取最小值按最不利的深度来标记而不是取平均值。原因不用多说船不会因为“这格子的平均深度够了”就不搁浅。2.4 坐标系投影与经纬度的坑电子海图里的坐标通常是经纬度WGS84而路径规划算法在栅格空间里计算时用的是平面坐标。从经纬度到平面坐标需要一个投影变换。这里有个容易被忽略的问题路径规划的距离代价计算必须在同一投影坐标系下做否则计算出来的航程会有偏差。我最早做原型验证的时候直接用经纬度差值算距离在高纬度区域误差非常大。因为经度1度的实际距离随着纬度升高而缩短如果不管纬度直接算欧氏距离规划的航线在视觉上没问题但实际航程计算会差很多。后来我统一改用UTM投影在规划区域选择合适的UTM分带先把所有海图点都投影到UTM平面坐标再做栅格化和路径搜索问题就解决了。另一个需要注意的坑是投影变形。UTM在分带中心经线附近变形最小往两侧变形逐渐放大。如果无人艇的作业区域跨了两个UTM分带建议要么选择跨带投影的变体要么按区域分块处理。对于大多数近海场景单带UTM够用但如果任务区域很大这个细节务必要提前考虑到。3. 全局路径规划算法的选型、实现与参数标定3.1 主流算法横向对比别一上来就上深度强化学习很多做无人艇路径规划的初学者喜欢一上来就尝试深度强化学习觉得这才“够智能”。但从工程落地的角度看全局路径规划面对的是静态已知海图深度强化学习在泛化性、可解释性、安全保证上都没有优势反而让系统变复杂。我把主流算法的优缺点整理成了下表基于这些年在嵌入式设备上跑规划算法的实际体验算法优势劣势适用场景Dijkstra完备、最优逻辑简单搜索节点多耗时长地图小、对航程最优要求高的场景A*有启发式引导效率远高于Dijkstra启发式设计不当会退化栅格海图里最常用推荐优先上跳点搜索JPS在A*基础上去冗杂节点更快只适用于均匀栅格大范围海图、算力受限的嵌入式平台RRT/RRT*采样法适用于高维空间路径曲折最优性差需要后处理更适合动态规划或复杂约束空间遗传算法/蚁群全局搜索能力强参数敏感计算量大不稳定多目标优化场景如同时考虑油耗和安全在这些算法里A是实现成本和效果综合最优的选择。原因在于海图转成的栅格地图环境是静态的、信息是完全的A能保证在有解时找到最优解而且启发式函数设计好了以后搜索效率也不差。对于一条几十公里范围的航线在5米栅格的地图上跑A*通常几百毫秒就能出结果完全满足全局规划的实时性要求。3.2 A*算法实现中的三个关键细节A*的原理不多说了网上资料一大把。但“原理懂了”和“能在海图上跑出能用的航线”之间隔着好几个工程细节。我重点说三个。第一个是启发式函数的选择。栅格地图里如果允许八方向移动启发式函数要用对角距离如果移动方向还考虑了转弯代价启发式函数要相应调整。很多人用欧氏距离作启发式在障碍物多的情况下会扩展大量无用节点速度慢。实际上海图里岛屿、浅滩分布复杂直接用切比雪夫距离或者对角距离搜索效率更高。我的做法是用大津法octile distance在八方向扩展时这是可采纳的而且非常贴合栅格地图的结构。第二个是数据结构。A*的open表一定用优先队列最小堆不要用数组遍历找最小值。这个优化听起来微不足道但地图一大性能差距是数量级的。我在Jetson Nano这类嵌入式板子上测试过同样的地图、同样的参数用优先队列比线性查找快20倍以上。第三个是地图数据的存储。栅格地图如果按二维数组存几百米范围的近海图还好但如果任务范围到几十公里栅格数会到千万级别内存就紧张了。我通常的做法是把栅格地图压成一维数组并且只存障碍物信息和安全水深信息需要的时候再通过索引换算成二维坐标。同时计算代价时用整数而不是浮点数避免大量的浮点运算拖慢速度。3.3 路径平滑A*给出的折线没法直接给无人艇用A*规划出来的路径本质上是一条从栅格中心到栅格中心的折线相邻节点之间的航向变化可能是45度甚至90度。这种航线给到控制层无人艇会走得非常别扭——它得不停地大幅转向不仅降低航速还可能超出艇体的最大旋回角速度导致跟踪失败。所以必须做路径平滑。平滑的目标是在不偏离原始路径太远、不穿越障碍物的前提下让航向变化变得连续。比较常用的方案有三类第一类是贝塞尔曲线或B样条曲线拟合对控制点序列做参数化曲线生成。实现简单但容易在狭窄区域里“削”出道路外边界需要额外做碰撞校验。第二类是三次样条插值。在保留原始路径形状的前提下生成平滑曲线但容易overshoot产生多余的波浪形摆动。需要对样条曲线做横偏约束corridor constraint。第三类是Dubins曲线。这是最贴合船舶运动特性的平滑方式因为船舶不能侧移、不能原地转向Dubins曲线正好描述了满足最小转弯半径约束的最短路径。实际做法是提取A*路径上的关键转向点然后用Dubins曲线逐段连接最后做整体曲线拼接。我自己的工程实践是混合使用先用A*在栅格地图上算出全局路径抽稀掉冗余节点再用三次样条生成平滑路径最后用最小转弯半径约束对平滑后的路径做校验和修正。这个流程参数少、通用性强而且计算量小适合嵌入式环境。3.4 约束处理转向能力、航道规则与海流方向算法选的再好不考虑船舶自身的动力学约束规划出来的航线也只能停留在仿真PPT里。有三个约束是我在实际项目里一定会处理的。第一个是最大转向角约束。每条无人艇都有固定的最大舵角和最大转向速率对应一个最小旋回半径。路径规划时如果不对相邻路径段的夹角做约束规划出来的航线上可能会出现极小的转弯控制层根本执行不了。处理方式是在A的代价函数里增加转向代价项相邻两个路径段的方向变化越大代价越高。这样A在搜索时就会倾向于走方向变化平缓的路径出来的航线天然满足转向能力约束。第二个是航道规则约束。海图里通常有航道、分道通航制、禁锚区等要素这些信息可以在栅格代价地图上表示为不同的代价等级。比如航道中心的代价最低航道边缘代价稍高禁锚区如果水深足够但规则不允许航行就标为极高代价算法会尽量避免。这种做法比简单地把禁航区设为障碍物更灵活可以让计划系统在必要时“借道”通过而不是彻底无解。第三个是海流与环境影响。虽然全局规划面对的本质是静态环境但在近海场景海流方向相对稳定可以作为先验信息加入。我的做法是在代价函数里加一个航行时间项顺流方向代价低、逆流方向代价高。这样规划出来的航线会自然偏向顺流路径减少实际航行时间和能耗。需要注意的是海流数据的网格分辨率通常比海图栅格粗需要做插值处理。4. 实操过程从海图文件输入到航线输出的完整流程4.1 数据预处理的具体步骤我以一条吃水1.5米、船长7米、最小旋回半径15米的小型无人艇为例走一遍完整的全局路径规划流程。第一步准备海图数据。从官方渠道下载目标海域的S-57格式ENC数据我习惯先导到OpenCPN里人工目检一遍确认数据覆盖范围和要素完整性。这个步骤看起来“土”但很有效能提前发现数据缺失、坐标系混乱等问题。第二步解析海图要素。用GDAL/OGR库读取S-57提取需要的要素图层另存为GeoTIFF或者Shapefile方便后续处理。如果在国内做项目也可以直接使用合规的海图数据源和SDK。重点是建立一个映射表把S-57的要素编码如OBSTRN代表碍航物、DEPCNT代表等深线映射到我们内部定义的障碍物类型和水深值。第三步统一坐标系。把所有的经纬度坐标统一投影到目标UTM分带然后用平面坐标系建立栅格地图的索引关系。第四步生成障碍物图层。把陆地、岸线、碍航物、水深不满足要求的区域都标记为障碍物然后做膨胀处理。膨胀半径取艇宽的一半约1.5米加安全余量4米总膨胀半径约5.5米。第五步生成代价图层。在可航水域里根据水深富余程度、是否靠近航道中心、是否靠近障碍物边缘等因素给每个栅格赋一个基础代价。我常用的公式是总代价 基础航程代价 水深风险代价 航道偏好代价 转向代价。4.2 关键参数设置与调优记录下面这张表是我在多次试验后觉得最适合近海无人艇场景的初始参数组合具体项目可以以此为起点再微调参数推荐值说明栅格尺寸2.5米船长7米取1/3船长略保守可航最小水深1.8米吃水1.5米安全系数1.2障碍物膨胀半径5.5米艇宽一半加安全余量A*启发式对角距离八方向扩展效率高转向代价权重0.3过大会导致航线过度绕弯航道偏好权重-0.5负值表示奖励偏向航道航行路径抽稀阈值5米相邻节点小于该距离则合并最小转弯半径15米与艇的旋回能力匹配参数调优有两条经验值得分享。第一转向代价和航道偏好权重是互相影响的先单独标定再联合调优不要同时调两个否则很难定位是哪个参数导致的航线异常。第二路径平滑的强度不能一次加太大我习惯先用较小的平滑系数跑一遍看航线是否贴近原始A*路径如果偏离超过一个栅格就减小系数。4.3 核心流程的代码结构参考这里给一个简化的伪代码流程帮你建立整体实现框架。实际开发中还需要补充海图解析、坐标系转换、消息订阅等平台相关代码。# 全局路径规划主流程结构化描述 def global_planning(start, goal, enc_data): # 1. 解析海图要素 chart_features parse_enc(enc_data) # 2. 构建网格地图 grid_map GridMap(cell_size2.5) grid_map.set_obstacle(chart_features.land) grid_map.set_obstacle(chart_features.obstruction) # 3. 水深筛查与障碍物膨胀 grid_map.set_water_depth(chart_features.depth) grid_map.mark_unsafe_depth(min_depth1.8) grid_map.dilate_obstacles(radius5.5) # 4. A*搜索 raw_path astar_path(grid_map, start, goal) # 5. 抽稀与平滑 key_points extract_keypoints(raw_path, threshold5.0) smooth_path cubic_spline_interpolate(key_points, max_curvature1/15) # 6. 碰撞校验与修正 final_path validate_and_correct(smooth_path, grid_map) return final_path这个流程本身看着简单但要工程落地每个环节都要做校验。比如解析完海图要素之后下一步做可视化叠加确认要素位置对不对做完膨胀处理之后检查狭窄水道是不是被堵死平滑完之后做碰撞校验确认平滑曲线没有切掉障碍物角。每一步都有可视化的中间输出查找问题会高效很多。4.4 在仿真环境中如何验证规划航线航线算出来之后第一件事不是在实船上测试而是在仿真环境里验证。我常用的仿真链路是基于Python的地图显示加无人艇运动学模型用一个简化的船舶运动模型模拟航迹跟踪把规划的航线作为期望轨迹输入看看实际走的路径会不会碰到障碍物、会不会超出转向约束。这里有一个很重要的工程习惯把每次实验的规划输入、规划参数、规划结果、仿真跟踪结果都记录下来最好每次保存一版带有参数配置的日志文件。这样出了问题可以回溯是哪个环节引起的。我做这个项目过程中至少有三次航线异常是因为前一天改了参数没记录第二天又改回来最后找不到原因。养成参数追溯的习惯能省下大量排查时间。仿真验证通过之后再进行小范围湖试或者近海试航。第一次实船测试建议选择一片开阔、无障碍物的水域先在真实环境下验证路径跟踪控制是否正常再逐步加入海图障碍场景。5. 常见问题与排查技巧实录5.1 规划航线穿过岛屿或者贴岸太近怎么办这是最常见的问题通常不是算法的问题而是地图处理的问题。航线穿岛大概率是栅格化时岛屿的边界没有被完整保留或者膨胀半径不够。排查时先在可视化界面里把生成的栅格地图打开看岛屿周围是否有“缺口”。如果岛屿边缘的格子在水深判断时因为某个水深点数值异常被误判为可通行或者障碍物图层在坐标转换时发生了便宜就会导致这个现象。我遇到过一种很隐蔽的情况S-57数据里岛屿的面要素和水深点要素在空间上存在微小重叠岛屿边缘的水深点显示水深很大栅格化时这个格子被判为可航水域于是航线直接从岛屿边缘“切”了过去。解决办法是在栅格化标记时只要一个格子被任何障碍物面要素覆盖就直接标为障碍物不管水深点怎么显示。换句话说处理优先级是陆地/岛屿高于水深判断。5.2 规划时间太长、导航过程中卡顿如果A*在海图范围不大但是栅格很密集的地图上跑出来特别慢优先检查两点。第一open表是不是真的用了优先队列第二启发式函数是不是可采纳的如果启发式设计得不合理扩展节点量会指数级上升。还有一个比较容易忽略的坑是在地图比较大的情况下close表用open表相同的数据结构来存储导致内存频繁分配释放。我的做法是把close表设计成纯数组或者哈希表避免频繁动态分配。如果地图确实很大推荐做分层规划先在一个分辨率较粗的地图上做快速搜索找到宏观走廊再在走廊内部的细栅格地图上做精细搜索。这个思路类似于开车导航先上高速再走城市道路计算量能少一个数量级。5.3 水深栅格化后大片可航区消失这个问题多半出在等深线数据的使用方式上。S-57里的等深线通常是一组封闭或非封闭的线如果只提取等深线本身作为边界数据而没有用深度区域DEPARE数据来填充水深值栅格地图上很多地方会变成“没数据”的状态默认处理成不可通行看起来就是大片可航区消失。正确的做法是优先使用S-57里的深度区域DEPARE要素它把海域划分成了一个个水深区间比离散的水深点更适合做栅格填充。水深点SOUNDG用于校验和插值而不是做主数据源。如果你拿到的海图源数据里DEPARE要素不完整那就要做邻域插值或者只能老实去下载更完整的数据。5.4 局部动态规避如何与全局路径衔接很多做全局路径规划的人会忽略一个后续问题全局规划算出的航线是一条静态参考线真船航行时遇到动态障碍物需要局部避让避让完之后怎么回到全局航线上我的经验是在系统架构层面把全局航线用一串航路点表达局部规划器运行时始终以当前全局航线上的某个前视点look-ahead point作为临时目标点。这个前视点距离船当前位置大约3到5倍船长太近了局部避让容易跟全局航线“打架”太远了局部避让失去了跟随全局路径的意义。避让完毕之后局部规划器把控制权交回全局航线跟踪不需要重新做全局规划除非全局航线本身被证明不可行。这种“全局粗规划局部细调整”的分层架构在工程上比让全局规划器频繁重规划要稳定得多。全局重规划不仅计算量大而且可能在动态环境下产生不连续的航线给控制层带来额外负担。记住全局路径规划的角色是“向导”不是“司机”真正的实时避障交给局部规划层来做分工明确系统才会稳定。我个人在实际操作中的体会是基于电子海图的全局路径规划七成工作量在处理海图数据上三成在算法调参上。很多初次上手的人把大部分时间花在调A的启发式、换更花哨的算法上却忽略了最基础的地图数据质量最后效果怎么都上不去。先把海图数据吃透把栅格地图画对规划算法哪怕用最基础的A都能跑出很漂亮的效果。数据不对算法越高级越容易在错误的地图上“自信地”犯错这个顺序千万别搞反了。