Zhenpeng Ge

这种方式可能会限制开发模式，从中间件（ROS）-算法功能解耦的角度看，建议采用的开发模式为： * 使用Eigen自行实现内部的云台模型（独立的类，增加复用性），读取云台编码器传感器数据，进行相应的换算。 * 自瞄功能调用云台模型，得到最终的目标控制命令。 同时，也可以支持tf的发布，方便进行可视化调试，而不是直接用tf参与自瞄目标位置到控制命令的计算。 另一方面，对于数据同步，可以采用buffer进行自行处理，更加方便，如需插值，也可实现插值工具类（可支持线性插值，球面插值等不同插值算法）。

cc @Ericsii @WUyinwei-hah

目前想到的rmoss_core应该包含以下package： * rmoss_transporter：即rmoss_base中transporter功能，仅作为库进行依赖 * rmoss_cam: 相机功能 * rmoss_projectile_motion: 弹道运动计算功能，仅作为库进行依赖 * rmoss_util：通用工具类，仅作为库进行依赖 rmoss_base没有存在的必要性，其中的simple_robot_base_node.cpp仅仅作为example样例存在，不同机器人的base模块必然不同，因此可以删除rmoss_base包。

参考[navigation2](https://github.com/ros-navigation/navigation2)，可以采用LifecycleNode进行节点管理，删除rmoss_util/task_manager功能类

> > 可以增加math目录层级，但是你这样的增加方式感觉有点怪，建议如下层级： > > > > * rmoss_util > > > > * include/rmoss_util/math/extended_kalman_filter.hpp > > * src > > 不加math目录主要是考虑contrib那里的包用到了原来的util里的东西，如果加了math那common也要加，这样还得改对应的路径 common目录没必要加，其他代码可以不动，只给extended_kalman_filter.hpp加一级math就行，像这样 rmoss_util * include/rmoss_util/ * mono_measure_tool.hpp * math/extended_kalman_filter.hpp...

> * 裁判系统可以单独作为一个功能提供 你说的是裁判系统给机器人提供的信息？还是仿真器的裁判系统实现？ > * rmoss_util可以进一步拆分，避免越做越大（防止为了一个小工具而安装一堆库，等一坨东西编译半天） > > * 除了ros2以外没有其他依赖的通用工具类 > * 图像处理的工具类或者是对OpenCV某个功能的封装 > * 一些常用的数学算法工具，比如均值滤波、卡尔曼滤波，曲线拟合，不同旋转表示之间的转换 这个我也赞同，rmoss_util应该只放一些简单的工具类，复杂的工具类应该单独做package，第二点图像处理工具类我倾向于独立出去，放在rmoss_perception_common之类的包中？

> 支持使用LifecycleNode来进行管理。rmoss_interface中对于云台的底盘控制的消息应该重新修改一下，我倾向于类似ros2_control的方式来控制云台 可以简单讲一下这种方式下云台和底盘消息怎么定义吗？比如应该包含哪些字段，我对ros2_control不太熟 @Ericsii

系统架构设计想法：  其中 * Task Layer: 功能任务层，包含感知，规划，定位，导航等任务的实现，可以被不同的机器人复用，不需要考虑机器人硬件结构。 * Interfece Layer: 机器人与功能任务的接口层，包含传感器与执行器驱动，由于不同机器人硬件结构差异性较大，而控制功能与机器人硬件结构相关性比较高，因此也放入该层，该部分可以采用[ros2-control](https://github.com/ros-controls/ros2_control)方式实现适配，也可以自行开发控制程序，不做限制。 * Hardware Layer：机器人本体，使用usb，以太网，串口与Interfece Layer进行数据通信。 Task Layer与Interfece Layer使用ros msg应该与机器人的具体硬件结构实现无关。 * state ros msg：`sensor_msgs/JointState` 等 * command ros msg：`geometry_msgs/Twist`, `trajectory_msgs/JointTrajectory` 等...

> 与真实的裁判系统实现通信，数据发布到指定话题上（在雷达站上算刚需）。目前好像没找到特别好的，在上位机与裁判系统通信的开源，只在广工的rm_controls开源上看到一个ROS1版的，但实现的有点复杂，不太好用 看起来没问题，创建一个新包，例如`rmoss_referee_bridge` , 把裁判系统的数据封装为ros msg发布出去，裁判系统的消息与比赛规则相关性高，可以单独创建仓库进行维护，后面可以加入开发计划。

rmoss_auto_aim模块重构的想法：  其中rmoss_auto_aim应该只包含armor detector和armor tracker模块，作为一个perception功能包。 模块功能： * armor detector: 检测装甲板目标与位姿估计，输出一组装甲板消息。 * armor tracker: 装甲板跟踪与预测，输出预测的最佳射击目标点等消息。 * gimbal controller: 云台控制，包含弹道补偿功能，输入目标点，输出关节角度目标JointState或者JointTrajectory给MCU，与机器人的机械结构强相关，不同的机器人不一样，甚至有可能是双云台机器人。 参考了[rm_auto_aim](https://github.com/CSU-FYT-Vision/FYT2024_vision/tree/main/rm_auto_aim)，其pipeline设计比较合理，这里只是解耦了perception和control模块，这样解耦的好处是perception模块无需关心硬件结构，只需要输出目标位置即可，gimbal controller也可以被能量机关这种需要射击的任务复用。同时perception和control模块之间也非常容易插入决策模块判断目标pose是否应该射击。