企业官网建设流程全解析

简介：MissionPlanner是一款广泛使用的开源飞控地面站软件，这份资源专门面向中国用户集成了高德地图服务，适合无人机开发者、飞手、航测与植保作业人员用于飞行任务规划、实时监控与后期数据分析。压缩包共7344个文件、约56.41MB，包含大量C#源代码（cs）、界面资源（resx）、可执行文件与动态库（exe/dll），以及png图标、xml配置、Python脚本、密钥证书等，可支撑二次开发、功能定制与地图服务调试。内容覆盖高德地图API接入、地图源切换、航点设置、飞行轨迹回放等关键环节，并附带源码级示例，能帮助读者深入理解如何将本土地图服务无缝融入MissionPlanner工作流。已有6121人学习下载，对于需要在地形复杂或城市环境中精准规划航线、提升飞行安全性的用户具有较高参考价值。

1. 把高德地图塞进 MissionPlanner：从“图源飘”到“点线对齐”

在某个飞场里，飞机 GPS 正常、姿态正常，屏幕上的飞行器图标却一直在田间小路上飘着，离真实跑道偏出几十上百米。MissionPlanner 默认的国外图源在国内加载慢、道路信息滞后，更麻烦的是它与国内定位存在坐标系差异。把高德地图接进去，是解决“图源难用”和“标注老旧”最直接的办法：高德的道路、兴趣点、卫星影像更新快，瓦片加载速度对国内网络友好。但这不只是填一个 URL 的事，MissionPlanner 默认使用 WGS-84 坐标，而高德地图使用 GCJ-02 坐标，直接切源会出现飞机位置和地面地物对不上的偏移问题。这篇文章讲一条能落地、不依赖重新编译 MissionPlanner 的路线：本地瓦片代理加坐标换算，让高德瓦片以 MissionPlanner 认识的方式被加载。适合无人机测绘、航测任务规划，以及做飞控二次开发的从业者参考。

2. MissionPlanner 的地图机制：三个坐标系是怎么把瓦片搞歪的

2.1 MissionPlanner 的地图到底是谁在画：GMap.NET 与瓦片金字塔

MissionPlanner 的地图部分并不是自己从零实现的，底层用的是 GMap.NET 这套地图控件。这套控件把所有地图都切成瓦片金字塔：缩放级别 z 决定层级，每一层由横向 x、纵向 y 的网格组成。MissionPlanner 界面里切换地图类型，本质上是给这个控件换了一个瓦片提供者，也就是“给定 z、x、y，返回一张图片”的数据源。它能显示哪些地图，取决于内置了哪些瓦片源，以及这些瓦片源的 URL 模板长什么样。

GMap.NET 对自定义地图源的支持很直接：你提供一个 URL 模板，里面用占位符表示层级和行列号，控件需要哪张瓦片就按模板拼出完整 URL 去请求。MissionPlanner 在设置界面里也保留了这样的入口，只是很多版本把这个选项藏得比较深，甚至默认没有可用的中文图源选项。常见做法是在地图类型里找“自定义”或者类似条目，把模板填进去；如果你的版本没有这个入口，就得从源码注册一个瓦片源。

这里有一个关键认知：MissionPlanner 的瓦片请求是有坐标基准的。它根据当前视窗中心点的经纬度计算应该显示哪些瓦片，这个经纬度来自飞控回传的 GPS 数据，是 WGS-84 坐标。换句话说，MissionPlanner 请求的瓦片行列号，是“WGS-84 坐标系下的 Web 墨卡托投影结果”。你的自定义地图源如果直接返回高德原始瓦片，地图按 GCJ-02 画，飞行数据按 WGS-84 画，两者基准不同，自然就“飘”了。

2.2 WGS-84、GCJ-02 与 Web 墨卡托：偏移不是地图不准，是坐标基准不同

GPS 模块输出的经纬度遵循 WGS-84 标准，这是全球卫星定位系统使用的坐标基准。而国内公开地图服务商在互联网地图上普遍使用 GCJ-02 坐标，俗称火星坐标系，高德地图也是这个基准。GCJ-02 是 WGS-84 基础上施加了一个非线性的加密偏移，偏移量不是固定常数，它会随着经纬度位置变化而变化，某些区域可能只有几十米，另一些区域能到几百米。

地图瓦片本身经过投影切割。Web 墨卡托投影把经纬度映射到平面，瓦片行列号就是这个投影平面上的网格索引。MissionPlanner 把 WGS-84 经纬度投影成屏幕坐标，高德瓦片则是在 GCJ-02 坐标基础上投影后切割的。两层叠加，误差就被放到了屏幕上：飞机实际在跑道上，图标却压在了跑道旁边的农田里。这个问题和地图分辨率无关，即使用最新卫星影像也一样飘，因为病根在坐标基准不一致。

要解决这个问题，不是给经纬度加一个固定值那么简单。正确方向是：把 MissionPlanner 请求的瓦片索引，先反算成 WGS-84 经纬度，再经过 WGS-84 到 GCJ-02 的转换，得到高德坐标系下的经纬度，最后重新计算高德瓦片索引。这样 MissionPlanner 端所有代码都不用动，它以为自己在加载普通 WGS-84 瓦片，实际拿到的却是高德坐标系下对应位置的瓦片，画面就对齐了。

2.3 两条技术路线的取舍：改源码还是本地代理

改源码路线是在 MissionPlanner 工程里新增一个高德瓦片源，把自定义瓦片源注册进去，有机会在加载瓦片时直接做坐标换算。优点是不需要额外起一个进程，图层管理更自然；缺点是你得维护自己的编译版本，MissionPlanner 版本升级时还要重新移植补丁，对不熟悉 C# 构建的开发者来说成本不低。

本地代理路线是在本机跑一个小服务，MissionPlanner 把瓦片请求发给这个服务，服务完成坐标换算、请求高德、返回图片。MissionPlanner 不需要任何修改，只要在界面里把地图源 URL 指到http://127.0.0.1:端口号即可。这条路线最大的好处是可复现、可回退，代理代码是纯 Python，换机器、换版本都可以继续用。我在大多数场景下推荐这个方案，尤其是当目标电脑上没有 Visual Studio 构建环境时。

两条路线我都实际验证过，对于只想把高德地图稳定用起来的人，本地代理是性价比最高的选择。下面的落地实现全部围绕这个方案展开。

3. 用 Python 写一个本地瓦片代理：把高德瓦片换算后喂给 MissionPlanner

3.1 代理要拆解成四步：从请求瓦片到返回图片

MissionPlanner 请求一张瓦片时，会向代理发送类似/z/x/y的 HTTP 请求。代理收到后要做四件事：第一步，把请求里的瓦片行列号反算成该瓦片覆盖的经纬度范围；第二步，把这个范围里的 WGS-84 经纬度做 GCJ-02 偏移变换；第三步，用偏移后的经纬度重新计算高德地图的瓦片行列号；第四步，用新行列号去请求高德瓦片服务，把图片字节原样返回给 MissionPlanner。

这个流程里最容易想错的一步是第三步。很多人在第一步就把高德 URL 填进去，认为“高德也是 z/x/y 瓦片，直接用就行”。问题在于 MissionPlanner 计算 z/x/y 时用的经纬度是 WGS-84，高德瓦片索引要求 GCJ-02，两个坐标系算出的行列号在放大到一定层级后明显不一致。代理的核心职责就是把这套“瓦片索引翻译”做对。

还有一个细节是经纬度换算的参考点。一张瓦片覆盖一个矩形区域，区域内的每个点偏移量都不完全一样。严格做法是对瓦片四个角分别做 GCJ-02 偏移，取偏移后的包围盒再计算目标瓦片索引。我提供的代码里先用左上角做近似，在常规规划场景下够用；如果要减少边缘误差，可以改成四角包围盒。

3.2 最小可运行代理：坐标系换算与 HTTP 转发完整代码

下面这个脚本基于 Python 标准库写成，不依赖第三方包，适合在没有安装额外依赖的电脑上直接运行。它实现了高德路网瓦片的代理转发，并带一个简单的磁盘缓存。

import http.server import os import math import urllib.request # 高德路网瓦片，style=8 表示路网样式 GAODE_SERVER = "webrd0%s.is.autonavi.com" GAODE_STYLE = 8 CACHE_DIR = "./tile_cache" # ---------- 坐标换算 ---------- def out_of_china(lng, lat): return not (73.66 < lng < 135.05 and 3.86 < lat < 53.55) def transform_lat(x, y): ret = -100.0 + 2.0 * x + 3.0 * y + 0.2 * y * y ret += 0.1 * x * y + 0.2 * math.sqrt(abs(x)) ret += (20.0 * math.sin(6.0 * x * math.pi) + 20.0 * math.sin(2.0 * x * math.pi)) * 2.0 / 3.0 ret += (20.0 * math.sin(y * math.pi) + 40.0 * math.sin(y / 3.0 * math.pi)) * 2.0 / 3.0 ret += (160.0 * math.sin(y / 12.0 * math.pi) + 320.0 * math.sin(y * math.pi / 30.0)) * 2.0 / 3.0 return ret def transform_lng(x, y): ret = 300.0 + x + 2.0 * y + 0.1 * x * x ret += 0.1 * x * y + 0.1 * math.sqrt(abs(x)) ret += (20.0 * math.sin(6.0 * x * math.pi) + 20.0 * math.sin(2.0 * x * math.pi)) * 2.0 / 3.0 ret += (20.0 * math.sin(x * math.pi) + 40.0 * math.sin(x / 3.0 * math.pi)) * 2.0 / 3.0 ret += (150.0 * math.sin(x / 12.0 * math.pi) + 300.0 * math.sin(x / 30.0 * math.pi)) * 2.0 / 3.0 return ret def wgs84_to_gcj02(lng, lat): if out_of_china(lng, lat): return lng, lat a = 6378245.0 ee = 0.006693421622965943 d_lat = transform_lat(lng - 105.0, lat - 35.0) d_lng = transform_lng(lng - 105.0, lat - 35.0) rad_lat = lat / 180.0 * math.pi magic = math.sin(rad_lat) magic = 1 - ee * magic * magic sqrt_magic = math.sqrt(magic) d_lat = (d_lat * 180.0) / ((a * (1 - ee)) / (magic * sqrt_magic) * math.pi) d_lng = (d_lng * 180.0) / (a / sqrt_magic * math.cos(rad_lat) * math.pi) return lng + d_lng, lat + d_lat # ---------- Web 墨卡托瓦片换算 ---------- def tile_to_lnglat(x, y, z): n = 2 ** z lng = x / n * 360.0 - 180.0 lat_rad = math.atan(math.sinh(math.pi * (1 - 2 * y / n))) lat = math.degrees(lat_rad) return lng, lat def lnglat_to_tile(lng, lat, z): n = 2 ** z x = (lng + 180.0) / 360.0 * n lat_rad = math.radians(lat) y = (1.0 - math.asinh(math.tan(lat_rad)) / math.pi) / 2.0 * n return int(x), int(y) # ---------- HTTP 代理 ---------- class GaodeProxy(http.server.BaseHTTPRequestHandler): def do_GET(self): parts = self.path.strip("/").split("/") if len(parts) != 3: self.send_error(404) return try: z, x, y = int(parts[0]), int(parts[1]), int(parts[2]) except ValueError: self.send_error(400) return # 1. 把 MissionPlanner 请求的 WGS-84 瓦片索引反算成经纬度 lng, lat = tile_to_lnglat(x, y, z) # 2. 转成高德的 GCJ-02 坐标 glng, glat = wgs84_to_gcj02(lng, lat) # 3. 用 GCJ-02 坐标重新算高德瓦片行列号 gx, gy = lnglat_to_tile(glng, glat, z) # 4. 拼高德 URL，第 4 个子域名用行列号选一个轮值 server_id = (gx + gy) % 4 url = ( f"https://{GAODE_SERVER % server_id}/appmaptile?" f"lang=zh_cn&size=1&scale=1&style={GAODE_STYLE}&" f"x={gx}&y={gy}&z={z}" ) body = self._load_with_cache(url) self.send_response(200) self.send_header("Content-Type", "image/jpeg") self.send_header("Content-Length", str(len(body))) self.end_headers() self.wfile.write(body) def _load_with_cache(self, url): os.makedirs(CACHE_DIR, exist_ok=True) key = str(abs(hash(url))) cache_path = os.path.join(CACHE_DIR, key + ".jpg") if os.path.exists(cache_path): with open(cache_path, "rb") as f: return f.read() req = urllib.request.Request(url, headers={ "User-Agent": "Mozilla/5.0", "Referer": "http://www.google.com/", }) with urllib.request.urlopen(req, timeout=8) as resp: body = resp.read() with open(cache_path, "wb") as f: f.write(body) return body if __name__ == "__main__": server = http.server.HTTPServer(("127.0.0.1", 8765), GaodeProxy) print("高德瓦片代理已启动，监听 127.0.0.1:8765") server.serve_forever()

这段代码的逻辑是完整的：收到 MissionPlanner 的瓦片请求后，先通过tile_to_lnglat反算经纬度，再通过wgs84_to_gcj02做火星坐标偏移，然后调用lnglat_to_tile得到高德的瓦片行列号。最后发起请求时带上了浏览器常见的 User-Agent 和 Referer，这是规避高德瓦片防盗链的常见做法。

参数说明：GAODE_STYLE控制瓦片样式，8 是普通路网，6 是卫星底图，你要是后期想切卫星影像，把这个值改成 6 就行。CACHE_DIR是代理本地缓存目录，默认放在脚本所在目录的 tile_cache 下。timeout=8控制单张瓦片请求超时时间，网络差的地方可以调大到 15，但注意过大的 timeout 会让代理线程长时间挂起。

代码里用左上角做偏移近似的效果在 z=16 以下几乎看不出问题，但到了 z=18 时瓦片边缘可能会有几米偏差。追求更严格对齐的读者可以把tile_to_lnglat换成四角包围盒版本：分别对四个角坐标做 GCJ-02 偏移，取偏移后经纬度的最小最大值，再计算目标瓦片范围。原理一样，只是多几步循环。

3.3 MissionPlanner 侧怎么接：自定义地图源 URL 模板

MissionPlanner 的自定义地图源入口在不同版本里的位置略有差异，一般在设置页的地图区域找“地图类型”下拉列表，选择带自定义字样的条目，会弹出 URL 模板编辑框。模板的占位符有两种常见写法，一种用{z}、{x}、{y}，另一种用{0}、{1}、{2}分别表示层级、横向、纵向。你只需要把代理地址填进去，比如：

http://127.0.0.1:8765/{z}/{x}/{y}

如果你的版本使用数字占位符，则对应写成http://127.0.0.1:8765/{0}/{1}/{2}，具体以你界面里的模板示例为准。填完之后把地图类型切到新添加的源，MissionPlanner 就会按模板发起瓦片请求，请求先落到本地代理，再由代理转发到高德。

如果你用的版本找不到地图类型下拉入口，说明这个自定义源功能被移到了更深的位置或者被隐藏了，需要查看对应版本的功能菜单。常见做法是在主界面右侧找地图设置面板，或者在“配置”里找地图缓存与源管理。这块每个版本布局差别较大，优先在设置面板里搜“map”或“自定义”。

3.4 启动与验证：先让代理能出图，再去调任务

写完脚本后直接在命令行启动：

python gaode_proxy.py

看到高德瓦片代理已启动说明服务正常。然后打开浏览器，直接访问一张瓦片测试地址，检验代理是否真的能返回图片：

curl -s -o /tmp/t.jpg "http://127.0.0.1:8765/15/13050/6423" && file /tmp/t.jpg

如果返回JPEG image data说明链路通了。接下来再到 MissionPlanner 里把地图源指到代理，缩放到任意层级，地图能正常刷出来就代表添加成功。这个过程最多五分钟，比重新编译 MissionPlanner 快得多。

4. 缓存、限速与离线预取：让高德瓦片在飞场也稳定加载

4.1 高德瓦片服务的“脾气”：并发限制、防盗链与层级上限

高德的瓦片服务面向网页和移动端应用设计，不会对高频瓦片抓取做特殊宽容。默认情况下，大量并发请求会触发服务端的限流，表现是连续返回 403 或者空白图片。还有一个常见现象是请求头里带明显的脚本特征、缺少浏览器标识的请求容易被拒绝，这就是防盗链机制在工作。实际用下来，代理向高德发请求的并发数控制在 2 到 4 比较安全，超过 6 之后的高德服务器响应质量会急剧下降。

层级上限也要注意。高德路网瓦片并不是所有区域都提供 19 级甚至更高层级，很多地区到 18 级就到顶了。MissionPlanner 的缩放控件没有这层限制，用户一直放大，代理请求到超过 18 级的瓦片时就拿不到有效图，界面会白屏。处理办法是代码里对 z 做一次钳制，超过上限就按上限重新计算瓦片行列号。这个限制在不同地区不完全一致，不要假设全国都是 18 级封顶。

4.2 给代理加磁盘缓存与并发信号量：第二次打开不再拉空

第三章的代码里已经包含一个最简缓存，瓦片第一次请求后落盘，第二次直接读文件。这在重复打开任务、切图、缩放时能省掉大量重复请求。实测状态下，同样的航线区域第一次跑任务时高德请求量很大，第二次开同一区域基本零请求。缓存目录里的文件名是用 URL 的 hash 生成的，代理逻辑简单，但要注意 hash 碰撞概率在小规模缓存下几乎为零，不需要额外处理。

并发信号量是防止代理把高德服务器惹毛的关键。在代理类里加一个全局信号量，每次真实请求高德前先获取信号量，拿到许可才发请求。修改方式是在文件顶部加import threading，再定义一个SEM = threading.Semaphore(3)，然后在_load_with_cache里用with SEM:包住网络请求那段。这样即使 MissionPlanner 一次性发起几十个瓦片请求，真正打到高德的也只有 3 个并发。

磁盘缓存没有过期时间，也不需要有过期时间。瓦片代表的是地面上的静态地物，道路和建筑更新周期以月甚至年为单位，规划任务的时效性远小于这个尺度。唯一要处理的是磁盘占用，一个航线区域的瓦片大概几十到几百 MB，攒多了可以定期删掉缓存目录，下次需要时重新拉取即可。

4.3 预取航线范围内的瓦片：把“在线高德”变成“本地高德”

飞场信号不稳定是常态，到了现场再在线拉瓦片容易失败。习惯做法是出发前在办公室网络环境里把任务区域的所有层级瓦片批量请求一遍，让代理缓存落盘，到了飞场 MissionPlanner 直接读缓存。预取脚本本质是两层循环，遍历 z 范围和瓦片行列范围，向代理发请求。下面是一个最小版本：

import urllib.request import time def prefetch(lat_min, lat_max, lng_min, lng_max, z_min, z_max): for z in range(z_min, z_max + 1): x_start = int((lng_min + 180.0) / 360.0 * (2 ** z)) x_end = int((lng_max + 180.0) / 360.0 * (2 ** z)) y_start = int((1.0 - math.asinh(math.tan(math.radians(lat_max))) / math.pi) / 2.0 * (2 ** z)) y_end = int((1.0 - math.asinh(math.tan(math.radians(lat_min))) / math.pi) / 2.0 * (2 ** z)) for x in range(x_start, x_end + 1): for y in range(y_start, y_end + 1): url = f"http://127.0.0.1:8765/{z}/{x}/{y}" try: urllib.request.urlopen(url, timeout=5).read() except Exception: pass time.sleep(0.05) # 控制请求节奏

预取脚本里最容易搞错的是 y 方向起点和终点的对应关系。瓦片坐标 y 轴从上往下增长，纬度越大 y 越小，所以计算范围时lat_max对应y_start，lat_min对应y_end。写反会导致预取区域跑到目标区域的对侧，白跑一趟。time.sleep(0.05)是让代理有机会把信号量释放，实测 3 并发下这个节奏能把高德请求量维持在安全区间。

5. MissionPlanner 接高德地图的 5 个常见坑：现象、原因、处理

5.1 飞机图标在道路旁边飘：偏移做了但又没完全做

现象：地图显示正常，道路、建筑都清楚，但飞机图标、航点、轨迹和地面地物对不上，整体偏移几十米甚至上百米。

原因：代理没有做坐标换算，直接把高德瓦片透传给了 MissionPlanner。MissionPlanner 计算瓦片位置用的是 WGS-84，高德瓦片是 GCJ-02 下切的，两层基准不同，偏移必然存在。还有一种情况是代理里做了转换，但把wgs84_to_gcj02误写成了gcj02_to_wgs84，方向反了，偏移量不减反增。

解决：确认代理代码里确实调用了wgs84_to_gcj02，并且结果被用于计算高德瓦片行列号。用已知点验证偏移方向，如果图标往西南偏，大概率是转换方向反了。最直接的办法是在代理里加一行日志，打印请求瓦片转换前后的经纬度。

5.2 地图放大几级之后整片灰块：并发把高德瓦片服务惹毛了

现象：前几级缩放正常，放大到 14 级以上地图开始出现大量灰块，刷新也不出来，过一阵又部分恢复。

原因：放得越大，屏幕内瓦片数量越多，代理瞬时请求量剧增。没有并发限制时，几十个请求同时打到高德，触发限流，返回的图片为空或者直接 403。

解决：给代理加threading.Semaphore，把并发限制在 3 以内。同时确认请求头带了User-Agent和Referer。灰块已经缓存进本地的情况，删掉缓存目录重试，否则代理会一直读到空数据。删除缓存路径就是脚本里CACHE_DIR指向的目录。

5.3 卫星图能看，道路标注叠不上去：MissionPlanner 不是网页地图

现象：把GAODE_STYLE改成 6 加载卫星图正常，但想叠加高德路网标注，MissionPlanner 里没有类似网页地图的透明图层开关。

原因：网页地图用两层瓦片叠合，底图是卫星影像，上层是透明路网。MissionPlanner 的瓦片源体系主要面向单层底图，没有标准的透明图层叠加机制，直接在自定义源里换一个 URL 只会整体替换，不会叠加。

解决：选择一个主力图源长期使用，不要频繁切换。日常任务规划用路网图够了，需要看地表细节时再切卫星图。如果必须叠合，可以改成在代理里同时请求两张瓦片，用图像处理库将卫星图与路网透明蒙版合成后返回，但这要求代理环境里安装额外的图像库，并且合成过程会拖慢响应，得不偿失。

5.4 19 级白屏：高德路网瓦片根本没有那么高

现象：地图放到 19 级以上，整屏空白，缩回到 18 级又正常。部分区域 18 级就已经花了，但换个城市又能到 19 级。

原因：高德瓦片服务对层级支持不统一，大部分区域路网只到 18 级，19 级请求返回的是空内容。MissionPlanner 侧没有感知这个上限，它会继续发 19 级请求。

解决：在代理里对 z 做钳制，if z > 18: z = 18，然后按 18 重新计算经纬度和瓦片行列号。这样超过上限时 MissionPlanner 拿到的是一张放大后的低层级瓦片，边缘会有拉伸模糊，但不至于白屏。同时看代理日志，如果某个 z 的值频繁被钳制，说明该区域确实不支持更高层级，任务规划时把默认缩放控制在这个层级以下。

5.5 改 hosts 之后默认地图也打不开了：万物皆有后悔药

现象：有人不想折腾自定义地图源，直接把默认图源域名通过 hosts 指向本地代理，结果 MissionPlanner 里所有地图都加载不出来，甚至启动变慢。

原因：hosts 是系统级的，不只影响 MissionPlanner 一个软件。默认图源域名被指到 127.0.0.1 后，MissionPlanner 的其他内置源同时失效，而且代理只处理高德瓦片路径，遇到默认图源路径直接返回 404。更麻烦的是部分失败响应被 GMap.NET 缓存，改回 hosts 后仍然读旧状态。

解决：hosts 方案可以快速验证思路，不建议作为长期方案。恢复方法是把 hosts 里相关行删掉，然后在 MissionPlanner 的地图缓存目录里清掉缓存数据。缓存目录的位置在不同系统不一样，Windows 下通常在用户数据目录或安装目录下，MissionPlanner 设置页里能看到路径。清完之后重启软件，默认地图源就能恢复。

6. 拿一个已知点标定高德瓦片拼接：飞行前 5 分钟的土办法

6.1 量像素算地面误差：判断代理写得对不对

代理完成后，先别急着规划航迹，花五分钟做一个标定。在飞场里找一个地面特征明显的点，比如跑道端线、机库转角或者一块颜色分明的田埂交叉点，用 RTK 或者高精度 GPS 模块测出它的 WGS-84 坐标。然后在 MissionPlanner 里以这个坐标添加一个航点，把地图缩放到任务常用的层级，观察航点图标是否落在那个地面特征上。

如果航点图标和地面特征在屏幕上差了几个像素，可以用 Web 墨卡托的像素分辨率估算误差距离。在某纬度 lat、缩放层级 z 下，每像素对应的地面距离约为156543.03392 * cos(lat) / 2^z米。假设在纬度 35 度、缩放 17 级时差了 5 个像素，误差大约是 5 乘以 0.38 米，也就是不到 2 米，这个量级在任务规划里可以接受。如果误差到了几十米，那就要回头查代理的坐标转换方向。

这个标定习惯我一直保留着。换电脑、换 MissionPlanner 版本、改代理代码之后，第一件事不是规划任务，而是先拿一个已知点验证拼接，等航点图标稳稳压在中线上才继续。坐标偏移这种问题不报错，只有视觉上能暴露出来，不标定就容易带着偏移飞出去。这个土办法省下了不少返工时间，希望帮到你。

6.2 顺手把航迹区域瓦片预取到本地

标定通过之后，用 4.3 的预取脚本把任务区域的所有层级瓦片拉一遍。脚本参数按你的任务范围填，比如中心点经纬度和边长，转换成经纬度范围后传给prefetch函数。预取完检查缓存目录大小，再断网状态下打开 MissionPlanner，地图应该能正常显示，这就是离线可用的状态。有了这层保障，到了现场即使网络信号差，规划界面也能流畅操作。

本文还有配套的精品资源，点击获取