roboforum.ru

Быть может через месяц получится выложить кое-какое обновление для slam_gmapping, будет немного резвее работать на arm. Он очень чувствителен и требователен к процу. Если не успевает обрабатывать сканы, то качество и устойчивость падают совсем. Это кстати верно почти для всех алгоритмов SLAM, разве что кроме графовых.

Чугунный Дятел писал(а):Быть может через месяц получится выложить кое-какое обновление для slam_gmapping, будет немного резвее работать на arm. Он очень чувствителен и требователен к процу. Если не успевает обрабатывать сканы, то качество и устойчивость падают совсем. Это кстати верно почти для всех алгоритмов SLAM, разве что кроме графовых.

А какие минимальные требования к arm процу, на ваш взгляд?
два ядра Cortex-A7 по 1.3GHz должно хватить?

linvinus писал(а):Предлагаю собирать рецепты как скрестить ROS с самодельным роботом.
Я новичок в этой области, так что буду обобщать по ходу изучения этого вопроса.

Нифига себе новичок! Судя по всем публикациям вы - ГУРУ! Мне бы таким новичком быть!

На 1.6ГГц (odroid-u2/xu) gmapping тратит на обработку скана порядка 500-1000мс, это очень много (на hokuyo 30lx). Можно пропускать сканы, так же поставить пропуск лучей в скане (кажется параметр lskip), заодно ограничивать скорость робота, тогда навигация будет более менее успевать (и отставание не будет накапливаться). Если есть возможность подключить для вычислений нормальный компьютер (intel i7), то лучше это сделать. Или же действительно попробовать hector_slam.

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

Где-то на ros google groups был совет, что стоит сначала аккуратно и медлено построить на gmapping карту, сохранить её, а потом смело катать на amcl. Совет актуален до сих пор.

PS: hector_slam лично не испытывал, и сужу в основном по статьям об его устройстве и результатах испытаний похожих алгоритмов. С интересом поглядел бы на результаты его испытаний на сенсорах подешевле. Желательно в виде построеной карты, или видео, как эта карта строилась. rosbag тоже сойдёт

Вот мои карты (hector_slam + самодельный дальномер):
post281679.html#p281679
post290606.html#p290606

О! Отличная работа! Скорость сканирования хромает, но точность достаточная. Хороший дальномер Вы соорудили. Чувствую себя избалованым робототехником, привыкшим работать с хорошими буржуйскими железками.

Но при этом Вы, как я вижу, так же столкивались с проблемой, что в некоторых случаях карта не очень сходится, сканы идут внахлёст и т.п. Приходится рулить очень аккуратно, осматривать карту в специальной последовательности, вообщем с бубном танцевать. (С Hokuyo URG04 у нас были ровно такие же проблемы, характеристики можно считать сравнимыми). Вот потому я и не сильно торопился испытывать hector_slam: любой SLAM на основе сканматчера или матчинга с картой обречён на такие ошибки. Чем больше размер территории (отношение реальных размеров комнат/коридоров к максимальной дальности сенсора), тем серьёзнее расхождение. Это их фундаментальный недостаток. Классический пример: длинный (длина больше нескольких максимальных дальностей) коридор, ровные стены, вообщем картина "не за что глазу зацепиться", на них рушится любой алгоритм подобного класса.

Как я уже говорил - hector slam - единственный slam, который выдавал у меня более-менее приличную карту.
gmapping работал значительно хуже, amcl на готовой карте довольно быстро сбивался.

AMCL сбился?! Это ж почти челябинский продукт. Он настолько суров, что за последние 10 лет так и не возникло необходимости его как-то дорабатывать. На чём именно запускали? Можете скинуть rosbag вместе с картой, которую построили? Взамен обещаю (попробовать) подобрать настройки
gmapping у меня на urg04lx тоже долго не желал работать, пока я наконец-то не попытался его запустить на нормальном компе.

К сожалению, сейчас не могу, так как сгорел Raspbbery Pi, управляющий роботом.
gmapping запускаю вроде и так не на самом слабом компьютере: Intel Core 2 Duo T5870 2GHz, 2Гб памяти.

Чугунный Дятел писал(а):И ребята с hector немного лукавят про odometry free: они всё равно IMU используют, что впринципе то же самое что и одометрия (интегрирование оценки скорости)

вообще-то не лукавят. Мы гектора изучали и тестировали вдоль и поперек (даже баги в коде исправляли).
простой SLAM у них работает без всяких IMU. IMU они используют только для проблем с 3D. Т.е. что бы оставлять сканы внужой плоскости (отфильтровывают). все хорошо, пока частота сканирования очень высокая, плоскость сканирования параллельна полу (во время движения) и есть за что цепляться на стенах (ну т.е. не просто длинный при длинных коридор).
С кинектом тоже пробовали, но очень не стабильно получается. 90% информации приходится выкидывать, а то что остается имеет слишком маленький обзор и маленькую частоту. При движении вперед еще куда ни шло, а вот на поворотах, разу карту ломает.

Добавлено спустя 31 минуту 35 секунд:

lori писал(а):У меня возникла некоторая мысль (и я ее думаю ) по поводу одометрии.......

Ну все правильно вам ответили, в принципе мышка это тот же принцип.
Но если говорить конкретно о вашей идеи (мы ее просто пробовали где-то год назад)
1. в виллогараже ребята этот вариант использовали. получилась очень маленькая погрешность, но там очень не тривиальная подсветка нужна. плюс у них очень текстурный пол был.
2. у нас получилось на базе OpenCV достаточно точно рассчитать одометрию, но так и не получилось сделать подсветку так, что бы это работало как надо (ну были еще и другие проблемы).
3. на неплоской поверхности все не так уж хорошо получается. Если отслеживать движение камеры по вертикали, то получается полноценный алгоритм визуальной одометрии (со всеми сложностями и нет того эффекта : гениальное - просто).
4. В НАСА применяется подобный алгоритм на марсоходах. Но, они там используют специальную телескопическую (если я правильно название запомнил) линзу. Это такая линза, которая убирает перспективу и не важно на каком расстоянии находится объект, он имеет всегда одни и те же размеры. Таким образом они решили проблему, о которой я говорил в пункте 3.
Интересно, есть ли такие линзы по нормальным ценам.

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

>Т.е. что бы оставлять сканы внужой плоскости
А они так и не перешли в 3д карту? Их алгоритм должен отлично адаптироваться на 3д, хоть и с увеличенным расходом памяти. И, кстати, вы не пробовали серию алгоритмов в ROS на основе NDT карты? (примерно тот же класс алгоритмов что и hector, только представление ячейки карты другое)

Чугунный Дятел писал(а):А они так и не перешли в 3д карту?

нет. не перешли. ну т.е. возможно у них и есть какие-то новые алгоритмы, но это уже другая история

Чугунный Дятел писал(а):Их алгоритм должен отлично адаптироваться на 3д, хоть и с увеличенным расходом памяти.

ну, у них и так памяти не слабо кушается. На счет адаприторования в 3Д... ну на сколько я понимаю, они уже сами по себе адаптировались из PCI (которых в 3Д) для 2Д. Гектор работает очень хорошо только за счет своей скорости.

Чугунный Дятел писал(а):И, кстати, вы не пробовали серию алгоритмов в ROS на основе NDT карты? (примерно тот же класс алгоритмов что и hector, только представление ячейки карты другое)

нет. не пробовали. А вы?
я посмотрел бегло, вы имеете ввиду ndt_registration и ndt_map?
хм... ну интересно будет попробовать, если время позволит. правда это не классический SLAM, а только одометрия и карта....

Попробовал вновь запустить amcl, возникло ощущение, что он не работает - после ручного указания координат робота точки скана совмещаются с картой, но после движения постепенно сбиваются.
При каждом ручном указании положения робота amcl выдает:
[ WARN] [1398627041.662649499]: Failed to transform initial pose in time (Lookup would require extrapolation into the future. Requested time 1398627041.662545784 but the latest data is at time 1398627041.567876755, when looking up transform from frame [/map] to frame [/base_link])

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

amcl одометрию из tf берет сам вроде бы.
Сама по себе одометрия присутствует. Метод проверки одометрии, описанный на второй странице, нормально работает.
Если запустить simple_move_base с использованием только одометрии, то работает нормально - робот приезжает в указанную точку, несколько сбиваясь из-за ошибок одометрии.

С amcl все намного хуже. Если указать начальные координаты (при этом лазерный скан совмещается с картой), то при движении по прямой скан удерживается на карте. Если робот сталкивается с препятствием (колеса при этом продолжают вращаться), то скан тоже удерживается.
Однако если под колеса попадает край ковра (на нем робот обычно поворачивается на небольшой угол) - то скан сразу слетает с карты. После этого, если робот столкнется с препятствием и начнет буксовать, скан начинает все дальше уходить от карты.

При использовании simple_move_base вместе с amcl навигация работает неверно - робот всегда едет в непонятно какое место. С hector_slam, правда, тоже самое.

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