roboforum.ru

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

Между тем, я все-таки смог запустить автономную навигацию робота со своими дальномерами.
Родной навигационный стек из ROS показался мне очень навороченным, раньше я пробовал его запускать на ПК, и он плохо работал, при этом сильно загружал процессор.
Поэтому я написал свой простенький узел навигации "simple_nav", который можно запускать прямо на одноплатнике (я использую Orange Pi PC).
Мой узел simple_nav работает на нем вместе с hector_slam, на ПК запускается только rviz.
Примеры работы с OpenLidar:



Так же проверял работу навигации с OpenSimpleLidar - работает (потом постараюсь видео записать).
Код узла пока что не оптимальный, можно еще много что дорабатывать.
Исходный код: https://github.com/iliasam/ROS_simple_nav

круто, но видно как картинка пляшет когда робот стоит, погрешность измерений велика, в самодельном лидаре так же псевдо синхронизация по углу?

Не очень понял, что вы называете псевдо синхронизацией".
Энкодер там действительно очень простой - с 16 секторами, так что из-за нестабильности вращения (паршивый подшипник) картинка действительно иногда вращается.

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

Очень интересно но понимания не хватает.
Чем конкретно занимается узел навигации "simple_nav"?Только прокладкой траектории?
Что за треугольник от старта до робота и с одной из вершин вне карты?
Есть статья на эту тему:https://itnan.ru/post.php?c=2&p=281760 но там алгоритмы slam не трогаются а применяется всё готовое из ROS. "simple_nav" разработан на уровне алгоритмов?
Извиняюсь за "примитивные" вопросы.

Локализация осуществляется при помощи "hector_slam".
Про то как работает "simple_nav", я немного написал на github:

Этот узел периодически прокладывает глобальный путь от робота до целевой точки и производит его фильтрацию, так что число точек в пути значительно сокращается.
Затем робот просто следует ко второй точке в этом пути (первой точкой являются стартовые координаты робота).

"Просто следует" - это значит, что робот просто поворачивается в нужном направлении, и начинает двигаться по прямой к нужной точке в построенном пути. Так как путь постоянно обновляется, то через некоторое время эта точка "убегает" от робота.
Красная стрелка указывает на ту точку глобального пути, в которую движется робот в данный момент.

Что за треугольник от старта до робота и с одной из вершин вне карты?

Это в rviz включено отображение всех фреймов TF. Один из них соответствует текущему положению робота, один - начало отсчета карты, один (за пределами границ комнаты) - фрейм /odom - начало отсчета одометрии, его положение корректируется hector_slam, на него можно не обращать внимания.

Весь "simple_nav" я написал с нуля, но в то же время, функции поиска глобального пути, работа с costmap - взяты из самого ROS.

Очень интересный проект. Хочется воспроизвести. Не понял зачем разъем под 3,5 джек. Вчера почти все компоненты на али нашел кроме фильтра

Т.е. построение карты и определение координат вычисляется на ПК?
Во многих проектах пишут о полезности применения IMU.На сколько это актуально?

Не понял зачем разъем под 3,5 джек.

Это разъем для программирования, я использую их во многих своих проектах.
Я собираюсь в ближайшее время немного поменять печатную плату OpenSimpleLidar.
Если не предполагается использовать лидар при ярком солнечном освещении комнаты, или если на полу нет ламп освещения, то светофильтр использовать не обязательно.
Вот пример продаваемого фильтра: https://www.ebay.com/itm/2pcs-Optical-I ... 3274417339

По simple_nav:
Построение карты и определение координат производится при помощи hector_slam, он тоже работает на Orange Pi PC.
На ПК - только визуализация данных.
Если нужно, могу нарисовать картинку, но это потребует времени.

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

"производит его фильтрацию"-правильнее наверное написать: каждый раз снова перепрокладывает путь с текущего положения робота используя глобальную карту не учитывая новые возможные препятствия.
Я понимаю,что изначально карта строится а уже потом по ней ездим.А одновременно не хватает мощности Orange Pi или
пока это упрощение?

За обновление карты и локализацию робота на ней отвечает hector_slam. Советую поискать в интернете видео с примерами его работы.
hector_slam обновляет карту по мере появления новых данных о карте, в первую очередь - для неисследованных участков пространства. Если slam признал некоторый участок карты свободным, то даже если позднее лидар обнаруживает на нем препятствие, то информация о нем может не добавится на карту.

Это понятно.Просто сбило с мысли определение- локальный планировщик пути,он ещё просто не прикручен? И постоянный пересчёт одной и той же траектории пути занимает ресурсы можно наверное было запомнить траекторию(координаты поворотов) и просто их последовательно загружать в команды на движение.

Глобальный/локальный планировщик пути - терминология из навигационного стека ROS: http://wiki.ros.org/navigation/Tutorials/RobotSetup
Полноценный локальный планировщик я не планирую делать, от достаточно сложен и потребляет ресурсы процессора.
Можно сделать просто механизм анализа наличия препятствий на пути робота, и аварийную остановку при наличии препятствий. Тут есть определенная проблема, заключающаяся в том, что мои самодельные дальномеры в некоторых случаях (из-за сильной засветки, всяких отражений от блестящих поверхносней) могут показывать несуществующие препятствия рядом с роботом.

Обновил файлы на github - немного подправил существующую разводку платы, добавил описание платы.
Также развел новую версию платы - теперь на одной плате сразу располагаются основная плата и плата мотора.
Таким образом, достаточно заказать только одну плату в Китае, а потом аккуратно отрезать от нее маленькую плату мотора:

День добрый, пытаюсь использовать лидар от пылесоса xiaomi. Пакет http://wiki.ros.org/xv_11_laser_driver
Работает, но проблема, по моему лидар не понимает в какую сторону он повернут. Вероятно та сторона в которую он смотрит при запуске принимается как 0 градусов, при рестарте пакета, головка лидара может быть повернута в любую сторону. получается что на каждый запуск "картинка" поворачивается.
вот и проблема, как определить направление лидара?