Системы координат ROS 2 TF2 для мобильных роботов

Скан лазера измеряется относительно лазера, поза одометрии колёс — относительно начальной системы координат, а цель навигации обычно задаётся в системе map. Чтобы сравнивать их, роботу необходимо геометрическое отношение между системами координат в правильный момент времени. Система TF2 в ROS 2 хранит это изменяющееся со временем дерево преобразований и выполняет его запросы.

Большинство отказов TF2 связано не с продвинутой математикой. Причиной становится отсутствующий родитель, обратное преобразование, неверная метка времени или два узла публикуют одно и то же преобразование.

Мыслите преобразованиями, а не копированием поз

Преобразование описывает поступательное перемещение и поворот от родительской системы координат к дочерней. Если base_link → laser задаёт, что лазер находится на 0.20 m впереди и 0.10 m выше основания робота, TF2 может преобразовать измерения лазера в систему координат основания. В сочетании с odom → base_link они выражаются в локальных координатах одометрии.

Системы координат образуют дерево: в каждый момент у каждой дочерней системы есть ровно один родитель. Преобразование может изменяться, но родительское отношение не должно быть неоднозначным. Циклы наподобие A → B → C → A недопустимы.

Идентификаторы систем координат (IDs) — семантические имена, а не единицы измерения или данные. Для точки, заданной в системе координат laser, по-прежнему необходимо соответствующее преобразование на момент измерения.

Используйте стандартную цепочку мобильного робота

Типичное дерево навигации имеет вид:

map → odom → base_link → laser
                       → camera_link
                       → imu_link

У каждой связи своя задача:

• map → odom: глобальная коррекция локализации. Она может изменяться, когда локализация исправляет накопленный дрейф.
• odom → base_link: плавное локальное перемещение по данным колёсной, визуальной или инерциальной одометрии. Оно должно быть непрерывным, но может дрейфовать.
• base_link → sensor: фиксированная геометрия установки, обычно статическое преобразование.

Разделение map и odom позволяет вносить глобальные коррекции, не вызывая скачков локальной системы управления. Имена соответствуют соглашениям ROS, но ваш робот может добавить base_footprint, системы координат подвеса или шарнирных звеньев.

Определите владельца каждого ребра

Перед запуском узлов составьте таблицу владения:

Каждое ребро должно публиковать ровно один авторитетный компонент. Два публикатора создают чередующиеся или конфликтующие преобразования, которые могут выглядеть как случайные скачки позы.

Статические преобразования описывают измеренную геометрию установки. Задайте начало координат и ориентацию осей там, где их ожидает модель датчика. Оптическая система координат камеры использует другие соглашения об осях, чем типичная система координат основания робота, поэтому следуйте соответствующему соглашению ROS для датчиков, а не пытайтесь угадать по рисунку.

Исследуйте действующее дерево

Начните с данных из командной строки:

ros2 run tf2_tools view_frames
ros2 run tf2_ros tf2_echo odom base_link
ros2 run tf2_ros tf2_echo base_link laser

view_frames создаёт граф, показывающий связность, публикаторов, частоту обновления и сведения о времени. tf2_echo target source сообщает преобразование, переводящее данные из исходной системы координат в целевую. Перестановка аргументов показывает обратное преобразование — источник частой путаницы.

В RViz осознанно задайте неподвижную систему координат. Если это map, но преобразование map → odom отсутствует, отображение, зависящее от одометрии и датчиков, невозможно разместить, хотя их собственные сообщения поступают.

Соблюдайте метки времени измерений

TF2 хранит историю динамических преобразований. Сообщение датчика с меткой времени t следует преобразовать с использованием дерева в момент t, а не просто последнего преобразования. Это важно при движении робота: использование более поздней позы смещает наблюдение.

Используйте общий источник часов во всех узлах. В симуляции все участники должны согласовать смоделированное время. На нескольких компьютерах часы необходимо синхронизировать с точностью, соответствующей времени работы датчика.

Ошибка «extrapolation into the future» часто означает, что запрошенная метка времени новее доступного преобразования. «Extrapolation into the past» означает, что запрошенные данные старше буфера TF2. Увеличение буфера может помочь с действительно задержанными данными, но не исправит рассинхронизированные часы или метки времени, созданные на неверном этапе.

Проверьте геометрию простыми физическими испытаниями

Значения могут выглядеть правдоподобно при неверных осях. Проверяйте по одному отношению:

1. Оставьте робота неподвижным и визуализируйте точки датчика в base_link.
2. Поместите цель прямо перед роботом. Преобразованное положение должно лежать на ожидаемой передней оси.
3. Поверните робот на месте. Неподвижная цель в мире должна оставаться неподвижной в odom, кроме ошибки одометрии.
4. Переместите робот вперёд. Наблюдения датчиков должны перемещаться согласованно с позой основания.

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

Преобразуйте данные на стороне получателя

Потребитель должен указать нужную целевую систему координат и попросить TF2 преобразовать данные с меткой времени. Не копируйте вручную значения смещения и поворота в формулы приложения: это обходит синхронизацию времени, последовательное объединение преобразований и проверенную обработку кватернионов.

Если преобразование может прийти немного позже сообщения, используйте фильтр сообщений с поддержкой TF или ограниченное ожидание, подходящее для узла. Не блокируйте контур управления в реальном времени на неограниченное время из-за ожидания геометрии.

Идентификаторы систем координат (IDs) не должны содержать начальных косых черт и должны иметь одинаковое написание и регистр. Пространства имён следует предусмотреть для мультироботных систем, чтобы robot_1/base_link и robot_2/base_link не конфликтовали.

Диагностируйте отказы по виду ошибки

• Нет связи между системами координат: отсутствует ребро или имя системы координат у публикатора и в сообщении различается.
• Дерево чередуется между позами: два узла публикуют преобразование одной дочерней системы.
• Данные датчика повёрнуты на 90° или зеркальны: неверна статическая ориентация или соглашение оптической системы координат.
• Данные отстают от движения: неверны метки времени, преобразования приходят с задержкой или получатель использует последнее преобразование.
• Робот скачет в глобальной системе, но локальное управление плавное: это может быть допустимая коррекция локализации map → odom.
• Локальное управление скачет при обновлении локализации: глобальная поза ошибочно публикуется как odom → base_link.
• RViz показывает сообщения, но не может их разместить: неверна неподвижная система координат или связность дерева.

Поза, вычисленная в одометрии дифференциального привода, естественным образом предоставляет odom → base_link. Руководство по основам SLAM объясняет, какой глобальный оценщик предоставляет map → odom и почему это разделение важно.