ThreatSourceLibaray/docs/project/develop_log.md

160 lines
8.1 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 开发日志
本文档以时间顺序, 记录了开发过程中的重要事件和分析、测试、DEBUG等过程。
日志格式:
- 日期
- 事件描述
- 分析处理
## 2025-05-12 规范了调试信息的输出
- 规范了调试信息的输出,使用 Debug 和 Trace 输出日志
- 修改了集成测试程序的菜单,增加了日志级别设置
System.Diagnostics 命名空间提供了用于日志记录的类:
- Debug.WriteLine(...):用于开发阶段,详细的内部调试信息。
- Trace.WriteLine(...):用于开发和发布阶段,跟踪应用程序的执行流程,记录重要的事件、错误或状态信息。
- Trace.TraceInformation(...):用于一般的操作信息。
- Trace.TraceWarning(...):用于潜在问题。
- Trace.TraceError(...):用于已发生的错误。
System.Diagnostics.Debug.WriteLine 和 System.Diagnostics.Trace.WriteLine 之间, 在用途和行为上有一些关键的不同:
1. 编译条件与用途:
Debug.WriteLine (以及 Debug 类的其他方法):
编译条件: 这些方法调用通常只在定义了 DEBUG 编译常量时才会被编译到程序中。在 Visual Studio 或 dotnet build 中,"Debug" 配置默认会定义 DEBUG (和 TRACE) 常量。"Release" 配置默认只定义 TRACE 常量。
用途: 主要用于开发和调试阶段。这些日志信息帮助开发者理解代码执行流程、变量状态等,通常不应出现在最终的发布版本中,因为它们可能会暴露过多内部信息或影响性能。
Trace.WriteLine (以及 Trace 类的其他方法):
编译条件: 这些方法调用通常在定义了 TRACE 编译常量时被编译。如上所述,"Debug" 和 "Release" 配置默认都会定义 TRACE。
用途: 用于跟踪应用程序的执行流程,记录重要的事件、错误或状态信息,这些信息在应用程序的发布版本中也可能是有用的。例如,记录关键操作的开始和结束,或者记录发生的异常。
总结编译与用途:
用 Debug.WriteLine 输出只在开发调试时需要看的信息。
用 Trace.WriteLine (推荐使用更具体的 Trace.TraceInformation, Trace.TraceWarning, Trace.TraceError) 输出在发布后也可能需要查看的跟踪信息。
在模拟器中,您可以设置日志级别来控制哪些日志信息会被输出。
例如,在模拟器启动时,您可以设置日志级别:
## 2025-05-09 完善了各组件的干扰功能
- 把各组件的烟幕透过率计算移到 update 方法中
- 完善了指示器的烟幕遮挡计算逻辑
- 完善了激光半主动导弹的落点计算逻辑
- 完善了配置文件格式
- 集成测试的正常运行,坦克、指示器、导弹的初始化运动参数关联很大,修改了可能会影响很多测试场景。
## 2025-05-07 完善了末敏弹各传感器的干扰功能
- 增加了烟幕弹对末敏弹的干扰功能
## 2025-04-23 增加了烟幕弹对激光目标指示器、激光驾束仪、红外测角仪的干扰处理
- 将测试用例全部通过
## 2025-04-18 改进了红外成像制导的目标识别和烟幕弹干扰算法
## 2025-04-14 增加了激光诱偏目标的干扰功能
- 增加了激光诱偏目标的干扰功能
- 把烟幕弹和激光诱偏都统一到Jammer架构中
- 修改了装备的接口把ISpectralCharacteristics接口移除
- 修改了威胁源数据管理器,增加了数据目录路径,在用户使用 dll 库时要指定DataManager 的数据目录路径
## 2025-04-10 增加了 Jammer 架构,实现了烟幕弹逻辑
## 2025-04-09 改进各导弹导弹制导系统的大气透过率计算
- 使用AtmosphereDllWrapper封装的计算函数实现了激光在大气中传输的透过率精确计算
- 添加了新的CalculateLaserTransmittance方法简化对大气透过率的计算
- 改进了接收功率计算逻辑,考虑了以下因素:
- 激光从发射器到目标的大气衰减
- 目标反射光从目标到导弹的大气衰减
- 发射系统透过率和接收系统透过率
- 激光波长对透过率的影响
- 增加了红外图像的最小像素限制
- 模拟效果改进:
- 在不同天气条件下的导引性能变化更加符合物理规律
- 远距离目标的锁定概率降低,符合实际武器系统特性
- 雾天、雨天等恶劣天气条件下制导性能降低,更加真实
## 2025-03-10 优化激光半主动导弹的制导加速度计算
- 降低了比例导引系数从 3 降至 2使最大加速度从 ±18 降低到 ±12左右
- 降低了四象限探测器的灵敏度spotOffsetSensitivity从 0.5 到 0.05
- 实现了制导加速度平滑处理机制,通过加速度历史值加权平均的方式减少突变
- 利用四象限探测器误差死区机制误差阈值0.01),当探测器误差在死区范围内时不产生制导指令
- 修改后的效果:
- 当光斑在四象限探测器中心位置时制导加速度保持为0
- 微小光斑偏移不再引起过度调整
- 制导加速度变化更加平滑,减少了能量消耗
- 导弹飞行轨迹更加稳定,飞行姿态变化更平滑
- 系统稳定性得到显著提升,特别是在瞄准目标过程中的稳定性
## 2025-03-05 修改各导弹运行中的一些 BUG修改日志的输出方式
- 修改了日志的输出方式,使用 Debug 和 Trace 输出日志
- 修改了 Vector3D 中归一化和点积的计算避免因为浮点数的精度问题导致出现NaN错误
- 将导弹自毁和爆炸的逻辑,移到导弹基类中
- 完善了集成仿真程序的逻辑,更方便进行仿真测试
## 2025-02-26 给激光半主动导弹增加四象限探测器
- 增加了四象限探测器,修改了制导方式
- 四象限最初的代码有个关键错误,聚焦后的光斑是 3mm传感器尺寸用的是镜头尺寸 10cm导致光斑总是偏离到某个象限。参考论文改为光斑直径 5mm传感器 30mm
- 四象限探测器的加速度与仿真步长有关0.025 秒 以下比较正常,加速度在 3左右
## 2025-02-25 给激光半主动导弹和激光目标指示器增加激光编码特性、四象限探测器
- 增加了 6 种激光编码方式
- 当激光编码方式和编码匹配,才能激活导引
## 2025-02-17 末敏弹的探测逻辑优化
- 优化了末敏弹的探测逻辑,完善了几个传感器的逻辑
- 优化了测试代码,完善了末敏弹的探测逻辑,完善了几个传感器的逻辑
- 测试脚本运行:在根目录运行 dotnet test
- 仿真程序运行:在 tools 目录运行 dotnet run
## 2024-01-09 视场角对目标探测高度的影响分析
在测试末敏子弹的目标探测功能时,发现视场角大小对首次探测高度有显著影响:
1. 视场角为 10° 时:
- 首次探测高度124.01米
- 扫描角度224.64°
2. 视场角为 1° 时:
- 首次探测高度93.89米
- 扫描角度224.64°
分析结论:
- 视场角越大,探测范围越大,可以在更高的高度发现目标
- 视场角越小,探测范围越小,需要更接近目标才能发现
- 两种情况下扫描角度相同224.64°),说明目标的相对方位是一致的
- 高度差约30米这个差异完全符合视场角的物理特性
这个发现对于系统设计有重要启示:
1. 视场角的选择需要权衡探测距离和精度
2. 在仿真中需要考虑视场角对探测时机的影响
3. 视场角属于固有误差,无法简单通过算法消除
## 2024-01-09 第二圈发射的径向误差分析
在分析末敏弹的打击精度时,发现当末敏弹进行第二圈螺旋扫描时会产生固定的径向误差:
1. 误差特征:
- 表现为固定的径向偏差
- 与目标的相对方位无关
- 在不同仿真条件下保持稳定
2. 误差原因分析:
- 末敏弹在第一圈扫描时记录首次探测角度
- 第二圈扫描到相同角度时触发攻击
- 由于末敏弹持续下降,第二圈时的高度低于第一圈
- 高度差导致了固定的径向误差
- 下降速度 10m/s, 扫描周期 0.25s, 高度差 2.5m,产生的径向误差是 1.44m
3. 与视场角的关系:
- 视场角影响首次探测高度
- 探测高度越高,两圈之间的高度差越大
- 因此视场角间接影响了径向误差的大小