★ FEATURED ARTICLE 简介一套基于C# Winform编写的无人机地面站软件完整源码采用GDI绘制界面适合刚接触无人机地面站开发的学习者用作入门参考。压缩包共169个文件、约15.1MB以cs源码、dll库、exe可执行程序、png图标和config配置文件为主同时含sln与csproj等工程文件可直接用Visual Studio打开编译。软件覆盖了飞行器状态显示、在线地图基于GMap可切换谷歌、高德、腾讯等图源、航线航迹绘制、飞行参数曲线图等核心模块并支持无人机航线跟踪飞行仿真方便在无硬件环境时调试上位机逻辑。代码基于C# SerialPort实现串口通信并自定义了一套简易通信协议能清晰展示上位机与飞控之间的数据交互过程对于刚入门的开发者可通过阅读源码掌握GDI绘图、GMap地图集成、曲线绘制等Winform常用技术。目前已有783人学习下载是学习无人机地面站开发一个较为轻量且完整的参考项目。1. 无人机地面站源码一套用 C# 把串口数据搬上地图的完整工程先把结论放在前面这套 UAV无人机地面站软件源码不是那种只能打开看看的“听课项目”而是一个用 C# WinForm 把串口通信、协议解析、地图航迹、仪表显示、日志回放整条链路串起来的桌面工程。某次我在现场要给一台旧设备做地面监控端没时间研究重型地面站框架就拿着这套源码当骨架三天时间把通信协议替换成自己的地图和仪表部分几乎是直接复用。如果你是在做无人机、无人船、地面机器人相关的 C# 软件/插件开发或者只是想把飞控数据顺利接到 Windows 桌面程序上这套源码正好能把“数据从串口进来到地图上出现一个移动点”的完整过程摊开给你看。需要动手改地面站的人会在这里找到比网上一堆零散代码更完整的参考坐标。2. 技术选型与整体架构跨线程消息管道是怎么搭起来的2.1 技术栈全景与选型取舍先看这套工程用了什么。地面站软件最常见的技术路线有两种一种是基于重型框架二次开发功能全但定制链路深光是搞懂它的模块调度就要花一周另一种就是这种轻量级 WinForm 方案把每个环节都摊开放在你自己眼皮底下出问题可以直接断点。从源码引用关系看核心技术栈是这么一组组合层次技术选型在工程里的职责界面层C# WinForm主窗体、仪表、按钮交互通信层System.IO.Ports.SerialPort与飞控串口收发数据协议层自定义航测协议 / 标准 MAVLink 简化版拆帧、校验、字段映射地图层GMap.NET 一类开源地图控件瓦片加载、航迹绘制、航点标注曲线层ZedGraph 一类绘图控件高度、速度、电压实时曲线日志层二进制文件 回放工具记录原始数据包离线回放调试为什么选这一套而不是上 WPF 或直接套用某个开源地面站框架我拆过不少类似工程判断一个源码可读性好不好的关键在于 UI 层是否被重型依赖绑架。这套工程的主窗体是纯 WinForm 写的没有引入体积很大的第三方 UI 库说明作者把工作重心放在数据通道和解析逻辑上这正好是二次开发者最关心的部分。地图用 GMap.NET 这类控件离线和在线瓦片都支持不需要为了一张地图去引入整套 GIS 引擎。缺点是明显的界面表现力没那么现代3D 姿态显示需要自己接 OpenGL 类库但对一个现场监控工具来说数据正确比界面华丽更重要。2.2 工程目录结构一眼看出模块边界源码的工程组织方式很清晰按职责分项目而不是把一堆窗体堆在一个程序集里。常见的模块划分大致长这样GroundStation/ ├─ GsMain/ # 主程序主窗体、串口管理、线程启动 ├─ GsProtocol/ # 协议层帧解析、校验、字段映射 ├─ GsControls/ # 自定义控件仪表盘、曲线、航点列表 ├─ GsMap/ # 地图封装瓦片加载、航迹与标注 ├─ GsLogger/ # 日志与回放原始数据落盘、离线回放 └─ SimDev/ # 模拟数据源UDP 回环模拟器无硬件也能跑这套结构里最值得学习的一点是 GsProtocol 被独立成类库UI 项目不直接引用串口对象。我一般会特别关注这样的边界如果协议解析代码和窗体事件揉在同一个文件里改动协议时界面逻辑跟着遭殃而这里把帧解析放到独立模块意味着你可以把自家的协议按相同接口替换进去主窗体几乎不用动。GsLogger 也是容易被忽视却很有用的部分。地面站软件在真机调试时不是每次都能复现问题把原始串口字节完整记录成日志文件之后用回放功能重新“喂”给解析层是排查疑难问题的后悔药。很多个人写的地面站缺的就是这一环导致现场数据丢了就再也找不回来。2.3 从串口到 UI 的链路一条可断点跟进的线程管道理解这套工程架构最核心的一条线索是数据流串口数据到达后经过多少个环节才会变成地图上的一个点。这条链路的设计直接决定软件会不会卡死、会不会丢帧。典型的事件驱动链路是这样的// 串口事件 → 原始缓冲 → 帧解析 → 数据模型 → UI 刷新 serialPort.DataReceived (s, e) { byte[] buffer new byte[serialPort.BytesToRead]; serialPort.Read(buffer, 0, buffer.Length); rawQueue.Write(buffer); // 1. 先写入字节缓冲队列 frameParser.Feed(rawQueue); // 2. 解析器按帧头拆出完整帧 }; frameParser.FrameReceived (frame) { telemetryStore.Update(frame); // 3. 单帧字段写入共享数据模型 uiSynchronizer.BeginRefresh(frame); // 4. 通过 UI 线程调度刷新界面 };这段链路设计的意图有三层。第一串口 DataReceived 事件是在后台线程触发的绝不能在里面直接改控件第二串口数据是一段连续的字节流可能一帧数据被拆成两次到达也可能一次到达多帧所以需要 rawQueue 先缓冲由解析器自行定界第三UI 刷新不逐帧硬刷而是通过 uiSynchronizer 合并最近一帧的状态避免高频率数据到达时界面不断重绘导致卡顿。把这条链路画在纸上再去读源码里的对应模块你会发现整个工程的调用关系不过如此。架构不是为了分层而分层而是让每个环节都能单独测试你可以在没有串口的情况下直接用字节数组喂给 frameParser看它能不能正确析出帧内容这就是模块边界的价值。3. 核心模块拆解串口解析、地图航迹与仪表刷新的完整实现3.1 串口接收与粘包拆包处理串口通信这块新手最容易翻车的地方是直接把整段数据 Read 出来然后按固定长度切割。实际上串口数据没有“消息边界”一帧数据可能在传输途中被拆开也可能两帧连在一起到达。这套工程里的处理方式是逐字节进队列按帧头定位积攒到足够长度再取帧。public void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { while (port.BytesToRead 0) { byte b (byte)port.ReadByte(); _buffer.Add(b); // 检查帧头帧头为 0x55 0xAA防止把噪声当数据 if (_buffer.Count 2 _buffer[0] 0x55 _buffer[1] 0xAA) { TryTakeFrame(_buffer); } else if (_buffer.Count 1 _buffer[0] ! 0x55) { _buffer.RemoveAt(0); // 丢弃非帧头字节 } } }这里有一个细节值得注意读串口用的是 ReadByte 逐字节读取而不是一次性 Read 到 byte[]。这样做的原因在于每次 DataReceived 触发时缓冲区里可能是半帧逐字节读取配合帧头判断更容易做状态切换。代价是性能上吃点亏但对地面站这个量级的遥测数据来说完全够用。TryTakeFrame 的职责是如果当前缓冲长度足够一个完整帧帧头 长度字节 数据体 校验就按长度字段切出这一帧交给上层解析同时从缓冲里移除已消费的字节如果长度不够说明这是半包保留缓冲等待下一轮数据到达。这种“字节积累 长度定界”的方式是处理粘包与半包的常见做法比任何花哨的算法都可靠。3.2 遥测帧解析与字段映射帧拿到手之后下一步是从字节数组里把姿态角、经纬度、高度、电压这些字段抠出来。这一步看起来简单实际暗藏不少玄学问题字节序不一致、分辨率比例尺对不上、符号位扩展处理错都会让你在调试器里看到一个离谱的高度值。public static TelemetryFrame ParseFrame(byte[] frame) { // 假设帧格式: 帧头2字节 序号1 字段区 校验 TelemetryFrame result new TelemetryFrame(); result.Sequence frame[2]; // 包序号: 用于检测丢包 result.Roll BitConverter.ToInt16(frame, 3) / 100.0f; // 分辨率0.01度 result.Pitch BitConverter.ToInt16(frame, 5) / 100.0f; float lat BitConverter.ToSingle(frame, 7); // 纬度 float float lon BitConverter.ToSingle(frame, 11); // 经度 float result.Latitude lat / 1e7f; // 有些协议存的是放大后的整数 result.Longitude lon / 1e7f; return result; }这段代码里的两个细节决定了解析是否正确。第一Roll 和 Pitch 用 ToInt16 读取两个字节再除以 100说明协议层把角度放大 100 倍用整型传输这样可以避免浮点数在串口传输中的精度问题第二经纬度用了 float 且除以 1e7说明发送端把经纬度乘以 1e7 转成整数。如果你的飞控协议输出的是 double 原值解析方式就得相应调整。我一般会在解析层加一个协议版本字段不同的帧类型共用同一个入口按照帧 ID 分发给不同的解析函数。这套工程里的做法是差不多的路子核心思想是解析层只负责“把字节变成结构体”不直接去碰控件。做到这一步后面无论是写日志、画曲线还是做回放所有模块都能复用同一份解析结果。3.3 GMap.NET 地图控件加载与航迹绘制地面站界面上最有感知度的部分是地图。地图控件的初始化通常放在主窗体 Load 事件里包括设置地图源、初始中心点、缩放级别以及建立航迹图层。// 初始化地图控件 mapControl.MapProvider GMapProviders.OfflineCache; // 离线瓦片模式 mapControl.Position new PointLatLng(31.2304, 121.4737); // 初始中心点 mapControl.MinZoom 3; mapControl.MaxZoom 17; mapControl.Zoom 10; // 建立航迹图层 Overlay trackOverlay new Overlay(track); mapControl.Overlays.Add(trackOverlay);航迹绘制不是直接在每次收到坐标时往地图上画一个点而是把历史坐标放进一个 GMapRoute 对象再把这个 Route 挂到 Overlay 上。这样做的道理在于地图控件本身有缩放和平移操作如果直接画在图片上每次地图移动都要重绘而且航迹和历史标注很难分层管理。用 Overlay 之后地图缩放时航迹会自动跟随对齐这也是 GMap.NET 这类控件最推荐的用法。每次收到新坐标时往 route.Points 列表里追加一个点然后调用 MapControl.Refresh 触发重绘。这个过程要注意性能如果航迹点已经积累了上千个点每次全量重绘会有肉眼可见的卡顿折中的做法是只保留最近 500~1000 个点或者降低刷新频率一秒刷新一次地图区域就足够平滑。地图显示还有一个离线与在线的选择问题。源码里默认配置是离线瓦片缓存模式这在实验室内网环境特别重要——地图数据预先放在本地目录不依赖外部网络也不会因为网络波动导致地图白屏。如果你的使用场景需要在线地图只需要把 MapProvider 切换成在线源并配置好访问密钥与代理服务器其余代码不需要改动。3.4 跨线程刷新 UI 的正确姿势与节奏控制UI 刷新是又一个高频翻车点。串口接收线程是后台线程直接访问 label.Text 或 textBox.AppendText 会抛跨线程异常或者界面间歇性卡死。这套源码里用了典型的消息调度方式把刷新动作通过 Invoke/BeginInvoke 切回 UI 线程执行。private void OnTelemetryReady(TelemetryFrame frame) { if (labelAttitude.IsDisposed) return; // 窗体已关闭则直接放弃 if (labelAttitude.InvokeRequired) { // 使用 BeginInvoke, 避免阻塞串口接收线程 labelAttitude.BeginInvoke(new ActionTelemetryFrame(OnTelemetryReady), frame); return; } labelAttitude.Text string.Format(Roll {0:0.00} Pitch {1:0.00}, frame.Roll, frame.Pitch); altitudeChart.AddValue(frame.Altitude); }这里最关键的是 BeginInvoke 和 Invoke 的选择。Invoke 是同步等待后台线程会卡在 UI 线程执行完毕才返回如果 UI 线程恰好繁忙后台线程就一直堵着串口缓冲区的数据越积越多界面看起来就“越来越卡”。BeginInvoke 是异步投递后台线程投递完消息立刻返回不会因为界面忙碌而阻塞数据接收。代价是 UI 请求可能排队但对遥测数据这种“永远是显示最新一帧”的场景完全不需要同步等待。还有一个参数值得注意判断 IsDisposed。窗体关闭时控件句柄已经销毁这时如果后台线程还往窗体投递刷新消息程序会直接崩溃。在地面站软件开发中关闭窗口后后台线程还活着是常见状态所以这个判断几乎是必写的。你也可以用一个 volatile bool isShuttingDown 标志位在关闭事件里置位双保险。4. 工程运行与避坑从编译到让地图动起来4.1 本地编译运行的完整步骤拿到源码后从打开到看到地图上的模拟航迹正常半小时内能完成。前提是你装了 Visual Studio且 NuGet 包还原网络畅通。# 用 Visual Studio 打开解决方案 GroundStation.sln # 还原 NuGet 依赖包 dotnet restore GroundStation.sln常规步骤是打开解决方案后先在“工具 → NuGet 包管理器 → 管理解决方案的 NuGet 程序包”里确认 GMap.NET、ZedGraph 等依赖包已经还原然后将启动项目设为 GsMain如果工程里有 SimDev 模拟程序先启动它生成 UDP 模拟数据最后运行 GsMain在主窗体的串口配置里填写模拟端口或选 UDP 回环模式。如果项目引用的是 .NET Framework注意目标框架要在项目属性里设置建议匹配源码作者使用的 .NET Framework 4.x 版本如果用的是 .NET 6/8 重新编译WinForm 项目需要额外处理 GMap.NET 对老版本框架的兼容性问题。我一般会先看 packages.config 或 csproj 里的引用声明确认控件版本再决定是不是要升级依赖。4.2 常见问题与排查三条高频踩坑记录坑一地图控件显示空白或黑屏。现象是程序能跑起来界面也有就是地图区域一片灰或黑。原因是 GMap.NET 的地图源没有正确初始化或者离线瓦片路径找不到。解决方法是检查 MapProvider 是否设置为 OfflineCache 且离线瓦片目录存在如果用的在线源检查网络代理是否拦截了瓦片请求。这类问题排查起来很费时间先把地图源切换成 OpenStreetMap 在线模式能显示就是瓦片路径问题还是空白就是控件初始化顺序不对。我一般会把地图初始化代码从窗体 Load 事件挪到构造函数末尾避免控件尚未创建完成就加载地图。坑二界面间歇性卡死移动窗口像幻灯片。现象是无人机数据越刷越快窗口拖动越来越卡崩溃时卡死不动。原因是后台线程高频调用 Invoke 同步刷新把 UI 线程堵死了。解决方法是把 Invoke 换成 BeginInvoke并且把刷新频率限制在 10~20 Hz。常见做法是加一个计时器定时从最新数据模型里取数刷新一次 UI而不是每一帧数据都触发一次界面更新。数据模型只保存最新状态这样即使串口 115200 波特率满载UI 也始终只按固定频率重绘性能立刻恢复。坑三解析出来的高度或经纬度数值翻倍、忽大忽小。现象是仪表显示的高度从 100 突然跳到 3000经纬度跑到海里。原因是字节序或者分辨率比例尺对不上常见的是发送端用大端序而 BitConverter 默认按小端序解析。解决方法是写一段固定测试向量的单元测试把已知的一帧字节数组喂给解析层比较输出结构体的字段值是否和约定一致。修改时统一在解析函数里做字节序转换比如把高字节和低字节交换而不是散落在各个业务代码里逐个字段改。从那以后我每次改协议都强制走一遍同样的测试向量再也不会出现现场才发现的数值漂移问题。4.3 没有飞控和无人机时怎么调试用 UDP 模拟器喂数据地面站开发最尴尬的场景是代码写好了但无人机不在手边。这套工程的聪明之处在于自带一个 SimDev 模拟数据源它通过 UDP 协议在本地回环地址上模拟飞控周期性发送遥测数据地面站本体只需要把数据通道抽象成“串口或 UDP 二选一”就能在没有真实硬件的情况下完成整个联调流程。这也意味着你可以把协议解析逻辑单独拿出来测试不用把无人机飞上天去验证代码对不对。// SimDev 模拟数据源核心逻辑: 定时发送一帧姿态位置数据 Timer sendTimer new Timer(100); // 100ms, 即10Hz 发送频率 sendTimer.Tick (s, e) { Random rand new Random(DateTime.Now.Millisecond); byte[] frame BuildFrame( seq: seq, roll: (float)(rand.NextDouble() * 20 - 10), // -10 ~ 10 度 pitch: (float)(rand.NextDouble() * 10 - 5), lat: 31.2304 rand.NextDouble() * 0.001, lon: 121.4737 rand.NextDouble() * 0.001, altitude: 50 seq % 200 ); udpClient.Send(frame, frame.Length, 127.0.0.1, 14550); };这段模拟器的核心设计是把随机数限制在合理范围内模拟飞机在某个区域小范围盘旋经纬度变化控制在万分位高度缓慢在 50 到 250 米之间爬升下降。这样地图上看到的轨迹是一条来回绕圈但不离谱的航迹方便观察地图缩放和航迹绘制效果。如果你有条件也可以把一组录制好的真实日志文件按时间戳逐帧发送效果比纯随机数真实得多这也是这套工程里日志模块配合回放功能的复用场景。5. 二次开发改造把协议层改成可插拔顺便加一个航点下发功能真正要改造一套地面站时第一个该动刀的地方是协议解析层。这套源码里解析函数直接面对具体帧格式如果你想接入自家飞控最快速的改法是把帧解析抽象成一个接口让不同协议各自实现上层业务代码完全不用感知协议差异。public interface IFrameParser { string ProtocolName { get; } bool TryParse(byte[] rawFrame, out TelemetryFrame result); byte[] BuildCommand(CommandType cmd, object[] args); // 航点、解锁、返航 }把所有协议相关的代码收敛到这个接口后面界面层只面对 TelemetryFrame 这种统一的数据模型。改动点在于新增一个协议实现类在主程序启动时按配置项选择使用哪一个解析器。这个抽象对二次开发的收益几乎是立竿见影的我第一次在自己的项目里做类似重构就是把原来散落在十几个事件里的解析逻辑收敛到一个类里之后每换一版飞控固件只改这个类就够了。在此基础上继续加一个航点下发功能就是顺理成章的事。地面站向飞控下发航点本质上是组装一帧包含目标经纬度、高度、航点序号和动作类型的指令帧然后通过串口或 UDP 发送出去。核心实现放在协议类的 BuildCommand 方法里public byte[] BuildCommand(CommandType cmd, object[] args) { if (cmd CommandType.NavTo) { int wpIndex (int)args[0]; float lat (float)args[1]; float lon (float)args[2]; float height (float)args[3]; byte[] frame new byte[22]; frame[0] 0x55; frame[1] 0xAA; // 帧头 frame[2] (byte)CommandType.NavTo; // 命令字 frame[3] (byte)wpIndex; // 航点序号 Buffer.BlockCopy(BitConverter.GetBytes(lat), 0, frame, 4, 4); Buffer.BlockCopy(BitConverter.GetBytes(lon), 0, frame, 8, 4); Buffer.BlockCopy(BitConverter.GetBytes(height), 0, frame, 12, 4); frame[21] CRC8(frame, 0, 20); // 校验字节 return frame; } return null; }对应的 UI 交互是在地图上双击设置航点再点击“上传航点”按钮把列表里的指令帧逐条发送。发送后别急着以为任务完成验证方法是根据遥测数据模型里的航点序号变化来判断是否执行成功——如果模拟器或真机返回的当前航点序号在下发后递增说明通讯链路通、解析正确整个改造闭环就落成了。这类工程最容易的误区是拿到源码就埋头改界面先把协议解析层抽出来等于先给整辆车换了发动机后续加什么功能都顺手。我这几年拆过的源码里凡是能快速二次开发的几乎都是这种“接口干净、链路清楚”的结构那些把串口、解析、界面揉在一个文件里的工程最终都逃不过推倒重写的命运。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
