boez писал(а):=DeaD= писал(а): Даже передавать "куда поехал робот сейчас" в алгоритм локализации - и то плохо.
А вот это не всегда верно. Если у нас не очень плохая ходовая (в большинстве ситуаций отрабатывает команды без сильных проскальзываний), то знание будущей позиции может помочь.
Скажем так - в алгоритм локализации который внешний и изолированный, хотя явно тут в теме это не было обозначено, чего внутри у робота можно нагородить - это отдельный разговор, оно может хоть по распознаваемым образам из карты расстояний до ближайших препятствий определять своё положение через нейросеть.
boez писал(а):Между прочим, мы в теме про LPS усиленно решаем задачу при неизвестном времени старта посылок, а ведь оно у нас уже начиная со второго раза известно, кварцы то есть у всех. Так что стоит наверное рассмотреть задачу с избыточной информацией (маяков штук 5-6) и чем-то типа метода наименьших квадратов для ее решения (хотя подозреваю, МНК как раз не годится, нужны так называемые робастные методы, когда "очевидно плохие" и сильно отличающиеся от ожидаемых входные данные мы просто не используем, или берем с неким уменьшительным коэффициентом).
Проблема в том, что при увеличении количества маяков в 2 раза растёт время на их опрос. Вот если наоборот делать (излучатель на роботе, а на маяках приёмники, тогда это не проблема будет, и вообще можно будет частоту до 20Гц поднять).
boez писал(а):А еще - не обязательно это все делать центральному процессору. Это вполне может быть такая "навигационная платка" с УЗ приемником (или двумя приемниками в разные стороны - для ориентации) и своим процом. Может AVR, а может и ARM мелкий и дешевый типа LPC2101 - 2103 - тут памяти много не надо, тут может считать много понадобится.
То что навигационная платка должна быть - это 100%, вроде никто и не предлагал на центральном МК это считать.
Добавлено спустя 3 минуты 12 секунд:
bolt писал(а):Я предложил способ, который позволяет точно узнать позицию бота и еще много чего делать. Большая часть компового ПО для такой видеосистемы у Dead, как выяснилось, уже есть.
Кол-во, цвет, угол обзора, скорости и пр. мелочи принципиального значения не имеют.
Давайте с этим ПО ознакомимся. Узнаем: какой Dead камерой в своей игре пользовался? Кто и как ботом управлял? Как сигнал с камеры вообще в комп попал?
У меня была беспроводная камера вот такая (заводил в комп через ресивер, который к ней в комплекте шел и ТВ-тюнер):
.Ботом управляла программка на С++ Билдере, но к теме это отношения не имеет. Я уже говорил, что такое решение не даёт информации о направлении робота, что существенно проигрывает визуальному маяку из цветных квадратов, сколько можно настаивать на заведомо ущербном решении?
bolt писал(а):ок,мы в теме про LPS усиленно решаем задачу при неизвестном времени старта посыл
Ваша задача решается ИК стробированием, что повышает точность в несколько раз. Вот ссылка на оригинал
Не думаю что тут точность в разы поднимается именно из-за стробирования.
и теперь усиленно решаете проблему, которую сами и создали.