过去要做一套无人机地面站，往往需要把前端界面、后端服务、通信协议、部署调试一项项打通：界面要设计，飞控数据要解析，指令链路要验证，最后还要部署到机载计算机或地面端设备上反复测试，传统的研发周期较长需要1年以上时间。

这次，我们以FlyCore硬件平台为例，尝试用AI开发工具参与整个开发流程，快速搭建一套无人机Web地面站Demo。它可以用于飞控数据展示、地图显示、三维坐标可视化，以及基础飞控指令交互。

对于其他无人系统来说，只要具备一定算力的处理器和稳定的网络接入能力，也可以参考这套技术路线，将Web前端、后端服务和飞控数据链路结合起来，快速验证地面站原型。

下面就从实际开发角度，梳理一下这套FlyCore Web地面站是如何搭建起来的。

01 为什么选择Web地面站？

Web地面站最大的优势，是不挑终端。

安卓平板可以用，Windows电脑可以用，遥控器上的浏览器也可以用。只要设备能打开浏览器，就能访问地面站界面。

结合FlyCore的硬件架构来看，RK3588具备本地计算能力，LQ-10可以提供飞控数据链路，MAVLink 提供标准化通信协议，再加上浏览器作为交互入口，就可以形成一套开发效率较高、调试路径清晰、后续扩展也比较方便的方案。

简单来说，Web 前端负责界面显示和交互，Python后端负责读取并处理飞控数据，RK3588负责承载服务，LQ-10 负责将飞控数据送入系统。

02 核心设计

AI 接管开发环境的网络基础

在实际开发过程中，Codex 需要能够访问FlyCore的机载计算机。常见方式主要有两种：

1. 通过LQ-10 图数传链路接入同一局域网。遥控器、地面端、路由器和RK3588处于同一网段，当路由器可以访问互联网时，云端 AI 开发工具就可以通过 SSH 或 Web 服务接入 RK3588，参与代码开发、部署和调试。

2. 直接接入FlyCore的网口。只要配置好 IP 网段，并确保 RK3588 能够访问互联网，同样可以让 AI 开发工具参与项目开发。

需要说明的是，这里的AI并不是直接控制飞控，也不是直接操作无人机飞行。它主要负责帮助开发者编写、部署和调试运行在 RK3588 上的软件。真正与飞控通信的，仍然是后端程序和 MAVLink 协议。

也就是说，AI更像是进入开发现场的工程助手，帮助工程师把代码、部署和调试流程跑起来。

03 开发前需要准备哪些材料？

用 AI 开发工程项目，最重要的不是一开始就写代码，而是先把软件架构、接口关系和交互目标描述清楚。

如果只给一句“帮我做一个地面站”，生成出来的内容很容易偏离真实需求。
但如果提前把接口、流程、架构和 UI 原型准备好，AI 就能更准确地理解项目目标，后续返工也会少很多。

本项目建议提前准备四类材料：

1. 接口代码

2. 接口文档

3. UML 流程图或系统架构图

4. Web 界面的交互 UI 原型图

接口代码

本项目的核心通信协议是MAVLink。作为无人机领域常用的通信协议，MAVLink已经具备成熟的消息结构和应用场景，AI开发工具通常能够理解其基本逻辑和常见消息类型。

不过在实际项目中，如果使用的是指定版本的 MAVLink接口代码，建议直接将相关代码提供给AI，而不是完全依赖它在线搜索。这样可以减少协议版本、字段定义或消息类型理解不一致带来的问题。

在后端解析飞控数据时，可以使用pymavlink这个 Python库。它能够读取飞控输出的MAVLink数据流，并将HEARTBEAT、GPS、姿态、电池、位置、速度等消息解析成后端程序可以直接使用的数据结构，为后续的数据展示和指令交互提供基础。

接口文档

MAVLink 的官方文档和常用示例可以作为 AI 理解飞控数据的参考资料。如果项目中对某些消息类型、坐标系、单位换算或飞控模式有特殊要求，建议在工程文档中明确写出。

例如：

1. GPS 经纬度通常来自 GLOBAL_POSITION_INT 或 GPS_RAW_INT

2. 本地位置可来自 LOCAL_POSITION_NED

3. 姿态信息可来自 ATTITUDE

4. 解锁、上锁、起飞、降落等指令通常通过 COMMAND_LONG 下发

5. 指令执行结果需要关注飞控返回的 COMMAND_ACK

6. 这些说明可以显著降低 AI 对协议理解出现偏差的概率。

UML流程图和系统架构图

本文演示的是一个相对简单的Web地面站 Demo，因此 UML流程图不需要设计得过于复杂，只要能够说明基本的前端交互、前后端数据流和飞控指令链路即可。

但如果要开发专业版本地面站，建议在正式开发前，由架构师提前梳理完整的系统流程，包括前端 Web 交互流程、前端与后端服务器的数据交互流程、飞控指令下发流程，以及异常状态下的处理逻辑。

这部分准备工作非常重要。项目越复杂，流程图就越需要细化。也可以结合一些对 AI 开发更友好的流程图或架构图工具，把关键模块、数据流向和指令关系表达清楚。这样 AI 在理解项目时会更准确，生成的代码也会更贴近实际需求，后续联调和修改成本也会更低。

交互UI原型图

前端UI原型建议使用Figma设计。相比静态截图，完整的Figma工程文件包含布局、间距、组件层级和交互关系，更有利于AI理解前端需求。

如果使用Codex辅助生成前端代码，建议将完整原型工程提供给它，而不是只提供界面截图。原型越清晰，生成的 HTML、CSS和JavaScript 代码就越接近实际需求，后续修改也会更少。

本项目的交互原型图可以在项目Gitee的README中查看。

04 架构设计

本项目采用 B/S 架构，也就是 Browser/Server 架构。

• 客户端：安卓浏览器、PC 浏览器或其他支持 Web 的终端，负责页面渲染和用户交互。

• 服务器端：运行在 RK3588 上的 Python 后端，负责托管前端页面、解析 MAVLink 数据、提供 API 接口和处理飞控指令。

• 数据链路：飞控通过串口输出 MAVLink 数据，LQ-10 将串口数据转发为 IP:Port 数据流，Python 后端通过 pymavlink 读取并解析。

当前Demo版本暂时没有引入数据库。后续如果需要飞行日志、历史轨迹、用户账号、任务配置等功能，可以在后端增加数据库模块。

更贴近本项目的架构可以描述为：

在代码实现上，前端主要由 index.html、src/*.js 和 src/styles.css 组成；后端主要由 backend.py 负责。后端默认监听 Web 服务端口 5173，MAVLink 数据默认从 UDP 8080 端口进入(LQ-10的图数传默认把飞控串口的mavlink数据流转发到该端口)。

05 UI 设计与前端交互实现

前端界面基于 Figma 原型实现，目标是在浏览器中呈现类似移动端地面站的操作体验。当前 Web 地面站主要包含以下功能区域：

• 登录与机型选择界面

• 地图展示界面

• RViz 风格三维坐标视图

• 姿态球显示

• GPS、速度、电池、飞行模式、ARM/DISARM 状态栏

• 飞控消息反馈列表

• 解锁、上锁、起飞、降落等基础交互按钮

前端并不直接解析 MAVLink 数据，而是通过 HTTP API 从后端获取已经处理好的遥测信息，再根据不同数据刷新对应界面。例如，地图模块读取 GPS 坐标，RViz 风格的三维视图读取本地位置 x/y/z，姿态球则读取 roll、pitch、yaw 和 heading 等姿态数据。

在飞控指令交互上，安全性需要重点考虑。以“一键起飞”为例，当前设计并不是用户点击按钮后立即向飞控发送起飞指令，而是先弹出滑动确认界面。只有完成滑动确认后，前端才会请求后端下发 takeoff 指令。后端收到请求后，还会继续检查 MAVLink 是否在线、飞控目标是否识别、飞机是否已经解锁，并等待飞控返回 COMMAND_ACK。

本项目的Figma原型链接可以在项目源码的README 中查看。

06 后端服务器设计

后端服务器运行在 RK3588 中，主要作用是连接飞控数据链路和 Web 前端界面。它承担三个核心任务：

• 使用 pymavlink 读取并解析 MAVLink 数据

• 将解析后的遥测数据缓存到内存中

• 通过 HTTP API 将数据提供给前端，同时接收前端控制指令

在 FlyCore 系统中，MAVLink 数据通常由飞控串口输出，再通过 LQ-10 图数传模块转发为网络数据流。实际部署时，需要在LQ-10的网络转发配置中，将飞控MAVLink数据转发到RK3588的IP地址和对应端口。

例如：

RK3588_IP:8080

后端默认配置为：

MAVLINK_URL=udpin:0.0.0.0:8080

这表示 Python 后端会在 RK3588 本机监听 UDP 8080 端口，等待LQ-10 转发过来的 MAVLink 数据流。

如果现场同时需要使用 QGC 和 Web 地面站，也可以将 LQ-10 配置为双路转发：

飞控串口  → LQ10     →QGC地面站IP     →RK3588 IP:8080

这样一来，QGC 和 Web 地面站就可以同时接收飞控数据：QGC 继续用于常规地面站操作，Web 地面站则通过 RK3588 后端读取数据并完成页面展示。

如果使用的是 LQ-10 图数传，可参考如下配置：

使用 LQ-10 图数传时，需要在转发配置中将飞控串口数据同时转发到两个 IP 地址：一个用于 QGC 地面站，另一个用于 RK3588。这样，QGC 可以正常接收飞控数据，RK3588 的 8080 端口也能同步获取 MAVLink 数据流，供后端服务器读取和解析。

如果当前图传设备不支持一对二转发，则需要单独设计网络转发方案，本文暂不展开。

整体数据流向可以理解为：

飞控串口输出MAVLink数据  →LQ10图数传移动端接收  →LQ10图数传地面端转发为IP端口数据  →Python后端通过pymavlink读取MAVLink数据流  →Python后端将数据提供给Web前端  →前端完成飞控状态展示与基础交互  

06 代码部署

部署阶段，可以让AI从Git仓库下载项目源码，并通过 SSH 远程登录 RK3588，完成代码部署、依赖安装、配置修改和服务启动等工作。部署完成后，建议将后端服务配置为系统自启动服务，这样 RK3588 开机后即可自动运行，无需手动启动。

需要注意的是，后端服务会持续读取飞控发送的 MAVLink 数据，并通过 API 提供给 Web 前端。如果后端没有正常接收到 MAVLink 数据流，即使 Web 页面能够正常打开，也无法显示实时飞控状态。因此在部署完成后，需要重点确认两项内容：

• 后端服务是否正常运行，

• RK3588 的 8080 端口是否已经收到飞控转发过来的 MAVLink 数据。

只有后端持续接收到飞控数据，Web 地面站才能正常完成遥测数据显示和飞控状态刷新。

AI远程接管机载计算机流程：

上图展示的是与 AI 的聊天过程，RK3588机载计算机默认可以通过 SSH 登录，登录地址为ssh amov@192.168.1.66，默认密码为 amov。

通过前面的操作，可以将本机公钥复制到 RK3588 中，实现免密登录。完成配置后，AI工具就可以通过 SSH/SCP 远程接入机载计算机，在 CLI 环境下进行代码部署、依赖安装、服务启动和问题排查。

这一步非常关键。它让AI不再只是停留在本地生成代码，而是能够进入真实的机载计算机环境，参与到无人机软件开发的部署和调试环节中。

以下步骤AI都能替你操作：

• 将代码上传到 RK3588，用git先clone然后上传

• 安装3588中 Python 依赖

• 配置 config.env

• 启动后端服务

• 设置 systemd 开机自启动

• 在浏览器中访问 http://RK3588_IP:5173

检查 8080 端口是否收到 MAVLink 数据

如果后端没有正常读取到 MAVLink 数据，Web 前端虽然可以打开页面，但不会显示实时飞控数据。因此部署完成后，首先要确认两件事：

• Web 服务是否在运行

• RK3588 的 8080 端口是否收到飞控 MAVLink 数据

常用检查命令：

systemctl status robosn-ground-station

ss -ulnp | grep 8080

curl http://127.0.0.1:5173/api/flight-fast

如果使用开发电脑同步代码到 3588，也可以通过脚本完成：

powershell -File sync-to-3588.ps1 -HostName 192.168.1.66 -User amov -Restart

07

浏览器访问效果

部署完成后，可以在安卓浏览器、PC 浏览器或遥控器浏览器中输入以下地址访问 FlyCore Web 地面站：

http://RK3588_IP:5173

进入页面后，系统会先显示登录或机型选择界面，随后进入飞行主界面。在主界面中，可以查看地图、三维坐标、姿态球、电池电量、GPS 卫星数量、飞行模式以及飞控反馈消息等信息。

如果飞控数据链路正常，前端页面会持续刷新飞控状态。如果页面可以正常打开，但数据没有变化，通常需要优先检查 LQ-10 是否已经将 MAVLink 数据转发到 RK3588 的 8080端口。

08 Demo 版本与专业版本

本文展示的是一个 Demo 版本 Web 地面站，主要用于验证 AI 辅助开发 FlyCore 地面站的可行性。当前版本已经具备基础遥测展示、地图定位、三维坐标显示、姿态显示和基础指令交互能力，但还不是完整的商用版本。

如果要进一步开发为专业版本地面站，还需要继续完善任务规划、航线编辑、地图缓存、飞行日志、历史轨迹、用户权限、数据库持久化、异常提示、飞控安全校验、多机管理和设备管理等功能。

不过从开发效率来看，这个 Demo 已经验证了一条更高效的开发路线：只要前期架构、接口、流程图和 UI 原型准备充分，AI 工具就可以承担大量代码生成、联调和部署工作。工程师则可以把更多精力放在系统设计、飞控安全逻辑和现场测试验证上。

部署建议

具体部署步骤可以查看项目README。实际操作时，建议通过SSH免密方式让AI远程接入RK3588，并将项目地址提供给AI，由它辅助完成Git 下载、环境配置、服务部署和问题排查。遇到部署报错或数据不显示等问题，也可以根据终端反馈继续让 AI 协助分析和修复。

09 商用专业版本案例

在Demo验证的基础上，我们也采用类似方式开发了一套商业版本Web地面站。该项目用约2个月完成，开发流程与上文类似，但在前期准备和后期调试上投入了更多时间。

如果按照传统方式开发类似地面站，通常至少需要2名工程师投入约1年时间。通过 AI 开发工具参与代码生成、部署和调试，可以明显缩短项目从原型到可用系统的周期，也进一步验证了这种开发方式在工程效率上的价值。

10 写在最后

FlyCore 的硬件架构非常适合 Web 地面站开发：RK3588 提供本地计算能力，LQ-10 提供飞控数据链路，MAVLink 提供标准化通信协议，浏览器则提供跨平台交互界面。通过 Codex 等 AI 开发工具，可以将这些模块快速组织起来，搭建出一套可运行的 Web 地面站 Demo。

这套方法不仅适用于 FlyCore，也适用于具备机载计算机、网络链路和标准飞控协议的其他无人系统。后续在此基础上继续完善数据存储、任务规划、安全控制和设备管理等模块，就可以逐步演进为面向实际应用的专业地面站系统。

本次展示的是 Demo 版本 Web 地面站，主要用于验证 AI 辅助开发无人机地面站的可行性。它已经能够完成基础数据显示和交互验证，证明这是一种效率较高的开发方式。

如果需要面向实际应用的专业版本 Web 地面站，可以联系销售工程师进一步沟通。专业版本会在Demo基础上继续完善功能细节、交互体验、飞控安全校验和实际应用场景适配，更适合直接用于商业项目。

项目 Gitee 地址：

https://gitee.com/amovlab/fly-core-web-ground

联系我们获取FlyCore更多产品信息

如果您有感兴趣的技术话题，请在留言区告诉我们！关注阿木实验室，更多技术干货不断更新！

开发遇到棘手难题可以上阿木官方论坛：

bbs.amovlab.com

有工程师亲自解答

10000+无人机开发者和你共同进步！