ailev.ru

4 октября 2016 · Комментарий

Без заголовка

Важна компонуемость не только логического типа, но и математического, для алгоритмов, которые крутятся вокруг этих блоков. Возьмём пример в моей сфере (indoor navigation) и распилим условного робота на части: - ходовая часть (колёсный узел с мотором, их драйвер) - несколько сенсоров геометрии (лидар) - инерциальный датчик - детектор внешних маркеров - навигационный модуль и сосредоточимся на паре задач: картография+локализация и автоматическое движение по этой карте в указаное место. Алгоритм локализации должен кое-как понимать точность текущих показаний от лидара, или RGBD камеры. Так же неплохо знать и оценку точности с ходовой части. Алгоритм так же с радостью примет оценку положения каких-то landmarks в кадре (Ленин на площади). Алгоритм локализации собирает все эти данные и расчитывает наиболее вероятное положение робота (состояние системы). Результаты данного расчёта вполне можно провертуть обратно всем модулям, которые поставляли информацию на вход. Например: - выдать поправку шасси "соврали на 3 метра", значитъ колёса проскальзывают или неисправность в колёсном узле. Иногда (да постоянно!) разработчики шасси неправильно указали радиус колёс и передаточное число в мотор-редукторе. Вот и повод внести коррекцию. - поправка в landmark detector/tracking. misalighment мы победим - автоматическое исправление искажений от сенсора (для всяких xtion/kinect ой как актуально) Вообщем прогресс по точности работы мобильных роботов (локализация, прибытие в точку, object handling) часто достигается глубиной подобных обратных связей. Но я пока не встречал случаев разработки, когда собраные в совершенно разных местах модули (алгоритмические) могли так сращиваться.

К записи · К обсуждению