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