# 7.8.4 The/odom Topic versus the/odom Frame

Читателю может быть интересно, почему мы использовали TransformListener в предыдущем скрипте для доступа к информации об одометрии, а не просто для подписки на тему / odom. Причина в том, что данные, опубликованные по теме / odom, не всегда являются полной историей. Например, TurtleBot использует одноосный гироскоп для дополнительной оценки вращения робота. Это объединено с данными от колесных кодеров узлом robot\_pose\_ekf (который запускается в файле запуска TurtleBot), чтобы получить лучшую оценку вращения, чем один из источников в отдельности.

Однако узел robot\_pose\_ekf не публикует свои данные обратно в теме / odom, которая зарезервирована для данных колесного энкодера. Вместо этого он публикует его в теме / odom\_combined. Кроме того, данные публикуются не как сообщение одометрии, а как сообщение PoseWithCovarianceStamped. Тем не менее, он публикует преобразование из фрейма / odom в фрейм / base\_link (или / base\_footprint), который предоставляет необходимую нам информацию. В результате, как правило, безопаснее использовать tf для мониторинга преобразования между фреймами / odom и / base\_link (или / base\_footprint), чем полагаться на тему сообщения / odom.

В каталоге rbx1\_bringup / hosts вы найдете узел с именем odom\_ekf.py, который повторно публикует сообщение PoseWithCovarianceStamped, найденное в теме / odom\_combined, как сообщение типа Odometry в теме под названием / odom\_ekf. Это сделано только для того, чтобы мы могли просматривать темы / odom и / odom\_ekf в RViz, чтобы сравнить одометрию на основе колеса TurtleBot с комбинированной одометрией, включающей гироскопические данные.
