این پیوست یک داستان واقعی مهندسی است، نه فقط یک جدول از اسمهای عجیب. تیمی را تصور کن که ARCHO را روی ROS 2 Humble ساخته، دو سال با آن کار کرده، حالا هم مدیر پروژه میپرسد «چرا آپدیت نمیکنیم؟» و هم یک عضو تیم مقالهای میخواند که در آن از ROS 2 Lyrical Luth صحبت شده. این پیوست دقیقاً همان مسیر فکریای را طی میکند که چنین تیمی باید طی کند: توزیع ROS 2 یعنی چه، چرا اصلاً وجود دارد، کدامها زندهاند و کدامها مرده، LTS چه فرقی با غیر LTS دارد، Rolling Ridley چیست، و در نهایت — با چه معیاری باید تصمیم گرفت.
نامگذاری توزیعهای ROS 2 به ترتیب حروف الفبا پیش میرود (هر سال یک حرف جدید). در زمان نگارش این پیوست،
توزیعهای تثبیتشده و مستند در docs.ros.org عبارتاند از Humble، Iron، Jazzy، Kilted Kaiju
و شاخهٔ همیشهدرحالتوسعهٔ Rolling Ridley. نام Lyrical Luth در این پیوست بهعنوان
«توزیع بعدی در این توالی حروف الفبا» بهکار رفته تا روش فکر کردن را یاد بدهد — نه به این معنا که تاریخ
انتشار، شماره نسخه یا جزئیات فنی دقیق آن را تضمین میکنیم. قبل از تصمیم واقعی روی ARCHO، همیشه
صفحهٔ رسمی docs.ros.org/en/rolling/Releases.html را چک کن — این یکبار خواندن پنج
دقیقهای، از ساعتها دیباگ یک نصب اشتباه جلوگیری میکند.
جلسهٔ تیم ARCHO اینطور شروع شد: «ما الان روی Humble هستیم. Humble یعنی چه؟ آیا ROS 2 یک برنامه است که
نسخه دارد، مثل مرورگر کروم؟» جواب دقیق نه. توزیع (Distro) در ROS 2 یعنی یک
مجموعهٔ نسخهبندیشده و آزمایششده از صدها پکیج که تضمین میکند همه با هم سازگارند — rclcpp،
rclpy، rmw، rviz2، nav2، ros2_control و
هزاران پکیج دیگر، همه در یک نسخهٔ مشخص «قفل» میشوند و زیر یک نام مثل humble یا
jazzy منتشر میشوند.
قیاس مفید: توزیعهای ROS 2 شبیه نسخههای اوبونتو هستند (۲۰.۰۴، ۲۲.۰۴، ۲۴.۰۴) — هرکدام یک لحظهٔ منجمد از هزاران پکیج سازگار با هم. قیاس غلط: ROS 2 خودش یک سیستمعامل نیست. ROS 2 روی یک سیستمعامل (معمولاً اوبونتو) نصب میشود؛ توزیع ROS همان نقشی را بازی میکند که «نسخهٔ اوبونتو» برای کرنل لینوکس بازی میکند — یک لایهٔ سازگاری، نه خودِ سیستمعامل.
چرا اصلاً اینهمه توزیع لازم است؟ چون بدون آن، این اتفاقها میافتاد:
وقتی میگویی «ARCHO روی Humble است»، در واقع میگویی «تمام پکیجهای ARCHO با همان نسخهٔ منجمدشده از
rclcpp، nav2، ros2_control و بقیه، کامپایل و تست شدهاند.» این
جمله، مسئولیت تیم است — نه چیزی که خودکار تضمین شود.
قبل از اینکه دربارهٔ آینده تصمیم بگیریم، باید تاریخچه را ببینیم. جدول زیر ستون آخرش «توصیهشده برای امروز؟» است — و این ستون است که واقعاً روی تصمیم اثر میگذارد، نه اینکه توزیع «جدید» است یا نه.
| توزیع | سال انتشار (تقریبی) | LTS؟ | وضعیت | توصیه برای پروژهٔ جدید |
|---|---|---|---|---|
| Ardent Apalone | ۲۰۱۷ | خیر | پایان پشتیبانی (EOL) | خیر — فقط تاریخی |
| Bouncy Bolson | ۲۰۱۸ | خیر | EOL | خیر |
| Crystal Clemmys | ۲۰۱۸ | خیر | EOL | خیر |
| Dashing Diademata | ۲۰۱۹ | بله | EOL | خیر |
| Eloquent Elusor | ۲۰۱۹ | خیر | EOL | خیر |
| Foxy Fitzroy | ۲۰۲۰ | بله | EOL | فقط سیستم قدیمی و مستندشده |
| Galactic Geochelone | ۲۰۲۱ | خیر | EOL | خیر |
| Humble Hawksbill | ۲۰۲۲ | بله | در حال پشتیبانی (رو به پایان) | فقط برای نگهداری سامانهٔ موجود روی اوبونتو ۲۲.۰۴ |
| Iron Irwini | ۲۰۲۳ | خیر | EOL | خیر |
| Jazzy Jalisco | ۲۰۲۴ | بله | در حال پشتیبانی | گزینهٔ محکم برای تولید روی اوبونتو ۲۴.۰۴ |
| Kilted Kaiju | ۲۰۲۵ | خیر | در حال پشتیبانی | برای دسترسی زودهنگام به قابلیتهای جدید |
| Lyrical Luth | نامشخص — قبل از استفاده تأیید شود | باید در docs.ros.org تأیید شود | باید تأیید شود | باید تأیید شود |
| Rolling Ridley | مداوم | ندارد (مفهوم LTS برایش معنی ندارد) | همیشه فعال | فقط توسعه/تست، نه تولید |
EOL یعنی End of Life — دیگر هیچ وصلهٔ امنیتی یا رفع باگی منتشر نمیشود. تنها استثنا: وقتی یک وابستگی قدیمی و غیرقابلجایگزین (مثلاً درایور سختافزاری خاص) تو را مجبور به ماندن روی نسخهٔ قدیمی میکند — که آنوقت باید آگاهانه و مستند این ریسک را بپذیری، نه از سر بیاطلاعی.
وقتی مدیر پروژهٔ ARCHO پرسید «چرا Jazzy را انتخاب کردید نه Iron؟»، جواب تیم یک کلمه بود: LTS — یعنی Long Term Support، پشتیبانی بلندمدت.
Humble → LTS (پشتیبانی بلندمدت)
Jazzy → LTS (پشتیبانی بلندمدت)
Lyrical → LTS بودنش را در docs.ros.org تأیید کن
در برابر:
Iron → غیر LTS (چرخهٔ کوتاه)
Kilted → غیر LTS (چرخهٔ کوتاه)چرا این تفاوت برای یک شرکت رباتیک اهمیت حیاتی دارد؟
فرض کن ARCHO الان در ۴۰ انبار مشتری نصب شده و روی Humble کار میکند. حتی اگر Jazzy یا Lyrical منتشر شود، آپدیت فوری یعنی: تست دوبارهٔ کل استک ناوبری، بررسی سازگاری تمام درایورهای سنسور، و ریسک خرابی در سیستمی که همین الان کار میکند. تصمیم درست معمولاً این است: نسخهٔ فعلی روی رباتِ درحالکار میماند تا پایان چرخهٔ پشتیبانیاش، و توزیع جدید فقط روی نسل بعدی محصول یا در یک شاخهٔ آزمایشی تست میشود.
یکی از اعضای تیم ARCHO یک روز پرسید: «چرا مستقیم روی Rolling کار نکنیم؟ همیشه جدیدترین چیزهاست!» این دقیقاً همان اشتباهی است که این بخش میخواهد جلویش را بگیرد.
Rolling Ridley یک توزیع عادی نیست؛ یک شاخهٔ همیشهدرحالتوسعه است. برخلاف Humble یا Jazzy که در یک لحظه منجمد میشوند، Rolling هر روز میتواند تغییر کند — دقیقاً همان جایی است که توسعهدهندگان اصلی ROS 2 و نگهدارندگان پکیجها، قابلیتهای نسل بعدی را آزمایش میکنند، قبل از اینکه در یک توزیع پایدار (مثل Lyrical) منجمد و رسمی شوند.
| سناریو | Rolling مناسب است؟ |
|---|---|
| نگهداری کدِ خودِ ROS 2 یا یک پکیج پرکاربرد (Nav2, ros2_control, ...) | بله — دقیقاً برای همین ساخته شده |
| تست زودهنگام یک قابلیت که قرار است در توزیع بعدی بیاید | بله، در یک شاخهٔ جدا از تولید |
| یادگیری ROS 2 برای اولینبار | خیر — مستندات و آموزشها معمولاً حول توزیع پایدار نوشته میشوند |
| رباتی که قرار است در محیط مشتری مستقر شود | خیر — API میتواند بدون اطلاع قبلی بشکند |
| پروژهٔ دانشگاهی که باید بعد از یک سال هم قابل اجرا باشد | خیر — Reproducibility تضمین نمیشود |
اگر ARCHO روی Rolling ساخته شود، ممکن است سه ماه بعد، همان دستور colcon build با خطایی متوقف شود که هیچکس در تیم انتظارش را نداشت — چون یک پکیج بالادستی خودش را بازطراحی کرده. برای یادگیری این پیوست هم، همیشه از یک توزیع پایدار استفاده کن، نه Rolling.
اینجا جایی است که تیم ARCHO باید از حرف کلی («جدیدتر بهتر است») به سؤالهای مشخص برسد. جدول زیر چارچوب سؤالاتی است که باید برای هر ارتقا از خودت بپرسی — نه یک ادعای قطعی دربارهٔ Lyrical، چون جزئیات دقیقش را باید از مستندات رسمی همان لحظه گرفت.
| حوزه | سؤالی که باید از مستندات رسمی بپرسی |
|---|---|
| rclcpp / rclpy | آیا امضای APIای که استفاده میکنم منسوخ (Deprecated) یا حذف شده؟ |
| DDS / RMW | پیادهسازی پیشفرض DDS همان است که روی آن تست کردهام؟ |
| QoS و Executors | آیا رفتار پیشفرض QoS یا زمانبندی Executor تغییر کرده؟ |
| launch | آیا فایلهای Launch پایتونی من هنوز بدون تغییر اجرا میشوند؟ |
| Nav2 / ros2_control / MoveIt 2 | آیا نسخهٔ این پکیج در توزیع جدید، پارامترها یا رابطهایش را عوض کرده؟ |
| Gazebo | کدام نسل Gazebo با این توزیع جفت (Pair) شده؟ |
| Python / C++ Standard | نسخهٔ پایتون و استاندارد ++C پایهٔ توزیع چیست؟ |
| Ubuntu | این توزیع روی کدام نسخهٔ اوبونتو Tier 1 است؟ |
هیچوقت جملهای مثل «Lyrical سریعتر است» یا «Lyrical بهتر است» را بدون منبع رسمی نپذیر. تفاوت واقعی بین دو توزیع را فقط از یادداشتهای انتشار رسمی (Release Notes) و صفحهٔ تغییرات هر پکیج میتوان استخراج کرد — نه از حدس یا از اینکه شمارهاش بزرگتر است.
فرض کن تیم ARCHO تصمیم گرفته یک نسخهٔ آزمایشی از ربات را روی Lyrical Luth بسازد تا برای آیندهٔ محصول
آماده باشد. قبل از هر کاری، اینها را باید از docs.ros.org استخراج کند — نه حدس بزند:
یک قابلیت را فقط زمانی «ویژگی Lyrical» بنام که در یادداشت انتشار Lyrical صراحتاً بهعنوان تغییر جدید ذکر شده باشد. اگر یک قابلیت از Jazzy یا Kilted به ارث رسیده، گفتن «این قابلیت Lyrical است» گمراهکننده است و دقیقاً همان نوع خطایی است که این پیوست میخواهد از آن دوری کند.
رابطهٔ Lyrical با Rolling هم مثل هر توزیع پایدار دیگر است: در یک لحظهٔ مشخص، Rolling «منجمد» میشود، آن عکس لحظهای همان توزیع پایدار جدید میشود، و از آن به بعد Rolling دوباره به جلو حرکت میکند تا زمانی که نوبت به انجماد توزیع بعدی برسد.
الگوی کلی جفتشدن ROS 2 با اوبونتو، LTS به LTS است — اما همیشه باید تأیید شود، نه فرض:
اوبونتو
│
├── ۲۰.۰۴ → ROS 2 Foxy (EOL)
├── ۲۲.۰۴ → ROS 2 Humble (LTS)
├── ۲۴.۰۴ → ROS 2 Jazzy (LTS)
└── نسخهٔ بعدی اوبونتو → Lyrical (در docs.ros.org تأیید شود)این فقط یک الگوی تاریخی است، نه سند رسمی. همیشه سطح پشتیبانی دقیق را بررسی کن:
چرا این تمایز اهمیت دارد؟ چون نسخهٔ اوبونتو، زنجیرهای از وابستگیها را با خودش میآورد که مستقیم روی ROS 2 اثر میگذارد:
مراحل زیر همان الگوی استاندارد نصب باینری ROS 2 است — قبل از اجرا، نام توزیع (lyrical) و اوبونتوی هدف را طبق مستندات رسمی جایگزین کن.
lsb_release -a
uname -asudo apt install ros-lyrical-desktop
# در برابر
sudo apt install ros-lyrical-ros-base| بسته | شامل چه چیزی است | مناسب چه محیطی |
|---|---|---|
ros-lyrical-desktop | ابزارهای گرافیکی (RViz2، rqt) + کتابخانههای اصلی | ایستگاه کاری توسعهدهنده |
ros-lyrical-ros-base | فقط کتابخانههای اصلی، بدون ابزار گرافیکی | کامپیوتر روی خود ربات (headless) |
source /opt/ros/lyrical/setup.bash
echo "source /opt/ros/lyrical/setup.bash" >> ~/.bashrc
source ~/.bashrc
نصب باینری ROS 2 در /opt/ros/lyrical کنار گذاشته میشود، ولی سیستم بهطور پیشفرض
نمیداند این پکیجها کجا هستند. اسکریپت setup.bash متغیرهای محیطی لازم برای پیدا کردن
پکیجها (Package Discovery) را تنظیم میکند. اگر Workspace خودت (Overlay) را هم بعداً بسازی، آن را
بعد از این Underlay سیستمی Source میکنی.
printenv | grep ROS
# ROS_DISTRO
# ROS_VERSION
# ROS_DOMAIN_ID
# RMW_IMPLEMENTATIONترمینال اول:
ros2 run demo_nodes_cpp talkerترمینال دوم:
ros2 run demo_nodes_py listenerاگر پیامها در ترمینال دوم دیده شوند، یعنی زنجیرهٔ کامل کار میکند: نصب درست بوده، محیط Source شده، Discovery شبکه فعال است، و پیامرسانی Publisher/Subscriber بین دو فرایند مستقل برقرار است.
هر فرمان زیر را با همین قالب یاد بگیر: هدف، کاربرد عملی، و زمانی که یک مهندس واقعاً به آن نیاز پیدا میکند.
| فرمان | هدف | وقتی به کارت میآید |
|---|---|---|
ros2 doctor | بررسی سلامت محیط و شبکهٔ ROS | وقتی چیزی «بدون دلیل» کار نمیکند |
ros2 node list | لیست نودهای فعال | بررسی اینکه نود مورد نظر واقعاً بالا آمده |
ros2 node info <node> | جزئیات یک نود | دیدن Topic/Service/Action هر نود |
ros2 topic list | لیست تاپیکهای قابلکشف | دیباگ ارتباط بین نودها |
ros2 topic echo <topic> | نمایش زندهٔ پیامهای یک تاپیک | بررسی اینکه دیتای واقعی منتشر میشود |
ros2 topic hz <topic> | فرکانس انتشار پیام | بررسی اینکه سنسور یا کنترلر با نرخ درست کار میکند |
ros2 service call | فراخوانی مستقیم یک سرویس | تست دستی بدون نوشتن کد کلاینت |
ros2 action send_goal | ارسال هدف به یک Action Server | تست رفتار طولانیمدت مثل ناوبری یا داک شدن |
ros2 param get/set | خواندن/تنظیم پارامتر در زمان اجرا | تنظیم زندهٔ رفتار نود بدون Restart |
ros2 pkg create | ساخت پکیج جدید | شروع یک ماژول جدید در Workspace |
ros2_ws/
├── src/ ← کد منبع پکیجها
├── build/ ← فایلهای میانی ساخت
├── install/ ← خروجی نصبشدهٔ قابل Source کردن
└── log/ ← لاگ ساختmkdir -p ~/ros2_ws/src
cd ~/ros2_ws
colcon build
source install/setup.bash| فرمان | کاربرد |
|---|---|
colcon build --symlink-install | لینک نمادین بهجای کپی — برای توسعهٔ پایتون و Launch بسیار سریعتر است، چون نیازی به Build دوباره برای هر تغییر کوچک نیست |
colcon build --packages-select <pkg> | ساخت فقط یک پکیج مشخص |
colcon test | اجرای تستهای پکیجها |
rosdep مسئلهٔ متفاوتی از colcon حل میکند: colcon کد را میسازد،
اما rosdep وابستگیهای سیستمی (کتابخانههای apt) لازم برای آن کد را نصب میکند.
sudo rosdep init
rosdep update
rosdep install --from-paths src --ignore-src -r -y| ابزار | حل میکند |
|---|---|
apt | نصب بستهٔ سیستمی (سطح لینوکس) |
pip | نصب کتابخانهٔ پایتون |
rosdep | ترجمهٔ «وابستگی ROS» به دستور apt/pip مناسب همان توزیع اوبونتو |
colcon | ساخت و نصب پکیجهای داخل Workspace |
برای دیدن پیادهسازی فعلی: echo $RMW_IMPLEMENTATION. هیچوقت پیادهسازی DDS را بدون دلیل
مهندسی مشخص (مثلاً نیاز به کارایی چندپخشی بهتر یا سازگاری با ابزار خاص) عوض نکن.
QoS (کیفیت سرویس) به این دلیل به ROS 2 اضافه شد که یک تنظیم واحد برای همهٔ تاپیکها درست نیست — جریان دوربین با LiDAR فرق دارد، فرمان موتور با نقشه فرق دارد، و وضعیت اضطراری باید همیشه برسد حتی اگر مصرفکننده دیر وصل شده باشد.
۱. نود ناوبری زنده است؟ → ros2 node list
۲. تاپیک /cmd_vel وجود دارد؟ → ros2 topic list
۳. آیا /cmd_vel واقعاً پیام میدهد؟ → ros2 topic echo /cmd_vel
۴. فرکانس آن چقدر است؟ → ros2 topic hz /cmd_vel
۵. کنترلر مشترک آن است؟ → ros2 topic info /cmd_vel
۶. نوع پیامها سازگار است؟
۷. پروفایل QoS طرفین سازگار است؟این بخشها همان مفاهیمی هستند که در فصلهای اصلی کتاب عمیق دیدی؛ اینجا فقط نقششان را در بستر «کدام توزیع» مرور میکنیم.
ros2 bag record /scan /odom /cmd_vel
ros2 bag play <bag_file>
ros2 bag info <bag_file>ضبط داده هیچوقت لوکس نیست — وقتی رباتی در محل مشتری رفتار عجیبی نشان میدهد، تنها راه بازسازی دقیق لحظه، یک Bag واقعی است.
بسیاری از آموزشهای آنلاین برای ROS 1، Foxy، Humble یا Gazebo Classic نوشته شدهاند. قبل از کپی هر
دستور دربارهٔ Gazebo یا gazebo_ros_pkgs، بررسی کن که آیا هنوز مسیر رسمی معرفیشدهٔ توزیع
جدید همین است یا نه — نسلهای جدید Gazebo و روش یکپارچهسازیشان با ROS 2 عوض شدهاند.
برای Nav2، ros2_control و MoveIt 2، سؤال کلیدی همان است که در بخش ب.۵ گفتیم: هر تغییری را فقط وقتی «مخصوص Lyrical» بدان که در یادداشت انتشار همان پکیج، صراحتاً ذکر شده باشد.
وقتی تیم ARCHO تصمیم گرفت واقعاً مهاجرت کند، این چهار دسته را از هم جدا نگه داشت — قاطیکردنشان باعث تصمیمهای عجولانه میشود:
| دسته | معنی |
|---|---|
| تغییر شکننده (Breaking Change) | کد قدیمی بدون تغییر دیگر کار نمیکند |
| منسوخشدگی (Deprecation) | هنوز کار میکند اما هشدار میدهد؛ باید قبل از حذف واقعی جایگزین شود |
| تغییر رفتاری (Behavioral Change) | API همان است اما نتیجه یا پیشفرض عوض شده |
| قابلیت جدید (New Capability) | چیزی که قبلاً اصلاً وجود نداشت |
grep در کد ARCHO جستوجو کردهامpackage.xml را بهروزرسانی کردهامبرای بردهای NVIDIA Jetson، سازگاری فقط به ROS 2 محدود نیست؛ باید JetPack، نسخهٔ پایهٔ اوبونتوی همان JetPack، CUDA، TensorRT و درایورهای NVIDIA هم همراستا باشند. سه مسیر معمول:
نصب بومی (Native) → فقط اگر نسخهٔ اوبونتوی JetPack دقیقاً Tier 1 توزیع هدف باشد
کانتینر (Docker) → رایجترین راهحل برای جدا نگهداشتن نسخهٔ ROS از پایهٔ سیستم Jetson
ساخت از سورس → آخرین راهحل، وقتی هیچ باینری سازگار موجود نیستبرای Raspberry Pi، ترجیح با معماری ۶۴ بیتی (arm64) و اوبونتو سرور یا دسکتاپ رسمی است — نه توزیعهای غیررسمی Raspberry Pi OS — چون پشتیبانی باینری رسمی ROS 2 حول همین معماریها ساخته میشود.
Docker باعث میشود دقیقاً همان نسخهٔ توزیع، همان وابستگیها و همان تنظیمات، روی لپتاپ توسعهدهنده و روی کامپیوتر ربات یکسان باشد. هزینهاش پیچیدگی اضافه در Discovery شبکهٔ DDS و دسترسی به سختافزار (دوربین، GPU، پورتهای سریال) است که باید صریحاً به کانتینر پاس داده شود.
| سناریو | راهبرد پیشنهادی | دلیل |
|---|---|---|
| یادگیری ROS 2 از صفر | جدیدترین LTS پشتیبانیشده | مستندات و آموزشها بیشتر حول همین نوشته میشوند |
| ربات تولیدی جدید | LTS سازگار با کل استک سختافزاری | پایداری بلندمدت |
| ربات با اوبونتوی قدیمی موجود | همان توزیع فعلی تا پایان چرخه | سازگاری با کل زنجیرهٔ نصبشده |
| پژوهش روی جدیدترین API | آخرین پایدار یا Rolling برای آزمایش | دسترسی زودهنگام به قابلیتها |
| نگهدارندهٔ یک پکیج عمومی | Rolling + چند توزیع پایدار همزمان | سازگاری روبهجلو با آینده |
| ربات مبتنی بر Jetson | توزیعی که با نسخهٔ اوبونتوی JetPack موجود Tier 1 است | وابستگی CUDA/TensorRT/درایور |
| ربات مبتنی بر Raspberry Pi | LTS با تصویر رسمی arm64 | پشتیبانی باینری رسمی |
| ربات میراثی (Legacy) با درایور خاص | ماندن روی توزیع فعلی + مستندسازی ریسک | وابستگی غیرقابل جایگزین |
«جدیدترین ROS» بهطور خودکار مساوی «بهترین ROS» نیست. توزیع درست، جدیدترین توزیعی است که با کل زنجیرهٔ سیستم — اوبونتو، کرنل، JetPack، CUDA، درایورهای دوربین و LiDAR، Gazebo، Nav2، ros2_control و چرخهٔ نگهداری تیم — سازگار باشد؛ نه صرفاً توزیعی که تازهترین تاریخ انتشار را دارد.
| نشانه | علت | راهحل |
|---|---|---|
فرمان ros2 پیدا نمیشود | محیط Source نشده | source /opt/ros/<distro>/setup.bash |
| پکیج ساختهشده در Workspace پیدا نمیشود | Overlay بعد از build سورس نشده | source install/setup.bash |
| خطای ناسازگاری عجیب پکیجها | مخلوطکردن پکیج دو توزیع مختلف | هرگز پکیج توزیع دیگر را روی توزیع فعلی نصب نکن |
| گرهها همدیگر را نمیبینند | ROS_DOMAIN_ID متفاوت یا مشکل شبکه | یکسانسازی Domain ID و بررسی ros2 doctor |
| رفتار متناقض بین دو ماشین | یکی روی Rolling، دیگری روی نسخهٔ پایدار | هر دو را روی همان توزیع پایدار نگه دار |
| Topic دیده میشود ولی داده رد و بدل نمیشود | ناسازگاری پروفایل QoS | ros2 topic info -v برای دیدن QoS دو طرف |
| کد از یک آموزش قدیمی کار نمیکند | آموزش برای ROS 1 یا توزیع خیلی قدیمی نوشته شده | همیشه تاریخ و توزیع منبع آموزشی را چک کن |
# محیط
source /opt/ros/lyrical/setup.bash
printenv | grep ROS
# نودها و تاپیکها
ros2 node list
ros2 topic echo /cmd_vel
ros2 topic hz /scan
# سرویس و اکشن
ros2 service call /battery_status
ros2 action send_goal /dock_robot
# پارامتر
ros2 param list
ros2 param set <node> <param> <value>
# ساخت و وابستگی
colcon build --symlink-install
rosdep install --from-paths src --ignore-src -r -y
# دیباگ و ضبط
ros2 doctor
ros2 bag record /scan /odom /cmd_velداستان تیم ARCHO اینطور تمام شد: آنها روی Humble ماندند برای ناوگان تولیدی موجود، یک شاخهٔ آزمایشی روی Jazzy برای محصول بعدی ساختند، و یک محیط جداگانه و صریحاً «آزمایشی» روی Lyrical راه انداختند تا وقتی واقعاً زمان مهاجرت رسید، غافلگیر نشوند. هیچ تصمیمی بر اساس اسم گرفته نشد — همه بر اساس سازگاری واقعی با سختافزار، Nav2، ros2_control، Gazebo و چرخهٔ نگهداری تیم.
docs.ros.org تأیید کردهام