2026-01

Jan. 8

walker s2 的推流方案

ubt 没有提供内部文档，因此只能自己把方法试出来。

首先确实是从容器 f9d4c8d31c14 即 walker-drivers.video_streaming-1 中执行的 VideoStreaming 节点实现推流。

该节点注册了两个服务 /streaming/start /streaming/stop ，（在 rosa 中而非 ros2）

其接口参数消息类型为 rosa_msgs/srv/VideoStream

ubt@vision:~$ ros2 interface show rosa_msgs/srv/VideoStream
string srs_url                  # streaming server url
string topic_name               # topic name to subscribe for video stream
string topic_type               # topic type:  image/image1m/image2m/image4m/image8m/image8k/image512k
int32  encode_width 640         # encode width
int32  encode_height 400        # encode height
int32  capture_fps 15           # capture fps
int32  encode_fps 10            # encode fps
int32  gop_size 50              # encode gop size
string codec_name "libx264"     # encode codec name
---
string heartbeat_topic          # Topic that client needs to publish empty messages periodically to keep the stream alive
string stream_url               # The URL where the video stream can be accessed
int32 code                      # 0: success, non-zero: failure

call /streaming/start 即可开启到 srs 服务器的推流

ros2 service call /streaming/start rosa_msgs/srv/VideoStream "{srs_url: 'rtmp://192.168.11.3:1935/sensor/camera/image', topic_name: '/sensor/camera/fisheye_right/image/raw', topic_type: 'image8m'}"

然后需要客户端持续往 heartbeat_topic 发送空消息保持推流。超时自动断开。

不过这样的推流方式似乎跟 ubt 网页端使用的方式还是有细微区别，后者可以同时保持 flv 和 webrtc 两种协议，且不同相机推流的 rtmp url 为同一个，不知道怎么实现的。

Jan. 7

取流及识别方案

因为 ubt 没有提供内部文档或者解答开始推流的消息方式，因此暂时只能从 ubt 的网页界面手动开始推流，再开始获取视频画面。

取流方式最简单的一种是直接取自 flv 地址，如 http://192.168.11.3:8080/sensor/camera/fisheye_left/image.flv 。

该方式延迟较高，在实际识别过程中可能影响效果。

另一种 webrtc 方式延迟极低。实现稍微繁琐，且目前无法正常获取解码后的帧（待解决）

Jan. 6

ubt 的推流方案

使用 srs 作为推流工具。docker id 是 3140a72fa2c0 。访问 192.168.11.3:8080 可以看到 srs 管理页。

推流具体方式为：前端通过 websocket(或 mqtt?) 发送消息到容器，容器收到消息后订阅主题，如 /sensor/camera/fisheye_right/image/raw 并编码 ffmpeg 编码开始推流至 1935 端口的 rtmp 服务，再通过 srs 以 webrtc 协议推到前端网页。

最好可以拿到 walker s2 中各个容器的功能说明，不然就要一个一个进去看。

Jan. 5

用户界面编写设计

需要实现简化版启停操作，并预设固定任务供客户选择。技术选型采用 React + roslib 框架。

walker s2 行走及工具抓取任务实现

方案一：在算力服务器上部署 Isaac Lab ，利用厂家提供的 urdf 编写仿真环境。使用 rl 强化学习进行训练。可以同时进行行走和抓取的训练，也可单独训练行走。抓取用方案二或三。
方案二：抓取部分用 VLA 模型如 Isaac-GR00T 。使用视觉摄像头拍摄抓取视频后训练 vla 模型。行走部分用建图导航。
方案三：用机器人自带摄像头拍摄大量工具照片并标注后用 Yolov11 训练成图像大模型，再推理后用脚本实现手臂抓取。行走部分用传统的建图导航。

以上三个方案最省时的应该是方案二。因为方案一和三需要大量的数据采集标注/仿真环境搭建时间，方案一的 rl 训练也需要较高算力。相对来说 VLA 的视频采集更简单，但抓取效果可能不够好。

walker s2 的下肢启停验证

下肢启停的一般操作为

按黑色按钮 -> F↓ + D 归零 -> H 中 + A 站立 -> 开始走
悬挂 -> F↓ + C 放松 -> 吊起来

经验证在 F↓ + C damping 状态后不能 F↓ + D 重新站起。考虑在系统中找出相应的启动进程实现重新站立。

用 `ros2_shm_msg` 库转换过来的 `std_msg/msg/Image` 图像报错 `tev: ddsi_udp_conn_write to udp/172.18.0.1:7470 failed with retcode -1`

各个摄像头发布的 raw 图像都很大，且已经被 rosbridge 订阅，因此直接在远程订阅会带宽不够。后续要获取图像还是要走 rosbridge 。

walker s2 发布的主题不能正常在远程 `ros2 topic list` 中显示

排查后是设置了太多不同网域的 ip 地址。把 192.168.11.0/24 以外的静态地址都去掉后就行了。