Самодельный робот на базе ROS - Custom mobile robot with ROS

daner

к сожалению, что-то вам посоветовать в голову не приходит (посоветуюсь с коллегами, но это будет через пару дней, так как у нас праздники).
Но ВСЕ вами описанное (т.е. конфигурации) у нас совершенно нормально работает. правда одометрию мы с колес не используем вообще, а берем только со скан мэтчеров.
ROS работает великолепно.

RootAdmin

Пинг к росу отношертя ИМХО не имеет. Я б top запустил и глянул загрузку. Да, и если через вайфай - то не включена ли рядом микрлволновка. Серьезно, может давать помеху.

linvinus

citizen писал(а):

Также заметил, что связка: (дальномер + roomba + raspberry с ros ) + роутер + (ноутбук с ros) работает как-то коряво.
Иногда ping до raspberry c ноутбука начинает достигать 100-2000 мс. Работа ros при этом становится просто ужасной. Причем складывается ощущение, что это связано с самой ros - пинг может резко увеличиваться при ручном указании amcl координат робота на карте.
Может ли это быть связано с static_transform_publisher, связывающего base_link и laser_link, или transform_publisher одометрии, которые работают на raspberry pi?

запустите

Код:

rostopic hz tf

на raspberry и на ноуте
сравните значения

1) на raspberry могут запускаться задания по cron, например обновление списка пакетов, это довольно большая нагрузка для raspberry.
2) помехи wifi
3) драйвер wifi глючный, вовремя сканирования сетей подвисает, в таком случае лучше прописать настройки wifi в /etc/network/interfaces и не использовать NetworkManager

citizen

Наконец появилось время заняться дальномером.
Проблема с пингом какая-то плавающая - то есть, то нет. Запускал top (на raspberry) - загрузка не более 20%.
Записал видео работы с amcl:

Видео ускорено в 2 раза. На 28 секунде робот застрял на краю ковра, и локализация сбилась. К 1:00 локализация более-менее восстановилась, но потом опять начала сбиваться, хотя робот все это время ездил по гладкому полу.

simple_move_base продолжает вести себя неадекватно, робот постоянно едет не в ту сторону. При запуске выдает сообщение: "MSG to TF: Quaternion Not Properly Normalized".

Чугунный Дятел

Можно попробовать сменить модель лазера, с likelihood_field на beam (если я не запамятовал)
~laser_model_type (string, default: "likelihood_field")
Which model to use, either beam or likelihood_field.

Так же стоит увеличить значения шума одометрии, особенно связанные с поворотом, раза в 2
~odom_alpha1 (double, default: 0.2)
Specifies the expected noise in odometry's rotation estimate from the rotational component of the robot's motion.
~odom_alpha2 (double, default: 0.2)
Specifies the expected noise in odometry's rotation estimate from translational component of the robot's motion.
~odom_alpha3 (double, default: 0.2)
Specifies the expected noise in odometry's translation estimate from the translational component of the robot's motion.
~odom_alpha4 (double, default: 0.2)
Specifies the expected noise in odometry's translation estimate from the rotational component of the robot's motion.
Можно ещё попробовать поставить режим одометрии odom_model_type=odom_corrected вместо odom (в официальной документации этого нет, но исходники не врут)

MoveBase вообще заумный. У него там куча стратегий типа "ой а я потерялся", и когда картограф работает не очень, вместо движения в точку он начинает постоянно отрабатывать эти стратегии. И к тому же он сука прожорливый. Ему i7 подавай, чтобы было всё круто. Но когда и дальномер хороший, и навигация успевает всё отрабатывать, move_base тоже работает просто на ура.

citizen

За подсказки спасибо, попробую.

Я использовал move_base_simple (http://isr-uc-ros-pkg.googlecode.com/sv ... simple.cpp), там алгоритм простейший - робот должен тупо поворачиваться в нужную сторону, и ехать прямо в указанную точку, препятствия при этом не анализируются и маршрут не строится.

daner

Чугунный Дятел писал(а):

MoveBase вообще заумный. У него там куча стратегий типа "ой а я потерялся", и когда картограф работает не очень, вместо движения в точку он начинает постоянно отрабатывать эти стратегии. И к тому же он сука прожорливый. Ему i7 подавай, чтобы было всё круто. Но когда и дальномер хороший, и навигация успевает всё отрабатывать, move_base тоже работает просто на ура.

не то слово. мы тут на разбери пай его запускали. просто на холостом ходу 40% CPU отжирает. А уж если работать заставить....
пришлось полностью переписывать.

linvinus

Запустил hector slam
датчик lidar но установлен вверх ногами и вращается в противоположную сторону, пришлось xv_11_laser_driver патчить чтобы получить значения

Вложение:

first_map_rqt.png [ 279.25 КиБ | Просмотров: 2989 ]

Спустя час построил нормальную карту

Вложение:

good_map.png [ 187.6 КиБ | Просмотров: 2991 ]

полезные туториалы
http://learn.turtlebot.com/
https://linorobot.org/
тут описано как по быстрому запусти slam http://meetjanez.splet.arnes.si/2015/08 ... -ros-slam/

sned

Дилетантский вопрос:Управление роботом для построения было вручную?что обозначают на карте черные квадраты?если серый цвет это свободная зона.

linvinus

это карта препятствий.
лазерный дальномер измеряет расстояние каждое совпадающее измерение - это скорее всего препятствие, так строится карта
https://en.wikipedia.org/wiki/Occupancy_grid_mapping

вот пример построения карты на базе УЗ дальномеров http://letsmakerobots.com/robot/project ... s-adaptors

основная сложность сопоставить данные после того как робот переместился

в ros есть несколько алгоритмов, я использовал hector slam он вроде как самый проверенный
http://wiki.ros.org/hector_slam
датчик lidar и одометрия, но одометрия у меня очень неточная, несмотря на это hector_slam успешно строит карту если робот двигается не слишком быстро.
далее эту карту можно сохранить и использовать для навигации и локализации
за это отвечает уже другой пакет amcl, ему только один раз при старте нужно указать примерно где робот на карте, далее он сам сопоставляет данные лазерного дальномера с картой, и по ним вычисляет возможное положение на карте

вот тут инструкции как настраивается навигация в ros http://wiki.ros.org/navigation

со всем этим можно играться даже если у вас нет робота.

sned

linvinus писал(а):

http://wiki.ros.org/hector_slam
датчик lidar и одометрия, но одометрия у меня очень неточная, несмотря на это hector_slam успешно строит карту если робот двигается не слишком быстро.

На этом видео карта строится совсем без использования одометрии.Результат идеальный.Поэтому самый важный элемент это все таки лидар.Очень интересно какое максимальное качество построения карты можно достигнуть на неатовском лидаре.Наверное качество в hector_slam зависит от количества и "качества"обходов помещения, и твоя карта ещё не окончательная? По идее hector_slam сам должен отлично локализовать по своей карте,зачем тогда Пакет amcl(или у hector_slam процесс не должен прерываться?)

linvinus

вы путаете процесс создания карты с процессом поиска местоположения в существующей карте.

представьте что вас включили и вам нужно нарисовать карту, что вы будете делать?
будете писать
1) слева от меня стул, справа тумба расстояния 1,2
2) сделал два шага вперёд, слева от меня шкаф справа дверь, расстояние 3,4
всё карта готова

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

задачи две, поэтому и программы две.

что такое "максимальное качество"?

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

lorry

citizen писал(а):

Также заметил, что связка: (дальномер + roomba + raspberry с ros ) + роутер + (ноутбук с ros) работает как-то коряво.
Иногда ping до raspberry c ноутбука начинает достигать 100-2000 мс. Работа ros при этом становится просто ужасной. Причем складывается ощущение, что это связано с самой ros - пинг может резко увеличиваться при ручном указании amcl координат робота на карте.

Мы тоже столкнулись с такой незадачей. Проблема в следующем. При каждом запуске, Raspberry начинает отсчет времени и даты с 01.01.1970. Текущее время и дата как то влияет на работу ROS "крутящегося" на борту Raspberry и вообще на связку ROS+Rasberry+ноут+роутер. Для решения проблемы нужно синхронизировать время и дату на Rasberry с ноутом. Можно написать скрипт который при запуске Raspberry будет запрашивать время с компа, можно синхронизироваться через интернет, а можно просто вручную установить правильное время и дату. Но и не забывайте, что каждый раз при загрузке Raspberry это действие необходимо повторять.

citizen

Ох, давно я в эту тему не заходил.
У меня изначально была синхронизация времени на Raspberry Pi настроена, из-за проблем с ROS пинг не должен был портится.
Позже я купил wifi адаптер на чипсете RTL8191, с внешней антенной, и вроде получше стало.
Недавно открыл для себя в ROS пакет rqt - очень удобно контролировать состояние ROS, воспроизводить rosbag.

linvinus

citizen, очень часто "проблемы" вызваны разнообразными режимами энергосбережения (по умолчанию они включены во всех драйверах).
если проблема присутствует можем попробовать разобраться, какой точно чип? RTL8191 много разных.

roboforum.ru

Самодельный робот на базе ROS - Custom mobile robot with ROS

Кто сейчас на конференции