roboforum.ru

Если будете заводить какой-нибудь SLAM (gmapping/amcl), то рекомендую озаботиться синхронизацией времени между роботом и компом, на котором будет работать построение карты. rostf хорошенько глючит если время не совпадает. NTP/chrony/ntpdate.

Вчера добавил поддержку cmd_vel в контроллер, и запустил move_base_simple http://isr-uc-ros-pkg.googlecode.com/sv ... simple.cpp (поскольку с сообщением одометрии пока проблемы, переделал на tf)
так что теперь в rviz указываю точку в пространстве и робот туда едет.
всплыли следующие проблемы:
1) пока не могу разобраться куда у меня указывает вектор одометрии, проблема проявляется в том что робот едет в противоположный угол от указанного на карте, но достигает цели и останавливается.
2) управляющие сигналы - линейная и угловая скорость, но при этом сигнал с энкодеров не совпадает с тем что приходит на вход, не знаю пока с какого конца разруливать это. толи энкодеры подстраивать, толи обратную связь по энкодерам делать.
3) нужно быть очень внимательным с единицами измерения, линейная скорость задаётся в m/s угловая rad/s соответственно сигналы с энкодеров нужно приводить к этим единицам.

Отвечаю на свой вопрос forum102/topic13980.html#p298193
да это одно и то же.

Есть ещё такая штука http://wiki.ros.org/robot_pose_ekf
нужно будет попробовать.

robot_pose_ekf полезен если у вас помимо обычной одометрии есть ещё какая-то информация, например GPS, IMU, visual odometry. Иначе получите просто сглаживание. Тем более там скучный калман: он не читает cmd_vel, а команды скорости правильный калман должен учитывать.
В nav_msgs/Odometry указывается два TF фрейма: фрейм, относительно которого вы пишете суммарную одометрию (header.frame), как правило это "odom", и фрейм, относительно которого указывается скорость робота (child_frame), как правило там что-то типа "base_link"
Проверять показания одометрии можно в том же rviz, добавив оснастку Odometry и указав там соответствующую тему. Так же добавляем оснастку с TF и сравниваем, где находятся фреймы TF, а где соответствующая стрелка от Odometry

Чугунный Дятел писал(а):robot_pose_ekf полезен если у вас помимо обычной одометрии есть ещё какая-то информация, например GPS, IMU, visual odometry. Иначе получите просто сглаживание. Тем более там скучный калман: он не читает cmd_vel, а команды скорости правильный калман должен учитывать.
В nav_msgs/Odometry указывается два TF фрейма: фрейм, относительно которого вы пишете суммарную одометрию (header.frame), как правило это "odom", и фрейм, относительно которого указывается скорость робота (child_frame), как правило там что-то типа "base_link"
Проверять показания одометрии можно в том же rviz, добавив оснастку Odometry и указав там соответствующую тему. Так же добавляем оснастку с TF и сравниваем, где находятся фреймы TF, а где соответствующая стрелка от Odometry

У меня есть imu, изначально так и планировал, просто не знал что есть готовый модуль.

Я только вчера разобрался с ошибкой, которая приводила к сбою при передаче сообщения odomery, через rosserial.
дальше пока не продвинулся.
Кому интересно вот тут описан формат протокола rosserial http://wiki.ros.org/rosserial/Overview/Protocol
в протоколе я изъянов не нашёл.

есть только одна проблема, rosserial фактически использует тот же формат сообщений что и ros, что не совсем оптимально особенно на микроконтроллерах.
например сообщение одометриии серриализуется в 715 байт (два вектора, кватернион и две матрицы 6x6 и всё это формата float64),что довольно жирно для uart.
в идеале нужно бы иметь инструмент в rosserial - проксирующую прослойку, для которой можно сгенерировать упращённые сообщения, а на стороне сервера переводить эти сообщения в полный формат.

Мне пока непонятно как понять, правильно ли сообщения трансформации показывают положение робота (yaw), и правильно ли реагирует на команды cmd_vel?
По карте оно двигается но есть подозрение что робот ездит боком.

нашёл, вот тут описаны принятые в ROS соглашения http://wiki.ros.org/geometry/CoordinateFrameConventions

Добавлено спустя 54 минуты 50 секунд:
Re: Самодельный робот на базе ROS - Custom mobile robot with ROS
noonv,
сравнивая ваш протокол с rosserial, обратил внимание на небольшой недочёт (на мой взгляд).
функции orcp2::copy* ничего не возвращают, хотя логичнее было бы если бы они возвращали длину скопированных данных, чтобы избежать двойного подсчёта длины

например есть

Код: Выделить всё

orcp2::copy_int32(dst+l, src->Encoder[i]);
l += sizeof(src->Encoder[i]);


а лучше если будет

Код: Выделить всё

l += orcp2::copy_int32(dst+l, src->Encoder[i]);


У нас такой тест правильности одометрии:
1. Открываем rviz,
2. Включаем рисование лазерного дальномера
3. В качестве базового фрейма ставим /odom
4. Едем в пределах метра.

При этом точки дальномера должны оставаться более менее неподвижными (в пределах погрешности одометрии). Лазерный дальномер можно заменить на kinect/xtion и смотреть на облако точек вместо скана, но суть та же: точки не должны убегать.

linvinus писал(а):noonv,
сравнивая ваш протокол с rosserial, обратил внимание на небольшой недочёт (на мой взгляд).
функции orcp2::copy* ничего не возвращают, хотя логичнее было бы если бы они возвращали длину скопированных данных, чтобы избежать двойного подсчёта длины

например есть

Код: Выделить всё

orcp2::copy_int32(dst+l, src->Encoder[i]);
l += sizeof(src->Encoder[i]);

а лучше если будет

Код: Выделить всё

l += orcp2::copy_int32(dst+l, src->Encoder[i]);

Спасибо, очень полезное замечание

Чугунный Дятел писал(а):У нас такой тест правильности одометрии:
1. Открываем rviz,
2. Включаем рисование лазерного дальномера
3. В качестве базового фрейма ставим /odom
4. Едем в пределах метра.

При этом точки дальномера должны оставаться более менее неподвижными (в пределах погрешности одометрии). Лазерный дальномер можно заменить на kinect/xtion и смотреть на облако точек вместо скана, но суть та же: точки не должны убегать.

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

на заметку, в rviz оси выделены цветом но не подписаны (например фрейм base_link)
red base_link.x (положительное напрвление вперёд относительно робота)
green base_link.y (положительное направление влево относительно робота)
blue base_link.z (положительное направление вверх относительно робота)

если я всё правильно понял,проверить можно так:
если при движении (линейная скорость 0.02 угловая 0) робот движется своей осью base_link.x (red), относительно фрейма /odom, вдоль оси odom.x (red),то оси x, в которой рассчитывается одометрия и base_link совпадают
если при движении (линейная скорость 0.0 угловая 0.2) робот вращается против часовой стрелки, относительно фрейма /odom, то оси y совпадают

Добавлено спустя 2 часа 49 минут 6 секунд:
Re: Самодельный робот на базе ROS - Custom mobile robot with ROS
ура, наконец то робот приехал в точку назначения.
как я и предполагал были перепутаны направления осей, проверял по инструкции выше.
было,
1) при движении вперёд направление движения указывала ось y (зелёная), должна быть x
2) при положительной угловой скорости вращение было по часовой стрелке,должно быть наоборот.
меняем синусы косинусы местами, плюс на минус, и стало как положено.


Добавил 3D модель робота.


Добавлено спустя 2 часа 26 минут 39 секунд:
Re: Самодельный робот на базе ROS - Custom mobile robot with ROS
На данный момент выполнены следующие шаги:
1) создана прошивка для контроллера
которая получает сообщение cmd_vel от rosmaster и публикует на нём сообщения tf (95 байт) и odometry (715 байт)
заданные скорости поддерживаются пид алгоритмом.
одометрия рассчитывается по сигналам с энкодеров
связь с мастером по uart (протокол rosserial) (500000 бод), частота сообщений 20Гц (занята треть полосы пропускания)

2) со стороны мастера (marsboard a20) запускается нода
rosserial_python/serial_node.py
и не стандартный модуль http://wiki.ros.org/move_base_simple
он создаёт сообщения cmd_vel и направляет робота к заданной точке назначения (точку назначения публикует rviz).
ланч файл.

Код: Выделить всё

<launch>
   <node pkg="rosserial_python" type="serial_node.py" name="my_serial" args=" ">
       <param name="~port" value="/dev/ttyS2" />
       <param name="~baud" value="500000" />
   </node>
   <node pkg="move_base_simple" type="move_base_simple" name="move_base_simple"/>
</launch>

3) на ноутбуке
в .bash_rc
есть запись
ROS_MASTER_URI=http://kr1:11311
которая всегда указывает на мастера, связь с мастером по wifi
на ноутбуке запускаются ноды
joint_state_publisher,robot_state_publisher и rviz

Народ, извиняюсь, что вклиниваюсь в вашу беседу.
Наша команда тоже ведет свой проект по созданию робота. Вот ссылка кому интересно
forum10/topic13841.html
У меня возникла некоторая мысль (и я ее думаю ) по поводу одометрии. Всем нам известно какую погрешность вносят энкодеры и дальномеры в данные одометрии, а если еще использовать SLAM, то через какое то время перемещения робота эта ошибка, если не производить корретировку, становится на столько большой, что робот просто начинает блуждать как ему вздумается. А идея вот в чем:
ROS очень тесно интегрирован с библиотекой компьютерного зрения OpenCV (хотя совсем не обязательно использовать библиотеку только в ROS). Сама эта библиотека представляет очень большой функционал по обработке видео, в том числе и с видео камер. Предлагаться следующее - создать систему одометрии по аналогии с оптической мышью компьютера. В мышке принцип такой: с частотой в несколько десятков герц сенсор мышки "фотографирует" поверхность стола (или чего там еще) по которому она (мышка) движется, при обнаружении смещения вычисляется вектор этого самого смещения, по вектору можно определить как скорость, так направление движения. Затем эти данные передаются в компьютер, который и отображает перемещение указателя по экрану синхронно с мышкой по столу.
Теперь к нашим баранам. Мы устанавливаем на робота простую веб-камеру, но не как обычно, когда камера смотрит вперед, а разворачиваем ее объективом вниз, в пол, так, чтобы камера видела поверхность по которой движется робот. Разумеется, нужно учесть фокусное расстояние, и возможно придется применить подсветку участка пола куда смотрит камера. С помощью библиотеки OpenCV анализируем полученные от камеры кадры - захватываем характерные точки пола (неровности, шероховатости, текстуру, пылинки и пр.) сравнением этих точек от предыдущего кадра к следующему (OpenCV умеет это делать), можно, очень точно, определить тот самый вектор смещения, и высчитать расстояние и угол на которые переместился наш робот за единицу времени. Ну, а имея все эти данные легко их применить к одометрии и вообще к SLAM. Самое главное, что точность такой одометрии будет практически идеальной. Ведь в этом случае мы не просто уходим от ошибок энкодеров и сканеров, мы имеем полную обратную связь между перемещением робота и реальным смещением его относительно пола.
На сегодняшний день это только идея, которую мы планируем реализовать в своем проекте.
Что скажете? Критика принимается.

>есть запись
>ROS_MASTER_URI=http://kr1:11311
Если у вас под рукой ровно один робот, то рекомендую попробовать multimaster_fkie, позволяет объединять несколько сетей с отдельными ros master в одну большую сеть, причём более менее автоматически, с поиском всех мастеров в сети.
Следует кстати помнить, что ROS узлы находят друг друга по имени, а не по IP адресу, а значит для нормальной связи все компы должны взаимно пинговаться. Явный симптом: данные с робота идут, но робот команд не слушается.

Добавлено спустя 29 минут 14 секунд:
Re: Самодельный робот на базе ROS - Custom mobile robot with ROS
>На сегодняшний день это только идея, которую мы планируем реализовать в своем проекте.
Хорошее начинание. Если хотите разобраться в вопросе более основательно, то рекомендую следующее:
1. Повесить камеру на потолок, на робота наклеить QR-код или любой другой отличимый (средствами OpenCV) маркер.
2. Средствами OpenCV отследить положение робота по маркеру. Конечно же предварительно исполнить "шахматный" ритуал по калибровке камеры
3. Собственно реализовать алгоритм определения смещения робота по камере.
4. Сравнить координаты, полученые из визуальной одометрии, с координатами от камеры на потолке.
5. Рассказать о результатах

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

Nesenin писал(а):http://www.kb-avrora.ru/map_room

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


Чугунный Дятел, благодарю за рекомендации, непременно воспользуемся, и результаты обязательно опубликуем.

lori писал(а):Народ, извиняюсь, что вклиниваюсь в вашу беседу.

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

Мышей обсуждали тут forum35/topic11223-315.html и тут forum10/topic5280-105.html
Для проверки своей теории возьмите камеру и направьте в пол, посмотрите много ли данных вы сможете выудить из это, пол может быть разным с рисунком и без.

Я с мышами тоже работл и объективы подбирал чтобы расстояние увеличить, но конструкция получается очень сложной, для вашего гиганта наверное пойдёт а уменя робот 13см в диаметре и 10см высотой.

И кинект есть, но не используется по той же причине, большой, и минимальная ближняя зона 1м.

для камеры есть и поинтереснее задачи, например
forum51/topic9799-150.html
или http://www.robots.ox.ac.uk/~gk/ (есть исходники)

Одометрию нужно корректировать.
А вообще есть варианты точного передвижения и без одометрии
http://www.youtube.com/watch?v=sieBqVxTz2c

если что то прикрутите к ROS то милости просим

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

Забыл добавить в отчёт
4) imu я тоже подключил (акселерометр гироскоп компас), но сначала хотел его использовать только внутри контроллера, для корректировки одометрии.
В том алгоритме AHRS, что я реализовал в контроллере, положение (yaw) сильно завязано на компас, а компас штука очень ненадёжная, реагирует на маленький магнит размером 5x5x3 мм уже на расстоянии 10см от компаса.

сейчас в раздумьях. думаю попробовать в связке с robot_pose_ekf.

Добавлено спустя 1 час 46 минут 26 секунд:
Re: Самодельный робот на базе ROS - Custom mobile robot with ROS
lori,
Мне кажется вот ответ на ваш вопрос http://wiki.ros.org/viso2_ros

linvinus, с AHRS да, тоже есть свои проблемы. Из-за работы движков она начинает "плыть", например проехали, остановились, а показания медлено поворачиваются. Но с ней всё равно лучше чем без.

hector_slam неплохая навигация, но для хороших дальномеров, типа SICK или hokuyo 30lx. На кинекте скорее всего будут проблемы со сходимостью карты. У нас был похожий алгоритм, но мы от него отошли. Математику, увы, так просто не обмануть, или, если другими словами: одним сканматчером (и матчером с картой) сыт не будешь.

Добавлено спустя 2 минуты 28 секунд:
Re: Самодельный робот на базе ROS - Custom mobile robot with ROS
И ребята с hector немного лукавят про odometry free: они всё равно IMU используют, что впринципе то же самое что и одометрия (интегрирование оценки скорости)

реализация AHRS которую я использую, требует указать минимальные и максимальные значения для сырых данных компаса.
В документации на компас сказано что в зависимости от широты показания могут плавать, поэтому требуется калибровка.

Так вот, даже на минимальной чувствительности компас улавливает посторонние предметы, например экран ноутбука, полагаю там есть магнит.
получается после калибровки при физическом повороте от 0 - 270 градусов о показывает поворот только на 180 градусов а в оставшиеся 90 градусов остальные 180, что с этим делать непонятно.

Ещё всплыл у меня вопрос как заполнять матрицу ковариаций,в сообщении одометрии.
в документации ROS сказано берите из datasheet, у меня его нет

насколько я понимаю эта матрица ещё должна пересчитываться в зависимости от управляющих воздействий (например cmd_vel)?

До slam я пока не добрался, у меня робот в разобранном состоянии на столе лежит.
Жду запчасти.

hector_slam неплохая навигация, но для хороших дальномеров

У меня с моим простейшим дальномером боле-менее работает (по крайней мере, лучше чем родной gmapping).
Одометрия или IMU там используется вроде бы только для того, чтобы обнаруживать начало движения робота.