3. 航点数据结构：数据包结构与格式解析
航点任务规划，说白了就是给无人机画一条它要走的路线。但无人机不是人，它看不懂地图上的点。它需要一种结构化的数据——航点数据包。每个航点，都是一个包含位置、行为、时间等信息的“指令包”。
我刚开始接触这个领域时，以为航点就是经纬度加高度。结果第一次试飞，无人机到了点就悬停，既不拍照也不转弯，像个木头。后来我才明白，航点数据包里的每个字段，都有它的意义。
3.1 航点数据包的核心字段
一个标准的航点数据包，通常包含以下六个核心字段。我习惯把它们分成两类：位置类和行为类。
| 字段 | 类型 | 说明 | 典型范围/示例 |
|---|---|---|---|
| 经度 (Longitude) | 浮点数 | WGS-84 坐标系，东经为正 | 116.397428 |
| 纬度 (Latitude) | 浮点数 | WGS-84 坐标系，北纬为正 | 39.90923 |
| 高度 (Altitude) | 浮点数 | 相对起飞点或海平面，单位米 | 50.0 (相对高度) |
| 速度 (Speed) | 浮点数 | 飞向下一个航点的速度，单位 m/s | 5.0 |
| 悬停时间 (Hover Time) | 整数/浮点数 | 到达该点后停留的秒数 | 3 (秒) |
| 动作指令 (Action Command) | 枚举/整数 | 到达该点后执行的动作 | 0:无动作, 1:拍照, 2:开始录像 |
关键点：高度字段最容易出问题。我见过不少新手把相对高度和绝对海拔搞混。无人机起飞后，如果使用相对高度，50米就是离起飞点50米；如果使用绝对海拔，50米就是海平面以上50米。在山区作业时，这个区别能决定你的飞机是撞山还是安全通过。
3.2 动作指令的细节
动作指令是航点数据包的“灵魂”。没有它，无人机就是个只会飞的搬运工。常见的动作指令包括：
- 0 - 无动作：仅飞过该点，不停留。
- 1 - 拍照：触发相机快门，常用于测绘。
- 2 - 开始录像：到达该点后开始录制视频。
- 3 - 停止录像：停止录制。
- 4 - 旋转云台：调整相机角度。
- 5 - 抛投：用于植保或物流无人机释放载荷。
我的习惯：在规划巡检航线时，我会在每一个需要拍摄的航点前插入一个“悬停+拍照”的组合。悬停时间设为1-2秒，确保飞机稳定后再拍照。这样拍出来的照片不会模糊，后期建模也省事。
3.3 JSON 格式解析
JSON 是目前最流行的航点数据交换格式。它轻量、易读，而且几乎所有编程语言都支持。一个典型的航点任务 JSON 文件长这样：
{
"mission": {
"name": "巡检任务-01",
"waypoints": [
{
"latitude": 39.90923,
"longitude": 116.397428,
"altitude": 50.0,
"speed": 5.0,
"hover_time": 3,
"action": 1
},
{
"latitude": 39.90950,
"longitude": 116.397800,
"altitude": 60.0,
"speed": 4.0,
"hover_time": 0,
"action": 0
}
]
}
}你看，每个航点都是一个对象，放在 waypoints 数组里。解析时，我一般会先检查 mission 根节点，然后遍历数组。嗯，这里要注意：JSON 的键名大小写敏感。有些飞控系统要求全小写，有些用驼峰。我建议统一用小写加下划线，兼容性最好。
我曾经踩过的坑：有一次，我把经纬度的顺序写反了——先写了纬度，后写了经度。结果无人机直接往反方向飞了十几公里。从那以后，我写解析代码时都会加一个校验：经度值应该在 -180 到 180 之间，纬度在 -90 到 90 之间。如果发现异常，立刻报错，绝不执行。
3.4 KML 格式解析
KML 是 Google Earth 的标记语言，基于 XML。它的优势在于可视化——你可以在 Google Earth 里直接看到航线。但说实话，KML 的解析比 JSON 麻烦一些，因为 XML 的层级结构更复杂。
一个 KML 航点文件的核心结构：
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document>
<name>巡检任务-01</name>
<Placemark>
<name>WP-001</name>
<Point>
<coordinates>116.397428,39.90923,50.0</coordinates>
</Point>
<ExtendedData>
<Data name="speed"><value>5.0</value></Data>
<Data name="hover_time"><value>3</value></Data>
<Data name="action"><value>1</value></Data>
</ExtendedData>
</Placemark>
</Document>
</kml>KML 里，经纬度和高度是放在 <coordinates> 标签里的，顺序是 经度,纬度,高度。这个顺序和 JSON 里常见的 [lat, lng] 正好相反。你想想看，如果不注意这个细节，解析出来的数据就是错的。
我的建议：如果你需要和 GIS 系统对接，KML 是首选。但如果只是做任务规划，我更喜欢 JSON。JSON 的解析速度快，而且结构清晰，不容易出错。我个人习惯在项目中同时支持两种格式，内部存储用 JSON，导出给第三方用 KML。
3.5 JSON 与 KML 的对比
| 对比维度 | JSON | KML |
|---|---|---|
| 格式基础 | 轻量级文本格式 | 基于 XML 的标记语言 |
| 可读性 | 高，结构简洁 | 中等，标签较多 |
| 解析复杂度 | 低，直接映射为对象 | 较高，需处理命名空间 |
| 可视化支持 | 需额外工具 | 原生支持 Google Earth |
| 扩展性 | 通过嵌套对象扩展 | 通过 ExtendedData 扩展 |
| 文件大小 | 较小 | 较大（含大量标签） |
3.6 航点数据包结构图
下面这张图，是我自己总结的航点数据包结构。它把位置、行为、元数据三个层次分得很清楚。每次带新人时，我都会先让他们看这张图。
3.7 实战中的格式选择
说了这么多，到底该用 JSON 还是 KML？我的经验是：
- 如果你在写地面站软件，用 JSON。解析快，调试方便。
- 如果你需要和测绘、GIS 部门协作，用 KML。他们习惯在 Google Earth 里看航线。
- 如果你在做跨平台开发，两种都支持。我一般会写一个转换器，JSON 转 KML 和 KML 转 JSON 都做。
注意：无论你选择哪种格式，一定要在代码里做好数据校验。我见过太多因为格式问题导致的炸机事故。比如，KML 里 <coordinates> 标签内的空格和换行符，有些解析器会处理不当。我的做法是：先做一次字符串清洗，去掉多余的空格和换行，再按逗号分割。
好了，航点数据包的结构和格式就讲到这里。记住，数据是任务规划的基石。格式选对了，解析写对了，后面的工作才能顺利展开。