2026-01
Jan. 29
机器人操作及安全事项
具身机器人由于其体积质量和材质，已经完全可以归类为中型机械。其操作过程中存在对人身造成伤害的风险。 因此规范每个需要实际接触甚至操作机器人的员工的操作行为是很有必要的。尤其是新员工，建议作为入职培训要求每个新人销售、技术掌握基本操作和安全行为规范。 各家机器人的实际操控可能有所区别，但是一些基本环节都是共通的，譬如吊装、急停、吊架移动、开关机顺序等。 还有最重要的安全规范，包括电量检查、站立前舵机姿态检查、吊绳就位情况、周边障碍物清理、误操作后的各种后果及其正确应对方式等。 建议整理成制度文档。 如果将来机器人到得更多甚至可以考虑增加考核环节。
Jan. 27
技术部门的绩效评测维度
- 任务完成时效 - 25%
- 关键技术掌握及创新 - 25%
- 编码质量及程序运行健壮度 - 25%
- 文档完善度 - 25%
每个维度按 1 -> 5 星评级。
-
任务完成时效：在项目进度计划内按要求完成任务（以阶段验收测试通过为准）得 3 星。提前 3 天以上 4 星。 在提前完成自身任务的前提下协助同项目其他队友使项目整体进度提前可得 5 星。 任务拖延3天以内 2 星， 未完成 1 星。
-
关键技术掌握及创新：对自己所负责项目的技术栈和算法原理有完整的理解，不存在大模型代写后不知道写了啥的情况，3 星。 总结现有开源实现或算法，提出新的能提高现有方案的新实现或算法，4 星。 向现有开源项目提 pr 并成功 merge / 发表一篇论文，5 星。 项目所用技术部分掌握，2星。 大模型代写，实际功能不了解，1星。
-
编码质量及程序运行健壮度：无重大功能性 bug, 程序按期望运行（所有测试用例通过）3星。程序覆盖了足够多的 exception 和 error 处理，健壮程度高,4星 前者基础上变量命名规范，注释清晰，编码语义精炼高效且优雅，5 星。优雅的具体定义参考 Linux coding style. 越符合文档内格式要求的代码越优雅。 程序能跑，但是有 bug ，或编码混乱可读性差， 2星。 程序存在功能性 bug, 经常无法跑完，1 星。
-
文档完善度：有正确清晰的使用文档，3 星。 有文档生成工具，如 doxygen 生成的 api 文档，或详细的代码内文档，如 js 的 jsdoc 注释块，4 星。 有手写的详细的开发文档（说明各个代码块的功能分类和实现），5 星。 文档简陋敷衍，大模型生成未细致完善，2星。 没写文档，1星。
上述 4 个维度所有评分相加，单季度获得 12 星以上的，拿 100% 绩效（80% 基本工资+ 20% 绩效）。 达到 16 星的， 110% 绩效（80% 基本工资+ 30% 绩效）。 19-20 星的 120% 绩效 （80% 基本工资+ 40% 绩效）。 8星到11星 90%。 4星到7星 80%。
另：额外贡献可酌情获 1-2 星 bonus。 包括不限于长期驻场出差、同时兼多个项目、积极帮助同事解决困难、人缘极佳提升技术部氛围等等。
Jan. 26
grasp 和 joint 节点的优化，用于到达目标位置后推出程序，方便后续通过 launch 文件控制多步骤移动
在 joint tuple 或灵巧手节点加入 is_reached 成员判断到达状态，并用 std::all_of() 判断是否所有关节都已就位。
之后参照 ROS2 官方文档 编写多步骤运控执行。
TODO
-
通过
disparity图获取stereo_left/image_rect_color图的深度信息，再转换成stereo_left_rectified_optical_frame到object frame的 tf 进行发布。（视觉组） -
利用已完成的
joint和grasp节点编写分阶段多目标点的拼接任务。 -
调试出抓握和举臂的最佳参数，尝试编写摆臂范围内的目标点坐标到各关节参数的对应映射。
-
编写 walker s2 或天工的 rl 学习 env cfg （如果需要）。
Jan. 23
给定空间坐标的前提下（视觉判定）手部动作对应的各关节参数
有两种方法确定空间坐标到手部关节参数矩阵的映射。一是算出这样的映射矩阵或函数，二是用大量对应点位凑出，或者叫拟合出近似函数。后者其实就是大模型的思路。 已经安排运控人员尝试第一种方法。
识别物体并通过 disparity 图像定位深度信息后的 transform 发布
已安排视觉人员在识别到对象后将坐标通过 tf2 发布出去。需要解决图像坐标到 tf 数值之间的映射数值。然后在识别节点内 sendTransform(t)
/point2 主题发布的点云没有正确匹配到双目摄像头的坐标 link
详细分析 /tf_static 后发现 stream_repub 节点发布的 image_raw 和 camera_info 主题的 frame_id 应该是 stereo_<left/right>_rgb_optical_link
而不是原先的 stereo_<left/right>_rgb_link 。
修正后图像跟机器人的相对坐标正常，stereo_left_rectified_optical_frame 也能跟点云之间建立正确相对映射。
Jan. 22
/disparity 主题获取后通过已有 tf 获取 world 平面
通过图像模型识别物体后将框体放置在 disparity 帧中，识别最近的像素。再计算坐标转换获取物体跟相机之间的 transform 变换。
已经安排视觉人员推进。
抓取节点的编写
对灵巧手的操控节点已经编写完成，运行方法：根据灵巧手3代或4代对 grasp.cpp 进行相应注释后
cd ~/Projects/ros2_ws/
colcon build --symlink-install
. install/setup.bash
ros2 launch ./launch/grasp.launch.py
Jan. 21
stereo_imge_proc 节点改进后的启动命令
cd ~/Projects/ros2_ws/launch
ros2 launch ./stereo_image_proc.launch.py left_namespace:=/stereo_left right_namespace:=/stereo_right
/disparity 和 /pointcloud2 主题没有输出
这两个主题的节点默认需要左右相机的 /image_raw 主题的 timestamp 完全一致，即 --approximate_sync:=False 。在 ~/Projects/ros2_ws/launch/stereo_image_proc.launch.py 里把 approximate_sync 设为 True 即可
return LaunchDescription(
[
DeclareLaunchArgument(
name="approximate_sync",
default_value="True",
description="Whether to use approximate synchronization of topics. Set to true if "
"the left and right cameras do not produce exactly synced timestamps.",
),
# ...
]
)
Jan. 20
img.to_ndarray(format='bgr24') 之后不能在 CvBridge().cv2_to_imgmsg(img, encoding="passthrough") 中直接传 passthrough
to_ndarray() 函数的参数 format 和 cv2_to_imgmsg() 的参数 encodings 不是一回事。前者会转换成 OpenCV CvMat types 的 8CU3，后者是 image encoding.
而 8CU3 的可转换 image coding 是 bgr8
stream_repub 节点配合 camera_calibration 包进行标定
ros2 run camera_calibration cameracalibrator --approximate 0.1 --size 7x4 --square 0.076 --ros-args --remap right:=/stereo_right/image_raw -r left:=/stereo_left/image_raw
uv 配合 colcon build 用法
cd ~/Projects/ros2_ws/src
# Distrobox
ros2 pkg create --build-type ament_python stream_repub
# Back to host
cd stream_repub
uv init
uv python pin 3.10
uv venv --system-site-packages
# Write scripts...
# Add env for colcon python interpreter in distrobox
source .venv/bin/activate
cd ~/Projects/ros2_ws
export COLCON_PYTHON_EXECUTABLE=$(which python)
export PYTHONPATH=$VIRTUAL_ENV/lib/python3.10/site-packages:$PYTHONPATH
colcon build --symlink-install
抓取动作节点的编写阻碍
目前空客 s2 的四代机械手抓取工具的节点，其 manipulate 部分基本已经跑通，视觉部分的图像模型已经训练完成，检测精度理想。 但获取深度信息部分（用到双目摄像头）存在硬件层面的阻碍。
- 计算深度信息需要左右相机
sensor_msgs/msg/Image的image_raw主题，由机器人提供的只有shm_msgs/msg/Image8M，这部分通过额外部署ros2_shm_msgs节点可以解决。 - 要使用
stereo_image_proc包把左右相机的image_raw计算转换为 disparity 和 pointcloud 。该 package 需要标定好的带时间戳的camera_info信息，目前机器人的 info 信息缺时间戳和长宽，导致stereo_image_proc包不能正确输出 disparity 和 pointcloud 。 - 尝试自己标定双目相机，但机器人没有提供可以远程 vnc 或 ssh -X 连入的图形界面。在远程订阅的话由于 Image 消息格式占用带宽格式过大，无法通过 cameracalibrator 包获取 Image 流完成标定。
- ubt 不提供对双目相机硬件的直接读取，其相机节点（或者也叫双目相机驱动）没有提供类似 /set_camera_info 的 service。既没办法自己写节点从相机硬件发布 camera 流也没法修改厂家的驱动节点。
- 目前在考虑妥协方案：从机器人里推流出 h264 编码的视频，在远程开发机上用
ffmpeg_image_transport包转成sensor_msgs/msg/Image完成标定，后续也继续通过这种转换在开发机计算深度信息，在发出控制 topic
关二开 sdk 刷入后的 bgm
在 udoke 界面里，vision -> walker -> voice -> speech_service.environment 里把 volumn_bgm_env 改为 0.0
Jan. 19
训练中心的 s2 不能启动
因为新装了 3 代灵巧手，而有灵巧手和没有的 HW_TYPE 不同，因此需要去 udoke 的 motion 页里把环境变量改了
# Without hand
HW_TYPE=walker_s2_v1
# With hand
HW_TYPE=walker_s2_v1_sps
Jan. 16
双目相机深度节点
先需要使用 ros2_shm_msgs 包把 shm_msgs/msgs/Image8M 主题转成 sensor_msgs/msgs/Image
cd ~/ros2_ws/src
git clone https://github.com/ZhenshengLee/ros2_shm_msgs.git
nano ros2_shm_msgs/src/ros2_shm_msgs/tool/shm_image_bridge.hpp
# modify line 48,49
# auto qos = rclcpp::QoS(10);
# qos.best_effort();
nano ros2_shm_msgs/src/ros2_shm_msgs/launch/shm_image_bridge.launch.py
# modify as below
cd ..
colcon build
. install/setup.bash
ros2 launch shm_msgs shm_image_bridge.launch.py
import launch
import launch.actions
import launch.substitutions
import launch_ros.actions
def generate_launch_description():
return launch.LaunchDescription(
[
launch_ros.actions.Node(
package="shm_msgs",
executable="shm_image8m_bridge",
output="screen",
name="stereo_left_bridge",
remappings=[
("shm_image_input", "sensor/camera/stereo_left/image/raw"),
("sensor_image_output", "sensor/camera/stereo_left/image/image_raw"),
],
parameters=[],
),
launch_ros.actions.Node(
package="shm_msgs",
executable="shm_image8m_bridge",
output="screen",
name="stereo_right_bridge",
remappings=[
("shm_image_input", "sensor/camera/stereo_right/image/raw"),
("sensor_image_output", "sensor/camera/stereo_right/image/image_raw"),
],
parameters=[],
),
]
)
再安装、配置、开启 stereo_image_proc 节点
sudo apt update && sudo apt install ros-humble-image-pipeline
mkdir -p ~/ros2_ws/launch && cd ~/ros2_ws/launch
cp /opt/ros/humble/share/stereo_image_proc/launch/stereo_image_proc.launch.py ./
cp /opt/ros/humble/share/image_proc/launch/image_proc.launch.py ./
# Modify configuration of the two launch file. Remap the correct topics.
# nano stereo_image_proc.launch.py
ros2 launch ./stereo_image_proc.launch.py left_namespace:=sensor/camera/stereo_left/image right_namespace:=sensor/camera/stereo_right/image
双目相机标定数据可能有问题
缺 width 和 height 数据，timestamp 也没有一起发布。其他数据的准确性存疑。用 stereo_image_proc 节点算深度数据会提示 image_color 和 camera_info not synced.
Jan. 15
抓取动作手部细节
4 代灵巧手似乎没有压力检测，且只能通过关节位置控制。 因此要实现对大部分工具的抓握需要额外的硬件支持，至少现有的二开 sdk 没法保证覆盖所有的抓握场景。
手臂关节控制
已经完成 airbus_project - joint 节点，通过
ros2 launch airbus_project joint.launch.py
操作手臂生起（其他关节也可以）
通过 launch 文件 ~/Projects/ros2_ws/src/airbus_project/joint.launch.py 中的 parameters 参数的修改可以达成对全部关节的操控。
另一个 launch 文件 ~/Projects/ros2_ws/src/airbus_project/joint_reset.launch.py 用于回正关节。
Jan. 14
抓取动作编码
经过对各关节节点的详细测试已经初步完成肩肘关节的抓取动作编码。详见 ~/Projects/ros2_ws/src/airbus_project/src/grasp.cpp
静音 BGM
进 udoke 管理页 https://192.168.11.2:9000 walker:Walkerubtnb666 后
将 vision -> walker -> voice 容器中的字段改为 volumn_bgm_env=0.0
图像模型有漏检错检
让刘莹将陈汉钊新拍的 200 张照片混合加了噪声的老照片进一步训练后得出了 v2 版模型， 新模型效果很好，没有再出现错检漏检。
Jan. 13
ubt 二开 sdk 刷入流程
- 解压
walker-s2-v0.5.1-6-g1173530_offline.tar.gz scp motion.tar walker@192.168.11.2:~/ && scp vision.tar walker@192.168.11.3:~/ssh walker@192.168.11.2 'docker load -i ~/motion.tar' && ssh walker@192.168.11.3 'docker load -i ~/vision.tar'- 网页访问
192.168.11.2:9000登录walker:Walkerubtnb666，页面左下上传walker-s2-v0.5.1-6-g1173530.tar.gz。 - confirm 忽略报错。（这之后两个板子的容器都会停止）
ssh walker@192.168.11.2 'udoke up -c walker' && ssh walker@192.168.11.3 'udoke up -c walker'
客户新需求
从 B6 开始在户外通过遥控方式走到 B4 进户内搭乘电梯（人工开门）。上二楼后出电梯开始自主导航至会议室并做出打招呼动作。
客户希望给机器人穿外衣（有可能遮挡后摄像头）、穿鞋子（嫌脚步声音响）
希望能完成 「领导将工牌系带交到机器人手上，机器人自己套到脖子上」这个动作。
通过遥控器 G→ 实现的上肢动作失效
因为刷了二开 sdk 后这些预设动作都没了
训练的图像模型效果
有部分漏检和错检，让她重新跑了 300 个 epoch 之后有一定改善，但还是存在一次错检和一次漏检。 错检可以通过 prob 阈值进行筛选，但漏检就没啥办法，需要改善模型，也就是拍更多照片标记好多跑点。
二开 sdk 效果
提供的 demo 已经可以跑，头手肘都能动起来，肩部需要自己写代码试。
Jan. 9
IsaacLab 仿真环境
source ~/Projects/IsaacLab/env_issaclab/bin/activate
walker s2 的二次开发 sdk 不可用
ubt 的文档和 demo 都跟空客现场这台 walker s2 的系统不匹配。连接方式、topic/service 名称都是不一样的。 沟通后是 ubt 这台 s2 出厂后没有搭载二次开发 sdk ，可能需要手动安装二开 sdk 或升级主版本，最终决定由深圳邮寄二开 sdk 的 U 盘到天津刷系统。
Jan. 8
运控、抓取、搬运操作实操
跟 ubt 沟通后他们只能提供非常简单的样例和文档，复杂操作需要自己试。由于机器人关节运动有一定的危险性，非常不推荐无文档无样例自己试这些操作。
图像大模型识别
让陈汉钊拍了200张左右的锤子图片，裁切到 640x480 大小让刘莹打了下标。鉴于刘莹完成得很好，yolo 训练也不是很耗算力，打算让她先在办公电脑上尝试训练一份锤子模型。
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 以外的静态地址都去掉后就行了。