=DeaD= писал(а): Даже передавать "куда поехал робот сейчас" в алгоритм локализации - и то плохо.
А вот это не всегда верно. Если у нас не очень плохая ходовая (в большинстве ситуаций отрабатывает команды без сильных проскальзываний), то знание будущей позиции может помочь.
А еще, полагаю, можно было бы рассмотреть систему с более чем 3 маяками, тоже с предсказанием будущей позиции. С таким примерно алгоритмом: предсказали новую позицию (пусть ориентацию и скорость мы знаем), приняли сигналы от маяков и смотрим - какие из маяков больше всего подходят под новую позицию, те и используем для нового расчета уточненной позиции. Если один маяк "врет" - его не используем. Если вышло, что все "врут" - возможно, имеем проскальзывание. А "врать" маяк может например при такой ситуации - мы проехали и некий предмет перекрыл прямой путь звука от маяка. А отраженный от стенки - мы продолжаем ловить. Но он приходит позже!
Между прочим, мы в теме про LPS усиленно решаем задачу при неизвестном времени старта посылок, а ведь оно у нас уже начиная со второго раза известно, кварцы то есть у всех. Так что стоит наверное рассмотреть задачу с избыточной информацией (маяков штук 5-6) и чем-то типа метода наименьших квадратов для ее решения (хотя подозреваю, МНК как раз не годится, нужны так называемые робастные методы, когда "очевидно плохие" и сильно отличающиеся от ожидаемых входные данные мы просто не используем, или берем с неким уменьшительным коэффициентом).
А еще - не обязательно это все делать центральному процессору. Это вполне может быть такая "навигационная платка" с УЗ приемником (или двумя приемниками в разные стороны - для ориентации) и своим процом. Может AVR, а может и ARM мелкий и дешевый типа LPC2101 - 2103 - тут памяти много не надо, тут может считать много понадобится.