Cesium 无人机智能航线规划：航点动作组与 AI 识别实战

这种结构化的航点数据，才是连接 Cesium 可视化编辑界面与无人机飞控系统的桥梁。后续所有工作，都是围绕如何设计、编辑、转换并最终执行这样的'智能航点'展开。

2. 构建航点动作组：让每个航点都'活'起来

动作组（Action Group）是智能航线规划的灵魂。它把航点从一个空间位置，升级为一个任务执行单元。在实际项目中，通常将动作分为几个核心类别，方便管理和配置。

2.1 基础飞行控制动作

这类动作直接影响无人机的飞行状态，是最常用的一类。在 Cesium 编辑器中，需要提供直观的 UI 来设置这些参数。

悬停与等待：这是最基础的动作。无人机到达航点后，不是立刻飞向下一点，而是悬停指定时间。这在巡检拍照时至关重要，要给云台稳定和相机对焦留出时间。参数通常包括悬停时长（秒）和是否允许位置微调（应对风扰）。

速度与高度变化：可以在某个航点指令无人机改变巡航速度或飞行高度。例如，在进入人口稠密区前减速，在跨越障碍物时爬升。在 Cesium 中，可以用一条动态变化的曲线来可视化这种速度/高度剖面，让操作者一目了然。

航向角设置：控制无人机机头的朝向。对于多光谱相机或倾斜摄影任务，保持航线方向与太阳光角度、建筑物立面平行非常重要。在 Cesium 中，习惯用一个小箭头模型来直观显示每个航点的机头朝向。

一个典型的基础动作组配置界面，在 Cesium 中可以通过右侧面板实现，代码层面可以这样组织：

// 航点动作组数据结构示例
const waypointActions = {
  waypointId: 1,
  flyActions: [
    { action: 'hover', duration: 5.0 }, // 悬停 5 秒
    { action: 'change_speed', value: 5.0 }, // 速度降至 5m/s
    { action: 'change_altitude', value: 120, mode: 'relative' } // 高度升至 120 米（相对起飞点）
  ],
  gimbalActions: [...],
  cameraActions: [...],
  aiActions: [...]
};

2.2 云台与相机控制动作

对于搭载了吊舱的无人机（如大疆 Matrice 3T/4T），云台和相机的控制是核心。这部分动作设计要特别细致，因为直接关系到数据采集质量。

云台角度控制：包括俯仰（Pitch）、偏航（Yaw）和横滚（Roll）。在 Cesium 中，通常会做一个实时预览镜头的功能。当用户设置云台角度时，界面上会同步显示一个虚拟相机的视角，模拟从这个航点看出去的实际画面。这个功能非常实用，能避免因为角度设置错误导致'拍了个寂寞'。

相机操作指令：包括单拍、连拍、录像开始/停止、变焦等。这里有个关键细节：拍照时机。是到达航点立刻拍，还是悬停稳定后再拍？通常会增加一个'延迟拍摄'参数，比如悬停后第 2 秒再触发快门，确保画面稳定。

多镜头切换：对于 M4T 这类多光吊舱，动作组需要支持镜头切换指令。比如在航点 A 用广角镜头拍全景，在航点 B 切换长焦镜头拍细节。在 Cesium 预览中，可以用不同颜色的视锥体来表示不同镜头的视野范围。

// 云台与相机动作配置示例
const gimbalCameraActions = [
  {
    trigger: 'reach_waypoint', // 触发条件：到达航点
    actions: [
      { type: 'gimbal_rotate', pitch: -90, yaw: 0, roll: 0 }, // 云台垂直向下
      { type: 'camera_switch_lens', lens: 'zoom_20x' }, // 切换到 20 倍变焦镜头
      { type: 'delay', duration: 2.0 }, // 等待 2 秒稳定
      { type: 'camera_capture', mode: 'photo_burst', count: 3, interval: 1.0 } // 连拍 3 张，间隔 1 秒
    ]
  }
];

2.3 第三方载荷控制动作

在工业级应用中，无人机可能搭载气体传感器、激光雷达、抛投器等特殊载荷。动作组需要为这些设备预留控制接口。

比如，在化工园区巡检时，可以在特定航点触发气体传感器采样，并将采样数据与地理位置、时间戳绑定。在 Cesium 中，可以用一个弹出的信息窗口来展示这些扩展的传感器数据流。设计时，建议采用插件化的架构，让不同类型的载荷可以方便地接入动作系统，通过统一的 payload_control 动作类型来分发指令。

3. 真机数据转换：从 Cesium 坐标到飞控指令

这是整个流程中最容易'踩坑'的环节。在 Cesium 里精心规划的航线，导出后发给无人机，结果飞出去发现位置偏差了几十米，或者动作根本没执行。问题往往出在数据转换上。

3.1 坐标系转换：GCJ-02 与 WGS84 的'爱恨情仇'

国内开发者基本都绕不开这个经典问题。Cesium 默认使用 WGS84 坐标系（全球 GPS 标准），而国内地图服务（如高德、百度）出于合规要求，使用的是 GCJ-02 坐标系（俗称'火星坐标'）。两者之间存在非线性偏移。

关键点：如果 Cesium 底图用高德，那么用户点击地图添加的航点，其经纬度是 GCJ-02 坐标。但大疆等无人机的飞控系统，通常要求输入 WGS84 坐标。如果不做转换，直接导出，无人机就会飞错位置。

常用解决方案是，在 Cesium 内部全程使用 GCJ-02 坐标进行存储和显示，确保地图上点的位置和用户点击位置完全一致。只在最后导出生成航线文件（如 KMZ）时，批量转换为 WGS84 坐标。这样既能保证前端体验无偏移，又能满足硬件要求。

// 坐标转换工具函数示例（使用公开算法）
import { transformGCJ02ToWGS84 } from './coordTransform';

// 航点数据内部存储（GCJ-02）
const internalWaypoint = {
  lng: 116.397128, // GCJ-02 经度
  lat: 39.916527, // GCJ-02 纬度
  alt: 150.0
};

// 导出为无人机航线时转换（WGS84）
const exportWaypoint = {
  ...internalWaypoint,
  ...transformGCJ02ToWGS84(internalWaypoint.lng, internalWaypoint.lat)
  // 输出：{ lng: 116.390703, lat: 39.913285, alt: 150.0 }
};

实测建议：一定要在目标区域用真机做一次闭环验证。规划一条简单的矩形航线，导出后导入到大疆司空 2 或类似地面站，观察地图上的位置是否准确。曾在山区项目中发现，即便转换了坐标，因为高程数据（DEM）的差异，实际飞行高度仍有偏差，后来引入了相对地形高度模式才解决。

3.2 动作指令的标准化封装

不同厂商、不同型号的无人机，对动作指令的格式要求可能不同。有的支持 MAVLink 协议，有的用自家 SDK。目标是设计一个中间表示层，将 Cesium 中定义的动作组，转换为目标硬件支持的指令集。

以生成大疆 WPML 1.0.6 标准的 KMZ 文件为例，每个航点对应的动作需要被编码到 waylines.wpml 这个 XML 文件中。一个拍照动作的转换可能如下：

// Cesium 中的动作定义
const cesiumAction = { type: 'CAMERA_SHOT', params: { duration: 1.0 } };

// 转换为 WPML 中的动作元素
const wpmlActionElement = `
  <action>
    <actionTriggerType>1</actionTriggerType> <!-- 1 代表到达航点触发 -->
    <command>
      <commandType>203</commandType> <!-- 203 代表云台控制 -->
      <gimbalPitchRotateMode>0</gimbalPitchRotateMode>
      <gimbalPitchAngle>-90.0</gimbalPitchAngle> <!-- 云台俯仰角 -->
    </command>
    <command>
      <commandType>206</commandType> <!-- 206 代表拍照 -->
      <shootPhotoTimeInterval>1.0</shootPhotoTimeInterval>
    </command>
  </action>
`;

需要根据无人机的官方协议文档，建立一套完整的动作映射表。这个过程比较繁琐，但一旦做完，就能实现'一次规划，多机执行'的灵活性。

3.3 航线文件的生成与验证

最终，需要把所有航点、动作、全局参数（如失控行为、完成动作）打包成一个航线文件。对于大疆生态，就是生成 KMZ（一个压缩包，内含 KML 和 WPML 文件）。

在生成文件后，建议增加一个'模拟验证'步骤。可以在 Cesium 中加载生成的航线，用一个无人机模型按设定速度飞行，并模拟触发动作（如显示拍照瞬间、云台转动动画）。这能提前发现一些逻辑错误，比如动作顺序不对、悬停时间不足等。

// 简单的航线模拟验证函数
async function simulateFlight(mission) {
  const droneEntity = viewer.entities.add({
    position: mission.waypoints[0].position,
    model: { uri: '/models/drone.glb' }
  });

  for (const wp of mission.waypoints) {
    // 飞行到航点
    await flyToPosition(droneEntity, wp.position, wp.speed);
    // 执行该航点所有动作
    for (const action of wp.actions) {
      await executeActionSimulation(action);
      // 例如，如果是拍照动作，在屏幕上显示一个闪光效果
      if (action.type === 'CAMERA_SHOT') {
        showCameraFlash(wp.position);
      }
    }
  }
}

4. 集成 AI 识别：为航线注入'大脑'

单纯的自动化飞行已经不够看了。现在的趋势是让无人机在飞行过程中就能实时分析，这就是 AI 识别与航线规划的深度融合。不是简单地在后端跑一个 AI 算法，而是让 AI 决策能动态影响航线。

4.1 航线分段与 AI 算法绑定

不是整个航线都需要 AI 识别。通常，只关心特定区域。在 Cesium 中，可以用绘制工具（如多边形、矩形）在航线上框选一段或多段，然后为这些航线段绑定 AI 算法。

例如，在光伏巡检中，可以为覆盖所有光伏板的航线段绑定'热斑检测'模型；在河道巡查中，为流经桥梁的航线段绑定'漂浮物识别'模型。在界面设计上，习惯用不同颜色的高亮显示来区分 AI 段和普通段，非常直观。

// 航线分段 AI 配置数据结构
const aiSegments = [
  {
    segmentId: 'segment_1',
    waypointIndexRange: [5, 12], // 绑定到第 5 到第 12 号航点之间的航段
    aiModel: 'solar_panel_defect', // 使用的 AI 模型
    confidenceThreshold: 0.7, // 置信度阈值
    actions: {
      // 触发后的动作，如标记、回传等
    }
  }
];

通过这种方式，AI 能力被无缝嵌入到飞行任务流中，实现了从'自动飞行'到'智能作业'的跨越。