具身智能机器人人工智能大模型模型推理服务本地部署计算机视觉ROS【免费下载链接】IB_RobotSave the code of IB-Robot, an AI robot execution framework developed by openEuler Embedded for embodied intelligence scenarios. It includes references to the forked version of tensormsg, references to lerobot fork, code references to the lerobot_ros2:ros2_ws branch, as well as some code related to development usability.项目地址https://gitcode.com/openeuler/IB_Robot点击查看免费下载本文面向需要实际执行 IB_Robot 干净环境验证的开发者与 CI 维护者系统梳理在osrf/ros:humble-desktop-full-jammyDocker 容器中运行scripts/setup.sh与scripts/build.sh时已知的 21 个典型故障每条均给出可复现的症状、根因分析、精确修复动作并回落到仓库源码与验证流程文档中的对应实现帮助读者从看到报错快速走到理解机制、一次修复。引言陷阱清单在验证流程中的定位IB_Robot 的 Ubuntu Docker 验证流程skill 定义见 .agents/skills/ibrobot-docker-verify/SKILL.md在干净容器中端到端执行setup.shbuild.sh目标是证明按脚本安装即可复现构建。该流程遵循一条核心纪律完整论述见 .agents/skills/ibrobot-docker-verify/references/discipline.mdsetup.sh和build.sh是唯一合法的软件安装途径。即禁止在容器中手动apt install/pip install、禁止sedpatch 容器内脚本、禁止手动配置 ROS 仓库只允许配置 apt 镜像源、创建用户、通过环境变量传递镜像 URL、挂载宿主机 pip 缓存与 CUDA 工具链。所有绕过脚本的操作都会让验证结果失去意义。验证按 Phase 06 推进完整命令见 .agents/skills/ibrobot-docker-verify/references/procedure.mdPhase目的关键产出0宿主机前置检查docker、uid、pip 缓存、CUDAPROJECT_ROOT、HOST_UID、HOST_PIP_CACHE1拉取osrf/ros:humble-desktop-full-jammy镜像IMAGE_SECONDS2创建容器、配置镜像源、创建testuser、验证缓存可写CONTAINER_SECONDS3准备源码工作区三种 source mode 择一SOURCE_MODE、SOURCE_DETAILS3.5ROS 源切换预清理条件执行容器内无ros-*残留4运行setup.sh --yes并计时/tmp/setup.log、SETUP_ELAPSED_SECONDS5运行build.sh并计时/tmp/build.log、BUILD_ELAPSED_SECONDS6收集 ERROR 行、汇总计时、清理容器最终报告验证通过的标准是日志出现Setup complete! Run ./scripts/build.sh to build the workspace.与Build complete. Source with: source install/setup.sh任何 ERROR 行都必须逐条列出并归入Fatal脚本未输出完成消息、进程异常退出阻塞或Non-fatalpip resolver 警告、rosdep keys 未解析等不阻塞两类。容器命名约定固定如下SKILL.md变量值容器名verify-ubuntu2204用户testuser工作区/home/testuser/IB_Robot镜像osrf/ros:humble-desktop-full-jammypip 缓存挂载点/var/cache/ibrobot-pip下面按故障主题将 21 个已知陷阱原始清单见 .agents/skills/ibrobot-docker-verify/references/pitfalls.md分组展开。用户、权限与缓存类陷阱这一组故障的共同根因是docker exec无 TTY、docker cp保留宿主 UID/GID、bind mount 由 root 预创建父目录。它们发生在任何软件安装之前但会让后续 setup 直接失败。1.sudo: a terminal is required to read the password症状容器内 sudo 相关命令报需要终端读取密码原因Docker exec 分离模式不分配 ttyUbuntu 22.04 默认 sudoers 开启use_pty使sudo -v即便在拥有NOPASSWD:ALL时也要求终端修复Phase 2.3 必须写入testuser ALL(ALL) NOPASSWD:ALL源码佐证在 scripts/setup/common.shensure_sudo_session先尝试非交互的sudo -n true失败才回退到需要终端的sudo -v。分离模式下没有终端可用所以容器必须配NOPASSWD:ALL让sudo -n true直接成功否则ensure_sudo_session在sudo -n true返回非零时即失败——此时既无 NOPASSWD 也无缓存凭证可依赖流程在[INFO] Sudo authentication required...之后中断。2.Permission denied: ~/.cache/pre-commit症状pre-commit 读取~/.cache时 Permission denied原因bind mount 使 Docker 以 root 预创建了 home 缓存父目录发生在useradd之前导致testuser无访问权修复pip 缓存挂载到/var/cache/ibrobot-pip不要挂载到~/.cache之下对应 procedure.md Phase 2 的--mount typebind,src${HOST_PIP_CACHE},dst/var/cache/ibrobot-pip。即使 pip 目录本身可写~/.cache父目录的属主错误也会破坏 pre-commit 等工具因此挂载点选择本身就是防错设计。3.pip cache has been disabled症状pip 报告cache has been disabled原因容器 UID/GID 与宿主缓存属主不匹配通常是1000:1000被硬编码修复用宿主机id -u/id -g重建testuser并在 setup 前强制用户级写探针Phase 0 要求HOST_UID$(id -u)、HOST_GID$(id -g)procedure.mdPhase 2.3 据此useradd -m -u ${HOST_UID} -g ... testuser。Phase 2.4 的缓存写探针必须以testuser身份执行root 的test -w会产生对他人属主目录的假阳性创建并删除PIP_CACHE_DIR/.ibrobot-write-test-$$探针文件探针失败即终止验证禁止通过把宿主缓存改为 world-writable 来绕过。Phase 4 中若setup.log仍出现cache has been disabled则按基础设施错误判定验证无效、计时不可信。4.fatal: detected dubious ownership in repository ...症状后续 git 探针如 Phase 6 的git rev-parseprovenance 行报 dubious ownership原因docker cp保留宿主 UID容器用户对复制的仓库没有safe.directory记录修复Phase 2.3b 在useradd后立即把/home/testuser/IB_Robot注册为testuser的 gitsafe.directory原始记录2026-09报告步骤原本应输出 HEAD/tree却因该错误中断。修复命令为docker exec -u testuser -e HOME/home/testuser ${CONTAINER} \ git config --global --add safe.directory /home/testuser/IB_Robot注意 openEuler 变体使用通配符safe.directory *因为其工作区每个子模块都是独立 git 仓库Ubuntu 侧按需追加即可详见 .agents/skills/ibrobot-docker-verify-oee/references/pitfalls.md 对照。网络与镜像类陷阱这一组故障集中在rosdep 工具链与 apt/pip 下载源上。IB_Robot 的 setup 脚本已将国内镜像设为默认值scripts/setup.sh环境变量默认值SETUP_ROSDISTRO_INDEX_URLhttps://mirrors.tuna.tsinghua.edu.cn/rosdistro/index-v4.yamlSETUP_ROSDEP_DEFAULT_SOURCES_URLhttps://mirrors.tuna.tsinghua.edu.cn/github-raw/ros/rosdistro/master/rosdep/sources.list.d/20-default.listSETUP_PIP_INDEX_URLhttps://repo.huaweicloud.com/repository/pypi/simple/SETUP_PIP_TRUSTED_HOSTrepo.huaweicloud.com5.sh: 1: rosdep: not found症状脚本调用 rosdep 时报 not found原因rosdepc 内部调用os.system(rosdep ...)导致找不到命令修复弃用 rosdepc改为直接pip install rosdep对应 scripts/setup/rosdep.sh 的ensure_rosdep先确认 workspace venv 存在ensure_workspace_venv再${VENV_PYTHON} -m pip install --ignore-installed --upgrade rosdep并验证${VENV_PATH}/bin/rosdep --version可用ROSDEP_BIN固定指向 venv 内可执行文件避免 PATH 与 os.system 子进程环境不一致。6.error loading sources list: Permission denied症状rosdep 初始化加载 sources list 时权限拒绝原因write_rosdep_sources_list曾以 600 权限 root 属主写文件修复写完后chmod 644源码见 scripts/setup/rosdep.sh先用run_sudo mkdir -p保证/etc/ros/rosdep/sources.list.d存在通过download_default_sources_list下载内容到临时文件run_sudo mv就位后run_sudo chmod 644 ${target_file}。644 是保证普通用户可读的关键权限位此后rosdep_sources_list_needs_refresh用 grep 判断是否仍指向 raw.githubusercontent 旧源来决定是否重写。7.rosdep update超时症状rosdep update长时间无响应后超时原因ROSDISTRO_INDEX_URL未被传入平台脚本修复平台脚本显式env ROSDISTRO_INDEX_URL...传递setup.sh 的platform_install_rosdeps中scripts/setup.sh固定以env ROSDISTRO_INDEX_URL${SETUP_ROSDISTRO_INDEX_URL} ${rosdep_cmd} update --rosdistrohumble调用把 TUNA 索引 URL 传递给 rosdep同时ensure_python_ssl_cert_file会为 Python 设置SSL_CERT_FILE/PYTHONHTTPSVERIFY规避 HTTPS 证书失败导致的静默超时scripts/setup/rosdep.sh。8. pip 从 pypi.org 下载仅约 10 KB/s症状容器内 pip 直连 pypi.org 极慢原因容器内未配置 pip 镜像修复ensure_workspace_venv向${VENV_PATH}/pip.conf写入镜像配置源码见 scripts/setup/rosdep.shvenv 创建后立即生成pip.conf[global] index-url ${SETUP_PIP_INDEX_URL} trusted-host ${SETUP_PIP_TRUSTED_HOST}因为该文件位于 venv 内部而非~/.config/pip即使容器用户与宿主 UID 不一致也能被 pip 正确读取。9. rosdep 从packages.ros.org下载约 10 KB/s症状rosdep 安装依赖时命中官方 ROS 源速度极慢原因ROS desktop-full 镜像保留了 deb822 格式的ros2.sources文件修复Phase 2 在apt-get update前把.sources与.list两套 ROS 条目统一切到 TUNAPhase 2.2 的 sed 同时处理ros2.sourcesdeb822与旧式ros2.list两种格式将packages.ros.org/ros2/ubuntu替换为https://mirrors.tuna.tsinghua.edu.cn/ros2/ubuntu并在替换后 grep 校验确认无官方源残留否则 exit 1procedure.md。apt 镜像源切换Aliyun属允许的容器环境初始化不算手动安装软件。10. TUNA ROS 源索引返回 404症状apt-get update访问 TUNA ROS 源时 404原因TUNA 只提供二进制 ROS 包不提供deb-src索引修复Phase 2 把 deb822 的Types: deb deb-src改为Types: deb并删除传统deb-src条目对应 Phase 2.2 的 sed 规则s|^Types: deb deb-src$|Types: deb|与/^deb-src /d。这是镜像可用但格式不兼容的典型场景误判为网络故障会浪费排查时间。源码准备与构建工具链类陷阱这一组故障发生在工作区拷贝、venv 复用、git 工具链与 CUDA 扩展编译环节。Phase 3 的三种 source mode独立 commit 快照 / 本地工作区拷贝 / 显式远端 clone都必须执行同一动作rm -rf /home/testuser/IB_Robot/{venv,build,install,log}即禁止复用宿主或上次运行遗留的 venv 与构建产物——这是多条陷阱的共同防线。11.The build time path ... doesnt exist症状build 报构建时路径不存在原因拷贝或迭代式源码保留了宿主专属的 venv/构建路径修复删除venv build install log后从所选 source 重新执行 setup这条直接对应上面的清理命令。工作区只允许代码进入容器任何记录绝对路径的元数据venv 内脚本、build 缓存、install 布局都会在 UID/路径双重变化后失效。12.git: command not found中途失败症状setup 进行到一半时 git 命令丢失原因install_ros.sh的 apt 安装可能移除 git修复Phase 1 已装 git必要时重跑apt-get install -y git git-lfs镜像初始 bootstrap 阶段Phase 2.2即安装sudo git git-lfs locales python3 curl gnupg2 lsb-release software-properties-common若中途仍丢失按修复动作补装后重跑。这与 scripts/setup/submodules.sh 中大量git -C ...子模块操作强相关——git 缺失会让子模块初始化阶段直接中断。13. lerobot patch 栈拉取失败症状LeRobot patch 应用时 fetch 失败原因子模块本地 checkout 不含所需 base commit修复先把分支 rebase 到upstream/master再拷贝源码侧的完整契约见 scripts/setup/lerobot_patches.sh 的_lerobot_ensure_base_commit若git cat-file -e ${base_commit}^{commit}失败会尝试从 manifest 声明的 upstream 仓库 fetch 对应 tag 或 commit。base commit 通过third_party/patches/lerobot/INDEX.yaml的 active_tag 解析并受 manifestlerobot_commit_range的 fail-closed 校验约束HEAD 必须落在范围内。验证流程用IBR_LEROBOT_FORCE_REBUILD1强制在容器内从记录的上游 base 重建 patch 分支规避本地 checkout 漂移。14.GraspGen pointnet2_ops requires a CUDA toolkit症状GraspGen 安装要求 CUDA toolkit原因宿主无 CUDA toolkit修复Phase 0 检测 nvcc缺失时 setup.sh 优雅跳过 grasp 安装仿SAM2_BUILD_CUDA0模式验证在无 grasp smoke test 的情况下继续Phase 0 用command -v nvcc或/usr/local/cuda/bin/nvcc探测宿主procedure.md检测失败仅告警并清空HOST_CUDA_HOME。对应源码见 scripts/setup/python_venv.sh 与 scripts/setup/install_graspgen_pip.shcheck_graspgen_cuda_toolkit依次探测CUDA_HOME/bin/nvcc、/usr/local/cuda-torch_cuda_version、PATH 上的 nvcc全部缺失则回退到third_party/wheels/pointnet2_ops下 ABI 绑定 Python 3.10 Torch 2.7.1cu126 的预编译 wheel校验 SHA256SUMS。而pointnet2_ops编译使用固定的TORCH_CUDA_ARCH_LIST默认 8.6见 install_graspgen_pip.sh不需要--gpus透传smoke test 仅做importlib.util.find_spec。15.nvcc: command not found于install_graspgen_pip期间症状grasp 安装阶段找不到 nvcc原因CUDA toolkit 挂载失败或CUDA_HOME环境变量未被docker exec继承修复确认 Phase 2.5 的nvcc --version探针通过docker run -e CUDA_HOME...必须设置使docker exec能继承Phase 2.5 的容器内探针执行test -x ${CUDA_HOME}/bin/nvcc与${CUDA_HOME}/bin/nvcc --version | head -1探针失败说明挂载或环境变量传递有问题应回到 Phase 2 修正而不是让 setup 带病运行。16.CUDA_HOME已设置但容器内 nvcc 不可执行症状环境变量在但 nvcc 二进制不可执行原因bind mount 使用了 Docker 未解析的符号链接路径修复用readlink -f解析真实目录后挂载真实目录如/usr/local/cuda-12.4而非/usr/local/cuda软链Phase 0 对command -v nvcc的结果执行readlink -f并dirname(dirname())上溯两级得到 toolkit 根或对/usr/local/cuda执行readlink -f挂载时src与dst使用同一已解析路径procedure.md。这保证容器内/usr/local/cuda-${torch_cuda_version}的检测逻辑见 install_graspgen_pip.sh能命中真实目录。17. bind mount/usr覆盖容器/usr症状挂载后容器内/usr内容异常原因宿主 nvcc 位于/usr/bin/nvccapt 安装dirname(dirname())上溯得到/usr修复Phase 0 拒绝系统目录/、/usr、/usr/localCUDA toolkit 应安装到/usr/local/cuda-version而非 apt 的nvidia-cuda-toolkitPhase 0 的显式黑名单检查procedure.mdif [[ ${HOST_CUDA_HOME} / || ${HOST_CUDA_HOME} /usr || ${HOST_CUDA_HOME} /usr/local ]]; then echo Host CUDA toolkit path is a system directory ... refusing to bind-mount. HOST_CUDA_HOME fi把整个系统目录 bind 进容器会静默覆盖容器自身/usr属于比找不到 nvcc更危险的故障因此选择拒绝挂载 优雅跳过 grasp的保守策略。排障纪律从单点修复到验证证据可信错误分类与报告无论哪条陷阱被命中修复后都必须回到 Phase 6 的收尾动作procedure.mddocker exec ${CONTAINER} bash -c cat /tmp/setup.status /tmp/setup.time cat /tmp/build.status /tmp/build.time git -C /home/testuser/IB_Robot rev-parse HEAD HEAD^{tree} grep -n -E ERROR|Error|error /tmp/setup.log || true grep -n -E ERROR|Error|error|Failed|failed /tmp/build.log || true 报告必须逐条列出 ERROR 行并标注Fatal / Non-fatal不能只给行数。另需明确声明 source modeisolated committed snapshotPR 证据带完整 commit 与 tree、local workspace copy仅本地调试标注 local-only或remote clean clone。PR 证据模式下两个平台必须验证 tree 等于VERIFIED_TREE的快照单纯重写 commit message 不会使结果失效SKILL.md。陷阱的共性规律把 21 条陷阱横向对比可以提炼出四条可迁移的工程经验无 TTY 环境先解决非交互问题NOPASSWD:ALL、DEBIAN_FRONTENDnoninteractive、sudo -n true优先都是为了让脚本在没有终端的容器里可执行对应陷阱 1、2、4、12。权限以目标用户实际可写为准缓存探针用testuser而非 root 执行UID/GID 从宿主id -u/id -g动态取得而非硬编码1000:1000对应陷阱 2、3、4。下载源全部走镜像apt→Aliyun、ROS→TUNA、pip→华为云且以环境变量/venv 内pip.conf形式固化在脚本默认值中对应陷阱 510。优雅降级优于硬失败无 nvcc 时跳过 grasp、无 git-lfs 时移除 LFS hook、gpgcheck 自动禁用让环境不完整也能产出有意义的验证结论对应陷阱 1417openEuler 侧同类策略见 .agents/skills/ibrobot-docker-verify-oee/SKILL.md。快速迭代入口若容器已通过完整 Phase 2 创建仅需重跑 setup 时可直接复用容器执行 quick-run 流程.agents/skills/ibrobot-docker-verify/references/quick-run.md重新docker cp工作区、清理venv/build/install/log后重跑bash scripts/setup.sh --yes。注意两次运行之间若 ROS 源发生切换必须重跑 Phase 3.5 的 ROS 预清理apt-get purge -y ros-*并移除/opt/ros否则旧源包会被 setup.sh 的 ROS 检测静默复用使新源安装路径完全未被验证。结语IB_Robot 的 Ubuntu Docker 验证陷阱清单是长时间真实运行沉淀的结果每一条都对应过一次看似环境问题、实则流程或脚本设计问题的排障。将本手册与 procedure.mdPhase 0-6 完整命令、discipline.md禁止/允许清单、SKILL.md变量与变体配合使用可以在遇到陌生报错时先在表中定位再回到源码确认机制从而把验证从反复试错升级为可预期、可解释、可复现。赞分享具身智能机器人人工智能大模型模型推理服务本地部署计算机视觉ROS【免费下载链接】IB_RobotSave the code of IB-Robot, an AI robot execution framework developed by openEuler Embedded for embodied intelligence scenarios. It includes references to the forked version of tensormsg, references to lerobot fork, code references to the lerobot_ros2:ros2_ws branch, as well as some code related to development usability.项目地址https://gitcode.com/openeuler/IB_Robot点击查看免费下载相关推荐IB-Robot openEuler Embedded Docker 验证排障手册qemu-user chroot 环境下的 18 个已知陷阱与修复实践IB Robot openEuler Embedded Docker 验证排障手册qemu user chroot 环境下的 18 个已知陷阱与修复实践 导读具身智能机器人人工智能大模型模型推理服务本地部署计算机视觉ROSopenEulerOpenHarmony深度学习语音AI AgentAscendIB_Robot 的 openEuler Embedded Docker 验证纪律setup.sh 与 build.sh 唯一安装途径的边界与实践IB_Robot 的 openEuler Embedded Docker 验证纪律setup.sh 与 build.sh 唯一安装途径的边界与实践 本指南以具身智能机器人人工智能大模型模型推理服务本地部署计算机视觉ROSopenEulerOpenHarmony深度学习语音AI AgentAscendGraphRAG 依赖升级实战手册pandas 3.0 / numpy 2.x 迁移陷阱与已验证修复模式GraphRAG 依赖升级实战手册pandas 3.0 / numpy 2.x 迁移陷阱与已验证修复模式 本文基于 GraphRAG 仓库中的迁移陷阱参考文档人工智能RAG知识图谱数据工程大模型上一篇终极指南10分钟用vRain制作专业古籍电子书让传统经典焕发数字新生下一篇Swagger UI 验证徽章变红3 步定位 Schema 校验与错误标记的根因创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考