学习路线与能力缺口
目标不是收集更多技术名词，而是把已有的工程能力升级为稳定、可解释、可复用的个人能力体系。
总体目标
未来的核心发展方向：
以飞行器和机器人为主要载体，发展自主导航、环境感知、系统控制和机器智能能力，同时保留硬件实现与完整系统交付优势。
希望最终具备的能力是：
- 能搭建可靠的飞行器或机器人硬件平台
- 能理解传感器数据如何产生、传输和变换
- 能完成定位、建图、规划和控制系统集成
- 能判断现有算法是否适合项目
- 能修改关键模块，而不只是运行现有功能包
- 能通过实验发现问题并形成科研成果
- 能把过程沉淀为代码、数据、文档和可复现实验
学习原则
需要真正掌握的部分
这些内容直接决定飞行器和机器人系统是否可靠，需要逐渐摆脱对AI和模板的完全依赖：
- 坐标系和坐标变换
- 传感器采样、时间同步和标定
- PID与串级控制
- 状态空间基础
- 状态估计和卡尔曼滤波
- 飞行器运动学与动力学
- ROS通信和TF
- 定位、规划与控制之间的数据流
- C/C++工程阅读和调试
- Linux、Git和日志分析
可以优先复用成熟方案的部分
这些内容不必为了证明能力而重复造轮子，但需要理解接口、限制和故障模式：
- MCU厂商驱动库
- 常见传感器驱动
- ArduPilot、Betaflight等成熟飞控
- Fast-LIO等成熟SLAM方案
- ROS现成功能包
- YOLO等成熟视觉模型
- Docker、Caddy和常用服务器组件
可以交给AI提高效率的部分
- 重复性代码
- 配置文件
- 基础页面
- 部署脚本
- 文档初稿
- 日志初步分析
- 不熟悉库的示例程序
- 格式转换和数据整理
AI生成的内容必须经过编译、运行、数据检查或实际硬件测试，不能以“代码看起来正确”作为完成标准。
优先级地图
| 优先级 | 方向 | 原因 |
|---|---|---|
| P0 | 控制、状态估计和坐标系统 | 是飞行器自主能力的基础 |
| P0 | ROS、传感器数据流与SLAM工程 | 是进入机器人和自主导航方向的入口 |
| P0 | C++、Python、Linux和Git | 决定能否维护越来越复杂的软件系统 |
| P1 | 点云处理与路径规划 | 与现有雷达、SLAM和专利经历直接相关 |
| P1 | PCB、电源与硬件可靠性 | 能将硬件强项从装配提升到原创设计 |
| P1 | 实验设计和数据分析 | 决定项目能否转化为研究成果 |
| P2 | Web、数据库与个人服务器 | 作为工具链学习，不作为当前主要研究方向 |
| P2 | 深度学习训练 | 根据具体科研问题按需学习，不盲目展开 |
| P2 | 家庭网络与影音系统 | 作为兴趣和基础设施持续维护 |
第一阶段：整理已有能力
目标
把过去“做成过”的东西转化为可复用知识，避免每次重新查找和重新踩坑。
需要完成
- 为主要项目建立独立记录
- 整理常用STM32外设模板
- 整理飞行器装机和首飞检查表
- 整理常见故障排查树
- 保存常用传感器资料和接线方式
- 建立Git代码仓库
- 给项目补充硬件照片、系统框图和关键代码
- 明确每个项目中独立完成与协助完成的部分
完成标准
不依赖记忆，能够从知识库中快速找到：
- 使用过什么
- 为什么这样选择
- 当时遇到了什么问题
- 最后如何解决
- 哪些内容可以直接复用
第二阶段：补齐控制与软件基础
控制方向
学习顺序
- 离散系统和采样周期
- 一阶、二阶系统响应
- PID各参数的实际作用
- 串级控制结构
- 低通滤波和噪声
- 状态空间表达
- 可控性和可观性
- 卡尔曼滤波
- 扩展卡尔曼滤波
- LQR
实践任务
- 用Python或MATLAB绘制PID响应
- 对同一系统比较不同参数
- 保存超调、稳态误差和响应时间
- 在真实电机或小车上验证
- 实现一个一维卡尔曼滤波器
- 实现IMU数据的基础滤波
- 尝试建立简化姿态或位置模型
完成标准
不仅能够让系统运行，还能够解释：
- 为什么出现振荡
- 为什么响应缓慢
- 采样周期如何影响控制
- 噪声从哪里进入
- 参数变化会产生什么结果
软件方向
C++
重点学习：
- 类与对象
- 引用和指针
- RAII
- STL常用容器
- 智能指针
- 多文件工程
- CMake
- 基础调试工具
目标不是学习所有高级语法，而是能够稳定阅读和修改ROS及机器人项目。
Python
重点学习：
- 模块和包
- 虚拟环境
- NumPy
- Matplotlib
- Pandas基础
- 文件和数据处理
- 串口及网络通信
- 日志和异常处理
目标是把Python作为实验、数据分析和快速验证工具。
Git
必须掌握：
- init
- clone
- add
- commit
- status
- diff
- branch
- merge
- pull
- push
- .gitignore
- 回退单个错误修改
目标是任何新项目从第一天开始使用Git，而不是完成后才备份代码。
第三阶段：建立ROS与SLAM系统认知
ROS基础
依次掌握：
- 工作空间和包
- 节点
- Topic
- Message
- Service
- Action
- Launch
- Parameter
- TF
- URDF
- rosbag
- RViz
- 日志和诊断工具
第一个完整练习
建立一个小型传感器系统：
- 读取一个真实或录制的传感器数据源
- 发布标准ROS消息
- 建立正确坐标系
- 在RViz中显示
- 使用rosbag录制
- 离线回放
- 用Python分析数据
- 故意制造一个配置错误并完成定位
SLAM与点云
学习顺序：
- 点云数据结构
- 坐标变换
- 体素滤波
- 离群点处理
- 地面分割
- 聚类
- ICP基本原理
- LiDAR与IMU标定
- Fast-LIO输入、输出和数据流
- 地图保存和定位结果评价
完成标准
对于一个Fast-LIO工程，能够说明：
- 雷达数据从哪里进入
- IMU数据从哪里进入
- 使用了哪些坐标系
- 参数文件影响什么
- 位姿和地图从哪里输出
- 数据异常时应该检查哪里
- 如何判断结果好坏
不要求立即独立重写Fast-LIO，但要从“会运行”提升到“理解系统”。
第四阶段：自主导航系统闭环
目标
建立一套从感知到执行的完整实验系统：
传感器
↓
定位与建图
↓
环境表达
↓
路径规划
↓
轨迹生成
↓
控制器
↓
飞行器或机器人
↓
状态反馈
推荐实施顺序
- 先在仿真环境验证
- 再使用地面机器人测试
- 最后迁移到飞行器
- 每一步都保存数据和故障记录
- 不直接在真实飞行器上验证未经测试的算法
阶段项目
可以选择一个具体目标：
- 基于激光雷达的室内自主移动平台
- 使用Mid-360进行建图和定位
- 已知地图中的自主导航
- 动态目标或障碍物检测
- 飞行器在局部环境中的自主航迹规划
- 定位失效情况下的安全降级策略
完成标准
- 能重复部署
- 能重复实验
- 有数据记录
- 有评价指标
- 能解释失败原因
- 能说明改进前后的差异
- 能形成论文、专利或工程报告所需的实验材料
硬件能力提升支线
硬件学习继续保留，但不与主线争夺全部时间。
建议训练顺序
- 独立设计一个简单传感器转接板
- 增加稳压、电源保护和接口保护
- 完成原理图检查
- 完成PCB布局布线
- 打样、焊接和通电测试
- 测量电源纹波
- 检查通信波形
- 记录第一次设计的问题
- 完成第二版改进
第一个合适项目
设计一块面向飞行器或机器人的小型接口板，可以包含：
- 电源输入与保护
- 5V和3.3V稳压
- UART
- I²C
- CAN
- 传感器接口
- 状态指示灯
- 调试接口
- 安装孔
重点不是功能数量，而是完成一次完整、可验证的原创设计流程。
服务器与个人工具链支线
服务器的定位是个人基础设施，不作为主要研究方向。
后续逐步完成：
- Git代码托管
- 知识库自动构建
- 定期备份
- 服务状态告警
- Docker数据备份
- 基础安全审计
- 私有页面认证
- 实验数据和文档归档
学习原则：
遇到真实需求再增加服务，不为了安装而安装。
暂时不优先投入的方向
为了避免学习路线继续发散，以下内容暂不作为主线：
- 从零训练大型视觉模型
- 深入Web前端框架
- 复杂商业后端系统
- 爬虫
- 网络安全攻防
- 游戏开发
- 为了熟悉语法而重复刷大量无关题目
- 没有实际项目支撑的软件和硬件工具
如果未来项目需要，再按需求进入。
能力升级判断标准
一个方向只有满足以下条件，才算从“接触过”升级为“掌握”：
- 能说明它解决什么问题
- 能画出输入、处理和输出关系
- 能独立完成基本配置
- 能看懂关键代码
- 能判断结果是否正常
- 能定位常见故障
- 能在新项目中再次使用
- 能说清自己的能力边界
如果只能跟随教程成功运行一次，仍然属于“接触或复现”。
每月复盘
每月更新一次下面的问题：
本月完成
- 完成了什么项目或实验？
- 哪些结果可以重复？
- 保存了哪些代码、数据和文档？
新增能力
- 哪件事已经可以独立完成？
- 哪件事从AI协作提升到了查阅完成？
- 哪件事仍然只停留在接触层？
暴露的问题
- 哪个基础知识反复阻碍进度？
- 哪类故障最消耗时间？
- 哪些工作没有形成记录？
下月重点
只选择：
- 一个主线目标
- 一个基础能力
- 一个可以交付的结果
避免同时启动大量互不关联的学习任务。