说明文档及下载链接

一、解决检测过程中的里程大小跳动问题

1. 坐标污染分析结果

•坐标重叠污染：在测绘（Mapping）过程中，如果 GPS 信号弱导致经纬度“卡死”，之前的系统仍会按时间或虚拟位移持续记录点。这导致坐标库中出现了同一个经纬度坐标对应多个不同里程的情况（例如在 K106 附近出现了 K225204 等异常值）。
•单调性破坏：库中存在部分里程“回跳”点，即地理位置在前进，但记录的里程值却减小了，这在插值计算时会导致计算结果瞬跳。
•多线路干扰：在 -6.967 纬度附近，库中混杂了 JBHSR、JSHSR、JBSHR 三条线路的数据，且物理距离极近，极易互相干扰。

2. 代码逻辑优化

为了根治上述问题，我已完成以下代码修改并推送到主分支：
A. 优化采集逻辑（源头防污染）
•位移锁死检查：修改了 InspectorService.kt 中的 mappingLocationCallback。现在，只有当 GPS 产生超过 5 米的实际位移时，系统才会累加里程并记录坐标。这彻底杜绝了因 GPS 卡死而在原地产生大量重复/错误坐标的问题。
•精度过滤：自动忽略精度偏差大于 50 米的低质量 GPS 点，确保入库数据的可靠性。
B. 增强里程计算的健壮性
•逻辑一致性校验：在 calculateMileageValue 中增加了校验。如果检索到的两个参考点物理距离超过 1km，或者里程跨度超过 2km，系统将判定为“不连续污染数据”，放弃插值，直接取最近的有效点，防止计算出离谱的中间值。
C. 强化库清理功能
•自动去重与纠偏：升级了 MainActivity.kt 中的 autoCleanupLibrary 函数。
◦坐标去重：自动扫描并删除经纬度完全相同的冗余点。
◦单调性检查：自动删除违反“里程单调递增/递减”规律的脏数据。

3. 操作建议

代码更新后，建议您执行以下操作以清理现有污染：
1.在 App 的线路管理/坐标库页面，针对出现跳变的线路（如 JBSHR 下行），点击 [自动清理] 按钮。
2.系统会提示“已删除 XX 个污染/无效点”，这将即刻修复现有库中的大部分跳变隐患。

二、解决采集数值偏小的问题

对比仪器采集的数值，发现手机采集的数值偏小，分析代码发现了三个导致低频加速度被严重削弱的关键点：

1. TYPE_GRAVITY 的“吸峰”效应（最可能的原因）

•现象：车体摆动持续 1-2 秒，这个频率（0.5Hz - 1Hz）非常接近 Android 系统 TYPE_GRAVITY 传感器的更新频率。
•原因：Android 系统的重力传感器是软件融合的，它会认为持续较长的加速度变化是“设备倾斜”引起的。当列车缓慢侧摆时，系统重力矢量会跟着摆动方向“偏移”。
•后果：在代码中用 lx = rx - gravityValues[0]。如果摆动产生的加速度被融合进了 gravityValues，相减之后，真正的摆动分量就被扣除掉了，导致你看到的数值只有仪器的一半甚至更低。

2. 互补滤波（Alpha）的“平滑”代价

•问题：互补滤波 filtered = alpha * new + (1-alpha) * old 是低通滤波。
•分析：如果为了去噪把 alpha 设置得很小（比如 0.05），对于一个持续 2 秒的摆动，滤波器的响应可能还没达到峰值，摆动就已经结束了，这会导致严重的幅度衰减。而调大 alpha 虽然保留了幅度，但手机 MEMS 传感器特有的高频电磁噪声和轨道细碎震动又会混进来。

3. 缺乏“动静态分离”算法

•专业仪器通常使用 带通滤波 (Band-Pass Filter)。
◦高通部分 (0.1Hz)：滤除重力偏置。
◦低通部分 (5Hz - 10Hz)：滤除轨道高频噪声，保留 1-2 秒（0.5Hz）的车体晃动。

优化方案：引入“窗口均值去重力”与“两级滤波”

对 InspectorService.kt 的算法进行如下重构，以还原 1-2 秒摆动的真实强度：
1.停止依赖系统的 TYPE_GRAVITY 进行每一帧的扣除。改用长窗口（例如 5 秒）的平均值作为基准重力，这样 1-2 秒的动态摆动就不会被当作重力变化扣除。
2.引入二阶低通滤波。相比目前的互补滤波，二阶滤波能在滤除高频噪声的同时，更好地保留低频摆动的幅值。
3.增加“动感补偿”系数。

目前的算法会显著提升对“低频大位移摆动”的灵敏度。如果仍然略有偏小， 可以在 App 设置中将 caleX 和 ScaleZ 统一微调为 1.15 左右。