Appearance
От симуляции к реальному роботу
В ноябре команда готовит приложение на дифференциальной модели ros2-robocar, в декабре переносит его на подготовленный реальный робот и проверяет на трассе. Это план этапов работы, а не новые сроки сдачи. Робот ещё проходит настройку: результаты симуляции помогают подготовить испытание, а решение о выезде на пол принимает ответственный за испытание по измерениям.
Уже выданные практики используют учебный Ackermann-стенд и его fixtures. Их входы, критерии и квалификация сохраняются. Командный робот поворачивает разностью скоростей колёс. Применяем изученные принципы к этому приводу в проектном профиле, сохраняя воспроизводимые проверки практик отдельно.
Что сохраняем при переключении
Приложение получает измерения, оценивает ситуацию и выбирает допустимую команду. Меняется источник измерений и исполнитель: в симуляции это Gazebo, на роботе — его драйверы и runtime. Подготовьте два профиля запуска, sim и real, с одинаковыми интерфейсами приложения. Алгоритмам не нужно знать устройство соединений с оборудованием.
| Интерфейс проекта | Контракт приложения |
|---|---|
/cmd_vel | geometry_msgs/msg/TwistStamped: свежий stamp, frame_id=base_link; linear.x — м/с, angular.z — рад/с |
/odom | nav_msgs/msg/Odometry: header.frame_id=odom, child_frame_id=base_footprint |
/scan | sensor_msgs/msg/LaserScan, frame_id=laser_frame; проверяем время, углы, единицы и QoS |
/camera/image_raw, /camera/camera_info | sensor_msgs/msg/Image и CameraInfo; профиль приводит драйвер к этим именам, оптические оси — в camera_optical_frame |
| TF | odom → base_footprint → base_link; далее крепления датчиков и camera_link → camera_optical_frame |
| Время | use_sim_time=true для симуляции; false для реального робота |
Поток команды проходит через проверку безопасности и единственный адаптер привода. У /cmd_vel один управляющий издатель; второй контроллер не подключается параллельно. Правила учебных /drive/raw и /drive/safe описаны в контрактах проекта. AckermannDriveStamped из практик и проектный TwistStamped — разные интерфейсы: рулевой угол нельзя просто переименовать в угловую скорость. Дифференциальный контроллер выбирает линейную и угловую скорости для своей кинематики.
У каждого ребра TF один владелец. В симуляции odom → base_footprint публикует её backend, на роботе — robocar_runtime; base_footprint → base_link и крепления датчиков задаёт описание робота. Локализатор добавляет map → odom. Не создавайте одновременно второе odom → base_link: у base_link уже есть родитель.
Для replay отдельно выбираем записанные часы и TF. Рабочую симуляцию или робот с теми же топиками рядом с player не запускаем. На реальном роботе телеметрия приводится runtime к ROS-времени; её часы не включают use_sim_time у приложения.
Ноябрь: подготовить перенос в симуляции
С недели9 в course kit доступны .course-kit/v1/fixtures/robocar/{lab.sdf,bridge.yaml,README.md}: локальный мир с дифференциальной моделью, RGB-камерой и лидаром без загрузок Fuel. Создайте проектный bringup и адаптеры, применив опыт ПР07; используйте README внутри fixture для имён потоков, frames и оценочных параметров динамики. CAD-меши и закрытая реализация стенда в этот комплект не входят.
- Сверить модель. В RViz проверить масштаб и направление корпуса, оси колёс, положение лидара и оптические оси камеры. Сопоставить TF с геометрией подготовленного выпуска
ros2-robocar. Картинка в RViz сама по себе не проверяет массы, контакты и движение Gazebo; физические параметры симуляционного профиля проверяем отдельным движением и остановкой. - Получить один работающий путь данных. Проверить типы, QoS и frames, команду, физическое перемещение модели и одометрию. Сохранить короткую запись и использовать её для повторяемой диагностики.
- Проверить приложение на отказах. Потеря scan, устаревшее изображение, отсутствие достоверной дальности и прекращение команд должны давать объяснимый результат. Профиль симуляции должен позволять повторить эти случаи до работы с оборудованием.
- Подготовить кандидата для робота. Зафиксировать код приложения, ревизию модели/backend и конфигурацию. Повторить запуск с чистого состояния, остановку и возврат к предыдущей версии. Оставить в README одну команду запуска приложения для каждого профиля и ожидаемые наблюдения.
Как используем практики
| Работа | Ноябрь: симуляция и повтор записи | Декабрь: применение к роботу |
|---|---|---|
| ПР07 — данные и движение | Проверить путь команды до дифференциального привода, scan/odom/TF и физическое движение модели | Сверить те же интерфейсы с драйверами и runtime; Gazebo bridge заменяется аппаратным backend |
| ПР08 — локализация | Повторять AMCL на записи; для проекта согласовать frames и карту с его моделью | После проверки одометрии и крепления лидара использовать карту реального полигона и измеренную геометрию |
| ПР09 — восприятие | Проверить 2D-выдачу, время, кодировки и unknown; RGB-D вычисления практики оставить на её фиксированных входах | Получать RGB и scan; дальность связывать с объектом только при проверенной ассоциации, калибровке и TF |
| ПР10 — описание сцены | Отладить схему, неопределённость и кэш на mock/cache | Подать записанные кадры своей камеры; сохранить происхождение и свежесть результата |
| ПР11 — безопасность | Проверить потерю данных, команд и явное восстановление сессии | Повторить разрешённые испытания останова и измерить реакцию под нагрузкой; учесть Hold и новый enable |
| ПР12 — сравнение контроллеров | Сохранить неизменный benchmark практики; проектный адаптер отдельно проверять с дифференциальными командами | Переносить выбранный алгоритм только в согласованных пределах; сравнивать с измерениями, а не с одним удачным заездом |
| ПР13 — последовательность действий | Проверять каждый шаг и отбрасывать остаток после отказа на виртуальном времени | Согласовать прерывание с runtime; прекращённая сессия не возобновляется следующей командой автоматически |
| ПР14 — версия и повторяемость | Пройти учебную квалификацию на её опубликованном Ackermann-контракте; отдельно зафиксировать кандидат проекта | Выйти на трассу только после аппаратного допуска; связать реальный прогон с точной версией приложения, backend и настроек |
Полная настройка Nav2 на реальном роботе пока не принята. Показ готового Nav2 в учебном стенде не означает готовности аппаратного bringup. Для проекта нужно согласовать локализацию, footprint, кинематику, источник команд и переходы сессии управления.
RGB, лидар и неизвестная дальность
Камера проекта — RGB; 2D-лидар не выдаёт совмещённое изображение глубины. Нельзя подставить массив LaserScan вместо depth из ПР09 или перенести калибровку её изображений 8×6 на реальную камеру.
Для совместного наблюдения нужны калибровка камеры, проверенный TF между сенсорами на время измерения и правило сопоставления. Лазерный луч должен действительно относиться к найденному объекту; ближайшее отражение вообще не обязано попадать в его рамку. Скан лежит в одной плоскости и не задаёт геометрию всего предмета. При неоднозначности сохраняем 2D-детекцию, дальность остаётся unknown. Сначала проверяем такую ассоциацию на записи; решение о движении опирается на отдельные условия безопасности.
Декабрь: подготовленный робот и трасса
Начинаем с просмотра данных и модели без выдачи команд. Проверяем положение сенсоров, соответствие осей реальному корпусу, свежесть одометрии и scan, кодировку и калибровку камеры. Затем ответственный за испытание определяет разрешённый объём испытаний: прямой участок, остановка и последующие элементы трассы. Реверс и разворот на месте требуют отдельной проверки.
В текущем robocar_runtime r6 нулевая команда, disable или watchdog завершают сессию управления и запрашивают Hold. Следующая ненулевая команда не должна самостоятельно возобновлять движение: требуется новое явное разрешение оператора. В частности, обычную паузу Nav2 нельзя считать готовой схемой stop/resume для этого runtime.
Текущие пределы runtime 0,1 м/с и 0,3 рад/с — предварительные ограничения, а не подтверждённая скорость или безопасность движения по полу. Под нагрузкой ещё измеряются скорость, эффективные параметры привода и останов. Время срабатывания программного watchdog не равно времени физической остановки; результаты потери команды и потери самого процесса фиксируются отдельно. Аппаратные подключения и порядок разрешения привода остаются в процедуре ответственного за испытание.
Что сохраняем о переносе
Используйте существующие README, конфигурацию проекта и журнал эксперимента, не создавайте пустые отчёты после каждого запуска. Для воспроизведения нужны:
- Версии: полный SHA приложения, ревизия backend/описания робота, хэш выбранной конфигурации, версия ROS и образа. Одного SHA приложения мало, если геометрия или настройки привода менялись отдельно.
- Входы: короткая запись нужных измерений с TF, её контрольная сумма, карта и калибровка, параметры времени. Перечень топиков зависит от опыта; для реального робота не добавляем симуляционные часы.
- Измеренный результат: что запрашивали, что произошло и какой отказ проверяли; физическое перемещение и odom, остановка и её причина, свежесть входов, ограничения конкретного прогона. Отделяйте наблюдение в симуляции от измерения на полу.
Учебная квалификация подтверждает воспроизводимость её фиксированного контракта и сценариев. Аппаратный допуск подтверждает готовность конкретного робота к конкретному испытанию. Ни один из этих результатов не заменяет другой. Условия сдачи, рубрика и обязательные файлы остаются на страницах практик и в регламенте проекта.