自动驾驶【免费下载链接】autowareAutoware - the worlds leading open-source software project for autonomous driving项目地址https://gitcode.com/GitHub_Trending/au/autoware点击查看免费下载本文基于 Autoware 官方仓库 docker/README.md 撰写并结合 docker/ 目录下的 Dockerfile、docker-bake.hcl、docker-entrypoint.sh 与 ansible 可复现构建体系进行源码级展开。读者将掌握 Autoware 的 12 个 Docker 镜像如何分层组织、如何从 GHCR 拉取与本地构建、如何通过USE_LOCKFILE获得可复现构建以及如何在常规 GPU 主机与 NVIDIA ThorJetson Thor / DRIVE Thor上正确启动 Autoware 容器。一、镜像拓扑一图看懂 12 个镜像的依赖关系Autoware 的容器镜像不是一个大而全的单体镜像而是一棵精心设计的镜像依赖树。base是唯一的根向上逐层叠加出core核心包与universe全量功能两条主线并以 CUDA 与否进一步拆分出*-cuda系列。图中三种色系分别代表三种镜像角色与 docker/docker-bake.hcl 中的 group 划分一一对应灰色base系最底层基础镜像一切镜像的基石蓝色devel系开发/构建镜像包含完整构建工具链与编译产物绿色runtime系精简运行时镜像只保留运行所需内容紫色cuda系叠加 CUDA/cuDNN/TensorRT 的 GPU 路径。分层设计的两条核心原则从 docker/core.Dockerfile 与 docker/universe.Dockerfile 的源码可以看出两个关键设计devel → runtime 的产物搬运core镜像通过COPY --fromcore-devel /opt/autoware /opt/autoware从构建镜像中拷贝编译产物随后执行find /opt/autoware -name *.so -exec strip --strip-unneeded {} 剥离符号表显著缩小运行时体积。universe/universe-cuda同样从各自的 devel 镜像搬运/opt/autoware与/opt/acados。依赖安装按需分层core-dependencies只安装autoware_core以外的 core 包构建依赖rosdep install --dependency-typesbuild,build_export,buildtool,buildtool_export,testcore-devel再叠加autoware_core等三个核心包的构建universe-dependencies则通过--tags acados额外安装 Acados 优化求解器并把CMAKE_PREFIX_PATH、ACADOS_SOURCE_DIR、LD_LIBRARY_PATH指向/opt/acados。这样每一层 CI 都可以只构建、只测试自己关心的那部分代码。二、镜像清单每个镜像的用途与适用场景镜像描述适用场景baseROS 基础 sudo、pipx、ansible、RMW用户aw所有其他镜像的地基core-dependencies构建依赖 编译好的 core 包不含autoware_core与autoware_rviz_pluginsautoware_core的 CIcore-devel在core-dependencies之上叠加autoware_core构建依赖autoware_core的包的开发与 CIcore仅运行时rosdep exec 依赖 来自core-devel的编译产物轻量级 core 运行时base-cuda-runtimebase CUDA/cuDNN/TensorRT 运行时库无-dev包universe-cuda的运行时地基base-cuda-develbase-cuda-runtime CUDA/cuDNN/TensorRT 开发头文件CUDA universe 包的构建地基universe-dependenciesAcados autoware 全量构建依赖非 CUDA 路径autoware_universe的 CIuniverse-dependencies-cudacore 相关 ansible roles acados rosdep 构建依赖CUDA 继承自base-cuda-develCUDA 相关包的 CIuniverse-devel构建全部 universe 源码无 CUDA无 GPU 开发universe-devel-cuda以 CUDA 构建全部 universe 源码有 GPU 开发universe含编译产物 autoware 的运行时镜像无 CUDA无 GPU 部署universe-cuda含编译产物 autoware 的运行时镜像CUDA 运行时继承自base-cuda-runtime有 GPU 部署从 Dockerfile 看各镜像的构建差异basedocker/base.Dockerfile以ros:${ROS_DISTRO}-ros-base${BASE_IMAGE_DIGEST}为基础安装sudo、pipx、bash-completion、iproute2、gosu通过 pipx 临时安装 ansible 并执行autoware.dev_env.install_rmw安装 RMWrmw_cyclonedds_cpp随后卸载 ansible 保持镜像干净。同时删除 Ubuntu 24.04 默认占用 UID 1000 的ubuntu用户创建无密码 sudo 的用户aw并写入默认的 cyclonedds.xml 与CYCLONEDDS_URI、RMW_IMPLEMENTATION环境变量。base-cuda-runtime/base-cuda-develdocker/base-cuda.Dockerfile分别以install_develN与install_devely运行autoware.dev_env.install_nvidia安装 CUDA/cuDNN/TensorRT。值得注意的源码细节是CUDA 13 把 Thrust、CUB 与 libcudacxx 的cuda/头文件移到了/usr/local/cuda/include/cccl/下因此 Dockerfile 为thrust、cub建立符号链接并把cccl目录加入CPATH以兼容autoware_universe中bevdet_vendor等仍使用旧式无前缀 include 的下游消费者CUDA 12.x 上这些操作自动为空操作。universe-dependencies-cudadocker/universe-cuda.Dockerfile直接COPY --fromautoware-core-devel /opt/autoware /opt/autoware复用 core 编译产物并设置CMAKE_CUDA_ARCHITECTURES86;87;89;90;110其中 86Ampere 消费级、87Orin、89Ada、90Hopper、110Thor BlackwellJetson Thor 与 DRIVE Thor 共用。三、从 GHCR 拉取预构建镜像官方在 GHCRGitHub Container Registry发布了 amd64 arm64 双架构预构建镜像开箱即用# 拉取指定镜像以最新滚动版本为例 docker pull ghcr.io/autowarefoundation/autoware:base-jazzy docker pull ghcr.io/autowarefoundation/autoware:base-humble # 拉取带日期的版本用于固定版本 docker pull ghcr.io/autowarefoundation/autoware:base-jazzy-20260407 # 拉取带版本号的发布版本 docker pull ghcr.io/autowarefoundation/autoware:base-jazzy-1.2.3Tag 命名规则stage-ros_distro[-date|-version]即阶段-发行版可选后缀为-日期如20260407适合精确固定构建或-版本号如1.2.3适合语义化发布。以下是jazzy发行版可用的全部 tag将jazzy换成humble即得另一发行版Tag描述base-jazzyROS 基础 ansible 用户 awcore-dependencies-jazzy构建依赖 core 包不含autoware_corecore-devel-jazzy完整 core 开发镜像core-jazzy轻量级 core 运行时base-cuda-runtime-jazzybase CUDA/cuDNN/TensorRT 运行时base-cuda-devel-jazzybase-cuda-runtime CUDA/cuDNN/TensorRT 开发universe-dependencies-jazzyuniverse 构建依赖无 CUDAuniverse-dependencies-cuda-jazzy基于 base-cuda-devel 的 universe 构建依赖universe-devel-jazzy完整 universe 开发镜像无 CUDAuniverse-devel-cuda-jazzy完整 universe 开发镜像带 CUDAuniverse-jazzy无 GPU 运行时universe-cuda-jazzy带 GPU 运行时四、本地构建镜像在仓库根目录下执行。注意base以外的目标都要求src/下已有源码仓库因为构建过程需要把源码 bind 挂载进构建容器执行colcon build。# 克隆源码仓库core 与 universe 目标必需 vcs import src repositories/autoware.repos # 构建全部默认目标universe universe-cuda docker buildx bake -f docker/docker-bake.hcl # 构建指定目标依赖会自动解析 docker buildx bake -f docker/docker-bake.hcl base docker buildx bake -f docker/docker-bake.hcl core-devel docker buildx bake -f docker/docker-bake.hcl universe docker buildx bake -f docker/docker-bake.hcl universe-cuda # 为 humble 构建 ROS_DISTROhumble docker buildx bake -f docker/docker-bake.hcl basedocker-bake.hcl 源码导读docker/docker-bake.hcl 是构建编排的核心几个关键点变量ROS_DISTRO默认jazzy、USE_LOCKFILE默认false、BASE_IMAGE_DIGESTShumble/jazzy 各自的 base 镜像 manifest 摘要、REGISTRY/PLATFORM/TAG_DATE/TAG_VERSION/TAG_REFCI 变量本地构建为空、USE_REGISTRY_CONTEXTSCI 中跨 group 引用已推送镜像时置为true。group 划分default组包含全部 12 个目标ci-base、ci-core、ci-base-cuda、ci-universe、ci-universe-cuda五个组与上文镜像表一一对应CI 中每组在独立 job 构建。目标继承universe-dependencies、universe-devel、universe共享_universe-base基础定义同universe-cuda三件套共享_universe-cuda-base通过inherits [...]复用 dockerfile、contexts 与 args避免重复声明。context 机制本地构建时ctx()返回target:name即直接用其他 target 的产物作为构建上下文CI 中USE_REGISTRY_CONTEXTStrue时返回docker-image://tag直接从仓库拉取上游镜像避免重复构建。tags()函数保证第一个元素始终是名称-发行版-平台形式的 tag因为ctx()依赖tags(name)[0]构造docker-image://引用。五、可复现构建USE_LOCKFILE默认情况下构建使用浮动的ros:distro-ros-basetag并从packages.ros.org与 Ubuntu 仓库拉取最新包——因此同一天之外构建的镜像可能不同。设置USE_LOCKFILEtrue即可获得可复现构建# 默认发行版jazzy的可复现 base 镜像 USE_LOCKFILEtrue docker buildx bake -f docker/docker-bake.hcl base # humble 的可复现构建 USE_LOCKFILEtrue ROS_DISTROhumble docker buildx bake -f docker/docker-bake.hcl base开启后构建行为的变化启用锁定模式后构建会依次执行四件事源码实现分布在 docker-bake.hcl 与 ansible/roles/version_lock/ 中固定 base 镜像摘要把基础镜像从浮动的ros:distro-ros-basetag 钉到 docker-bake.hcl 中BASE_IMAGE_DIGESTS里按发行版记录的 manifest 摘要sha256:...从而冻结 OS 层闭包。注意这里使用的是多架构 manifest 摘要一个摘要同时服务 amd64 与 arm64。向 ansible 传递use_locked_versionstrueansible 据此把 Ubuntu 仓库包钉到ansible/vars/locked-versions- - .yaml中记录的版本并把 ROS 源指向该 lockfile 记录的带日期快照源snapshots.ros.org冻结该快照提供的每一个 ROS 依赖。快照回退reconcile把 base 镜像预装但版本与快照不一致的包回退到快照版本——因为浮动的ros:distro-ros-basetag 通常比 lockfile 的ros_snapshot_date更新。回退逻辑由 tasks/reconcile.yaml 驱动 files/list_ros_snapshot_drift.py 完成使最终镜像中每个快照可提供的包都处于快照版本。安装后校验安装完成后校验每个锁定包是否落在锁定版本任何漂移都会让构建失败见 tasks/verify.yaml。锁定模式的边界仅支持同时具备 lockfile 与BASE_IMAGE_DIGESTS条目的发行版当前为humble与jazzy。对其他ROS_DISTRO请求USE_LOCKFILEtrue会直接构建失败而不是静默回退到浮动 base——这是 docker-bake.hcl 中function base_image_digest故意使用直接 map 索引而非带默认值的lookup()实现的大声失败设计。CUDA 目标同样支持锁定base-cuda-*与universe-cuda继承自base的冻结 apt 固定与带日期快照CUDA/cuDNN/TensorRT 闭包则通过 lockfile 的nvidia_pins段冻结——NVIDIA 不发布带日期快照因此该闭包按包精确钉版本记录方式见 ansible/roles/version_lock/README.md。锁定并非完全封闭hermetic构建滚动的packages.ros.org源仍然配置着因此快照未携带的ros-*包包括 Autoware 自己发布的包仍会从滚动源安装并浮动。完整边界清单见 ansible/roles/version_lock/README.md 中 What the freeze does not cover 一节该文档同时说明 lockfile 格式与如何生成/更新 lockfile。Lockfile 格式每个发行版/架构一个文件ansible/vars/ 下共四个YAML 顶层为五个键ros_snapshot_date: 2026-04-13 # snapshots.ros.org/distro/ 下的一个真实发布日期 apt_pins: # 仅 Ubuntu 归档来源按名称排序渲染为 APT pins ccache: 4.9.1-1 git-lfs: 3.4.1-1ubuntu0.4 pip_pins: {} # pip/pipx 来源供角色消费不渲染为 APT pins nvidia_pins: # NVIDIA apt 来源CUDA/TensorRT 闭包渲染为 APT pins cuda-nvcc-12-8: 12.8.93-1 libnvinfer10: 10.8.0.43-1cuda12.8 ros_overrides: {} # 个别 ROS 包的例外固定通常为空各键的语义要点详见 ansible/roles/version_lock/README.mdros_snapshot_date驱动锁定模式下由ros2角色配置的带日期snapshots.ros.org源冻结整个 ROS 依赖闭包。pin 文件还包含Package: * / Pin: origin snapshots.ros.org / Pin-Priority: 1001段使快照优先于滚动源否则两者同为优先级 500apt 会安装更新的滚动构建。apt_pins渲染进/etc/apt/preferences.d/autoware-lockPin-Priority: 1001。nvidia_pins同样渲染为优先级 1001 的 APT pins由emit_nvidia_pins.py而非generate_ansible_lockfile.sh填充——因为 NVIDIA 仓库只增不减、默认只提供最新构建所以闭包内每个包都必须按精确版本钉住。ros_overrides渲染为Pin-Priority: 1002比快照来源高一档用于把单个 ROS 包移动到快照之外的版本且被钉版本必须能从已配置的 APT 源解析到否则校验会失败。六、运行 Autoware 容器完整启动命令GPU 图形界面 数据卷xhost local:docker docker run --rm -it \ --net host \ --privileged \ --gpus all \ -e DISPLAY$DISPLAY \ -e NVIDIA_DRIVER_CAPABILITIESall \ -e NVIDIA_VISIBLE_DEVICESall \ -e HOST_UID$(id -u) \ -e HOST_GID$(id -g) \ -e QT_X11_NO_MITSHM1 \ -v /tmp/.X11-unix:/tmp/.X11-unix:rw \ -v $HOME/autoware_data/maps:/home/aw/autoware_data/maps \ -v $HOME/autoware_data/ml_models:/home/aw/autoware_data/ml_models \ -v $HOME/autoware:/home/aw/autoware \ -w /home/aw/autoware \ --runtimenvidia \ autoware:universe-cuda-jazzy \ bash -c source /opt/autoware/setup.bash exec bash各参数的含义与必要性Flag作用--rm退出即删除容器避免堆积停止状态的容器-it交互式终端stdin TTY--net host共享宿主机网络栈使 ROS 2 节点能互相发现--privileged访问宿主机设备传感器、CAN 总线等--gpus all向容器暴露全部 GPU-e DISPLAY转发 X11 显示供 GUI 程序rviz2、rqt使用-e NVIDIA_DRIVER_CAPABILITIESall启用全部 NVIDIA 驱动特性compute、graphics、video-e NVIDIA_VISIBLE_DEVICESall使容器内可见全部 GPU-e HOST_UID/HOST_GIDentrypoint 将aw用户重映射为宿主机 UID/GID避免挂载卷的权限问题-e QT_X11_NO_MITSHM为 Qt 程序禁用 MIT-SHM共享内存在容器边界不工作-v /tmp/.X11-unix挂载 X11 socket 用于 GUI 转发-v autoware_data/maps挂载宿主机的 mapslanelet2 点云-v autoware_data/ml_models挂载宿主机 ML 模型产物-v autoware挂载源码用于开发-w /home/aw/autoware把工作目录设为挂载的源码目录--runtimenvidia使用 NVIDIA 容器运行时以支持 GPU轻量运行不挂载卷docker run --rm -it \ --net host \ autoware:core-jazzy覆盖默认 CycloneDDS 配置默认的 cyclonedds.xml 只使用lolocalhost接口——它把NetworkInterface namelo prioritydefault multicastdefault/设为默认接口并开启了回环多播、MaxMessageSize65500B、SocketReceiveBufferSize最低 10MB 等 DDS 调优参数。要覆盖它挂载你自己的配置即可docker run --rm -it \ --net host \ -v /path/to/your/cyclonedds.xml:/home/aw/cyclonedds.xml \ autoware:universe-cuda-jazzyEntrypoint 做了什么docker/docker-entrypoint.sh 在每次容器启动时执行若设置了HOST_UID/HOST_GID把aw用户重映射到宿主机 UID/GID防止挂载卷权限问题尝试开启回环接口的多播ip link set lo multicast on让钉在lo上的 DDS 发现机制正常工作应用 DDS 网络调优 sysctlnet.core.rmem_max2147483647、net.ipv4.ipfrag_time3、net.ipv4.ipfrag_high_thresh134217728需要--privileged或--cap-addNET_ADMIN失败仅告警不中断source/opt/ros/distro/setup.bash若AUTOWARE_RUNTIME1且存在/opt/autoware/setup.bash则一并 source通过gosu降权到aw用户执行命令。七、在 NVIDIA Thor 上运行Jetson Thor / DRIVE ThorJetPack 7 在所有 Arm 目标上统一使用 CUDA 13.0因此为linux/arm64SBSA 风味构建的universe-cuda-jazzy镜像在两种 Thor 变体上都是受支持的运行时——运行 JetPack 7 的 Jetson Thor 与运行 DRIVE OS 的 DRIVE Thor 共享同一颗 Blackwell SoCsm_110与同一套 SBSA 兼容的 CUDA / TensorRT 包集。下方修复步骤与运行时操作已在本地 Jetson ThorL4T R38.4.0 / CUDA 13.0上端到端验证。DRIVE Thor 按设计应当同样可用——容器内 CUDA 栈完全相同——但其宿主机侧的 container-toolkit 打包来自 DRIVE OS 而非 JetPack BSP因此下文前置命令的名称在 DRIVE 宿主机上可能有所不同。Thor 宿主机前置条件Arm 主机Ubuntu 24.04 Linux 6.8JetPack 7 的 Jetson Thor或运行 DRIVE OS 的 DRIVE Thor 目标。来自 JetPack BSP或 DRIVE OS 等价物的nvidia-container-toolkitsudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker启动命令docker run --rm -it \ --net host \ --runtime nvidia \ -e NVIDIA_VISIBLE_DEVICESall \ -e NVIDIA_DRIVER_CAPABILITIESall \ -e HOST_UID$(id -u) -e HOST_GID$(id -g) \ -v $HOME/autoware_data/maps:/home/aw/autoware_data/maps \ -v $HOME/autoware_data/ml_models:/home/aw/autoware_data/ml_models \ autoware:universe-cuda-jazzy \ bash -c source /opt/autoware/setup.bash exec bash与通用用法的关键差异Tegra 上不使用--gpus all--runtime nvidia加上两个NVIDIA_*环境变量才是受支持的方式。正是这两个环境变量触发 L4T container toolkit 把libcuda.so.1与/dev/nvidia-*挂载进容器——缺少它们时libcuda.so不存在CUDA 调用会报cudaErrorInsufficientDriver35。省略了--privileged相对通用示例Thor 推理负载不接触传感器与 CAN 总线。若接入需要宿主机设备访问的外部硬件需重新加上。容器内验证 GPU 是否可达python3 -c import ctypes rt ctypes.CDLL(libcudart.so) cnt ctypes.c_int(); rt.cudaGetDeviceCount(ctypes.byref(cnt)) maj ctypes.c_int(); minor ctypes.c_int() rt.cudaDeviceGetAttribute(ctypes.byref(maj), 75, 0) rt.cudaDeviceGetAttribute(ctypes.byref(minor), 76, 0) print(fdevices{cnt.value}, sm_{maj.value}{minor.value}) 在 Thor 上会打印devices1, sm_110而不是 PTX JIT 回退或Insufficient driver错误。推理运行时宿主机上执行sudo tegrastats可以看到 iGPU 利用率GR3D_FREQ抬升到空闲水平之上。范围说明DLA、VPI、NVDEC/NVENC 与 Argus 相机支持有意不在本镜像范围内——它们需要单独的 L4T 衍生变体。八、配套资源DevContainer 与示例编排除手写docker run外仓库还提供开箱即用的编排模板DevContainerdocker/devcontainer/提供core-devel、universe-devel、universe-devel-cuda三个 compose 模板例如 core-devel.compose.yaml 默认使用ghcr.io/autowarefoundation/autoware:core-devel-jazzy配置了privileged: true、network_mode: host、X11 与autoware_data卷挂载并以../..即仓库根目录挂载到容器内/home/aw/autoware。示例场景docker/examples/README.mdbasic/提供dev-cpu、dev-dri、dev-nvidia三种最小开发 shell按 GPU 选择demos/提供 planning-simulator、awsim、carla、scenario-simulator 等容器启动即拉起 Autoware 的预配置场景分别有对应的 compose 文件与 README。总结Autoware 的 Docker 体系以base为根、按 core/universe × CUDA/非 CUDA 四个象限组织出 12 个镜像配合docker buildx bake的 target 继承与 CI 分组实现了每层 CI 只构建自己关心的代码的高效流水线USE_LOCKFILE通过基础镜像摘要 apt/ROS 快照 NVIDIA 精确版本钉 安装后校验四重机制把滚动构建冻结为可复现构建运行侧则针对常规 GPU 主机与 NVIDIA Thor 分别给出了经过验证的启动参数。按需选择core/universe系列镜像即可覆盖从轻量运行时到完整 GPU 开发部署的全部场景。赞分享自动驾驶【免费下载链接】autowareAutoware - the worlds leading open-source software project for autonomous driving项目地址https://gitcode.com/GitHub_Trending/au/autoware点击查看免费下载相关推荐LibrePhotos Docker 部署体系解析镜像分层、Compose 配置与 GPU 构建实践LibrePhotos Docker 部署体系解析镜像分层、Compose 配置与 GPU 构建实践 本文以 LibrePhotos 仓库中贡献者文档 doc后端前端移动开发计算机视觉机器学习face_recognition 官方 Docker 镜像全解析CPU/GPU/Jupyter 镜像的构建、部署与实战指南face_recognition 官方 Docker 镜像全解析CPU/GPU/Jupyter 镜像的构建、部署与实战指南 本篇技术指南围绕 face_rec人工智能计算机视觉深度学习Fluent Bit Docker 容器镜像实战快速部署、多架构构建与 Distroless 安全镜像解析Fluent Bit Docker 容器镜像实战快速部署、多架构构建与 Distroless 安全镜像解析 本篇指南基于 Fluent Bit 仓库中的官方可观测性日志分析云原生流处理上一篇youtube-dl-gui自定义主题与暗黑模式个性化界面设置指南下一篇推荐开源项目DropPoint - 让拖放操作更简单创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考