Как стать автором
Обновить

Комментарии 16

Может быть, эта тема кому-нибудь будет интересна, поэтому добавлю немного от себя. Алгоритм RRT не является оптимальным. Существует его оптимальная (в пределе) версия RRT*.

Помимо поиска в конфигурационном пространстве, где мы учитываем только кинематику нашего робота и принимаем, что полученный путь может быть в дальнейшем исполнен нашим контроллером, можно искать путь сразу в пространстве управления. В этом случае мы можем определить динамическую модель робота (от ручных дифференциальных уравнений до какого-то физического движка) и использовать ее. Это называется в kinodynamic planning и дает преимущество для управления роботами с какой-то сложной динамикой. Сложность заключается в переходе к случайно сгенерированному узлу. Здесь надо определить функцию steer, позволяющую определить необходимое управление для перехода из одного состояния в другое (т.е. решить обратную задачу). В общем случае, это весьма нетривиально нереально. В простейшем — рандомный выбор. Думаю, понятно, сколько шагов потребуется солверу.

Поиграться с разными sample-based солверами можно в библиотеке Open Motion Planning Library, в которой реализованы RRT, RRT* и ряд других.

И встречал весьма оригинальный метод, как сделать это несколько проще, моделируя систему робот+контроллер:
  • Motion Planning for Urban Driving using RRT
  • Motion Planning in Complex Environments using Closed-loop Prediction
Огромное спасибо! Просьба всем: Если Вы знаете об алгоритме — напишите в комментариях его название и краткое описание.

А вот у меня в процессе чтения возник вопрос.


Ровер при обнаружении ультразвуком препятствия поворачивает по часовой стрелке на 90 градусов, проезжает 1м, поворачивает на 90 против часовой стрелке. При обнаружения препятствия бампером перед поворотом робот на 0.5 метра возвращается назад.

У вас робот оснащен компасом/одометрией, чтобы точно поворачивать и ездить?

У нас GPS, но сейчас переходим на GPS RTK.
Есть магнетометр, акселерометр, гироскоп, бампреы, ультразвуковые датчики.
Добавляем одометры.
Для оптимальным является разделение вопроса построения маршрута на глобальный и локальный.
Автор подустал под конец :)
Спасибо. Исправил. Такое лучше в ЛС.
Да, действительно. Это я зря
Отличный подбор алгоритмов. Спасибо автору! Вспомнилось, как писали алгоритм построения маршрута уборки для промышленной поломоечной машины внутри рандомного прямоугольника многократно превышающего размеры робота с рандомным набором препятсвий внутри. И вычисление этого маршрута за адекватное количество переборов и оптимизаций. Для нас решением стало применение огромного ряда эвристик, какой бы базовый метод мы не выбирали.
Спасибо! Если у Вас есть еще варианты — добавляйте.
Вопрос. Робот предназначен для сбора мячей. Каким образом вы задаете целевую точку движения для робота? Т.е. как он понимает куда ему ехать(где сейчас находится мячик)? Или в итоге он все равно проезжает все поле?
Он проезжает все поле.
Благодарю за ответ. Т.е. весь алгоритм суммарно навигации робота сводится только к объезду препятствий и все?
Ровер при обнаружении ультразвуком препятствия поворачивает по часовой стрелке на 90 градусов, проезжает 1м, поворачивает на 90 против часовой стрелке.

Т.е. если возникло препятствие, которое в одну сторону(влево) 20 метров, а в другую 2 метра, то он объедет все равно слева — по более длинному пути в любом случае?
Сервисный робот должен быть максимально простым. Когда он натыкается на препятствие, то не знает о его размере.

В алгоритме есть еще array с целями.
можно несколько более сложно решать задачу объезда препятствий youtu.be/GribbOH1vAg с помощью компьютерного зрения
А чем это сложнее алгоритма жука? Он же просто поворачивает пока не найдет в локальной карте проходимости возможность ехать вперед.
тем что он видит размеры препятствия и выбирает более короткий путь, если там геометрически сможет проехать (из датчиков только web-camera)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории