ПР01. Окружение и граф ROS 2

НЕДЕЛЯ 01понять→собрать→сломать→доказать→проверить себя

Работа входит в общее ядро курса. Рассчитывайте на одну лабораторную пару и примерно 2 часа самостоятельной доработки. На этой неделе вы запускаете готовые ноды и исследуете их через терминал. Первый граф разберём на лекции 02, собственную Python-ноду — на лекции 03.

На первой паре достаточно завершить установку и сохранить отчёт среды. Граф и разрыв домена завершаем после демонстрации на лекции 02; установка и ещё не разобранный граф не принимаются как один неделимый результат.

Входные данные

Нужны среда ROS 2, стандартный пакет turtlesim, личный репозиторий и course kit с checker, шаблоном отчёта и манифестом PR01. Установку и первый запуск проходим на лабораторной.

Цель

Запустить готовую систему, увидеть обмен сообщениями, сохранить состав графа и версии окружения. Затем разорвать связь разными доменами и доказать её восстановление тем же наблюдением.

Критерии зачтено

Стадия	Что требуется
1 · Собрать	turtlesim и управление с клавиатуры; список нод, топиков, типов и замер частоты /turtle1/pose
2 · Сломать	после повторного запуска подписчика в другом ROS_DOMAIN_ID данные не поступают; сохранены команда, таймаут и наблюдения
3 · Доказать	после запуска в исходном домене та же проверка получает позу; причина объяснена в отчёте
Автопроверка	check_practice.py PR01 проверит evidence/pr01/{doctor.txt,graph.md,environment.json} и заявления public_tests_passed, defect_reproduced, defect_fixed

Checker проверяет комплектность отчёта. Работу ROS подтверждают сохранённые наблюдения и повторение опыта на защите.

Перед командами: четыре понятия

• Пакет — установленный набор программ: здесь turtlesim.
• Нода — участник работающего графа: например /turtlesim.
• Топик — именованный поток: /turtle1/pose несёт положение черепахи.
• Домен — область обнаружения участников. Значение ROS_DOMAIN_ID применяется при запуске; export не перенастраивает уже работающую ноду.

ros2 run turtlesim turtlesim_node означает «запусти программу turtlesim_node из пакета turtlesim». Вводить Python-код для этого не нужно.

Что сделать

1. Подготовьте терминалы

Откройте три Bash-терминала в одной среде (одна Ubuntu/WSL или один контейнер). В каждом подключите свою дистрибуцию:

source /opt/ros/jazzy/setup.bash   # Ubuntu 24.04
# Для Ubuntu 26.04 вместо строки выше:
# source /opt/ros/lyrical/setup.bash
export ROS_DOMAIN_ID=16

В аудитории используйте выделенную вам пару доменов: ниже используются 16 и 17. Подставляйте свою пару во всех шагах, чтобы не видеть чужих черепах. Перед опытом остановите прежние talker/listener и turtlesim через Ctrl+C.

В терминале C перейдите в корень своего репозитория и подготовьте каталог:

mkdir -p evidence/pr01
ros2 doctor --report > evidence/pr01/doctor.txt 2>&1

Рабочее пространство и смысл source показаны на лекции. Создание пакета, сборка собственной ноды и тесты colcon будут следующим шагом на неделе 03.

2. Запустите и опишите исправный граф

Терминал A — симулятор (команда занимает терминал до Ctrl+C):

ros2 run turtlesim turtlesim_node

Терминал B — управление:

ros2 run turtlesim turtle_teleop_key

Нажимайте стрелки, пока фокус находится в терминале B. Черепаха движется. Терминал C — наблюдение:

ros2 node list --no-daemon --spin-time 2
ros2 topic list -t
ros2 node info /turtlesim
ros2 topic type /turtle1/pose
POSE_TYPE=$(ros2 topic type /turtle1/pose)
ros2 topic echo /turtle1/pose --once
ros2 topic hz /turtle1/pose

Последнюю команду оставьте работать не менее 10 секунд и завершите Ctrl+C. Ориентир при нормальной нагрузке — около 60–62,5 Гц (таймер turtlesim 16 мс); это не строгий порог зачёта. Запишите фактическую частоту и длительность замера. При заметном отклонении проверьте нагрузку GUI/виртуальной среды и повторите измерение. Поза публикуется и у неподвижной черепахи.

Вручную составьте evidence/pr01/graph.md: команды и их вывод, ноды и их роли, полные имена топиков и типы, измеренная частота. Имя типа позы зависит от версии: Jazzy — turtlesim/msg/Pose, Lyrical — turtlesim_msgs/msg/Pose. Команда движения приходит в /turtle1/cmd_vel.

3. Разорвите связь и восстановите её

POSE_TYPE в C хранит тип, полученный на предыдущем шаге. Он нужен явно: в чужом домене CLI не сможет узнать тип по издателю. Конструкция $(команда) подставляет её вывод в переменную.

Симулятор A всё время работает в домене 16. В B остановите teleop через Ctrl+C и запустите заново в другом домене:

export ROS_DOMAIN_ID=17
ros2 run turtlesim turtle_teleop_key

Стрелки больше не управляют черепахой. В C тоже установите домен 17, чтобы новый CLI-подписчик искал позу в той же области, что и teleop:

export ROS_DOMAIN_ID=17
ros2 node list --no-daemon --spin-time 2
timeout 5s ros2 topic echo /turtle1/pose "$POSE_TYPE" --once > evidence/pr01/pose-broken.txt 2>&1
printf 'exit=%s\n' "$?"

Ожидается /teleop_turtle, но нет /turtlesim; поза не приходит, exit=124 означает истечение пяти секунд. Другой код или ошибка импорта — другой сбой, который сначала нужно устранить. --no-daemon исключает кэш daemon из проверки. node list показывает обнаруженные ноды домена, а не процессы своего терминала.

Теперь в B остановите teleop, установите ROS_DOMAIN_ID=16 и запустите его снова. В C повторите тот же тест, изменив только домен и имя файла:

export ROS_DOMAIN_ID=16
ros2 node list --no-daemon --spin-time 2
timeout 5s ros2 topic echo /turtle1/pose "$POSE_TYPE" --once > evidence/pr01/pose-fixed.txt 2>&1
printf 'exit=%s\n' "$?"

Обе ноды видны, приходит поза, ожидается exit=0; стрелки снова двигают черепаху. Если discovery ещё не завершилось, дайте участникам обнаружиться и повторите тест. Добавьте в graph.md сравнение «до / сбой / после», домены участников и коды возврата. Объясните, почему пришлось перезапустить teleop, а симулятор и установку ROS менять не потребовалось.

4. Оформите результат

В evidence/pr01/environment.json вручную запишите JSON-объект: способ запуска (native, wsl2 или docker), версию ОС, дистрибуцию ROS, версию Gazebo, RMW и домены опыта; для Docker — digest образа. Значения берите из /etc/os-release, ros2 doctor --report, gz sim --versions и своих команд. Секреты и полный вывод переменных среды не сохраняйте.

Заполните report.json по шаблону из course kit и порядку сдачи. В этой работе коммит реализации фиксирует README с порядком запуска и CI workflow; затем отдельным коммитом добавляется evidence. В tests перечислите реально выполненные проверки графа, частоты и связи. public_tests_passed означает успешное выполнение этих проверок; не заявляйте о тестах собственной ноды, которой в ПР01 ещё нет.

Проверка

Обязательные файлы сдачи

• В корне репозитория — AI_USAGE.md, с отдельной записью для PR01: модель, инструмент, характер помощи и способ проверки. Если ИИ не использовался, напишите это явно и поставьте ai_used: false в отчёте; файл всё равно нужен. Предыдущие записи сохраняйте. Правила и пример.
• В evidence/pr01/report.json поле commit — SHA уже созданного коммита реализации. Отчёт фиксируется следующим коммитом; его SHA указывается при сдаче вместе со ссылкой на CI. Пошаговый пример двух коммитов.

python3 -m json.tool evidence/pr01/environment.json > /dev/null
python3 .course-kit/v1/tools/check_practice.py PR01 --submission .

CI первой работы проверяет JSON и комплектность evidence. Живой опыт выполняется локально. Дополнительно можно повторить безоконный talker/listener в Docker по инструкции установки.

Как работаем на лабораторной

Сначала вместе проверяем установку и исправный граф. Затем каждый повторяет разрыв связи и объясняет результат. На следующей паре сравним отчёты и начнём управление через CLI; первый пакет patrol появится после лекции 03.

Общий порядок: runbook · troubleshooting. Декларация AI_USAGE.md оформляется по правилам курса, в том числе без ИИ.

Официальные справочники

• ROS 2 Lyrical: первые шаги
• Настройка окружения
• Знакомство с turtlesim