Как проектируется робототехническая система?

Updated: Sep 12, 2018


Давайте рассмотрим общие принципы, взяв условный пример задачи создания робота для сборки урожая помидоров.


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


Сформулировав ее предварительно, надо 2) собирать требования (скажем, брать зрелые (что значит...), в такой-то зоне, при таких-то условиях и т.п. Отдельно (но параллельно) 3) собираются ограничения (куда-то не провалиться, уместится в проходе, вес не более и т.п.)


Исходя из этого, вы 4) понимаете, что должна делать система, чтобы задача была решена - причем не на уровне системы («взять то-то, переместить туда-то»), а на уровне ожидаемого результата («вот этот помидор с этой ветки должен переместиться вот в этот контейнер»).


Другими словами, расписывается деятельность, которую должна осуществить система, чтобы выполнить задачу для которой она создается.


Если понятно, что должна делать система, то определяете 5) какими "компетенциями" должна обладать система, чтобы выполнить эту деятельность. То есть, если деятельность системы заключается в том, чтобы «вот этот помидор с этой ветки переместился вот в этот контейнер», значит система должна уметь «опознать такой-то помидор, захватить его, переместить его в такую-то зону, уложить вот сюда-то».


Если мы можем представить себе, как добра выглядеть система, решающая данную задачу, мы, фактически, уже начинаем представлять ее концепцию ее «образа» (vision).


Но что значит «должна уметь»? Это значит обладать необходимыми средствами и быть способной их использовать.


Поэтому когда компетенции расписали - надо их разложить на то, 6) как это должно быть сделано и 7) какими средствами: скажем, если написали, что система «должна уметь сорвать помидор», то значит она должна иметь такой-то захват, который она будет действовать так-то.


В результате получается 8) список подсистем, обладающих каждая своей компетенцией или набором компетенций - одна отвечает за распознавание, другая за перемещение, третья, за распознавание, четвертая - за передвижение вдоль грядки и т.п. И мы примерно понимаем, как они между собой должны взаимодействовать. Таким орбразом, у нас появляется представление об 9) архитектуре системы.


Имея концепцию и архитектуру системы, уже можно начинаете смотреть 10) способ реализации по каждому пункту - скажем, передвижение вдоль грядки можно сделать по направляющим, а можно подвижную платформу, платформу можно «свободную», а можно так же по направляющим и т.п. Если «свободную», то колесную, гусеничную или еще какую-то, и так далее.


Тут важно, что любое конструктивное решение исходит из требуемой «компетенции» системы, и, соответственно, обязательно «завязано» на его поведение: так, захват, чтобы «трясти дерево» будет устроен совсем не так, как тот, что должен «срывать плод».


Когда это все это для себя поняли - получили 11) концепцию, и уже можно переходить к 12) проектированию - определять, как технически реализовать эти выбранные «средства» и их «поведение», тут начинается конструкторская работа и, условно, «программирование», а на самом деле - проектирование поведения системы.


Тут логично, что каждая из подсистем действует самостоятельно, на основани приходящих вне ее (в том числе в других подсистах) событий. К примеру, система распознавания сообщает «вижу помидор в таки-то координатах», запускается манипулятор: «раз есть координаты - хватаю!» и т.п.


Соответственно, в у каждой подсистемы свое управление либо на уровне физически отдельного контроллера, либо отдельного программного модуля, если контроллер на все управление один.


А дальше расписывается логика управления всем этим, причем она может быть даже не на самом роботе, а вынесена,


Для моделирования поведения систему удобно использовать подходящую платформу. А дальше либо перенести готовое решение «на борт», либо оставить внешним, что сильно проще для отладки и развития системы: видно, что она делает, а при внесении изменений в логику поведения, сразу в реальном времени можно наблюдать, что получается, и нет необходимости каждый раз что-то перепрограммировать на роботе, тем более, если контроллеров на роботе несколько, а потом и роботов


Более подробное обсуждение данного подхода можно найти конспекте лекций Основы проектирования приложений интернета вещей