Apollo-11 是我给一套探空火箭遥测系统起的开发代号。名字的寓意很简单五十多年前人类第一次登月的那次飞行把所有传感器的读数、所有链路上的信号、所有地面人员的判读整合进同一套决策流程里最终才安全着陆我做的东西规模小得多但精神是一样的——飞行器在手地面必须看得见、算得清、存得下。这里先交代清楚这个项目不是要复现登月而是把遥测数据这一件事从嵌入式传感器一路做到 Web 可视化大屏前前后后改了四版飞行失败过两次地面站抽风过无数次最后才稳定下来。这套系统最核心的价值是解决一个在模型火箭、无人机甚至小型探空平台上非常普遍但容易被低估的问题飞行器真正飞起来以后人的肉眼根本跟不上几个 g 的姿态变化无线环境也不像实验室里那么善良落地以后你还会发现现场数据记不全、事后没法复盘。Apollo-11 做的事情就是把飞行器上的关键状态以 10Hz 的频率实时搬回地面同时把 100Hz 的原始数据完整写入板载存储配合一套能回放、能看曲线、能定位问题的地面站软件让飞出去变成看得见。这篇内容适合三类人一是玩模型火箭、固定翼或者穿越机想自己搭地面站和数据链的玩家二是对 LoRa 长距离通信和嵌入式状态机感兴趣想做一个完整项目的开发者三是想练一练 Web 实时可视化、但又不想只做无关紧要 Demo 的前端同学。你会看到我踩过的坑、最终采用的方案以及那些文档里不会写、只有实测才能摸出来的细节。1. 项目概述Apollo-11 到底想解决什么问题1.1 名字背后的三条设计原则从登月任务里借鉴的不是技术参数而是三件事第一系统再复杂关键状态必须在远端可见第二链路再稳定也要有本地记录兜底第三飞行阶段要能自动识别不能全靠人盯着屏幕猜。阿波罗-11这个代号挂在项目头上就是想提醒自己别把工程做歪——所有子系统都要为这三条原则服务而不是为了炫技术。落到执行层就是三个硬性要求机载端必须能跑状态机自动切分出点火、上升、顶点、下降、着陆这些关键阶段无线电链路必须足够可靠就算丢包也要让地面知道丢了哪一段地面站必须同时干两件事实时显示和事后回放数据不能只活在内存里。这三个要求看起来简单实际做的时候会牵扯出无数细节后面每一章都会展开。1.2 要解决的三个实际问题第一个问题是距离。人站在地面飞行器几百米甚至一两公里外高度、速度、姿态全靠望远镜和猜没有任何说服力。第二个问题是记录。很多模型火箭连个简单的气压计都不带飞完就没了连到底飞了多高都说不清更别说分析故障。第三个问题是判读。就算你用某款商业飞控记录数据飞行中你也看不到实时曲线只能落地后导文件现场没有交互相应。Apollo-11 把这三个问题揉成一个链路来解机载传感器采集数据——LoRa 无线发回地面——地面站接收后转发给后端——后端存储并广播——浏览器大屏实时绘制。飞行结束后同一个数据源还可以回放复盘。这套链路里每一个环节单独拆出来都不难但串在一起以后稳定性和实时性的矛盾就出来了这也是整篇内容最想讲透的地方。1.3 项目边界和参考价值我得把话说清楚这个项目不是商业遥测设备的平替它不追求顶级精度也不追求军用级可靠性定位是够用、可复现、能学到东西。飞行器本身发射高度预期在两公里以内链路设计按开阔地两公里稳定、树林或建筑遮挡下至少三百米来算。姿态角不做磁力计融合因为模型火箭上的铁磁性零件会干扰航向参考而且对一次弹道飞行来说俯仰和横滚才是重点航向丢了不影响判读。如果你只是想抄作业后面第 2 到第 5 章有完整的架构、选型和代码思路如果你想理解为什么这么设计每一章我都会先把为什么讲清楚再给结论。这样不管你最后用不用我的选型都能拿着这套思路去判断自己方案里的取舍。2. 整体架构设计从传感器到可视化大屏2.1 系统分四段数据流只有一条把整个系统拆成四个节点按数据流方向串联机载飞行控制板、无线链路、地面接收站、后端与前端展示。机载端负责高频采样、状态判断、本地存储和无线发送无线链路负责把遥测帧从机载端送到地面地面站负责把 LoRa 信号转成上位机能认的数据后端负责解析、入库、向浏览器实时推送前端负责曲线绘制、状态展示和飞行回放。数据率的设计是这套系统能否稳定的关键。机载端内部以 100Hz 采样 IMU 和气压计但无线链路不传全量数据只按 10Hz 发送一包压缩后的关键状态帧大概 21 个字节。这样算下来链路负载只有 10 × 21 210 字节每秒换算成比特也就是不到 1.7kbps给 LoRa 留足了余量。全量 100Hz 的原始数据写进板载 SD 卡飞行结束后取卡导出这就是前面说的链路再稳定也要有本地记录兜底。2.2 为什么无线链路选 LoRa而不是 WiFi 或蓝牙这是整个方案里第一个大取舍。有人会问ESP32 自带 WiFi直接一路传到电脑不就行了问题是 WiFi 的有效距离通常在几十米到一百米左右而且穿树林能力很差飞行器一旦出了视线范围链路基本立刻断。蓝牙更短穿人体都费劲根本不在考虑范围。蜂窝网络虽然远但需要实名 SIM 卡、资费、覆盖依赖基站在野外发射场地不一定靠谱而且模块功耗也高。LoRa 是远距离低速率通信的代表技术用的是扩频调制典型接收灵敏度可以到 -140dBm 左右配合四分之一波长天线在开阔地实现一两公里甚至更远的通信并不难。它的缺点是速率低。以我最终选定的 SF8 扩频因子、125kHz 带宽为例空中速率大约 3.1kbps这个速率跑纯文本或者简单遥测帧绰绰有余但想传视频或者高密度波形就完全不行。这个特征决定了 LoRa 只适合做关键状态回传不适合做海量数据搬运所以上面才会安排板载 100Hz 全量记录 无线 10Hz 关键帧的分工。2.3 每个节点上的技术选型清单选型的时候我给自己定了一条规矩每个模块都选资料多、社区验证过、我自己手里有的零件不在这个项目里追新鲜芯片。节点选型理由机载主控STM32F103 系列定时器精准、外设丰富、文档多、裸机开发简单功耗和稳定性都有验证机载 IMUMPU6050 六轴三轴加速度计加三轴陀螺仪I2C 接口量程可调性价比高机载气压计BMP280I2C/SPI 接口气压分辨率足够静态高度跳动可控制在 ±0.3 米内无线模块SX1278 LoRa 模块433MHz 频段ISM 开放频段功率可配穿遮挡能力比 2.4G 强定位模块通用串口 GPS 模块只用于落点粗定位不参与姿态解算所以不追求高精度地面站主控ESP32自带 USB 转串口和 WiFi既能当串口桥也能扩展网络转发后端Python 异步 Web 框架解析、校验、存储、WebSocket 推送一套搞定开发效率高前端开源图表库实时曲线、温度计式高度表、状态灯做起来快且视觉够用地面站的 ESP32 多出来的 WiFi 能力在后面扩展成无线远程地面站时特别有用。只要把 ESP32 收到的遥测帧再通过 WiFi 推给局域网里的服务器地面站本体就不需要坐在电脑旁边可以把天线架到房顶。第一版我就是图省事让 ESP32 直接 USB 连电脑后来才发现这个区别在实测时被放大了好几倍。3. 核心硬件设计主控选型与传感器安装3.1 机载主控为什么选了 STM32F103机载端的第一指标不是算力而是时序确定性。姿态解算、状态机切换、SD 卡写入、LoRa 发送这些事情如果混在一个乱调度的系统里会出现各种诡异的时序抖动脉冲。STM32F103 的定时器可以做到微秒级触发中断响应稳定非常适合这类每 10ms 干一次固定活的场景。而且它的 ADC、I2C、SPI、UART 数量刚好够用不用外扩太多东西。我用的开发方式不是实时操作系统而是裸机加定时器主循环。简单解释一下主循环负责调度10ms 定时器中断里喂传感器数据100ms 定时器中断里组包发送。这样每个功能的执行频率是写死的不会因为某个模块偶尔卡顿而拖垮全局。使用实时操作系统当然也行但对这个量级的工作负载裸机反而更容易排查问题因为每一段代码什么时候跑、跑多久心里一清二楚。另一个原因是STM32F103 的参考手册、示例工程和社区讨论非常多新手照着做也不容易掉进深坑。3.2 传感器安装比选型更容易翻车硬件上我踩得最大的坑不是芯片选错而是传感器安装。MPU6050 对振动非常敏感而模型火箭点火瞬间的振动大得惊人。如果直接把传感器用螺丝刚性锁死在结构板上加速度计的读数会出现严重的噪声尖峰发射检测逻辑很容易误判。最终方案是加一块减震泡沫垫把搭载传感器的小板固定在结构上再用软排线连接主控。这个改动让加速度计的数据干净了不止一个量级。气压计 BMP280 的安装也有讲究。探空飞行器上气压计必须接触到外部大气但又不能直接暴露在气流冲刷面否则气流动压会带来额外误差。正确做法是在箭体侧面开一个静压孔用一根软管把静压引到气压计模块上模块本身密封在舱内。第一次发射我没开静压孔只是把窗口开在迎风面结果上升段气压读数明显偏低算出来的高度比实际高出好大一截。GPS 模块在模型火箭上的表现其实很一般。它冷启动时间长、动态下失锁概率高而且高度精度通常有十几米误差根本不适合做飞行高度参考。所以我只把它当成落点粗定位手段飞行中能收到几个有效点就算赚到收不到也不影响主线数据。3.3 电源和布线的三个教训第一LoRa 模块在发射瞬间电流会突然拉到 120 到 140 毫安左右如果供电回路没有足够的储能电容主控就会掉电复位。我在电源输入端并联了一个 1000 微法的电解电容再在 LoRa 模块旁边加了一个 100 微法陶瓷电容这个组合基本解决了发射瞬间的电压跌落。第二机载端一定不要用过大的线性稳压器硬抗电池电压变化大、瞬时电流要求高用 DC-DC 降压模块更稳妥。第三I2C 总线要加 4.7k 欧姆上拉电阻而且传感器和主控之间的线尽量短长线会导致波形畸变出现随机通信错误。这些看起来都是基础中的基础但真在发射现场遇到时你才会知道每一条都对应一次排查到半夜的经历。4. 嵌入式软件实现状态机、数据帧与姿态解算4.1 飞行状态机让机器自己判断飞到哪一步地面人员需要实时知道飞行器处于哪个飞行阶段这个判断不能靠人眼得靠机载端自动识别。状态机是这一节的核心。初始状态是怠速上电后持续采集传感器但什么都不做一旦检测到持续超过 4g 的加速度判为点火进入上升段上升段中高度持续增加、垂直速度为正当垂直速度由正转负并且持续若干秒时判定到达弹道顶点进入下降段最后当高度回到发射场附近并保持一段时间判为着陆。状态切换不能只看单次数据否则一个振动尖峰就误判。点火检测我用了连续 3 个采样点都超过 4g的条件采样率是 100Hz也就是 30ms 内持续超阈值才算数。顶点判断则是对气压计高度求导得到垂直速度再对这个速度做平滑滤波看它是否跨过零点。用加速度计判断顶点也可以但振动的干扰大得多气压计更稳。typedef enum { ST_IDLE 0, ST_LAUNCH, ST_ASCENT, ST_APOGEE, ST_DESCENT, ST_LANDED } flight_state_t; flight_state_t state ST_IDLE; float last_vz 0.0f; // 每 10ms 调用一次 void flight_update(float ax, float ay, float az, float alt, float vz) { float acc_norm sqrtf(ax*ax ay*ay az*az); switch (state) { case ST_IDLE: if (acc_norm 40.0f) { // 4g lauch_cnt; if (lauch_cnt 3) state ST_ASCENT; } else { lauch_cnt 0; } break; case ST_ASCENT: if (vz 0.0f last_vz 0.0f) { state ST_APOGEE; } break; case ST_APOGEE: if (vz -2.0f) state ST_DESCENT; break; case ST_DESCENT: if (fabsf(alt - ground_alt) 3.0f) { land_timer 1; if (land_timer 200) state ST_LANDED; // 持续2秒 } break; default: break; } last_vz vz; }4.2 遥测帧格式为什么不用 JSON无线速率有限JSON 这种人类可读格式在调试时很友好但一帧数据至少几百字节对 LoRa 链路来说太奢侈了。我采用的是紧凑二进制帧帧头、类型、序号、时间戳、传感器值、校验位全部按固定偏移排列。这样一帧只占 21 个字节还能保证接收端解析的时候不依赖任何字符串切分逻辑。帧格式设计有一个很容易被忽略的点序号字段。LoRa 链路本质是单向广播没有 ACK所以丢包一定会发生。接收端必须能通过序号发现中间丢了哪几包这样才能在统计上量化链路质量而不是模糊地感觉好像卡了一下。字段长度说明帧头2 字节固定 0xAA 0x55用于接收端对齐类型1 字节遥测帧 / 事件帧 / 调试帧序号1 字节0-255 循环用于丢包统计时间戳4 字节开机以来的毫秒数三轴加速度6 字节每组 int16量程 16g除以 2048 得物理值高度2 字节int16单位米带偏移垂直速度2 字节int16单位 0.1m/s电池电压1 字节单位 0.01V0-255 映射CRC162 字节对前面 19 字节做校验CRC 用最常见的 Modbus 多项式 0xA001机载端算一遍接收端算一遍不匹配直接丢。校验通过才允许数据进入后续统计和展示。接收端收到的坏帧往往比想象中多如果跳过 CRC 直接用一个位翻转就能让高度曲线出现一个极其突兀的毛刺而排查时你根本不知道它来自传感器还是通信。uint16_t crc16_modbus(uint8_t *buf, uint16_t len) { uint16_t crc 0xFFFF; for (uint16_t i 0; i len; i) { crc ^ buf[i]; for (uint8_t j 0; j 8; j) { if (crc 0x0001) { crc (crc 1) ^ 0xA001; } else { crc 1; } } } return crc; }4.3 高度解算与姿态解算的取舍高度主要由气压计提供。标准气压高度公式是 h 44330.8 × (1 - (P/P0) 的 0.190295 次方)P 是当前气压P0 是地面基准气压。升空前先采集 100 个气压值取平均作为 P0后续所有高度都相对于它计算。这样能消除传感器个体差异和海平面大气压的偏差只看相对高度。def altitude_from_pressure(p_pa, p0_pa101325.0): return 44330.8 * (1.0 - (p_pa / p0_pa) ** 0.190295)姿态角我这里用的是互补滤波而不是卡尔曼滤波。原因是卡尔曼滤波在这个项目里收益不大计算量和调参复杂度却高得多。互补滤波的思路很简单陀螺仪短时间精度高但会随时间漂移加速度计长期稳定但动态响应噪声大两者各取所长。陀螺仪积分出的角度作为主要输出加速度计算出的角度作为校正项用一个 0.95 的系数把两者融合起来。对一次几分钟的飞行来说这个精度完全够用。注意发射检测阈值不要拍脑袋写死。先在静置和手动摇晃两个场景下各采 10 分钟数据看看加速度计噪声底有多大再决定 4g 这个阈值合不合适。不同的减震安装方式会让噪声底差好几倍。5. 数据接收与可视化大屏实操5.1 后端怎么把串口变成实时数据流地面站接收端是 ESP32 加 LoRa 模块它只做一件事把收到的 LoRa 数据包通过 USB 串口原样吐给主机。主机跑一个 Python 异步后端负责串口读取、帧对齐、CRC 校验、入库和 WebSocket 推送。这样做的好处是解析逻辑集中在一个地方改帧格式只需要改一处不用在三个环境里同步维护。数据存储我选的是嵌入式数据库表结构非常简单。每条遥测记录包含序号、时间戳、三轴加速度、高度、垂直速度、电池电压和飞行状态。实时性要求高的是 WebSocket 推送历史复盘要求的是查询和导出这两个需求分开处理内存里维护一个最近 5 分钟的滑动窗口用于实时推送数据库全量保存用于事后查询。import serial import struct import asyncio SYNC_0 0xAA SYNC_1 0x55 FRAME_LEN 21 def crc16_modbus(data): crc 0xFFFF for b in data: crc ^ b for _ in range(8): if crc 0x0001: crc (crc 1) ^ 0xA001 else: crc 1 return crc def parse_stream(buf): points [] i 0 while i len(buf) - FRAME_LEN: if buf[i] SYNC_0 and buf[i1] SYNC_1: blk buf[i:iFRAME_LEN] typ, seq blk[2], blk[3] t_ms int.from_bytes(blk[4:8], little) ax, ay, az struct.unpack(3h, blk[8:14]) alt, climb struct.unpack(2h, blk[14:18]) vbat blk[18] / 100.0 crc_rx int.from_bytes(blk[19:21], little) if crc16_modbus(blk[:19]) crc_rx: points.append({ seq: seq, t_ms: t_ms, ax: ax / 2048.0, ay: ay / 2048.0, az: az / 2048.0, alt: alt, climb: climb / 10.0, vbat: vbat }) i FRAME_LEN else: i 1 return points实时推送用的是 WebSocket每解析出一帧数据就向所有连接的浏览器广播。广播频率是 10Hz浏览器端不一定需要每秒重绘 10 次我会在展示端再做一次抽稀按 4Hz 刷新图表减少绘图开销。5.2 前端大屏实时曲线与飞行回放前端最重要的是三块内容实时曲线、精确到秒的飞行状态指示、以及飞行结束后的回放模式。实时曲线我用的是开源图表库画三条曲线高度、垂直速度和合成加速度。状态指示我用几种颜色的状态灯表示当前处于哪个飞行阶段并把发射检测作为重点高亮事件突出显示。WebSocket 断开重连是现场演示最容易出丑的地方。我把重连逻辑做了退避机制断开后第一次立即重连之后每隔 1 秒、2 秒、4 秒逐步增加间隔最多不超过 10 秒。这样即使用户把电脑合盖再打开页面也能自动恢复数据流不用手动刷新。let ws null; let altSeries []; let timer null; function connect() { ws new WebSocket(ws://${location.host}/ws); ws.onmessage (event) { const msg JSON.parse(event.data); if (msg.type point) { altSeries.push([msg.t_ms, msg.alt]); if (altSeries.length 600) altSeries.shift(); if (msg.state ASCENT) setStateLight(上升, orange); } }; ws.onclose () { setTimeout(connect, Math.min(10000, backoff * 2)); }; }飞行回放模式其实不用额外做复杂的东西只要把数据库里的历史数据按时间戳重新推给前端曲线就活了。我加了一个简单的播放滑块从某个序号开始按原始时间间隔逐帧发送模拟出飞行过程。这个功能后来在复盘第二次发射失败时起了大作用——故障原因是一个插头松脱导致机载端中途重启回放曲线上时间戳直接跳了几秒一眼就看出来了。5.3 实测数据长什么样怎样才算正常第一组正常数据应该长这样发射前高度曲线在零点附近小幅抖动抖动范围在 ±0.3 米内点火瞬间合成的加速度曲线冲出一个尖锐的尖峰数值通常会到 4 到 6g动力段结束后加速度回落并在零附近波动顶点附近垂直速度从正值平滑穿过零下降段高度单调下降速率大致平稳着陆后高度回到接近地面的数值并稳定。如果曲线不是这个形态大概率不是图表代码的问题而是传感器或状态机出了问题。比如发射前高度就持续向上漂移可能是气压计基准值没取准或者静压孔被堵了一半点火尖峰没有出现可能是发射检测阈值设太高状态机根本没切到上升段顶点之后垂直速度反复穿越零可能是高度噪声太大导致求导结果抖动需要对高度数据做更强一档低通滤波。6. 常见问题与排查技巧实录6.1 无线链路丢包和误码先看天线再看速率第一次外场实测链路丢包率差不多到了 15%CRC 错帧率一度让我怀疑是不是 LoRa 模块本身有问题。排查到最后发现两个原因叠加一是接收天线直接横躺在地面上天线辐射场型被打得七零八落二是发射功率虽然开到了最大但地面站离机载端不到一百米按说不会这么差。把接收天线竖起来、架到约 1.5 米高度之后丢包率立刻降到 3% 以下。这说明 LoRa 对天线位置的敏感度远超很多人预期。天线离地太近地面吸收和反射会把信号质量搞得很糟绝对不是只要频率对就能收到那么简单。四分之一波长天线在 433MHz 频段长度大约是 17 厘米我绕了一个螺旋天线效果比鞭状天线更稳占空间也小。如果天线调整后丢包率还是高就要考虑降低速率。SF8 带宽 125kHz 的情况下把数据率进一步降到 SF10链路余量能增加接近 10dB穿透和抗遮挡能力会明显提升。代价是空中速率降低但只要遥测帧保持在 10Hz仍然绰绰有余。速率、可靠性和功耗之间的取舍永远是这类系统的核心功课。6.2 传感器数据跳变先区分来源再做滤波数据曲线出现毛刺第一反应不要急着加滤波器先确定毛刺来自传感器本身、通信链路还是处理逻辑。我用的办法是让机载端在每次开机时先往串口打印 5 秒原始传感器数据不经过任何滤波直接看。如果原始 IMU 数据本身就有周期性的尖峰方向指向减震和供电如果原始数据干净但曲线上有毛刺方向指向通信和解析。IMU 的零漂必须在升空前做一次校正。开机后采集 1000 个静止样本取平均把这个平均值作为陀螺仪零偏减掉。不做这一步姿态角会以肉眼可见的速度慢慢飘走状态机对顶点的判断也可能被干扰。滤波方面加速度计用滑动平均就够高度数据用一阶低通滤波系数根据采样率经验取 0.2 左右既压得住噪声又不会明显滞后顶点判断。6.3 地面站 USB 掉线和浏览器卡顿的幕后原因地面站 ESP32 通过 USB 连主机听起来简单但实际遇到两个问题一个是 ESP32 会被 LoRa 模块发射瞬间的射频干扰带崩现象是拔插 USB 才能恢复另一个是主机端串口读取不及时底层缓冲区溢出表现为数据突然断几秒然后连跳一大截。射频干扰的问题靠布局解决。把 LoRa 模块的天线接口放在板边让它远离 USB 座和主控晶振同时在 ESP32 的供电脚加上去耦电容PCB 背面铺连续地。串口溢出则是把 ESP32 到主机的波特率从 921600 降回 115200同时主机端把串口读取线程的等待时间调小保证及时把数据拿出来。浏览器卡顿主要是渲染线程扛不住高频刷新我最终在服务端只推 10Hz前端再降采样到 4Hz曲线依然流畅CPU 占用却降了一个台阶。6.4 排障的三个习惯比任何技巧都值钱第一个习惯是黑匣子思维板载 SD 卡的原始日志永远开着就算无线链路全断也能事后恢复完整飞行数据。第二次发射失败能定位到插头松动靠的就是 SD 卡日志里时间戳的断层。第二个习惯是分层打桩每个模块开始时都要先单独验证机载端先测传感器、再测 LoRa、再上 SD 卡地面站先测串口、再测解析、再连前端每一层都有确定的输出信号出问题时就能二分定位。第三个习惯是基线测试每次外场正式发射前先带着全部系统和寻的装置做一次短距离全流程演练不开火、不拉高只验证链路和状态机。基线跑通了再上真正有风险的飞行。这三个习惯说起来都不难难的是每次都坚持。我的体验是凡是偷懒跳过一次基线测试接下来的排查时间通常会是测试时间的十几倍。Apollo-11 做了这么多个版本最稳定的反而不是某个具体技术而是这套先验证、再上场的流程本身。做遥测这种跟飞行器安全沾边的东西流程和纪律比灵光一现重要得多。
Apollo-11 是我给一套探空火箭遥测系统起的开发代号。名字的寓意很简单五十多年前人类第一次登月的那次飞行把所有传感器的读数、所有链路上的信号、所有地面人员的判读整合进同一套决策流程里最终才安全着陆我做的东西规模小得多但精神是一样的——飞行器在手地面必须看得见、算得清、存得下。这里先交代清楚这个项目不是要复现登月而是把遥测数据这一件事从嵌入式传感器一路做到 Web 可视化大屏前前后后改了四版飞行失败过两次地面站抽风过无数次最后才稳定下来。这套系统最核心的价值是解决一个在模型火箭、无人机甚至小型探空平台上非常普遍但容易被低估的问题飞行器真正飞起来以后人的肉眼根本跟不上几个 g 的姿态变化无线环境也不像实验室里那么善良落地以后你还会发现现场数据记不全、事后没法复盘。Apollo-11 做的事情就是把飞行器上的关键状态以 10Hz 的频率实时搬回地面同时把 100Hz 的原始数据完整写入板载存储配合一套能回放、能看曲线、能定位问题的地面站软件让飞出去变成看得见。这篇内容适合三类人一是玩模型火箭、固定翼或者穿越机想自己搭地面站和数据链的玩家二是对 LoRa 长距离通信和嵌入式状态机感兴趣想做一个完整项目的开发者三是想练一练 Web 实时可视化、但又不想只做无关紧要 Demo 的前端同学。你会看到我踩过的坑、最终采用的方案以及那些文档里不会写、只有实测才能摸出来的细节。1. 项目概述Apollo-11 到底想解决什么问题1.1 名字背后的三条设计原则从登月任务里借鉴的不是技术参数而是三件事第一系统再复杂关键状态必须在远端可见第二链路再稳定也要有本地记录兜底第三飞行阶段要能自动识别不能全靠人盯着屏幕猜。阿波罗-11这个代号挂在项目头上就是想提醒自己别把工程做歪——所有子系统都要为这三条原则服务而不是为了炫技术。落到执行层就是三个硬性要求机载端必须能跑状态机自动切分出点火、上升、顶点、下降、着陆这些关键阶段无线电链路必须足够可靠就算丢包也要让地面知道丢了哪一段地面站必须同时干两件事实时显示和事后回放数据不能只活在内存里。这三个要求看起来简单实际做的时候会牵扯出无数细节后面每一章都会展开。1.2 要解决的三个实际问题第一个问题是距离。人站在地面飞行器几百米甚至一两公里外高度、速度、姿态全靠望远镜和猜没有任何说服力。第二个问题是记录。很多模型火箭连个简单的气压计都不带飞完就没了连到底飞了多高都说不清更别说分析故障。第三个问题是判读。就算你用某款商业飞控记录数据飞行中你也看不到实时曲线只能落地后导文件现场没有交互相应。Apollo-11 把这三个问题揉成一个链路来解机载传感器采集数据——LoRa 无线发回地面——地面站接收后转发给后端——后端存储并广播——浏览器大屏实时绘制。飞行结束后同一个数据源还可以回放复盘。这套链路里每一个环节单独拆出来都不难但串在一起以后稳定性和实时性的矛盾就出来了这也是整篇内容最想讲透的地方。1.3 项目边界和参考价值我得把话说清楚这个项目不是商业遥测设备的平替它不追求顶级精度也不追求军用级可靠性定位是够用、可复现、能学到东西。飞行器本身发射高度预期在两公里以内链路设计按开阔地两公里稳定、树林或建筑遮挡下至少三百米来算。姿态角不做磁力计融合因为模型火箭上的铁磁性零件会干扰航向参考而且对一次弹道飞行来说俯仰和横滚才是重点航向丢了不影响判读。如果你只是想抄作业后面第 2 到第 5 章有完整的架构、选型和代码思路如果你想理解为什么这么设计每一章我都会先把为什么讲清楚再给结论。这样不管你最后用不用我的选型都能拿着这套思路去判断自己方案里的取舍。2. 整体架构设计从传感器到可视化大屏2.1 系统分四段数据流只有一条把整个系统拆成四个节点按数据流方向串联机载飞行控制板、无线链路、地面接收站、后端与前端展示。机载端负责高频采样、状态判断、本地存储和无线发送无线链路负责把遥测帧从机载端送到地面地面站负责把 LoRa 信号转成上位机能认的数据后端负责解析、入库、向浏览器实时推送前端负责曲线绘制、状态展示和飞行回放。数据率的设计是这套系统能否稳定的关键。机载端内部以 100Hz 采样 IMU 和气压计但无线链路不传全量数据只按 10Hz 发送一包压缩后的关键状态帧大概 21 个字节。这样算下来链路负载只有 10 × 21 210 字节每秒换算成比特也就是不到 1.7kbps给 LoRa 留足了余量。全量 100Hz 的原始数据写进板载 SD 卡飞行结束后取卡导出这就是前面说的链路再稳定也要有本地记录兜底。2.2 为什么无线链路选 LoRa而不是 WiFi 或蓝牙这是整个方案里第一个大取舍。有人会问ESP32 自带 WiFi直接一路传到电脑不就行了问题是 WiFi 的有效距离通常在几十米到一百米左右而且穿树林能力很差飞行器一旦出了视线范围链路基本立刻断。蓝牙更短穿人体都费劲根本不在考虑范围。蜂窝网络虽然远但需要实名 SIM 卡、资费、覆盖依赖基站在野外发射场地不一定靠谱而且模块功耗也高。LoRa 是远距离低速率通信的代表技术用的是扩频调制典型接收灵敏度可以到 -140dBm 左右配合四分之一波长天线在开阔地实现一两公里甚至更远的通信并不难。它的缺点是速率低。以我最终选定的 SF8 扩频因子、125kHz 带宽为例空中速率大约 3.1kbps这个速率跑纯文本或者简单遥测帧绰绰有余但想传视频或者高密度波形就完全不行。这个特征决定了 LoRa 只适合做关键状态回传不适合做海量数据搬运所以上面才会安排板载 100Hz 全量记录 无线 10Hz 关键帧的分工。2.3 每个节点上的技术选型清单选型的时候我给自己定了一条规矩每个模块都选资料多、社区验证过、我自己手里有的零件不在这个项目里追新鲜芯片。节点选型理由机载主控STM32F103 系列定时器精准、外设丰富、文档多、裸机开发简单功耗和稳定性都有验证机载 IMUMPU6050 六轴三轴加速度计加三轴陀螺仪I2C 接口量程可调性价比高机载气压计BMP280I2C/SPI 接口气压分辨率足够静态高度跳动可控制在 ±0.3 米内无线模块SX1278 LoRa 模块433MHz 频段ISM 开放频段功率可配穿遮挡能力比 2.4G 强定位模块通用串口 GPS 模块只用于落点粗定位不参与姿态解算所以不追求高精度地面站主控ESP32自带 USB 转串口和 WiFi既能当串口桥也能扩展网络转发后端Python 异步 Web 框架解析、校验、存储、WebSocket 推送一套搞定开发效率高前端开源图表库实时曲线、温度计式高度表、状态灯做起来快且视觉够用地面站的 ESP32 多出来的 WiFi 能力在后面扩展成无线远程地面站时特别有用。只要把 ESP32 收到的遥测帧再通过 WiFi 推给局域网里的服务器地面站本体就不需要坐在电脑旁边可以把天线架到房顶。第一版我就是图省事让 ESP32 直接 USB 连电脑后来才发现这个区别在实测时被放大了好几倍。3. 核心硬件设计主控选型与传感器安装3.1 机载主控为什么选了 STM32F103机载端的第一指标不是算力而是时序确定性。姿态解算、状态机切换、SD 卡写入、LoRa 发送这些事情如果混在一个乱调度的系统里会出现各种诡异的时序抖动脉冲。STM32F103 的定时器可以做到微秒级触发中断响应稳定非常适合这类每 10ms 干一次固定活的场景。而且它的 ADC、I2C、SPI、UART 数量刚好够用不用外扩太多东西。我用的开发方式不是实时操作系统而是裸机加定时器主循环。简单解释一下主循环负责调度10ms 定时器中断里喂传感器数据100ms 定时器中断里组包发送。这样每个功能的执行频率是写死的不会因为某个模块偶尔卡顿而拖垮全局。使用实时操作系统当然也行但对这个量级的工作负载裸机反而更容易排查问题因为每一段代码什么时候跑、跑多久心里一清二楚。另一个原因是STM32F103 的参考手册、示例工程和社区讨论非常多新手照着做也不容易掉进深坑。3.2 传感器安装比选型更容易翻车硬件上我踩得最大的坑不是芯片选错而是传感器安装。MPU6050 对振动非常敏感而模型火箭点火瞬间的振动大得惊人。如果直接把传感器用螺丝刚性锁死在结构板上加速度计的读数会出现严重的噪声尖峰发射检测逻辑很容易误判。最终方案是加一块减震泡沫垫把搭载传感器的小板固定在结构上再用软排线连接主控。这个改动让加速度计的数据干净了不止一个量级。气压计 BMP280 的安装也有讲究。探空飞行器上气压计必须接触到外部大气但又不能直接暴露在气流冲刷面否则气流动压会带来额外误差。正确做法是在箭体侧面开一个静压孔用一根软管把静压引到气压计模块上模块本身密封在舱内。第一次发射我没开静压孔只是把窗口开在迎风面结果上升段气压读数明显偏低算出来的高度比实际高出好大一截。GPS 模块在模型火箭上的表现其实很一般。它冷启动时间长、动态下失锁概率高而且高度精度通常有十几米误差根本不适合做飞行高度参考。所以我只把它当成落点粗定位手段飞行中能收到几个有效点就算赚到收不到也不影响主线数据。3.3 电源和布线的三个教训第一LoRa 模块在发射瞬间电流会突然拉到 120 到 140 毫安左右如果供电回路没有足够的储能电容主控就会掉电复位。我在电源输入端并联了一个 1000 微法的电解电容再在 LoRa 模块旁边加了一个 100 微法陶瓷电容这个组合基本解决了发射瞬间的电压跌落。第二机载端一定不要用过大的线性稳压器硬抗电池电压变化大、瞬时电流要求高用 DC-DC 降压模块更稳妥。第三I2C 总线要加 4.7k 欧姆上拉电阻而且传感器和主控之间的线尽量短长线会导致波形畸变出现随机通信错误。这些看起来都是基础中的基础但真在发射现场遇到时你才会知道每一条都对应一次排查到半夜的经历。4. 嵌入式软件实现状态机、数据帧与姿态解算4.1 飞行状态机让机器自己判断飞到哪一步地面人员需要实时知道飞行器处于哪个飞行阶段这个判断不能靠人眼得靠机载端自动识别。状态机是这一节的核心。初始状态是怠速上电后持续采集传感器但什么都不做一旦检测到持续超过 4g 的加速度判为点火进入上升段上升段中高度持续增加、垂直速度为正当垂直速度由正转负并且持续若干秒时判定到达弹道顶点进入下降段最后当高度回到发射场附近并保持一段时间判为着陆。状态切换不能只看单次数据否则一个振动尖峰就误判。点火检测我用了连续 3 个采样点都超过 4g的条件采样率是 100Hz也就是 30ms 内持续超阈值才算数。顶点判断则是对气压计高度求导得到垂直速度再对这个速度做平滑滤波看它是否跨过零点。用加速度计判断顶点也可以但振动的干扰大得多气压计更稳。typedef enum { ST_IDLE 0, ST_LAUNCH, ST_ASCENT, ST_APOGEE, ST_DESCENT, ST_LANDED } flight_state_t; flight_state_t state ST_IDLE; float last_vz 0.0f; // 每 10ms 调用一次 void flight_update(float ax, float ay, float az, float alt, float vz) { float acc_norm sqrtf(ax*ax ay*ay az*az); switch (state) { case ST_IDLE: if (acc_norm 40.0f) { // 4g lauch_cnt; if (lauch_cnt 3) state ST_ASCENT; } else { lauch_cnt 0; } break; case ST_ASCENT: if (vz 0.0f last_vz 0.0f) { state ST_APOGEE; } break; case ST_APOGEE: if (vz -2.0f) state ST_DESCENT; break; case ST_DESCENT: if (fabsf(alt - ground_alt) 3.0f) { land_timer 1; if (land_timer 200) state ST_LANDED; // 持续2秒 } break; default: break; } last_vz vz; }4.2 遥测帧格式为什么不用 JSON无线速率有限JSON 这种人类可读格式在调试时很友好但一帧数据至少几百字节对 LoRa 链路来说太奢侈了。我采用的是紧凑二进制帧帧头、类型、序号、时间戳、传感器值、校验位全部按固定偏移排列。这样一帧只占 21 个字节还能保证接收端解析的时候不依赖任何字符串切分逻辑。帧格式设计有一个很容易被忽略的点序号字段。LoRa 链路本质是单向广播没有 ACK所以丢包一定会发生。接收端必须能通过序号发现中间丢了哪几包这样才能在统计上量化链路质量而不是模糊地感觉好像卡了一下。字段长度说明帧头2 字节固定 0xAA 0x55用于接收端对齐类型1 字节遥测帧 / 事件帧 / 调试帧序号1 字节0-255 循环用于丢包统计时间戳4 字节开机以来的毫秒数三轴加速度6 字节每组 int16量程 16g除以 2048 得物理值高度2 字节int16单位米带偏移垂直速度2 字节int16单位 0.1m/s电池电压1 字节单位 0.01V0-255 映射CRC162 字节对前面 19 字节做校验CRC 用最常见的 Modbus 多项式 0xA001机载端算一遍接收端算一遍不匹配直接丢。校验通过才允许数据进入后续统计和展示。接收端收到的坏帧往往比想象中多如果跳过 CRC 直接用一个位翻转就能让高度曲线出现一个极其突兀的毛刺而排查时你根本不知道它来自传感器还是通信。uint16_t crc16_modbus(uint8_t *buf, uint16_t len) { uint16_t crc 0xFFFF; for (uint16_t i 0; i len; i) { crc ^ buf[i]; for (uint8_t j 0; j 8; j) { if (crc 0x0001) { crc (crc 1) ^ 0xA001; } else { crc 1; } } } return crc; }4.3 高度解算与姿态解算的取舍高度主要由气压计提供。标准气压高度公式是 h 44330.8 × (1 - (P/P0) 的 0.190295 次方)P 是当前气压P0 是地面基准气压。升空前先采集 100 个气压值取平均作为 P0后续所有高度都相对于它计算。这样能消除传感器个体差异和海平面大气压的偏差只看相对高度。def altitude_from_pressure(p_pa, p0_pa101325.0): return 44330.8 * (1.0 - (p_pa / p0_pa) ** 0.190295)姿态角我这里用的是互补滤波而不是卡尔曼滤波。原因是卡尔曼滤波在这个项目里收益不大计算量和调参复杂度却高得多。互补滤波的思路很简单陀螺仪短时间精度高但会随时间漂移加速度计长期稳定但动态响应噪声大两者各取所长。陀螺仪积分出的角度作为主要输出加速度计算出的角度作为校正项用一个 0.95 的系数把两者融合起来。对一次几分钟的飞行来说这个精度完全够用。注意发射检测阈值不要拍脑袋写死。先在静置和手动摇晃两个场景下各采 10 分钟数据看看加速度计噪声底有多大再决定 4g 这个阈值合不合适。不同的减震安装方式会让噪声底差好几倍。5. 数据接收与可视化大屏实操5.1 后端怎么把串口变成实时数据流地面站接收端是 ESP32 加 LoRa 模块它只做一件事把收到的 LoRa 数据包通过 USB 串口原样吐给主机。主机跑一个 Python 异步后端负责串口读取、帧对齐、CRC 校验、入库和 WebSocket 推送。这样做的好处是解析逻辑集中在一个地方改帧格式只需要改一处不用在三个环境里同步维护。数据存储我选的是嵌入式数据库表结构非常简单。每条遥测记录包含序号、时间戳、三轴加速度、高度、垂直速度、电池电压和飞行状态。实时性要求高的是 WebSocket 推送历史复盘要求的是查询和导出这两个需求分开处理内存里维护一个最近 5 分钟的滑动窗口用于实时推送数据库全量保存用于事后查询。import serial import struct import asyncio SYNC_0 0xAA SYNC_1 0x55 FRAME_LEN 21 def crc16_modbus(data): crc 0xFFFF for b in data: crc ^ b for _ in range(8): if crc 0x0001: crc (crc 1) ^ 0xA001 else: crc 1 return crc def parse_stream(buf): points [] i 0 while i len(buf) - FRAME_LEN: if buf[i] SYNC_0 and buf[i1] SYNC_1: blk buf[i:iFRAME_LEN] typ, seq blk[2], blk[3] t_ms int.from_bytes(blk[4:8], little) ax, ay, az struct.unpack(3h, blk[8:14]) alt, climb struct.unpack(2h, blk[14:18]) vbat blk[18] / 100.0 crc_rx int.from_bytes(blk[19:21], little) if crc16_modbus(blk[:19]) crc_rx: points.append({ seq: seq, t_ms: t_ms, ax: ax / 2048.0, ay: ay / 2048.0, az: az / 2048.0, alt: alt, climb: climb / 10.0, vbat: vbat }) i FRAME_LEN else: i 1 return points实时推送用的是 WebSocket每解析出一帧数据就向所有连接的浏览器广播。广播频率是 10Hz浏览器端不一定需要每秒重绘 10 次我会在展示端再做一次抽稀按 4Hz 刷新图表减少绘图开销。5.2 前端大屏实时曲线与飞行回放前端最重要的是三块内容实时曲线、精确到秒的飞行状态指示、以及飞行结束后的回放模式。实时曲线我用的是开源图表库画三条曲线高度、垂直速度和合成加速度。状态指示我用几种颜色的状态灯表示当前处于哪个飞行阶段并把发射检测作为重点高亮事件突出显示。WebSocket 断开重连是现场演示最容易出丑的地方。我把重连逻辑做了退避机制断开后第一次立即重连之后每隔 1 秒、2 秒、4 秒逐步增加间隔最多不超过 10 秒。这样即使用户把电脑合盖再打开页面也能自动恢复数据流不用手动刷新。let ws null; let altSeries []; let timer null; function connect() { ws new WebSocket(ws://${location.host}/ws); ws.onmessage (event) { const msg JSON.parse(event.data); if (msg.type point) { altSeries.push([msg.t_ms, msg.alt]); if (altSeries.length 600) altSeries.shift(); if (msg.state ASCENT) setStateLight(上升, orange); } }; ws.onclose () { setTimeout(connect, Math.min(10000, backoff * 2)); }; }飞行回放模式其实不用额外做复杂的东西只要把数据库里的历史数据按时间戳重新推给前端曲线就活了。我加了一个简单的播放滑块从某个序号开始按原始时间间隔逐帧发送模拟出飞行过程。这个功能后来在复盘第二次发射失败时起了大作用——故障原因是一个插头松脱导致机载端中途重启回放曲线上时间戳直接跳了几秒一眼就看出来了。5.3 实测数据长什么样怎样才算正常第一组正常数据应该长这样发射前高度曲线在零点附近小幅抖动抖动范围在 ±0.3 米内点火瞬间合成的加速度曲线冲出一个尖锐的尖峰数值通常会到 4 到 6g动力段结束后加速度回落并在零附近波动顶点附近垂直速度从正值平滑穿过零下降段高度单调下降速率大致平稳着陆后高度回到接近地面的数值并稳定。如果曲线不是这个形态大概率不是图表代码的问题而是传感器或状态机出了问题。比如发射前高度就持续向上漂移可能是气压计基准值没取准或者静压孔被堵了一半点火尖峰没有出现可能是发射检测阈值设太高状态机根本没切到上升段顶点之后垂直速度反复穿越零可能是高度噪声太大导致求导结果抖动需要对高度数据做更强一档低通滤波。6. 常见问题与排查技巧实录6.1 无线链路丢包和误码先看天线再看速率第一次外场实测链路丢包率差不多到了 15%CRC 错帧率一度让我怀疑是不是 LoRa 模块本身有问题。排查到最后发现两个原因叠加一是接收天线直接横躺在地面上天线辐射场型被打得七零八落二是发射功率虽然开到了最大但地面站离机载端不到一百米按说不会这么差。把接收天线竖起来、架到约 1.5 米高度之后丢包率立刻降到 3% 以下。这说明 LoRa 对天线位置的敏感度远超很多人预期。天线离地太近地面吸收和反射会把信号质量搞得很糟绝对不是只要频率对就能收到那么简单。四分之一波长天线在 433MHz 频段长度大约是 17 厘米我绕了一个螺旋天线效果比鞭状天线更稳占空间也小。如果天线调整后丢包率还是高就要考虑降低速率。SF8 带宽 125kHz 的情况下把数据率进一步降到 SF10链路余量能增加接近 10dB穿透和抗遮挡能力会明显提升。代价是空中速率降低但只要遥测帧保持在 10Hz仍然绰绰有余。速率、可靠性和功耗之间的取舍永远是这类系统的核心功课。6.2 传感器数据跳变先区分来源再做滤波数据曲线出现毛刺第一反应不要急着加滤波器先确定毛刺来自传感器本身、通信链路还是处理逻辑。我用的办法是让机载端在每次开机时先往串口打印 5 秒原始传感器数据不经过任何滤波直接看。如果原始 IMU 数据本身就有周期性的尖峰方向指向减震和供电如果原始数据干净但曲线上有毛刺方向指向通信和解析。IMU 的零漂必须在升空前做一次校正。开机后采集 1000 个静止样本取平均把这个平均值作为陀螺仪零偏减掉。不做这一步姿态角会以肉眼可见的速度慢慢飘走状态机对顶点的判断也可能被干扰。滤波方面加速度计用滑动平均就够高度数据用一阶低通滤波系数根据采样率经验取 0.2 左右既压得住噪声又不会明显滞后顶点判断。6.3 地面站 USB 掉线和浏览器卡顿的幕后原因地面站 ESP32 通过 USB 连主机听起来简单但实际遇到两个问题一个是 ESP32 会被 LoRa 模块发射瞬间的射频干扰带崩现象是拔插 USB 才能恢复另一个是主机端串口读取不及时底层缓冲区溢出表现为数据突然断几秒然后连跳一大截。射频干扰的问题靠布局解决。把 LoRa 模块的天线接口放在板边让它远离 USB 座和主控晶振同时在 ESP32 的供电脚加上去耦电容PCB 背面铺连续地。串口溢出则是把 ESP32 到主机的波特率从 921600 降回 115200同时主机端把串口读取线程的等待时间调小保证及时把数据拿出来。浏览器卡顿主要是渲染线程扛不住高频刷新我最终在服务端只推 10Hz前端再降采样到 4Hz曲线依然流畅CPU 占用却降了一个台阶。6.4 排障的三个习惯比任何技巧都值钱第一个习惯是黑匣子思维板载 SD 卡的原始日志永远开着就算无线链路全断也能事后恢复完整飞行数据。第二次发射失败能定位到插头松动靠的就是 SD 卡日志里时间戳的断层。第二个习惯是分层打桩每个模块开始时都要先单独验证机载端先测传感器、再测 LoRa、再上 SD 卡地面站先测串口、再测解析、再连前端每一层都有确定的输出信号出问题时就能二分定位。第三个习惯是基线测试每次外场正式发射前先带着全部系统和寻的装置做一次短距离全流程演练不开火、不拉高只验证链路和状态机。基线跑通了再上真正有风险的飞行。这三个习惯说起来都不难难的是每次都坚持。我的体验是凡是偷懒跳过一次基线测试接下来的排查时间通常会是测试时间的十几倍。Apollo-11 做了这么多个版本最稳定的反而不是某个具体技术而是这套先验证、再上场的流程本身。做遥测这种跟飞行器安全沾边的东西流程和纪律比灵光一现重要得多。
