Обсуждение идей позиционирования роботов

=DeaD=

boez писал(а):

=DeaD= писал(а):

Даже передавать "куда поехал робот сейчас" в алгоритм локализации - и то плохо.

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

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

boez писал(а):

Между прочим, мы в теме про LPS усиленно решаем задачу при неизвестном времени старта посылок, а ведь оно у нас уже начиная со второго раза известно, кварцы то есть у всех. Так что стоит наверное рассмотреть задачу с избыточной информацией (маяков штук 5-6) и чем-то типа метода наименьших квадратов для ее решения (хотя подозреваю, МНК как раз не годится, нужны так называемые робастные методы, когда "очевидно плохие" и сильно отличающиеся от ожидаемых входные данные мы просто не используем, или берем с неким уменьшительным коэффициентом).

Проблема в том, что при увеличении количества маяков в 2 раза растёт время на их опрос. Вот если наоборот делать (излучатель на роботе, а на маяках приёмники, тогда это не проблема будет, и вообще можно будет частоту до 20Гц поднять).

boez писал(а):

А еще - не обязательно это все делать центральному процессору. Это вполне может быть такая "навигационная платка" с УЗ приемником (или двумя приемниками в разные стороны - для ориентации) и своим процом. Может AVR, а может и ARM мелкий и дешевый типа LPC2101 - 2103 - тут памяти много не надо, тут может считать много понадобится.

То что навигационная платка должна быть - это 100%, вроде никто и не предлагал на центральном МК это считать.

Добавлено спустя 3 минуты 12 секунд:

bolt писал(а):

Я предложил способ, который позволяет точно узнать позицию бота и еще много чего делать. Большая часть компового ПО для такой видеосистемы у Dead, как выяснилось, уже есть.
Кол-во, цвет, угол обзора, скорости и пр. мелочи принципиального значения не имеют.
Давайте с этим ПО ознакомимся. Узнаем: какой Dead камерой в своей игре пользовался? Кто и как ботом управлял? Как сигнал с камеры вообще в комп попал?

У меня была беспроводная камера вот такая (заводил в комп через ресивер, который к ней в комплекте шел и ТВ-тюнер):

.
Ботом управляла программка на С++ Билдере, но к теме это отношения не имеет. Я уже говорил, что такое решение не даёт информации о направлении робота, что существенно проигрывает визуальному маяку из цветных квадратов, сколько можно настаивать на заведомо ущербном решении?

bolt писал(а):

Цитата:

мы в теме про LPS усиленно решаем задачу при неизвестном времени старта посыл

ок,
Ваша задача решается ИК стробированием, что повышает точность в несколько раз. Вот ссылка на оригинал

Не думаю что тут точность в разы поднимается именно из-за стробирования.

Виталий

Из-за стробирования точность не поднимется вообще.

bolt

Цитата:

Ботом управляла программка на С++ Билдере, но к теме это отношения не имеет. Я уже говорил, что такое решение не даёт информации о направлении робота,

Т.е. ботом управлял РС, анализируя изображение. Именно это нам и нужно. Определяем позицию, а уж с направлением проблем не будет. Выкладывайте исходники ПО и схему управления ботом, не стесняйтесь.

Цитата:

мы в теме про LPS усиленно решаем задачу при неизвестном времени старта посыл

При ИК стробировании (см. оригинал системы) УЗ посыл привязан к окончанию строба, т.е. время старта известно. От помех это не избавляет, но точность, как пишет автор, повышает в 5 раз. Даже странно, что вы этого не заметили

и теперь усиленно решаете проблему, которую сами и создали.
Стоит отметить, что схему можно значительно упростить, если соединить маяки.

=DeaD=

Виталий писал(а):

Из-за стробирования точность не поднимется вообще.

ИМХО поднимется, но не в разы, а просто настолько же, насколько от лишней итерации измерения и усреднения результатов.

hudbrog

Лень так много страниц текста читать... так что не знаю, упоминали или нет.
Американцы давно и активно в любительском робостроении используют алгоритмы SLAM, в частности fastSLAM2. Почитайте, правильная штука.

=DeaD=

Вроде SLAM и иже с ним fastSLAM это для полной автономки - под это надо отдельную темку наверное открывать... или ошибаюсь?

Digit

Да, SLAM - это автономка.
Есть книжка на буржуйском "SLAM for Dummies" - могу выложить. Сам пока не вникал, но тема понравилась. Можем в отдельной теме пообсуждать книжку и другие материалы.

EdGull

давай заводи

=DeaD=

Завёл - viewtopic.php?f=35&t=5279

roboforum.ru

Обсуждение идей позиционирования роботов

Кто сейчас на конференции