تا اینجا هرچه برای ARCHO ساختیم، روی یک سیستم توسعه مشخص با نسخه مشخصی از Jazzy نصب شده تست شد. اما وقتی همکار دیگری بخواهد همان پروژه را اجرا کند، یا بخواهی همان کد را روی ده ARCHO مختلف مستقر کنی، یک مشکل کلاسیک ظاهر میشود.
«روی لپتاپ من کار میکند» ولی «روی سیستم تو خراب است» — چون نسخه ROS، نسخه پکیجها، یا حتی نسخه سیستمعامل فرق دارد.
Docker یعنی بستهبندی کامل محیط نرمافزاری پروژه — نسخه ROS، Dependencyها، Packageها و متغیرهای محیطی — داخل یک Container قابل تکرار. با Docker، محیط اجرای ARCHO دقیقاً همان است، چه روی لپتاپ تو اجرا شود، چه روی کامپیوتر همکار، چه روی خود ربات.
# Dockerfile
FROM ros:jazzy-ros-base
SHELL ["/bin/bash", "-c"]
RUN apt-get update && apt-get install -y \
python3-colcon-common-extensions \
ros-jazzy-navigation2 \
ros-jazzy-nav2-bringup \
ros-jazzy-slam-toolbox \
ros-jazzy-robot-localization \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /archo_ws
COPY src /archo_ws/src
RUN source /opt/ros/jazzy/setup.bash && \
colcon build --symlink-install
COPY docker/entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
CMD ["bash"]#!/bin/bash
# docker/entrypoint.sh
set -e
source /opt/ros/jazzy/setup.bash
if [ -f /archo_ws/install/setup.bash ]; then
source /archo_ws/install/setup.bash
fi
exec "$@"RViz و Gazebo (فصل ۶ و ۷) به یک Display واقعی نیاز دارند و Containerها بهطور پیشفرض هیچ رابط گرافیکی ندارند. چند روش رایج برای حل این مشکل:
| روش | مناسب برای |
|---|---|
| X11 Forwarding | لینوکس، سریع برای توسعه محلی |
| Wayland Forwarding | دیستروهای جدیدتر لینوکس |
| VNC | دسترسی از راه دور یا سیستمعاملهای غیر لینوکس |
| Gazebo روی Host، Nodeها داخل Container | شروع تدریجی و سادهترین حالت |
بهترین نقطه شروع این است که Gazebo و RViz مستقیماً روی Ubuntu اجرا شوند و فقط Nodeهای پردازشی (Nav2، SLAM، Controllers) داخل Docker باشند. بعد از اینکه این ترکیب پایدار شد، میتوانی کل سیستم را بهتدریج کاملاً Containerized کنی — مثلاً با Dev Container در VS Code.
# docker-compose.yml
services:
archo:
build: .
network_mode: host
privileged: true
volumes:
- /dev:/dev
environment:
- ROS_DOMAIN_ID=20این تنظیم ارتباط DDS بین Nodeها را بسیار ساده میکند (چون Containerها مستقیم روی شبکه Host قرار میگیرند)، اما از نظر امنیت و جداسازی محیط باید آگاهانه استفاده شود — بهخصوص روی رباتی که به شبکه بیرونی هم متصل است.
Docker خود ربات را شبیهسازی نمیکند؛ محیط نرمافزاری آن را قابلتکرار، قابلتحویل و قابلاستقرار میکند.
| معنی | |
|---|---|
| CI (Continuous Integration) | هر بار کد تغییر کرد: Build، Test، Lint بهصورت خودکار اجرا شوند |
| CD (Continuous Delivery/Deployment) | پس از تأیید CI: Package، Deploy، Release |
در یک ربات حرفهای، تست فقط قبل از تحویل نهایی انجام نمیشود؛ با هر تغییر کد بهصورت خودکار تکرار میشود.
# .github/workflows/ros2-ci.yml
name: ROS 2 CI
on:
push:
pull_request:
jobs:
build-and-test:
runs-on: ubuntu-24.04
container:
image: ros:jazzy-ros-base
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Install dependencies
shell: bash
run: |
apt-get update
apt-get install -y python3-colcon-common-extensions
rosdep update
rosdep install \
--from-paths src \
--ignore-src \
-r -y
- name: Build
shell: bash
run: |
source /opt/ros/jazzy/setup.bash
colcon build --event-handlers console_direct+
- name: Test
shell: bash
run: |
source /opt/ros/jazzy/setup.bash
source install/setup.bash
colcon test
- name: Test results
shell: bash
run: |
colcon test-result --verboseتوجه: فایل YAML بالا فقط مراحل Build و Test را پیادهسازی کرده؛ مراحل Lint و Security Scan در این نمودار بهعنوان بخش کامل یک Quality Gate واقعی نشان داده شدهاند و اضافهکردنشان (مثلاً با ament_lint یا ابزارهای اسکن امنیتی) بهعنوان تمرین باقی مانده است.
| نوع تست | چه چیزی را بررسی میکند |
|---|---|
| Unit Test | یک تابع یا کلاس کوچک و مجزا |
| Integration Test | ارتباط صحیح چند Node با هم |
| Launch Test | آیا کل سیستم بدون خطا Launch میشود؟ |
| Simulation Test | آیا ARCHO در Gazebo مسیر مشخص را درست طی میکند؟ |
| Regression Test | آیا تغییر جدید قابلیتی که قبلاً کار میکرد را خراب کرده؟ |
کد ARCHO حالا در یک Container قابلتکرار بستهبندی شده و هر تغییر کد بهصورت خودکار Build، Test و بررسی میشود قبل از اینکه اجازه Merge بگیرد. این یعنی از این به بعد، تحویل نسخه جدید نرمافزار به یک ARCHO واقعی دیگر یک فرآیند دستی و پرخطا نیست.
پروژه ARCHO اکنون یک Dockerfile و Docker Compose کامل برای بستهبندی نرمافزار دارد و هر Commit جدید بهطور خودکار در GitHub Actions Build و Test میشود.
در فصل شانزدهم از دنیای نرمافزار خارج میشویم و به سراغ سختافزار کامپیوتری خود ARCHO میرویم: Jetson، Raspberry Pi و ESP32 — و اینکه هرکدام برای چه نوع پردازشی مناسباند.
network_mode: host بدون توجه به امنیت.