На данный момент ты неплохо разбираешься во внутренней кухне программной части робота: узлы (ноды), топики, TF, конфигурация Rviz, написание своих launch.
Всё это позволяет уверенно идти дальше и разбираться в вопросе, как организовано движение робота во внешней среде!
Сегодня мы затронем немного теоретическую, но очень важную тему - одометрия в роботе, так как в ROS для неё выделен отдельный фрейм в REP-105 и вообще куча материала!
Если посмотреть инфу о фреймах в стандарте, то можно заметить три основные фрейма, которые выделяют относительно движущихся роботов: base_link, odom, map.
-
base_linkчасто ставят вместе сbase_footprintза единственной разницей, чтоbase_linkнаходится где-то в центре робота, аbase_footprint- на уровне Z=0 (на уровне земли). То есть,base_{link/footprint}- это фрейм, привязанный к движущемуся роботу. -
odom- интересующий нас фрейм, он показывает положение в пространстве, относительно которого робот движется. -
map- фрейм, который привязан к фиксированной точке в пространстве, относительно которой движентся робот.
Все определения фреймов даны в собственной интерпретации и не претендуют на полноту.
Так, а не кажется тебе, что odom и map уж очень похожи? По сути так, но у них есть одно маленькое различие. odom фрейм - это определённая точка в пространстве, относительно которой показывает движение наша система одометрии в роботе.
Отличительной особенностью map является то, что этот фрейм более стабилен и относительно него TF формируется не только системой одометрии, но и системам позиционирования (типа кортографирование, коррекция по карте и т.д.).
Так, кажется, это сложно, простой пример!
Вот есть вафелька и у неё есть два колеса. Мы начинаем движение и говорим ей ехать 20 секунд. Теперь, вафелька проехала какое-то расстояние, так? Но как узнать, какое?
У нас есть три источника данных: рулетка, оценка перемещения по построенной карте и колёсная одометрия.
Ну, думаю, понятно, что мы делаем автономных/телеуправляемых роботов, а значит с рулеткой не побегать - это вариант отпадает, так как не применим в ходе работы робота.
Колёсная одометрия - это неплохой метод оценить перемещение робота. У нас же есть формула длины окружности? Есть информация о диаметре. По-любому в микроконтроллере подключён энкодер с колёс, который знает, сколько оборотов робот сделал за 20 секунд. Значит можно вычислить пройденный прямо путь?
Например, 3 оборота, длина окружности колеса ~ 0.32 м. Значит, робот проехал 0.96 м. Это показания колёсной одометрии!
Карта помещения строится, например, с помощью лидара - это мы видели и пробовали. Значит, Робот (система картографирования) может соотнести новый скан от лидара и существующую карту и понять, что робот переместился.
Положим, что система карты говорит нам, что робот переместился на 1 м.
Вот так получается, что одометрия говорит о перемещении на 0.96 м, а карта говорит о перемещении на 1 м!
Тогда TF odom->base_link будет X=0.96, а что будет с map->base_link?
Система картографирования сместит TF map->odom на 0.04 м, чтобы TF map->base_link получился X=1.0.
О том, как работает система карт с фреймом map мы поговорим в другой теме, но главное, что odom фрейм и TF odom->base_link показывает, как смещается робот в мире, судя по показаниям одометрии. Во многих системах есть ошибки расчёта математики одометрии (не любое движение можно по длине окружности посчитать), а также, робот может попросту пробуксовывать, а система внутри него будет думать, что робот всё ещё движется!
Давай проверим это на практике!
Нам надо убедиться, что колёсная одометрия не всегда отражает корректные показания и подвержена влиянию разных факторов. Сейчас мы проведем эксперимент, в котором упремся в столб и будем дальше двигаться в него. Во время этого движения посмотрим, как отрабатывает система одометрии по колёсам.
В нашем симуляторе вафельки уже включена колёсная одометрия, но разработчики пакета черепашки сделали хитро. В качестве источника информации используется информация из симулятора, что не соответсвует работе в реальному мире. Нужно в качестве источника информации сделать энкодер, а не информацию из симулятора.
Можно не делать следующие действия, если переживаете, результаты мы показали в виде gif в конце раздела!
Для приведения модели к поведению как в реальном мире надо выполнить следующую команду, которая находит в файле описания модели источник одометрии и заменяет на encoder источник.
Всегда аккуратно относитесь к командам, которые делаются с
sudo. Лучше лишний раз переспросить, если не уверены в том, что команда делает.
sudo sed -i -E "s/(<odometrySource>).*(<\/odometrySource>)/\1encoder\2/" "$(rospack find turtlebot3_description)/urdf/turtlebot3_waffle.gazebo.xacro"
sed- это очень мощная утилита для поиска и замены строк текста в файле.
Чтобы вернуть обратно на то, как было [клик]
```bash
sudo sed -i -E "s/(<odometrySource>).*(<\/odometrySource>)/\1world\2/" "$(rospack find turtlebot3_description)/urdf/turtlebot3_waffle.gazebo.xacro"
```
После этого запускай наш симулятор (turtlebot3_sim_start.launch), управление на клавиатуре (на твой выбор). После этого настрой в Rviz отображение TF и данных с лидара, а в качестве Fixed Frame поставь odom.
Иии, поехали в столб! Как упрёшься, не останавливайся, смотри, как ведёт себя TF! Ему кажется, что колёса всё ещё крутятся, а значит TF odom->base_footprint продолжает смещать, но на деле ведь не так?
Вот результат в виде GIF:
В конце записи мы немного понажимали влево и вправо, но видишь, робот упёрся и не может откликнуться.
Укатились, думает робот, а на деле всё там же =)
Главное, что надо запомнить, на колёсных роботах колёсная одометрия - это один из наиболее часто используемых источников информации. В большинстве случаев он полезен и хорошо работает, но надо понимать, что малые промахи и через час катаний робот, судя по колесной одометрии, уже будет не там, где реально находится. Это называется дрифт - он проявляется как смещения между истинным значением и показаниями измерений. Ему подвержены относительные источники измерения. Абсолютные (например, ориентир по маячкам или по карте) как правило не страдают от такого эффекта.
Таким образом, уровень фрейма odom - это относительные показания от разных видов одометрии (колесная, визуальная, инерциальная), которые позволяют локализовать робота, но могут иметь дрифт.
Не забывай закидывать наработки в Git!
Если ты провёл замену на encoder источник информации одометрии в модели, то можешь попробовать включить turtlebot3_slam.launch из своего пакет и посмотреть, что происходит, когда с учётом gmapping робот едет в стену? Попробуй поменять Fixed Frame на odom, потом обратно на map.
- Какие источники информации подвержены дрифту?
- Какие виды одометрии вы знаете/узнали?
- В каких ситуация кроме езды в стену/столб одометрия может врать?