Комментарии 14
Ну как самое простое решение можно увеличить количество замеров. При построении построении геоподосновы обычно используют три группы по три замера. Считаем центры каждой группы и из этих центров считаем еще раз центр. Чтобы не увеличивать количество приемников можно покрутить передаичиками (в какой плоскости это отдельный вопрос)
Автор, а вы про сонары слышали? Зачем пиарить ЭТО? Ну возьмите сделайте нормальное расположение излучателей/приемников, напишите алгоритмы не только определения дальности, но и азимута, и Допплера. Этих статей миллион найдете не только в области сонаров, но и радаров. Причем по стоимости изделие окажется примерно таким же, как ваше. Что касается позиционирования, то ищите статьи по radar SLAM. И будет у вас архитектурно выверенное решение, которое можно людям показать.
Здравствуйте, насколько я знаю SLAM не способен определять координаты, как и сонары как и радары, к тому же ориентация по SLAM очень быстро портит карту до такой степени что определять позицию по ней даже примерно уже не возможно, радары и сонары больше для обнаружения препятствий. Я сейчас конечно же погуглил по этой теме, и ничего не нашел пригодного для определения положения мобильной платформы в помещении, если вам не трудно скиньте пожалуйста хоть одну ссылку.
Вы наверно это семейство алгоритмов с чем-то путаете. SLAM — Simultaneous Localization and Mapping. Вы строите карту и рассчитываете свои координаты по определению этого алгоритма. Мне вот эта статья нравится www.uni-das.de/images/pdf/veroeffentlichungen/2017/01.pdf
SLAM будет портить карту при неправильной калибровке сенсора. Если все более-менее нормально работает, углы/дальности разрешаются, то получите и карту, и навигацию.
По поводу вашего метода триангуляции, если не хотите лезть во все эти дебри, попробуйте для начала простой фильтр Калмана к вашим измерениям прикрутить. С ним, скорей всего, будет лучше, чем с просто усреднением.
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
Вот тут как раз энкодеры + лидар… Уже что-то можно сделать… Мда, наверно я погорячился с ультра-звуковыми :-))
Но, команды, поданные на шаговый двигатель — уже что то.
Короче, как я понимаю у вас есть: (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 датчики для построения карты проходимости, но в любом случае карта проходимости это уже следующий уровень для этой системы.
Можно использовать ToF датчики для построения карты проходимости, но в любом случае карта проходимости это уже следующий уровень для этой системы.
Спасибо, за комментарий, я в ближайшее время попробую IMU сенсор, оценю его реальную полезность в данном случае.
Скажите а как правильно это все подключать к Raspberry? датчик — STM32 — Raspberry, или напрямую? на каком языке логичнее писать? у меня больше опыта по МК и мало по ПК так что на каком языке лучше писать не особо понимаю, чтобы было легко и быстро
Скажите а как правильно это все подключать к 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, чтобы он локализацию считал, Калманы, одометрию и тому подобное.
Если вы просто хотите изучать робототехнику, то все можно делать в 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, чтобы он локализацию считал, Калманы, одометрию и тому подобное.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ультразвуковая система определения координат 2.0