“滞空回线”试车数据处理平台是一个便于拓展的软件,旨在通过插件的方式处理任何硬件获取的数据,为试车的数据处理分析提供便利。
写在全文之前,感谢辰星梦人提供的火箭发动机数据,感谢小恒ovo的火箭发动机数据,感谢氢离子的推力采集卡。
本文提供
目录:
一、“滞空回线”火箭发动机试车数据解算平台简介
二、软件的获取
三、软件的使用
四、软件的二次开发
五、软件原理
六、结语
一、“滞空回线”火箭发动机试车数据解算平台简介
“滞空回线”具备以下功能:
1.通过关键词实现大多数表格形式的数据解析,对大部分表格数据友好,在解析失败的时候会自动打开高级,可以人工修改,也可以切换插件。
2.通过插件实现任意格式数据解析,当前有“T(s),Raw\n”格式的推力、室压、温度txt文件(为方便后续称其为TR_F/P/T格式,氢离子的采集卡用的是TR_F格式的,因此辰星引力的所有发动机试车数据都是TR_F格式的),按列排布的推力、室压、温度csv或xlsx文件的处理器(为方便,后续称其为表格格式,小恒ovo提供的原始文件为表格格式的),对于其他的格式的数据页可以通过简单的插件实现,具体写插件的方法已经在文件夹中了。
3.通过插件实现传感器校准,目前有压力传感器的线性校准插件。
4.通过插件实现各物理量的处理(如推力,室压,温度等,未实现的力矩,振动加速度等等也可以简单地加入),受限于我手上的数据,所以其他的暂时没有实现,但是框架已经做好了,接入很简单。
5.当前已经实现通过推力数据或者室压数据自动识别推力峰,支持手动调试。对推力页面还有线性模型补偿非水平试车时发动机自重变化引起的推力误差的功能。当前已加入推力0参考线和室压可修改参考线。
如果有坛友愿意提供试车原始数据,我会去做一下对应的插件的。2026年8月23日12:00前,在本评论区提出的记录格式、校准模型、以及其他建议,我会在2026年8月28日前加入更新。2026年8月23日12:00后的建议我也会处理,但是肯定会慢很多。
二、软件的获取
如果你只想简便地使用,这是已经打包好的程序和对应的哈希:
Underline_RETLDC_0_0_4_Windows_Portable.zip97.74MBZIP1次下载
SHA256SUMS.txt0.11KBTXT2次下载
下载后,读README或者继续看后面的教程即可。
值得说明的是,后续可能会更新,加入新内容或者修改bug,我会在下面的置顶评论发出来,但是如果想要方便,可以直接在这里下载:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
如果你打算在此基础上开发,那更建议用github:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
克隆对应版本的仓库后,读README或者继续看后面的教程即可,当前是v0.0.4,修复了v0.0.2的插件导入问题,修复了v0.0.3的GUI问题,拓展了自动识别数据格式功能,下面的使用教程是基于v0.0.4,以后更新后操作应该不会大改。大多数人用的应该是win,或者至少有win,所以就只做exe了,如果有其他系统的需要可以评论,我看到了会抽空做的。
三、软件的使用
本部分只讲基本的使用方法,不含开发。
进入页面后,是这个情况。
右上方是界面语言和主题,目前支持中文和英文,主题有浅色和深色。
我更喜欢浅色,后面以此为基础讲解。
![image.jpg]()
![image.jpg]()
文件拉选框都是字面意思,导入是导入原始数据,不限制格式,但是如果没有对应的解析器的话不能工作。导出就是导出图片,表格等,具体导出选项后面再说。工程主要是方便下次不用重复解析,不用也没问题。退出就是退出程序。
文件和工具下方的主要是快捷键,和前面的功能一样。
![image.jpg]()
工具->插件负责管理插件,单纯使用已有的插件可以不用管
工具->设置,除了界面语言和主题外,就是单位了,这些就是字面意思了,建议别改默认。然后表格导入设置就是对表格的特殊处理,也是建议别改默认。
![image.jpg]()
接下来就是正式使用了,这里先以辰星梦人的依天蓝小型发动机做示例:新年新作!依天蓝系列固体火箭发动机试车! - 科创。测试时使用了未发表的一个发动机的数据,我就不在此展示了,我希望这个发动机第一次还是由他发布。
这个测试主要用于举例txt文档等偏原始的数据的处理。bin文件等也可类似处理,只不过要新增插件。
这是原始数据,只记录了推力F,是TR_F格式的。
TEST_SD.txt82.29KBTXT1次下载
我们这里还是正式一点,点击新建工程吧,然后再导入该文件:
![image.jpg]()
可见自动识别成功。由于TR_*系列文件的格式类似,所以需要手动选择,然后点击导入并解析,可见解析成功:
![image.jpg]()
向下翻会有warning,但是这是固件记录的问题,我们忽略它。对了那个解析器配置如果有必要可以改,都是字面意思,但是一般默认就行。
这次试车只有推力通道,所以其他不用管。
现在我们填入发动机相关数据,用于制作导入openrocket的eng文件。
![image.jpg]()
然后我们要点开高级通道设置,选择线性校准,来校准本文件。TR_*格式文件是给只记录原始数据的固件准备的,所以要这一步,但是如果你的固件已经解决了,可以直接选择已经校准并把数据单位从raw修改为对应的物理单位,这里是N。本次试车使用的传感器是数据1对应0.1N。
![image.jpg]()
配置好后,就可以去后面的页面了,这里只有推力,所以只用推力即可。点击使用推力数据自动分析区间。
![image.jpg]()
这里发现该发动机推力拖尾效应比较大(当时好像受潮了),所以这里手动修一下,正好展示手动功能()只需要手动拉框即可。选好后适配区间,或者适配区间后再微调。
![image.jpg]()
这里滑到最下方,选择应用处理,补偿发动机自重变化带来的影响,这里默认是不启用的,如果需要可以启用,这里启用。不过不启用也要点一下。
![image.jpg]()
如果你发现原始数据是负的,大概是传感器线接反了,可以修改极性,如果你觉得两条曲线很难看清,可以再曲线显示中配置。
一切结束后,可以点击计算推力分析结果。
![image.jpg]()
计算完了,后面的压强和温度没有记录,可以不用管。数据浏览器一般没用,如果需要的话可以去随便看看。
![image.jpg]()
现在可以保存项目了,以后打开直接打开这个就行。
ytl.retldc.json5.82KBJSON0次下载
接下来就是导出:
![image.jpg]()
![image.jpg]()
导出语言可配置,导出选项只能导出计算过的,当前工程没有的压强和温度无法导出。PNG中标注峰值推力和总冲虽然是推力那块的,但我感觉是总体配置放最后了,这个GUI问题,看看各位的建议了。然后勾选了eng文件的话就需要填写下方的发动机信息了,这里我们前面填了,会自动搬过来。点击导出即可。
这里我只展示图了。zip在这里:
ytl_exports.zip66.59KBZIP1次下载
![thrust_curve_ZH.png]()
操作流程就结束了。以后要重新做,或者改数据的话,可以直接打开工程。
接下来展示另一个案例,小恒ovo最近的文章,其中有室压和推力的原始数据。一枚高性能固体火箭发动机设计与试车测试 - 科创
这是数据。后续了解到这份数据并不是这台发动机的试车数据,所以这里仅用他作为这个数据格式的参考。
结果.xlsx189.76KBXLSX10次下载
后续就稍微简略一点,大同小异。
新建工程,导入原始数据,可见直接根据关键词自动映射,如果识别失败或者其他需要可以手动处理,或者点高级映射,对大部分表格都是不用的,可以兼容。
![image.jpg]()
这里我们默认已经校准,就不重复做了。
由于eng文件生成前面讲了,这里数据又有缺失,所以就不瞎猜一个填写了。
直接看推力和室压(如果出现看不到可以点一下适配区间)。我个人认为用室压判断试车时间比较好,我就在室压页面做了,最终适配好区间,推力修正完,点击计算,是这样的:
![image.jpg]()
![image.jpg]()
这份数据并不是原文章的原始数据,这里仅作为格式的参考!
温度通道没有,不看了。数据浏览器可以用来看原始数据那些不在分析范围内的辅助通道,比如喷燃比:
![image.jpg]()
毕竟不是辰星引力的发动机,这个就不保存工程了,然后导出数据:
只展示图了,这是zip:
结果_exports.zip163.15KBZIP0次下载
![thrust_curve_ZH.png]()
![chamber_pressure_curve_ZH.png]()
我想只是使用的话,到这里应该就可以了,不看各种高级配置的话也没什么上手难度。总之建议用TR_*的格式或者表格,毕竟TR_*插件已经有了,对嵌入式系统要求很低,然后表格就毕竟无脑。
四、软件的二次开发
软件的二次开发主要是写插件,要改GUI的话,那不如整个给codex改了,或者把bug告诉我让我改。
本来想着这个应该写起来比较麻烦,但是我觉得开发者应该都有时间看文档,所以应该也不麻烦()先复制文档上来吧。
本平台没有太多复杂的算法,重点是作为平台可以.json配置文件和.py程序文件安装各种功能的插件。具体架构正常使用不用了解,如果感兴趣可以跟着README.txt及其中引用的各docs中的文件看。
README.txt24.08KBTXT0次下载
新增解析器_PROMPT.txt18.06KBTXT1次下载
新增校准配置_PROMPT.txt14.00KBTXT1次下载
生成这些的时候,我跟GPT要求的是,即便是豆包也能够根据文档新增插件,我粗略检查过,应该算是很详细了。
这里看一下工具->插件:
![image.jpg]()
插件默认安装在程序的插件目录,就是下载的zip,解压出来,和exe同路径的plugins,如果想装到C盘又担心权限问题可以放到用户插件目录中,即C:\Users\用户名\AppData\Roaming\Underline_RETLDC\plugins
安装插件也可以安装文件夹或者zip压缩包,不通过这个按钮的话也可以手动复制。当前plugins内的分类不影响它的使用,只是看起来有条理,只要在plugins内,不管什么子路径都没问题,限制只是系统。
安装插件的文件夹只要内部有plugin.json就行,甚至可以选择一个大文件夹,程序自己会去找。有多个plugin.json只要保证不在同一目录下或互相包含即可,这些例外条件只要正常做都不会触发。
这里把tr_t解析器剪切出来,举个例子:
选择安装文件夹,并选择对应文件夹后:
![image.jpg]()
点击确定,会出现页面显示检测到的插件:
![image.jpg]()
没有重复,直接安装即可,安装后会自动刷新:
![image.jpg]()
![image.jpg]()
接下来用tr_t.zip插件做个例子,看看安装压缩包,以及插件重复时会怎样。
选择插件zip:
![image.jpg]()
安装,和前面一样,直接看检测页面:
![image.jpg]()
可见检测出重复了,这里可以选择跳过或者替换。
五、软件原理
这个部分主要讲一下该软件的架构和一些具体部分的算法,虽然使用上几乎用不到,但是有必要的话可以看这部分查找。
软件内部采用 Project—Source—Stream—Channel 的层级组织数据。Project 对应一个试车工程;Source 对应一个导入文件;同一 Source 可以产生一个或多个 Stream,每个 Stream 保留自己的时间轴;具体物理量则以 Channel 表示。这样设计的主要目的,是避免把多文件、多采样率的数据强行重采样到同一个数组中。工程内部通过 Channel Reference 保存“主要推力”“主要燃烧室压力”等绑定关系,后续分析不直接依赖某个固定列名或固定文件格式。
数据处理链被拆分为 Parser、Calibration、Processor、Analyzer 和 Exporter。Parser 只负责把原始文件转换成结构化通道;Calibration 负责传感器标定;Processor 用于推力极性、基线或自重变化等附加处理;Analyzer 根据最终通道计算试车指标;Exporter 只负责结果输出。不同阶段相互独立,可以避免解析格式、标定方法和分析算法彼此耦合,也便于后续增加新的解析器、校准模型或分析方法。需要说明的是,这些插件的确按照以上文件夹名称分类,用程序安装插件也会进入对应文件夹,但是实际上程序会完全扫描整个插件文件夹,手动安装放错了也时能识别的。
对于 CSV、TSV 和 XLSX 等表格数据,程序先检测表头、数据起始行、时间列、单位和列语义。自动识别采用确定性规则和统计特征,不依赖大模型。时间列会综合名称、单位、单调性、重复率和采样间隔稳定性进行评分;推力、室压和温度则主要依据表头和单位识别。无法可靠分类的列保留为“其他”,例如 Kn、燃面面积和已燃肉厚等数据不会因为是数值列而被误判为温度。
校准与单位被视为两个独立概念。“已校准”只表示不再施加额外数值变换,并不意味着软件对传感器的计量准确度作出保证。线性标定采用常见的比例与零偏模型,原始数据始终保留,显示单位转换也不会改写底层数值。推力处理则按照“校准—极性—可选修正—分析”的顺序执行,新工程默认不启用额外基线修正,避免软件在用户不知情的情况下改变测量结果。
试车区间使用统一的 PRE、ACTIVE_TEST 和 POST 表示。推力与燃烧室压力页面分别使用对应的主要通道进行自动区间检测。推力页面以主要推力数据作为检测参考,燃烧室压力页面则以主要室压数据作为检测参考。当前版本的区间状态仍在工程层统一保存,因此在任一页面确认或修改区间后,其他分析页面会同步显示该区间。
推力分析以实际时间戳为基础,不假设采样周期绝对恒定。总冲通过离散数据的梯形积分得到,最大推力直接取处理后推力序列的峰值,平均推力采用总冲除以有效试车时长的时间平均定义。若用户提供推进剂质量,可进一步计算比冲。
燃烧室压力统计包括试车起始压力、工作段平均压力、峰值压力及峰值时刻。温度由于存在明显热惯性,不仅统计试车区间内的最大值,也保留全记录最大温度及其时刻。图形中的推力 0 N 线和室压参考线仅用于观察,不参与数据修正。
这里给一张GPT-image2.5生成的流程图,已人工检查,解析结果评估还是有一点字混乱,但是整体不影响:
![ChatGPT Image 2026年9月11日 23_53_26.png]()
六、结语
考虑到手上数据不够,以及个人精力有限,这个软件不管前后端都可能有bug,但是按照已有的测试,正常功能不受影响。如果有发现bug,希望加入插件,希望修改GUI的,请在下方评论。2026年8月23日12:00前的,我尽量在2026年8月28日前解决,之后的,我尽量。最新一次修改于2026年9月11日,由于笔者项目,比赛,学业压力都很爆炸
,所以很难迅速解决反馈,但是我会在收集到一定意见后,抽时间统一处理的。
希望这个平台能帮到大家。