Zhenpeng Ge

> 为了兼容不同队伍机器人会有不同的总线设计，需要一套能够兼容不同总线通讯协议的基础工具类，有一套统一的数据读取机制 兼容不同通信方式可行，统一通信接口就行，比如现在rmoss_base中的Transporter就做的这件事，但是要统一通信数据格式比较困难，不同队伍有着不同数据格式的需求，这个感觉比较难统一，比如比如rm-vision中的[rm_serial_driver](https://github.com/rm-vision-archive/rm_serial_driver/blob/main/include/rm_serial_driver/packet.hpp)直接使用结构体作为数据传输格式，简单有效。这也是我为什么想把rmoss_base更改为rmoss_transporter的原因，即仅提供通信接口，通信的数据处理不同队伍会有各自不同的实现。 > Transporter 作为通讯基类，仅提供 ros_control 中对于 hardware_interface 需要提供的 read 和 write 接口 这里我感觉是不是要和 ros_control 的hardware_interface 解偶开来，Transporter 应该作为通用的消息传输接口（字节传输），Transporter 有Can, Serial Socket等方式，ros2_control 中 hardware_interface 通过使用Transporter 获得硬件交互能力，比如[rm_controls/rm_hw](https://github.com/rm-controls/rm_control/blob/master/rm_hw/src/hardware_interface/hardware_interface.cpp) 中也是使用CanBus（属于Transporter ），另外GPIO感觉比较特殊，感觉不应该继承Transporter基类，单独实现一个接口即可 ，[rm_controls/rm_hw](https://github.com/rm-controls/rm_control/blob/master/rm_hw/include/rm_hw/hardware_interface/gpio_manager.h)设计感觉就行。

> 这里应该是我的表述有误，其实想法是 Transporter 使用类似 hardware_interface 的接口定义，这样如果后续想要做无下位机的方案可以比较方便的放到 ros_control 里面 那感觉就是ros_control的内容了，有点像之前rmoss_base的设计目标了，硬件和ros接口之间的桥梁，需要设计数据格式，以及数据处理逻辑，设计上较难考虑周全。另外，我觉得Transporter定义还是得回归通信本身，最好解耦开来，至于是否需要统一接口，这个也有待讨论。

> 这里并没有规定数据格式，按照UML图例 DataFrame 仅包含数据的元信息 encoding (或者别的名字)和原始的字节数据，具体如何拼接和解析二进制数据的协议并没有包含在这个 Transporter 设计中应该作为使用者来进行实现。是满足这里说的硬件通信和协议解耦的 从UML中，read和write函数并没有看到data参数，那么怎么利用Transporter去发送和读取DataFrame？我好像并没有看到，这里能不能解释一下？我理解read和write是处理read_buffer和write_buffer，但是好像没有加进去和读出来的接口，没太看明白这里是怎么工作的。

rmoss_cam重构想法： * cam_server/cam_client框架略显繁琐，消息链路为raw data->cv::Mat->ros msg->cv::Mat，可以去掉cam_server/cam_client封装，简化为raw data->ros msg->cv::Mat方式。 * 重点规范ros msg/srv接口，而不是统一程序API，提供一些通用相机工具类/函数，例如https://github.com/robomaster-oss/rmoss_core/issues/17 中功能。 * 提供usb相机和虚拟相机功能（维持原有功能）。 * 实现参数配置GUI，可以参考[ros2_mindvision_camera](https://github.com/chenjunnn/ros2_mindvision_camera/tree/main) 目前 [rmoss_gz_cam](https://github.com/robomaster-oss/rmoss_gazebo/blob/d7466597afdf7fbda48671f0de92df76b058d6ef/rmoss_gz_cam/src/gz_cam_node.cpp)已经去掉cam_server/cam_client包装，极大简化了程序，避免为了适配代码封装而产生大量繁琐且冗余的代码。

没看明白，装甲板安装规范只是规定了安装位置，但是机器人本身姿态是不确定的，摄像头的位姿也可能不是固定的，那么，roll,pitch也没法固定吧？PNP求解装甲板位姿，最重要的是平移项，去确定装甲板位置，而不是旋转项吧？希望可以补充更多的信息，可以先描述一下问题。

没看明白，nomachine客户端有报什么错？

do you mean you tried to run this container in a windows host? @winnerlyy

I'm sure that this image can be ran on win11, you can access it by ssh or remote desktop, and OpenGL rendering based on software is still supported. I try...

这个问题好像很nvidia驱动有关系，我在使用驱动nvidia-driver-545时复现了该报错，然后我安装了旧的驱动nvidia-driver-525就可以正常运行了。这个问题确实比较奇怪，两个驱动版本下宿主机的vkcube都能正常运行，但是docker内的行为却不一致，具体原因我也不是很清楚。