Как стать автором
Поиск
Написать публикацию
Обновить

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

Ну как самое простое решение можно увеличить количество замеров. При построении построении геоподосновы обычно используют три группы по три замера. Считаем центры каждой группы и из этих центров считаем еще раз центр. Чтобы не увеличивать количество приемников можно покрутить передаичиками (в какой плоскости это отдельный вопрос)
да не факт что поможет, тут есть принципиальная проблема в том что всегда найдутся места где звук будет переотражаться и в итоге собрав переотражение 3 раза будем получать такую же кривую координату.
Автор, а вы про сонары слышали? Зачем пиарить ЭТО? Ну возьмите сделайте нормальное расположение излучателей/приемников, напишите алгоритмы не только определения дальности, но и азимута, и Допплера. Этих статей миллион найдете не только в области сонаров, но и радаров. Причем по стоимости изделие окажется примерно таким же, как ваше. Что касается позиционирования, то ищите статьи по radar SLAM. И будет у вас архитектурно выверенное решение, которое можно людям показать.
Здравствуйте, насколько я знаю SLAM не способен определять координаты, как и сонары как и радары, к тому же ориентация по SLAM очень быстро портит карту до такой степени что определять позицию по ней даже примерно уже не возможно, радары и сонары больше для обнаружения препятствий. Я сейчас конечно же погуглил по этой теме, и ничего не нашел пригодного для определения положения мобильной платформы в помещении, если вам не трудно скиньте пожалуйста хоть одну ссылку.
Вы наверно это семейство алгоритмов с чем-то путаете. SLAM — Simultaneous Localization and Mapping. Вы строите карту и рассчитываете свои координаты по определению этого алгоритма. Мне вот эта статья нравится www.uni-das.de/images/pdf/veroeffentlichungen/2017/01.pdf
SLAM будет портить карту при неправильной калибровке сенсора. Если все более-менее нормально работает, углы/дальности разрешаются, то получите и карту, и навигацию.

По поводу вашего метода триангуляции, если не хотите лезть во все эти дебри, попробуйте для начала простой фильтр Калмана к вашим измерениям прикрутить. С ним, скорей всего, будет лучше, чем с просто усреднением.
Калманом кстати и состояние вашего робота можно будет определить, включая координаты и скорость.

(А называться это будет Kalman-based SLAM)
Спасибо, почитаю.
если скорость передачи несильно важна, можно использовать LoRa/LoRaWAN.

SLAM вам правильно подсказали. И Kalman filter может подойти. Особенно, если у вас есть odometry хоть какая. Пусть даже команды поданные роботу — уже odometry. Wheel encoder конечно лучше будет, ну или хотя бы imu sensor. Короче читайте, изучайте, тут много математики, но все решается.

Одометрия есть, но там тоже все не идеально, у меня шаговые двигатели, это как энкодеры но лучше, так же есть BNO080 это насколько я знаю очень современный и хороший инерционный модуль, но я его пока использую только для определения угла поворота относительно вертикальной оси, я раньше использовал MPU6050, пытался с его помощью определить линейное перемещение, но у меня почему то очень быстро накапливались ошибки, и он был почти бесполезен, может у вас есть какой то опыт в этом, или ссылки на хорошие видео или примеры того как это сделать правильно? а то все при помощи таких модулей только кубиком крутят, а перемещение никто не пытается определять по нормальному
В том то и дело что только одним IMU не получится восстановить траекторию. Это как раз из-за постоянного дрифта у IMU сенсора. Гуглите IMU Dead Reconing. Шаговый двигатель это не тоже что я имею ввиду. Для одометрии энкодер нужен на пассивном колесе (или лучше двух), а не на моторе.
Но, команды, поданные на шаговый двигатель — уже что то.

Короче, как я понимаю у вас есть: (1) самодельный сенсор на ультразвуке, (2) не очень хорошая odometry из комманд к устройству/роботу, (3) 6-DoF IMU сенсор (теоретически).
Этого уже вполне достаточно чтобы сделать fusion с помощью Kalman Filter, и уже тогда получить хорошую траекторию движения.
Дрифт все-равно останется, но будет гораздо меньше.

1-я проблема — Arduino это ни о чем. Нужен хотя бы Raspberry Pi, или что то подобное.
2: Используйте ROS, там эти проблемы уже решены. Статьи по ROS есть даже на хабре, но лучше конечно читать в оригинале.
3. Если у вас будут Raspberry Pi + ROS, то ультра-звуковые сенсоры уже можно использовать для построения карты проходимости вокруг робота.
https://www.youtube.com/watch?v=eSeLW9Hkjhc
Вот тут как раз энкодеры + лидар… Уже что-то можно сделать… Мда, наверно я погорячился с ультра-звуковыми :-))

Ультразвук здесь использован как маяки, а не как радар.
Можно использовать ToF датчики для построения карты проходимости, но в любом случае карта проходимости это уже следующий уровень для этой системы.
Спасибо, за комментарий, я в ближайшее время попробую IMU сенсор, оценю его реальную полезность в данном случае.
Скажите а как правильно это все подключать к Raspberry? датчик — STM32 — Raspberry, или напрямую? на каком языке логичнее писать? у меня больше опыта по МК и мало по ПК так что на каком языке лучше писать не особо понимаю, чтобы было легко и быстро
Вам нужно определиться какая конечная (или промежуточная) цель вашего проекта.
Если вы просто хотите изучать робототехнику, то все можно делать в ROS и в симуляторах — там можно достигнуть результатов гораздо быстрее.
В ROS вообще зачастую писать ничего не надо — просто конфигурировать существующие модули. Launch файлы и urdf (кинематика робота) написаны в XML.
Но при этом надо понимать что и как вы используете — т.е. нужны знания, и, соответственно, будете обучаться.
Код можно писать в Python, что особенно хорошо для новичков. Если не хватает производительности, можно всегда перейти на C/C++.

Теперь о вашем проекте. Если предположить, что у вас уже есть карта пространства (2D) то SLAM (Localiztion & Mapping) вам не нужен, а нужен только Localization.
В таком случае, можно использовать обычный Monte Carlo Localization / Particle Filter. И обычные ультра-звуковые сенсоры, смонтированные на роботе, (а не ваша супер-система) могут вам помочь гораздо больше.

Идея MCL в том, что если у вас 4 сенсора со всех сторон и они показывают какие-то значения, то на карте всего-лишь одна или несколько областей соответствует таким измерениям. (предпологается что на карте есть множественные стены/коридоры). MCL кидает множество рандомных точек с произвольной ориентацией (всевозможные позы робота) на карту и сверяет предсказанные измерения датчиков с существующими. Те позы, что дают минимальные ошибки запоминаются и используются на следующей итерации. Если робот двигается, и вы с помощью одометрии знаете как именно, то это значит что изменения в измерениях тоже можно предугадать. И если все правильно, то MCL сходтится к верному решению в течении нескольких фреймов/итераций.

По поводу вопроса о Raspberry: наверное стоит оставить Arduino как real-time контроллер, а на Raspberry крутить ROS, чтобы он локализацию считал, Калманы, одометрию и тому подобное.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации