Хорошо размышлять о роботах и искусственном интеллекте в нерабочее время перед домашним компьютером и за чашечкой кофе. И совсем другое дело, когда оказываешься перед необходимостью в сжатые сроки разработать высокоуровневое ПО для роботизированного склада. И при этом практический опыт в данной предметной области напрочь отсутствует, но есть богатый теоретический. Вы скажите, что умному человеку не стоит оказываться в подобной ситуации. Ну что ж, возможно Вы правы, однако жизнь весьма сложная и нелинейная штука. Поэтому когда ко мне обратился мой приятель-директор фирмы, производящий железо для роботизированных складов с жалобой на то, что предыдущий разработчик высокоуровневого ПО их кинул (взял предоплату, долго кормил завтраками, а затем и вовсе скрылся в неизвестном направлении) — я обещался подумать что тут можно сделать.
Роботизированный склад-автомат
Пару слов о железе (АСК — автоматизированный складской комплекс), для которого нужно было разработать высокоуровневое ПО. Возможно, некоторые из читателей не согласятся с утверждением, что устройство на фото выше есть робот. Оно больше похоже на некий автомат: снизу и сверху установлены две рельсы, по которым перемещается робот с выдвижной платформой. Слева и справа расположены стеллажи с ячейками в несколько уровней (высотой до 12 метров). Товар хранится в стандартных недорогих контейнерах различных размеров. Робот-штабелер может ездить по рельсам, загружать контейнер из определенной ячейки, и выгружать контейнер в определенную ячейку. Подробней можно посмотреть на сайте производителя www.vind.ru.
Раздумья
Как я уже говорил, у меня не было практического опыта ни в искусственном интеллекте, ни в управлении роботами. Однако был большой опыт в СУБД и в различных системах визуализации. Низкоуровневое ПО для самих роботов было написано на C#. У меня в команде были люди с большим опытом в C#. Поэтому было логично использовать C# для разработки модуля, который будет общаться с роботами.
Предыдущий горе-разработчик в качестве СУБД использовал Oracle SQL сервер. У нас был огромный опыт работы с этим сервером, поэтому решили оставить именно этот сервер для СУБД.
Однако меня одолевали сомнения — а справится ли моя команда? Поэтому решили попробовать сделать вначале маленький кусочек — мы его назвали сервером штабелеров. Данный сервер имел фактически лишь одну команду — переместить контейнер из одной ячейки в другую. Сложность заключалась в том, что ячейки могли располагаться в разных подскладах, или в кольцевых подскладах с двумя роботами. У предыдущего разработчика камнем преткновения стали постоянные столкновения роботов и неэффективность выбираемого варианта действий.
Сервер штабелеров
Модуль взаимодействия с роботами написали довольно легко. Памятуя свой прошлый опыт работы с любыми железками, я решил в первую очередь реализовать эмулятор и толковый визуализатор роботизированного склада. Ну не на живых же роботах отлаживать алгоритм — количество столкновений, которые они смогут выдержать, строго ограничено. Эмулятор на одного робота уже был у производителей роботов, и они мне любезно предоставили его вместе с исходниками на C#. Насчет визуализатора у наших коллег-разработчиков низкоуровневого ПО для роботов были сильные сомнения, что его вообще можно реализовать теоретически. Однако после нескольких дней медитаций как-то сама собой вырисовалась форма, приведенная внизу.
То есть визуализатор показывает АСК как бы сверху, при этом занятость робота выделяется различными анимационными эффектами от WPF. Найденная форма визуализации так всем понравилась, что было решено использовать ее на всех уровнях, вплоть до маркетингового, при конструировании коммерческих предложений.
Любимые триггеры от Oracle
Основная логика работы АСК — это управление конечным автоматом (так, кажется, это нам называли на лекциях в ВУЗе). Есть набор состояний склада, и нужно переключать систему между различными состояниями в зависимости от определенного набора условий. И вот для этих целей Oracle SQL сервер оказался прямо таки идеальным средством разработки. Триггеры от Oracle позволили быстро и удобно запрограммировать всю логику работы склада. Отлаживать было очень удобно. Оказывается, невероятно приятно работать, когда матмодель предметной области хорошо коррелирует с матмоделью средства разработки.
Были еще сомнения в быстродействии Oracle — объем базы был небольшой, но число операций изменений таблиц достигало иногда 20-ти в секунду. Однако Oracle тут не подвел, даже бесплатный Oracle SQL XE.
Трудности
Вся эта идиллия продолжалась до тех пор, пока не пришла очередь писать модуль эффективного управления двумя роботами на одном кольцевом пути. Казалось чего проще — есть общий ресурс (рельса), есть правило его выделения. Но как принять решение — каким роботом выполнять какую команду и в каком направлении? После недели топтания на месте я вдруг обнаружил, что в наш обиход прочно вошли такие слова как выбор стратегии, принятие решения, оптимальный путь и тому подобные. И пришло понимание, что мы серьезно забрели в болото искусственного интеллекта, из которого нужно было как можно быстрей выбираться. Время то было ограничено. Вспомнив институтский курс (помянув добрым словом своих преподавателей), что в случае проблем со временем у разработчиков в задачах с искусственным интеллектом прибегают к имитационной модели и методу полного перебора, решил поступить таким же образом. Может быть не совсем красиво, зато точно будет работать.
Визуализатор принятия решений
Однако даже имитационное моделирование такой несложной системы с двумя роботами на одном рельсе оказалось весьма непростой задачей. Количество разнообразных вариантов поведения системы росло, чуть ли не в геометрической прогрессии, и, начиная с какого то момента, разработчик уже не понимал ход имитационного моделирования. Пришлось реализовать одну вещь, упоминания о которой я встречал разве что у В. Пелевина в его <зенитных кодексах от Аль-Эфесби>: визуализатор принятия решений. То есть, поскольку в результате имитационного моделирования система частенько принимала неоптимальные решения, и нужно было понять, где ошибка, а отлаживать в реальном масштабе времени было не вариант — все менялось каждую секунду, то в процессе принятия решений (не более 1 секунды) система генерировала удобно-читаемый текстовый файл. Графика в нем рисовалась текстовыми символами — опять таки некруто, но позволяла разработчику довольно в сжатые сроки как модифицировать сам визуализатор, так и отслеживать и исправлять ошибки.
Успех
В результате неимоверного напряжения сил всего нашего коллектива нам удалось в указанные сроки реализовать высокоуровневое ПО для управления роботами. После некоторых размышлений я его назвал <групповым искусственным интеллектом для роботов-штабелеров>, поскольку именно оно делает действия роботов псевдоосознанными, направленными на реализацию заданной цели. Разработка визуализатора принятия решений была переломным моментом во всем проекте. Мы поняли, что делать подобные системы мы можем, и они работают. Хотя и после этого был целый ряд проблем (например, концептуализация взаимодействия АСК с конкретной информационной системой Заказчика с целью унификации), но эти проблемы решались уже в обычном рабочем порядке. Если будет интересно, я расскажу об этих моментах подробней в следующих топиках.
И что еще выяснилось интересного — не все мои программисты смогли работать именно над модулем искусственного интеллекта системы. Несмотря на более чем 10-летний опыт программирования. Видимо, задача вообразить себя даже не роботом, а группой роботов, решаема только программистами с определенным складом ума. Правда тех специалистов, кто особенно интенсивно работал над модулем искусственного интеллекта, какое-то время преследовали ночные кошмары, будто бы они роботы-штабелеры, которые никак не могут найти свой оптимальны путь.
Недостатки
Несмотря на то, что система внедрена и успешно работает вот уже более полугода, я прекрасно вижу некоторые недостатки созданного продукта. Прежде всего, хотелось бы нанять математика и попытаться сделать классическую математическую модель процесса работы роботов-штабелеров. Однако, как мне помнится из институтского курса, не каждая задача из имитационного моделирования имеет решение в виде математических формул.
Также есть мысли сделать все на полноценном объектно-ориентированном подходе. Из-за ограничения со временем то и дело приходилось срываться на написание классических процедур и функций.
Еще есть мысль все-таки ознакомиться с мировым практическим опытом в создании подобных систем. Однако быстро ничего найти не получилось. Может это строжайшее ноу-хау разработчиков, или я не знаю нужных ключевых слов?
Заключение
Не буду говорить тривиальные слова о неизбежности роботизации всего народного хозяйства. Скажу проще. На мой взгляд, пройдет еще лет 10, и как минимум 30% существующих складов во всем мире будут роботизированы. По целому ряду причин, и не только из-за экономической целесообразности (повышенная плотность хранения и сокращение штата). И мне приятно будет осознавать мой небольшой вклад в этот процесс в направлении избавления человека от рутинного труда.
Автор: korvint
