1. 使用VScode+Codex CLI+WSL2:Ubuntu20.04
2. 纯原生环境，未增加任何额外提示词/skills

最终效果

Step 0 初始状态

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

.
├── ros1_side_ws
│   └── src
│       ├── data_converter
│       └── data_example
│           └── image_demo
├── ui_console
│   ├── main.cpp
│   ├── mainwindow.cpp
│   ├── mainwindow.h
│   ├── mainwindow.ui
│   ├── ui_console.pro
│   └── ui_console.pro.user
└── 显示数据.docx

6 directories, 7 files

Step 1 基于.docx的双机械臂ROS1 Topic发布模块构建

1.1 启动codex

1

codex

1.2 任务需求描述

User

请先阅读我的ui界面@ui_console/mainwindow.ui，我现在需要写在此文件夹中@ros1_side_ws/src/data_example写python程序，目的是将@显示数据.docx中提到的数据都通过ros1的topic发布出来，需要注意的是，命名要区别左右机械臂，我现在有两条机械臂。请以right或者left开头命名@显示数据.docx其中提到的所有ros1节点，并模拟数据的随机性，按照2Hz发出。其中所有的6维数据的格式都是xyzrpy，请以这个格式填充。

Codex

已按你的 mainwindow.ui 和 显示数据.docx 落了一个 ROS1 示例发布包，核心脚本在 ros1_side_ws/src/data_example/scripts/dual_arm_topic_publisher.py:1。它会把文档里提到的左右臂数据全包骨架也补齐了，包含 ros1_side_ws/src/data_example/package.xml、ros1_side_ws/src/data_example/CMakeLists.txt 和运行说明ros1_side_ws/src/data_example/README.md:1。其中 7x1 bool 我用std_msgs/UInt8MultiArray 的 0/1 表示，1x1 使能状态用 std_msgs/Bool，其余按 Float32MultiArray / Int32MultiArray / Int32 发布。已完成的校验是 python3 -m py_compile，语法通过；我没有在当前环境里实际启动 roscore / rosrun 做联调。运行方式见 ros1_side_ws/src/data_example/README.md:19。如果你还需要我下一步把这些 topic 接到 Qt 界面字段上，我可以继续补订阅和显示逻辑。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

.
├── README.md
├── ros1_side_ws
│   └── src
│       ├── data_converter
│       └── data_example
│           ├── CMakeLists.txt	# new
│           ├── README.md		# new
│           ├── image_demo
│           ├── package.xml		# new
│           └── scripts			# new
├── ui_console
│   ├── main.cpp
│   ├── mainwindow.cpp
│   ├── mainwindow.h
│   ├── mainwindow.ui
│   ├── ui_console.pro
│   └── ui_console.pro.user
└── 显示数据.docx

7 directories, 11 files

1.3 补充订阅和显示逻辑

User

补订阅和显示逻辑

Codex

已补完 UI 侧订阅和显示逻辑。

核心改动在 ui_console/mainwindow.cpp:10。现在窗口启动后会建立左右臂 topic 订阅，把实时遥测页和按需遥测页里能显示的字段都接上，包括关节角/速度/电机速度/电流、制动器状态、夹爪速
度与位置、六维力、末端位姿/速度、抓取点、输出位置/速度、驱动指令、算法错误标志位、到位标志位、速度环 p/d 参数和制动器占空比。顶部的使能状态和控制模式标签也会随 / right_enable_status、/left_enable_status、/right_control_mode、/left_control_mode 更新。

ROS 和 Qt 的集成入口在 ui_console/main.cpp:6 和 ui_console/mainwindow.h:23：程序启动时先 ros::init，窗口里用 QTimer + ros::spinOnce() 驱动回调；工程链接配置在 ui_console/ ui_console.pro:5，已经加上 roscpp 和 std_msgs。所有 QLineEdit 也都设成只读，按需页里 UI 本来标 N/A 的几个框保持 N/A。

我已经在本地跑过 qmake ui_console.pro 和 make -j2，编译通过，生成了 ui_console/ui_console。如果你愿意，我下一步可以继续把“连接”按钮和“一键请求数据”按钮也接成实际 ROS 行为。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

.
├── README.md
├── ros1_side_ws
│   └── src
│       ├── data_converter
│       └── data_example
│           ├── CMakeLists.txt
│           ├── README.md
│           ├── image_demo
│           ├── package.xml
│           └── scripts
├── ui_console
│   ├── Makefile			# new
│   ├── main.cpp
│   ├── main.o				# new
│   ├── mainwindow.cpp
│   ├── mainwindow.h
│   ├── mainwindow.o		# new
│   ├── mainwindow.ui
│   ├── moc_mainwindow.cpp	# new
│   ├── moc_mainwindow.o	# new
│   ├── moc_predefs.h		# new
│   ├── ui_console			# new
│   ├── ui_console.pro
│   ├── ui_console.pro.user
│   └── ui_mainwindow.h		# new
└── 显示数据.docx

7 directories, 19 files

[!CAUTION]

此处出现跃层实现问题，Codex没有充分理解我的原始架构中的data_converter，选择了跳过了你原本隐含的中间层分层设计，直接让 Qt 去订阅 ROS topic 。

问题分析：

• 典型的AI编程Agent“跃层实现”现象

  在上下文未明确约束系统架构的情况下，Codex基于最短可运行路径直接构建端到端闭环（data_example→ui），而忽略了中间层data_converter的分层设计需求，这反映了Agent在上下文驱动决策中更倾向于完成“功能闭环”而非遵循“架构约束”的特性，其根因在于Agent行为完全依赖当前上下文而非长期结构记忆。

• 开发者对任务需求约束不充分、架构表达不明确

  在与AI协作过程中，开发者未对系统分层（如 data_example → data_converter → ui_console）进行显式约束与强调，导致Agent只能基于当前显性信息进行推断，从而选择最短路径实现功能闭环。同时，对ROS1与Qt集成流程理解不够深入，未能在关键步骤对Agent的实现路径进行校验与干预，使得“跃层实现”未被及时发现并纠正，最终偏离原有架构设计意图。

Step 2 实现中间层data_converter

2.1 改回原定架构

User

取消 ui_console 对 data_example 的直接订阅；先生成 data_converter，由 data_converter 统一订阅、转换、重发布，Qt 只对接 data_converter 输出。

Codex

已经改成 data_example -> data_converter -> ui_console。

新加的中转节点在 ros1_side_ws/src/data_converter/scripts/data_converter_node.py:1。它统一订阅 data_example 的左右臂原始 topic，然后重发布到 /data_converter/right_* 和 / data_converter/left_*；当前做的是统一接入和中转，6 维量在中间层也显式收敛成 6 元数据，方便后续继续加转换规则。运行说明在 ros1_side_ws/src/data_converter/README.md:1。

Qt 侧已经取消对 data_example 的直接订阅，订阅入口统一改成了 /data_converter/...，位置在 ui_console/mainwindow.cpp:113。也就是说，ui_console 现在只认 data_converter 的输出，不再直接读 /right_* 或 /left_* 源 topic。

我做过两项校验：python3 -m py_compile 校验 data_converter 脚本通过，ui_console 重新 make -j2 编译通过。接下来实际运行时，顺序应该是先起 roscore，再起 data_example，再起
data_converter，最后启动 ui_console。如果你要，我下一步可以继续把 data_converter 做成“真正转换层”，例如统一字段单位、枚举映射、错误码解释、或者把多 topic 聚合成更适合 Qt 的少量
输出 topic。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

.
├── README.md
├── ros1_side_ws
│   └── src
│       ├── data_converter
│       │   ├── CMakeLists.txt	# new
│       │   ├── README.md		# new
│       │   ├── package.xml		# new
│       │   └── scripts			# new
│       └── data_example
│           ├── CMakeLists.txt
│           ├── README.md
│           ├── image_demo
│           ├── package.xml
│           └── scripts
├── ui_console
│   ├── Makefile
│   ├── main.cpp
│   ├── main.o
│   ├── mainwindow.cpp
│   ├── mainwindow.h
│   ├── mainwindow.o
│   ├── mainwindow.ui
│   ├── moc_mainwindow.cpp
│   ├── moc_mainwindow.o
│   ├── moc_predefs.h
│   ├── ui_console
│   ├── ui_console.pro
│   ├── ui_console.pro.user
│   └── ui_mainwindow.h
└── 显示数据.docx

8 directories, 22 files

2.2 回补data_example功能

User

我现在希望在@ros1_side_ws/src/data_example/scripts/dual_arm_topic_publisher.py 中添加一个功能，我现在有4个相机的数据，topic前缀的命名分别为scene1，scene2，left，right，随机从@ros1_side_ws/src/data_example/image_demo 取出4张图，以2Hz的频率发布。

Codex

已经在 ros1_side_ws/src/data_example/scripts/dual_arm_topic_publisher.py:1 里加了 4 路相机发布功能。现在脚本启动后会从 ros1_side_ws/src/data_example/image_demo 随机取 4 张图，以 2Hz 发布到这四个 topic：

/scene1/image/compressed、/scene2/image/compressed、/left/image/compressed、/right/image/compressed

实现上我用了 sensor_msgs/CompressedImage，这样可以直接发布现有 PNG/JPG 文件，不需要再引入 cv_bridge。对应依赖也已经补到 ros1_side_ws/src/data_example/package.xml:12 和 ros1_side_ws/src/data_example/CMakeLists.txt:4，说明也更新到 ros1_side_ws/src/data_example/README.md:5。

我做过 python3 -m py_compile，语法通过。当前这 4 路图像还是由 data_example 直接发出；如果你希望继续保持“Qt 只对接 data_converter 输出”的原则，我下一步可以把这 4 路图像也一起接进 data_converter 中转。

1

# 此步未新增文件，仅修改ros1_side_ws/src/data_example/scripts/dual_arm_topic_publisher.py

2.3 增加图像解压转换

User

我现在只有compressed格式的图片，请发布image_raw

Codex

已经改成发布 image_raw 了。

现在 ros1_side_ws/src/data_example/scripts/dual_arm_topic_publisher.py:181 会把 image_demo 里的压缩图片先用 cv2.imdecode 解码，再以 sensor_msgs/Image 发布到：

/scene1/image_raw、/scene2/image_raw、/left/image_raw、/right/image_raw

这样你虽然只有压缩文件，但对外拿到的是原始图像 topic。脚本会根据图片内容自动设置 mono8、bgr8 或 bgra8。说明也同步更新到了 ros1_side_ws/src/data_example/README.md:11。

我已经跑过 python3 -m py_compile，语法通过。如果你下一步也希望保持“Qt 只对接 data_converter 输出”，那我建议把这 4 路 image_raw 也接进 data_converter 转发一层。

1

# 此步依旧未新增文件，仅修改ros1_side_ws/src/data_example/scripts/dual_arm_topic_publisher.py

2.4 完整data_converter需求说明

User

好的，我现在已经完成了data_example部分的工作，我现在需要在@ros1_side_ws/src/data_converter 中写c++的节点，命名为data_converter_node.cpp，其功能是把@ros1_side_ws/src/data_example 中发布的数据全部接收进来，并通过UDP向上发送到上位机@ui_console 。需要注意的是，并不是所有数据都是一次性发布的，speed_loop_p、speed_loop_d、brake_duty_cycle这三个数据和4张图片都是需要收到上位机指令才发送UDP报文的，@ui_console/mainwindow.ui 中的pushButton_3是同时请求左右两条臂的speed_loop_p、speed_loop_d、brake_duty_cycle 的，即每触发一次按钮，就把这6个数存入log_request.txt中；pushButton_4是用于同时请求4张图片的，请新建4个文件夹分别存入4张图片，即每触发一次按钮，就在4个文件夹分别存入一张图。目前，把data_converter_node.cpp收到的所有实时数据都存在上位机的log.txt中（请求数据存在log_request.txt中）。最后，lineEdit和lineEdit_2分别为上位机连接@ros1_side_ws/src/data_converter 的ip和端口号，pushButton按钮触发UDP建立连接，如果连接失败，请在ui中给出弹窗报错。请先写一个通信协议满足我的全部要求，全部使用定长协议帧，图片传输每帧报文不超过400字节，并加入每帧的校验和重新传输的机制。

Codex

本阶段完成了从ROS topic层到UI通信层的系统接口设计，明确引入data_converter作为中间层，构建了基于UDP的定长协议体系，实现了实时数据上传、按需参数请求及多路图像分片传输的完整链路定义，同时补充了连接管理（握手/心跳）、数据可靠性机制（ACK/NACK/重传）以及日志与落盘规范，从而将原有松散的ROS数据流整合为一套可工程化落地的通信与数据交互框架。

1

# 本步仅设计通信协议，未更改与新增

2.5 根据需求重构data_converter

我认可这份协议，请写data_converter_node.cpp和protocol_v1.md。另外去掉之前的data_converter_node.py。

Codex

新增了 C++ 节点 ros1_side_ws/src/data_converter/src/data_converter_node.cpp:1 和协议文档 ros1_side_ws/src/data_converter/protocol_v1.md:1。data_converter 现在是 C++ 包，订阅
data_example 的实时数据、按需参数和 4 路 image_raw，提供 UDP 握手、心跳、实时上送、参数请求响应、图片 JPEG 分片发送，以及缺片重传入口。构建配置也已经切到 roscpp + sensor_msgs + OpenCV + zlib，见 ros1_side_ws/src/data_converter/CMakeLists.txt:1 和 ros1_side_ws/src/data_converter/package.xml:1。

之前的 Python 版本已经删除。catkin_make 我已经跑过，编译通过，生成的可执行文件在devel/lib/data_converter/data_converter_node。运行方式是：

1 2 3

cd /home/wjy12394/codex-project/codex-demo/ros1_side_ws source devel/setup.bash rosrun data_converter data_converter_node

当前边界也说明一下：这次我完成的是 data_converter 侧和协议文档；你要求的 ui_console 端 UDP 建连、弹窗、log.txt / log_request.txt 落盘、pushButton_3 / pushButton_4 行为，还没有开始改。如果你继续，我下一步就直接把 ui_console 按这份协议接上。

Step 3 开发ui_console上位机

3.1 提出ui_console开发需求

User

@ui_console qt端的上位机程序还没进行开发，请按照上述要求继续开发。

Codex

已继续把 ui_console 开发成 UDP 上位机，Qt 端现在不再直接订阅 ROS。

核心逻辑都在 ui_console/mainwindow.cpp:107。现在支持：

• 连接按钮 pushButton 用 ui_console/mainwindow.ui:33 和 ui_console/mainwindow.ui:46 发起 UDP 握手，失败会弹窗；实时帧按协议解析后刷新双臂界面并写 log.txt；pushButton_3 发送参数请求，收到后更新按需页并写 log_request.txt；pushButton_4 请求 4 路图像，支持分片接收、缺片重传、CRC 校验，最后分别落到 left/、right/、scene1/、scene2/ 并显示在相机页标签上。

• 结构定义和协议收发接口在 ui_console/mainwindow.h:23。工程配置也改成了 Qt Network，并补了 zlib 链接，见 ui_console/ui_console.pro:1。同时 main.cpp 已去掉 ROS 初始化，Qt 端现在是
  纯 UDP 客户端。

• 我已经实际跑过 qmake ui_console.pro 和 make -j2，编译通过。日志和图片目录默认会落在程序运行目录下。下一步如果你要，我可以继续把 data_converter 侧补上真正的 log.txt /
  log_request.txt 文件写入，或者把 UI 上未接的第二组连接按钮也按同一协议补齐。

3.2 根据提示完善需求

User

继续把 data_converter 侧补上真正的 log.txt /log_request.txt 文件写入

Codex

data_converter 侧日志已经补上了，并且重新编译通过。

现在 ros1_side_ws/src/data_converter/src/data_converter_node.cpp:203 会在启动时读取 ~log_dir，默认写到当前工作目录下的 log.txt 和 log_request.txt。实现位置主要有两块：一块是日志工具和路径初始化，在 ros1_side_ws/src/data_converter/src/data_converter_node.cpp:164 和 ros1_side_ws/src/data_converter/src/data_converter_node.cpp:210；另一块是实际写入点，在实时帧发送、参数请求处理、图片请求和图片发送时追加日志，见ros1_side_ws/src/data_converter/src/data_converter_node.cpp:409 和 ros1_side_ws/src/data_converter/src/data_converter_node.cpp:512。

当前行为是：

• log.txt 记录左右臂实时关节、末端、算法、状态四类实时数据；

• log_request.txt 记录连接事件、pushButton_3 触发的参数请求内容，以及 pushButton_4 触发的图片请求、编码和发送信息。

我已经重新跑过 catkin_make，编译通过。如果你要把日志目录固定到某个位置，运行时可以加：rosrun data_converter data_converter_node _log_dir:=/你的目录。如果你继续，我下一步可以把 ui_console 端的图片保存路径和 data_converter 的 log_request.txt 条目做成一一对应的索引格式。

3.3 最终完善工程代码

User

请根据整个工程的当前状态和我的需求，完善当前的结构，并清理不必要的编译产物，最后再给@README.md中写清最终的编译及运行方式。

我已经把工程按当前最终架构整理了一遍，并清掉了不必要的编译产物。主要调整有两处。

• 根目录说明已经补全到 README.md:1，现在明确写了三层结构 data_example -> data_converter -> ui_console、依赖环境、编译顺序、运行顺序、日志位置、图片保存位置，以及 UI 上 pushButton / pushButton_3 / pushButton_4 的使用方式。第二，忽略规则修正到了 .gitignore:1，现在会忽略 Qt/catkin/Python 的构建缓存，但不会再误忽略 data_example/ image_demo 这类运行必需图片资源。

• 清理方面，我已经删除了当前目录里的 Qt 和 catkin 编译产物，包括 ui_console 下的 Makefile、.o、moc_*、生成的可执行文件，以及 ros1_side_ws/build、ros1_side_ws/devel 和 Python__pycache__。所以仓库现在是源码态；如果你要运行，直接按 README.md:74 里的步骤重新编译即可。

• 补充一点：我这次没有在清理后再次执行编译，因为你要求的是最终整理和清理源码树；当前状态就是“干净源码 + 明确说明文档”。如果你要，我下一步可以继续帮你把仓库再做一轮“可提交”整理，
  比如统一 package 版本号、补 license、补启动脚本或 launch 文件。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

.
├── README.md
├── ros1_side_ws
│   └── src
│       ├── CMakeLists.txt 		# 对比原始新增
│       ├── data_converter
│       │   ├── CMakeLists.txt 	# 对比原始新增
│       │   ├── README.md		# 对比原始新增
│       │   ├── package.xml		# 对比原始新增
│       │   ├── protocol_v1.md	# 对比原始新增
│       │   ├── scripts			# 对比原始新增
│       │   └── src				# 对比原始新增
│       └── data_example
│           ├── CMakeLists.txt	# 对比原始新增
│           ├── README.md		# 对比原始新增
│           ├── image_demo
│           ├── package.xml		# 对比原始新增
│           └── scripts			# 对比原始新增
├── ui_console
│   ├── main.cpp
│   ├── mainwindow.cpp
│   ├── mainwindow.h
│   ├── mainwindow.ui
│   └── ui_console.pro
└── 显示数据.docx

9 directories, 15 files

Step 4 浏览version 1.0的说明文档

这是一个完整的 ROS1 + UDP + Qt 上位机演示工程，当前结构已经收敛为三层：

• ros1_side_ws/src/data_example：ROS1 Python 示例数据源，发布双臂实时数据和 4 路 image_raw
• ros1_side_ws/src/data_converter：ROS1 C++ 转换与通信层，订阅 ROS topic、按协议通过 UDP 上送、处理按需请求、写 log.txt / log_request.txt
• ui_console：Qt 上位机，负责 UDP 建连、界面显示、按需请求、日志记录和图片落盘

4.1 目录结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

codex-demo/
├── README.md
├── ui_console/
│   ├── main.cpp
│   ├── mainwindow.cpp
│   ├── mainwindow.h
│   ├── mainwindow.ui
│   └── ui_console.pro
└── ros1_side_ws/
    └── src/
        ├── CMakeLists.txt
        ├── data_example/
        │   ├── CMakeLists.txt
        │   ├── package.xml
        │   ├── README.md
        │   ├── image_demo/
        │   └── scripts/
        │       └── dual_arm_topic_publisher.py
        └── data_converter/
            ├── CMakeLists.txt
            ├── package.xml
            ├── README.md
            ├── protocol_v1.md
            └── src/
                └── data_converter_node.cpp

4.2 功能划分

data_example

• 以 2Hz 发布左右机械臂模拟数据
• 所有左右臂 topic 使用 right_ / left_ 前缀区分
• 所有 6 维量统一按 xyzrpy
• 从 image_demo/ 随机取图，发布：
  • /scene1/image_raw
  • /scene2/image_raw
  • /left/image_raw
  • /right/image_raw

data_converter

• 订阅 data_example 的全部实时数据
• 实时数据通过固定长度 UDP 协议上送到 ui_console
• speed_loop_p、speed_loop_d、brake_duty_cycle 只在上位机请求时回传
• 4 路图片只在上位机请求时进行 JPEG 分片发送
• 在启动目录或 ~log_dir 指定目录写：
  • log.txt
  • log_request.txt

ui_console

• 使用 lineEdit 和 lineEdit_2 输入 data_converter 的 IP 和端口
• pushButton 负责 UDP 握手建连，失败弹窗
• 实时数据显示到界面并写本地 log.txt
• pushButton_3 请求左右臂的 speed_loop_p、speed_loop_d、brake_duty_cycle，并写本地 log_request.txt
• pushButton_4 请求 4 路图片，分别保存到运行目录下的：
  • left/
  • right/
  • scene1/
  • scene2/

4.3 依赖环境

ROS1 工作区

• Ubuntu 20.04
• ROS Noetic
• OpenCV
• zlib

Qt 上位机

• Qt 5
• qmake
• Qt Widgets
• Qt Network
• zlib

4.4 编译

1. 编译 ROS1 工作区

1
2
3

cd /home/wjy12394/codex-project/codex-demo/ros1_side_ws
catkin_make
source devel/setup.bash

2. 编译 Qt 上位机

1
2
3

cd /home/wjy12394/codex-project/codex-demo/ui_console
qmake ui_console.pro
make -j"$(nproc)"

编译完成后，可执行文件位于：

1

/home/wjy12394/codex-project/codex-demo/ui_console/ui_console

4.5 运行

建议严格按下面顺序启动。

1. 启动 ROS Master

1

roscore

2. 启动模拟数据源

1
2
3

cd /home/wjy12394/codex-project/codex-demo/ros1_side_ws
source devel/setup.bash
rosrun data_example dual_arm_topic_publisher.py

3. 启动 UDP 转换节点

1
2
3

cd /home/wjy12394/codex-project/codex-demo/ros1_side_ws
source devel/setup.bash
rosrun data_converter data_converter_node

如果要显式指定日志目录或端口，可以这样运行：

1
2
3

cd /home/wjy12394/codex-project/codex-demo/ros1_side_ws
source devel/setup.bash
rosrun data_converter data_converter_node _udp_port:=9000 _log_dir:=/tmp/data_converter_logs

4. 启动 Qt 上位机

1
2

cd /home/wjy12394/codex-project/codex-demo/ui_console
./ui_console

4.6 上位机使用方式

建立连接

1. 在 lineEdit 中填写 data_converter 所在主机 IP
2. 在 lineEdit_2 中填写 UDP 端口，默认 9000
3. 点击 pushButton
4. 如果三次握手失败，界面会弹窗报错

请求按需参数

1. 点击 pushButton_3
2. ui_console 会一次性请求左右臂的：
   • speed_loop_p
   • speed_loop_d
   • brake_duty_cycle
3. data_converter 会把该次请求写入它自己的 log_request.txt
4. ui_console 也会把收到的结果写入它运行目录下的 log_request.txt

请求图片

1. 点击 pushButton_4
2. ui_console 会同时请求 4 路图片
3. data_converter 按协议进行 JPEG 分片发送，单帧报文不超过 400 字节
4. ui_console 会校验、缺片重传并最终分别保存到：
   • left/
   • right/
   • scene1/
   • scene2/

4.7 协议说明

• 固定长度协议定义见：
  • ros1_side_ws/src/data_converter/protocol_v1.md
• 图片传输支持：
  • CRC32 校验
  • ACK
  • 缺片重传

4.8 日志与输出位置

data_converter

• 默认在节点启动目录写：
  • log.txt
  • log_request.txt
• 可通过 _log_dir:=... 修改

ui_console

• 默认在可执行文件运行目录写：
  • log.txt
  • log_request.txt
  • left/
  • right/
  • scene1/
  • scene2/

4.9 备注

• 仓库中的 Qt 和 catkin 编译产物属于临时文件，已经通过 .gitignore 统一排除
• data_example/image_demo/ 中的图片是运行所需资源，应保留在仓库中

Step 5 debug优化

5.1 点击“一键请求图像”后无响应

User

Qt 上位机已成功连接（127.0.0.1:9000），点击“一键请求图像”后无任何响应（无图片保存、无日志、无报错），请帮我排查是请求未发送、UDP未接收还是data_converter未返回数据。

Codex

我先把结论说清楚：从当前代码路径看，“一键请求图像”本身不是空按钮，Qt 侧原来确实会发 REQUEST_IMAGE；你之所以看到“无图片保存、无日志、无报错”，更像是 data_converter 收到请求后，在“没有缓存图 / 图像编码不支持 / JPEG 编码失败”这几个早退分支直接返回了，而这些分支之前只打 ROS_WARN，不写 log_request.txt，所以表面上像完全没反应。

我已经把这条链路补成可观测状态，并且重新编译通过了。改动在 mainwindow.cpp 和 data_converter_node.cpp。现在：

• Qt 侧会记录 image_request_sent
• Qt 侧收到图像分片/结束帧时会记录 image_chunk_received、image_end_received
• data_converter 侧会记录 image_request
• 如果它没法返回图片，会明确写 image_skip reason=no_cached_image、unsupported_encoding 或 jpeg_encode_failed

你现在可以直接按下面这套判断链路：

1. 点“一键请求图像”后，看 ui_console 运行目录下的 log_request.txt
   • 如果没有 image_request_sent，就是 Qt 按钮/发送链路有问题
2. 如果 Qt 有 image_request_sent，再看 data_converter 启动目录下的 log_request.txt
   • 如果没有 image_request，就是 UDP 请求没到 data_converter
   • 如果有 image_request，但紧跟着是 image_skip reason=no_cached_image，就是 data_converter 没收到 ROS 图像
   • 如果有 image_prepare 和 image_sent，说明 data_converter 已经回包了
3. 如果 data_converter 已经 image_sent，但 Qt 没有 image_chunk_received
   • 就是返回 UDP 没到 Qt
4. 如果 Qt 有 image_chunk_received / image_end_received，但没有落盘
   • 再看是否出现 image_missing_chunks 或 image_crc_failed

这次编译校验都过了：

• ui_console: qmake ui_console.pro && make -j2
• data_converter: catkin_make

最可能的实际原因，我目前仍然优先怀疑是 data_converter 当时没有拿到 4 路 image_raw 缓存，所以请求到了但没图可发。你下一步只要把两边新的 log_request.txt 里和这次点击相关的几行贴给我，我就能直接告诉你断在 Qt 发送、UDP 接收，还是 data_converter 返回阶段。

User

请直接进行编译、运行和测试

Codex

可以，而且我已经实际跑过了一轮联调。

这次测试里我做了三件事：

• 成功启动了 roscore
• 成功启动了 data_example
• 成功启动了 data_converter

然后我没有依赖手工点 Qt，而是直接按你定义的协议向 127.0.0.1:9000 发了 CONNECT_REQ 和 REQUEST_IMAGE。结果很明确：

1. REQUEST_IMAGE 是能被 data_converter 收到的
2. data_converter 确实在返回图像数据
3. 返回的不是空包，而是大量 IMAGE_CHUNK，并且已经至少返回了 1 路相机的 IMAGE_END

我这边实际收到的内容里，已经有这种结果：

• 连接成功：收到 CONNECT_ACK
• 图像请求成功：连续收到 IMAGE_CHUNK
• 已完成至少 1 路图像：收到 cam=0 的 IMAGE_END
• 这说明“请求未发送”和“UDP 未接收”都基本可以排除
• 更不符合“data_converter 未返回数据”

目前更像的真实问题有两个：

1. data_converter 的日志目录不会自动创建
   你传了 _log_dir:=...，但目录不存在时它不会自己 mkdir，所以即使服务端已经处理了请求，log_request.txt 也可能根本写不出来。这就是你之前看到“无日志”的一个直接原因。

2. 图像分片太大、太多，Qt 端可能在整张图收齐前一直看起来“没反应”
   我这边一次 4 路图像返回量非常大，单路就三百多片，4 路总共是一千多片。当前逻辑是：

• data_converter 连续猛发
• ui_console 要等整张图收齐并 CRC 正确后才保存
• 所以如果分片还没收完，界面上就不会立即出现图片文件
• 这会表现成“点击后像没反应”

我这次协议测试里，8 秒内已经收到了 801 个 chunk，但只完整走完了 1 路图像的 end。这个现象很关键，说明服务端在发，但整条图像链路吞吐偏重。

结论可以先定下来：

• 不是 REQUEST_IMAGE 协议格式错了
• 不是 data_converter 完全没收到
• 不是 data_converter 完全没返回
• 当前主要问题更偏向：
  • data_converter 日志不可见
  • 图像传输过重，Qt 端完成一张图落盘比较慢

如果你愿意，我建议下一步直接做这两个修复：

• 让 data_converter_node.cpp 自动创建 log_dir
• 给图片发送加“缩放 + 节流”，比如先缩到固定分辨率再发，或者每发若干片 sleep 几毫秒

这样我们就不是只停在排查，而是把“点按钮没反应”这件事一起解决掉。

User

连接上了，我请求的图像存在哪里了？

按当前实现，Qt 上位机保存图片的位置是 ui_console 可执行文件的运行目录，而不是 data_converter 那边。

如果你是这样启动的：

1 2	cd /home/wjy12394/codex-project/codex-demo/ui_console ./ui_console

那图片会保存在这四个目录里：

• scene1
• scene2
• left
• right

文件名格式是：

• <snapshot_id>_<image_id>.jpg

另外两个日志也在这个目录下：

• log.txt
• log_request.txt

如果你现在没看到这四个文件夹，通常只有两种情况：

• 图像还没完整接收并通过 CRC，所以还没落盘
• 你不是从 ui_console 目录启动的，而是从别的工作目录启动了可执行文件

如果你愿意，我可以直接帮你检查当前这四个目录和 log_request.txt 里有没有图像接收记录。

User

我现在希望把这个界面中的label_86，label_87，label_88，label_89分别存入/left/ , /right/, /scene1/, /scene2/中，在触发pushButton_4时，存图的同时，写入到界面中的上述四个位置。

Codex

已经按你的要求补好了，改动在 mainwindow.cpp 和 mainwindow.h。

现在行为是这样的：

• 点击 pushButton_4 后，会先确保这四个目录存在：
  • left
  • right
  • scene1
  • scene2
• 同时把界面上的 4 个位置切到“接收中…”：
  • label_86 -> left
  • label_87 -> right
  • label_88 -> scene1
  • label_89 -> scene2
• 每一路图片一旦完整接收并保存成功，就会立刻显示到对应 label 上，并继续保存在对应目录中

也就是说，你要的这两件事现在是同步发生的：

• 落盘到 /left/、/right/、/scene1/、/scene2/
• 写入并显示到 label_86、label_87、label_88、label_89

我已经重新编译通过：

1 2 3

cd /home/wjy12394/codex-project/codex-demo/ui_console qmake ui_console.pro make -j2

如果你愿意，下一步我可以继续把 data_converter 的图片发送做轻一点，比如先缩放再发。这样界面上的 4 个 label 会更快出现图，不会长时间停在“接收中…”。

User

我现在有个新问题，无法运行rosrun data_converter data_converter_node，请帮我排查问题在哪里。请先解决这一问题。测试时，请不要用sandbox模式运行，直接在外面运行即可，我进行完全授权。

Codex

已经解决了。现在标准命令：

1 2 3 4

cd /home/wjy12394/codex-project/codex-demo/ros1_side_ws source /opt/ros/noetic/setup.bash source devel/setup.bash rosrun data_converter data_converter_node

我已经在沙箱外实际跑通，当前它可以正常启动并监听默认端口 9000。

这次排查到的根因有两层：

1. 一开始没有可用的 roscore

• 当时的真实报错是连不上 ROS Master：Failed to contact master at [localhost:11311]
• 这会让节点一直重试，看起来像“rosrun 跑不起来”

2. 之后机器上还有旧的 data_converter_node 残留状态

• 旧进程占用了 UDP 端口 9000
• ROS 参数服务器里残留过 /data_converter_node/udp_port=9001
• ROS Master 里还残留了一个空壳节点名 /data_converter_node
• 这些残留会导致你重新运行默认命令时立刻退出，或者偷偷跑到 9001

我已经做了这些清理：

• 启动了 roscore
• 清掉了旧的 data_converter_node 进程
• 删除了残留的 /data_converter_node/udp_port
• 清理了 ROS Master 上残留的同名节点注册

你后续正常启动顺序建议固定为：

1

roscore

1 2 3 4

cd /home/wjy12394/codex-project/codex-demo/ros1_side_ws source /opt/ros/noetic/setup.bash source devel/setup.bash rosrun data_example dual_arm_topic_publisher.py

1 2 3 4

cd /home/wjy12394/codex-project/codex-demo/ros1_side_ws source /opt/ros/noetic/setup.bash source devel/setup.bash rosrun data_converter data_converter_node

如果以后又出现“默认命令直接退出”，优先检查这三件事：

• roscore 是否已启动
• ss -lunp | rg 9000 看端口是否被旧进程占用
• rosnode list | rg data_converter 看是否有残留同名节点

如果你愿意，我下一步可以继续把这个问题彻底“固化修复”到代码里，比如让 data_converter_node 在 bind 失败时把原因明确打印到终端，而不是现在这样静默退出。

User

我愿意

Codex

已经补好了，核心改动在 data_converter_node.cpp。

现在 data_converter_node 的启动诊断比之前清楚很多，主要增加了三件事：

• 启动前先检查 ROS Master，可达性失败时直接在终端打印明确提示
• UDP bind 失败时，把端口号和系统错误一起打出来
• log_dir 不存在时自动创建，避免“节点跑了但没有日志目录”的假象

我已经重新编译通过，并实际验证过新的报错输出。现在如果没开 roscore，你会直接看到这种信息，而不是之前那种不够直观的退出：

1	data_converter_node failed: cannot contact ROS master at http://localhost:11311. Start 'roscore' first and then rerun this node.

也就是说，后面你再遇到启动失败，终端会更明确地区分这几类情况：

• roscore 没启动
• UDP 端口被占用
• 日志目录创建失败

你现在可以按这个顺序启动：

1

roscore

1 2 3 4

cd /home/wjy12394/codex-project/codex-demo/ros1_side_ws source /opt/ros/noetic/setup.bash source devel/setup.bash rosrun data_converter data_converter_node

如果你愿意，我下一步可以继续把“端口占用”的提示再做得更友好一些，比如直接提示你去执行哪条命令查看 9000 端口是谁占用。

User

rosrun data_converter data_converter_node

[INFO] [1775180663.925689934]: data_converter_node startup: udp_port=9000 realtime_hz=2.00 heartbeat_timeout_ms=3000 jpeg_quality=75 log_dir=.

data_converter_node failed: socket bind failed on udp_port=9000: Address already in use

难道我每次都要手动kill一下之前的进程关闭端口吗？不能直接ctrl+c中止自动关闭端口吗？

Codex

正常情况下，不需要。

Ctrl+C 对前台运行的 data_converter_node 是会正常退出并释放 UDP 9000 端口的。UDP 也没有像 TCP 那样的 TIME_WAIT 问题，所以只要进程真的结束，端口会立刻释放。

你现在看到 Address already in use，说明不是“端口没及时释放”，而是“还有一个旧的 data_converter_node 进程还活着”。这通常只会发生在这几种情况：

• 之前的节点是在另一个终端里启动的，你按的不是它那个终端的 Ctrl+C
• 之前是被后台启动的
• 之前启动了不止一个实例
• 我前面联调时留下了残留进程

先直接查一下是谁占着 9000：

1	ss -lunp | rg 9000

如果确认是旧的 data_converter_node，清掉它：

1	pkill -f data_converter_node

然后再启动：

1 2 3 4

cd /home/wjy12394/codex-project/codex-demo/ros1_side_ws source /opt/ros/noetic/setup.bash source devel/setup.bash rosrun data_converter data_converter_node

关键结论是：

• Ctrl+C 本身没问题
• 你不应该每次都手动 kill
• 现在之所以要 kill，是因为机器上已经有残留实例在运行

更稳妥的做法不是让节点“自动杀掉旧进程”，因为那样风险比较大，而是：

• 启动前先检查端口占用并提示 PID
• 或者提供一个单独的启动脚本，先检查旧实例，再决定是否重启

如果你愿意，我下一步可以直接帮你加一个 start_data_converter.sh，做到：

• 发现旧实例就提示
• 可选自动清理旧实例
• 然后再启动新节点

这样你以后就不用手动排查了。

User

现在点击一键请求图像，会显示接收中，但是无反应，一直请求不到图像

Codex

问题已经定位并修了，根因不是按钮没发请求，而是图像 UDP 传输量太大，Qt 侧一直收不齐。

我从日志里确认到这几点：

• Qt 侧确实发出了请求：image_request_sent
• data_converter 确实收到了请求并开始回图：image_prepare、image_sent
• Qt 侧也收到了很多分片，甚至收到了 image_end_received
• 但同一时刻丢片非常严重，比如：
  • missing=281
  • missing=199

这就是为什么界面一直停在“接收中…”，而且四个目录里没有文件。不是没请求到，而是 4 路 1280x720 图同时分片直发，UDP 丢包后一直拼不完整。

我已经在 data_converter_node.cpp 做了这几个修复，并重新编译通过：

• 发送前先缩放图片，默认缩到不超过 640x360
• 每个 chunk 之间增加节流，默认 1500us
• 每路相机之间增加间隔，默认 30ms
• 启动日志里会打印这些参数，方便确认当前生效配置

现在你先这样重启链路再试一次：

1

roscore

1 2 3 4

cd /home/wjy12394/codex-project/codex-demo/ros1_side_ws source /opt/ros/noetic/setup.bash source devel/setup.bash rosrun data_example dual_arm_topic_publisher.py

1 2 3 4

cd /home/wjy12394/codex-project/codex-demo/ros1_side_ws source /opt/ros/noetic/setup.bash source devel/setup.bash rosrun data_converter data_converter_node

然后再启动 Qt，点一次“一键请求图像”。

如果你还想更稳一点，我建议下一步继续把默认负载再压低一点，例如：

• image_max_width=480
• image_max_height=270
• jpeg_quality=50

如果你愿意，我可以继续把这些参数直接调成更保守的默认值，优先保证“点一次就稳定出图”。

5.2 优化图像传输

User

现在有一定概率能显示了，但是我希望传输原图，不进行任何降采样，请重新实现传输图片的协议，我对传输时间无要求。

Codex

已经按你的要求改成“原图传输，不做任何降采样”，并把图片协议重构成了可靠顺序发送。

这次的关键变化在 data_converter_node.cpp：

• 保留原图尺寸，不再缩放
• 图片不再一次性把几百个分片全发出去
• 改成 IMAGE_CHUNK/IMAGE_END 逐片发送
• 每发一片都等 Qt 回 ACK
• 超时没收到 ACK 就重发当前片
• 收到当前片 ACK 后才继续下一片

协议说明也同步更新到了 protocol_v1.md。

我已经重新编译通过：

1 2	cd /home/wjy12394/codex-project/codex-demo/ros1_side_ws catkin_make -j1

你现在需要重启这条链路再测一次：

1

roscore

1 2 3 4

cd /home/wjy12394/codex-project/codex-demo/ros1_side_ws source /opt/ros/noetic/setup.bash source devel/setup.bash rosrun data_example dual_arm_topic_publisher.py

1 2 3 4

cd /home/wjy12394/codex-project/codex-demo/ros1_side_ws source /opt/ros/noetic/setup.bash source devel/setup.bash rosrun data_converter data_converter_node

然后再启动 Qt，点击 pushButton_4。
这次传输会比之前慢，但目标就是稳定把原图收齐，并最终写到：

• left
• right
• scene1
• scene2

如果你愿意，我下一步可以继续帮你做一轮实测，把这条“原图可靠传输”从点击按钮到实际落盘完整验证一遍。

User

我现在可以等待到图片显示了，但我还是希望先存图再显示，@ros1_side_ws/src/data_converter/data_converter_node.cpp data_converter端可以将图片压缩成JPG再进行传输，在ui这端需要先保存再显示，请继续在label_86，label_87，label_88，label_89中显示传输进度，请根据我的思路修改代码。

Codex

已经按你的思路改好了。

现在链路是这样：

• data_converter 端继续把图像压成 JPG 再传
• ui_console 端先接收完整 JPG
• 先保存到磁盘
• 保存成功后，再从保存好的文件加载并显示到界面

这次主要改动在 mainwindow.cpp 和 mainwindow.h。

现在四个标签的行为变成了：

• label_86 对应 left
• label_87 对应 right
• label_88 对应 scene1
• label_89 对应 scene2

点击 pushButton_4 之后：

• 先显示“接收中…”
• 接收过程中显示每路的进度：
  • 已收 chunk 数
  • 总 chunk 数
  • 百分比
  • 是否已收到 IMAGE_END
• 完整收齐后：
  • 先写文件到对应目录
  • 再从文件路径加载图片并显示
• 如果保存失败，会明确在 label 上显示“保存失败”
• 如果保存成功但界面加载失败，会显示“已保存，显示失败”

保存目录仍然是：

• left
• right
• scene1
• scene2

我已经重新编译通过：

1 2 3

cd /home/wjy12394/codex-project/codex-demo/ui_console qmake ui_console.pro make -j2

你现在可以直接重启 Qt 再测一次。
如果你愿意，我下一步可以继续帮你把四个 label 的进度文案再优化一下，比如显示成更紧凑的“scene1 63%”这种样式。

5.3 基本功能优化

User

请将默认IP改为127.0.0.1，另外帮我做：

• 逐项核对 mainwindow.ui 上每个实时遥测框和协议字段是否一一对应
• 把“实时遥测未连接/已连接/数据更新时间”做成界面提示，方便你现场判断是不是断流

Codex

已经处理好了。

默认连接地址现在是：

• IP = 127.0.0.1
• Port = 9000

对应改动在 mainwindow.cpp。

实时遥测状态提示也已经做进界面状态栏了，现在会持续显示这几种状态：

• UDP未连接 | 实时遥测未连接
• UDP已连接 127.0.0.1:9000 | 实时遥测等待数据
• UDP已连接 ... | 实时遥测已连接 上次:HH:mm:ss msg=0x1001
• UDP已连接 ... | 实时遥测断流 上次:HH:mm:ss msg=0x1008

相关逻辑在：

• mainwindow.h
• mainwindow.cpp

另外，我把 mainwindow.ui 和当前协议做了核对，实时遥测这部分是一一对应的，当前映射是：

右臂：

• label_9：使能状态
• label_11：控制模式
• lineEdit_5：关节角
• lineEdit_6：关节速度
• lineEdit_7：关节电机速度
• lineEdit_8：关节电机电流
• lineEdit_9：关节制动器状态
• lineEdit_41：夹爪电机速度
• lineEdit_42：夹爪位置
• lineEdit_21：末端六维力
• lineEdit_20：末端位姿 arm base
• lineEdit_24：末端速度 arm base
• lineEdit_22：末端位姿 robot base
• lineEdit_23：末端速度 robot base
• lineEdit_43：抓取点
• lineEdit_27：关节输出速度
• lineEdit_25：关节输出位置
• lineEdit_26：驱动指令
• lineEdit_28：算法错误标志位
• lineEdit_29：到位标志位

左臂：

• label_10：使能状态
• label_12：控制模式
• lineEdit_10：关节角
• lineEdit_11：关节速度
• lineEdit_12：关节电机速度
• lineEdit_13：关节电机电流
• lineEdit_14：关节制动器状态
• lineEdit_59：夹爪电机速度
• lineEdit_60：夹爪位置
• lineEdit_15：末端六维力
• lineEdit_16：末端位姿 arm base
• lineEdit_17：末端速度 arm base
• lineEdit_18：末端位姿 robot base
• lineEdit_19：末端速度 robot base
• lineEdit_40：抓取点
• lineEdit_31：关节输出速度
• lineEdit_33：关节输出位置
• lineEdit_32：驱动指令
• lineEdit_34：算法错误标志位
• lineEdit_30：到位标志位

按需遥测：

• lineEdit_35 / 36 / 37：右臂 speed_loop_p / d / brake_duty_cycle
• lineEdit_50 / 51 / 52：左臂 speed_loop_p / d / brake_duty_cycle

保留为 N/A 的是：

• lineEdit_38
• lineEdit_39
• lineEdit_53
• lineEdit_54

这四个目前仍然没有对应协议字段，现状和实现是一致的，不是漏接。

我已经重新编译通过：

1 2 3

cd /home/wjy12394/codex-project/codex-demo/ui_console qmake ui_console.pro make -j2

如果你愿意，下一步我可以继续把“实时遥测状态”做得更直观一点，比如在界面上再加一个醒目的红绿状态标签，而不只是状态栏。

User

请加入红绿状态标签

codex

红绿状态标签已经加上了，并且编译通过。

现在界面右下角状态栏会多一个醒目的状态标签，颜色规则是：

• 红色：未连接
• 黄色：等待数据 或 已断流
• 绿色：已连接

实现位置在：

• mainwindow.h
• mainwindow.cpp

当前效果是两层提示同时存在：

• 状态栏文字：显示 UDP连接状态 + 实时遥测最近更新时间 + 最近一帧 msg_id
• 状态标签：用红/黄/绿快速告诉你现在是不是正常在流动

你现在现场判断可以这样看：

• 红色：根本没连上
• 黄色：
  • 刚连上但还没收到实时帧
  • 或者之前收到了，但已经超过 3 秒没新帧，属于断流
• 绿色：实时遥测正在正常更新

另外，前面你要的两项也已经都完成了：

• 默认 IP 已改成 127.0.0.1
• mainwindow.ui 上实时遥测框和协议字段已经逐项核对过，当前映射是对齐的

Qt 已重新编译通过：

1 2 3

cd /home/wjy12394/codex-project/codex-demo/ui_console qmake ui_console.pro make -j2

如果你愿意，我下一步可以继续把这个状态标签再做细一点，比如：

• 红色 UDP断开
• 黄色 已连接但无遥测
• 黄色 遥测断流
• 绿色 遥测正常

这样现场区分会更直观。

User

现在的问题是label_9、label_10、label_11 、label_12未更新，请在ui界面实时显示。

Codex

已经处理了，label_9、label_10、label_11、label_12 现在会在收到实时状态帧时显式更新。

这次我做了两层保证：

• 保留原来的 updateStateWidgets(...) 更新逻辑
• 额外新增了直接更新四个标签的路径，在收到：
  • 0x1007 右臂状态帧时，直接刷新 label_9、label_11
  • 0x1008 左臂状态帧时，直接刷新 label_10、label_12

另外我顺手加了更直观的样式：

• 使能：绿色
• 失能：红色
• 模式标签：蓝色加粗

改动位置在：

• mainwindow.cpp
• mainwindow.h

Qt 已重新编译通过：

1 2 3

cd /home/wjy12394/codex-project/codex-demo/ui_console qmake ui_console.pro make -j2

你现在重新启动 ui_console 后，这四个标签应该会随着实时遥测状态帧实时变化。
如果你愿意，我下一步可以继续把这四个标签旁边补一个“最近更新时间”，这样你能更直观看出是不是状态帧没到。

User

我现在希望添加一下UDP连接后的断开功能，pushButton在连接成功后文字变成断开。

Codex

已经加好了，pushButton 现在会在连接成功后切成“断开”，再次点击会主动断开当前 UDP 会话，并把按钮文字切回“连接”。

改动在 mainwindow.cpp 和 mainwindow.h。当前行为是：

• 初始显示：连接
• 收到 CONNECT_ACK 后：按钮变成 断开
• 再次点击：清空当前会话状态、停止重连计时、清空图像接收缓存、状态栏恢复未连接，并弹出“已主动断开与 data_converter 的 UDP 连接”
• 如果心跳超时断开：按钮也会自动恢复成 连接

我已经重新编译通过：

1 2 3

cd /home/wjy12394/codex-project/codex-demo/ui_console qmake ui_console.pro make -j2

你现在直接重启 ui_console 测一下就行。如果你愿意，我下一步可以继续把“断开”做得更完整一些，比如断开时顺手清空实时遥测显示和顶部状态标签。

5.4 UI界面优化

User

现在请求图像的界面四张图的ui大小不一致，请帮我修改，另外还有什么可优化的可视项都帮我优化下。

Codex

已经整理好了，四张图现在会按统一尺寸和统一显示规则渲染，不会再出现一张大一张小的视觉问题。

这次我做了两类优化。界面层面，我把 mainwindow.ui 里的 label_86、label_87、label_88、label_89 统一成 480x270，位置也对齐了。逻辑层面，我在 mainwindow.cpp 和 mainwindow.h 里把图片卡片样式、占位态、进度态、保存后显示都统一了：未请求时显示“等待请求”，请求后显示更清楚的传输进度，保存成功后再从磁盘重载显示，并且窗口尺寸变化时会自动按同一规则重绘，始终保持 KeepAspectRatio 居中显示。

顺手一起优化的可视项有这些：

• 四个图框统一背景、边框、圆角、字体权重，空态不再显得凌乱。
• 进度文案改成更直接的格式，例如“传输进度 63% / 分片 120/190 / 尾帧已到达”。
• 已保存图片会记录路径并在窗口变化时重新缩放，避免后来切页或拉伸窗口后四张图显示风格不一致。
• 占位文字统一为两行格式，便于现场看状态。

我已经重新编译通过：

1 2 3

cd /home/wjy12394/codex-project/codex-demo/ui_console qmake ui_console.pro make -j2

如果你继续想收一轮视觉细节，我建议下一步做两个小项：

• 给四个图框标题 left/right/scene1/scene2 也统一成更醒目的标题条样式。
• 在每张图下方加“最近保存时间”或“最后一帧 snapshot_id”，现场调试会更方便。

User

现在有几个问题：

• 四个图的传输进度百分比用了两个百分号；
• 四个图的位置没有对齐，大小已经对齐了；
• 需要断开连接后清空实时遥测显示；
• 实时遥测的控制模式部分占位太小，文字显示不完全；

Codex

这四个问题都已经处理好了，并且我重新编译通过了。

改动在 mainwindow.cpp 和 mainwindow.ui：

• 图像传输进度里的百分号已经改成单个显示，不会再出现两个 %。
• 四张图的位置已经对齐，之前是 label_89 的 y 坐标比另外三张少了 10 像素，现在四个图框都在统一网格上。
• 断开连接后会清空实时遥测显示，界面恢复到初始态：
  • 顶部状态回到 失能 / 待机模式
  • 实时和按需遥测内容清空
  • N/A 的四个框继续保持 N/A
  • 心跳超时断开时也会做同样处理
• 控制模式的显示宽度已经放大，label_11 和 label_12 从 61 扩到 121，常见模式文字不会再被截断。

我已经跑过：

1 2 3

cd /home/wjy12394/codex-project/codex-demo/ui_console qmake ui_console.pro make -j2

你现在直接重启 ui_console 看效果就行。
如果你愿意，我下一步可以继续把“断开后图像区是否保留上一帧”也做成统一策略，现在我建议默认保留图像、只清空遥测，这样调试时更直观。