|
ПРЕДИСЛОВИЕ
Успешное решение поставленных XXVII съездом _КПСС_гза дач .автоматизации производственных процессов зависит от своевременного создания программного обеспечения разрабатываемых промышленностью автоматических систем на базе микро-ЭВМ. Значимость программного обеспечения в настоящее время определяется следующими факторами:
требованиями гибкости и простоты переналаживаемости автоматизированного производства при изменении объема или номенклатуры выпускаемой продукции, а также при изменении конфигурации оборудования;
архитектурой вычислительных управляющих устройств и терминального оборудования, используемых в составе систем управления автоматических производств, предполагающих обязательное наличие программных средств для объединения элементов оборудования в единую систему;
использованием микропроцессорной элементной базы, требующей разработки микропрограмм и программ для формирования необходимых функциональных характеристик;
. необходимостью адаптации средств автоматизированного производства к неопределенностям производственного процесса, связанным с начальным расположением обрабатываемой детали и погрешностями работы технологического оборудования.
Настоящий сборник подготовлен Рабочей группой по программному обеспечению роботов Научного совета АН СССР по проблеме «Робототехника и автоматизированное производство». Цель сборника — ознакомить широкий круг читателей с разработками в области программного обеспечения роботов. Статьи сборника написаны ведущими специалистами в этой области, принимающими непосредственное участие в создании робототехнических систем.
Сборник состоит из четырех частей посвященных проблемам разработки программного обеспечения роботов, описанию имеющихся реализаций системного . и прикладного программного обеспечения устройств управления, разработкам алгоритмов управления ро-
ботами. Статьи сборника охватывают широкий круг вопросов как практического, так и теоретического плана.
Представляют интерес статьи, посвященные конкретным системам управления сварочными роботизированными комплексами, окрасочными роботами «Колер» и сборочным многооперационным роботом. В сборнике представлены также статьи, описывающие программное обеспечение мультипроцессорных систем управления на базе микро-ЭВМ, программное обеспечение устройств контурного управления для промышленных роботов.
В ряде статей сборника отражен опыт эксплуатации специализированных операционных систем для управления и обучения роботов. Большое внимание уделено проблемам, возникающим в процессе организации и создания программного обеспечения роботизированных комплексов для полунатурного моделирования.
ПРОБЛЕМЫ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РОБОТОВ
НАУЧНЫЕ ПРОБЛЕМЫ СОЗДАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РОБОТОТЕХНИЧЕСКИХ СИСТЕМ
И. М. Макаров, Д. Е. Охоцимский, А. К. Платонов
Отличительным признаком рооототехнических_хистем является принципиальная возможность применения их в широкой области произ-водетвеппых процессов и технологий. Такая возможность достигает-/ся путем введения в контур системы управления робота программ-I ных средств, обеспечивающих перенастройку на выполнение ро-\ ботом работ различного характера. Это объясняет современную тенденцию создавать системы управления на базе универсальных дикро-ЭВМ с соответствующими программными средствами. Трудозатраты и сроки разработки системы управления промышленного робота и последующего его внедрения па конкретном производстве увеличиваются в связи с необходимостью разработки программного обеспечения, стоимость изготовления которого в настоящее время соизмерима со стоимостью аппаратной части системы управления.
Функции программного обеспечения роботов, в общем виде весьма похожие на функции программного обеспечения вычислительных систем, заключаются в обеспечении согласованной работы подсистем робота, в реализации процессов программирования, отладки и редактирования программ работы, в организации доступа к информации в памяти системы и взаимодействия с сопряженным с роботом оборудованием, в формировании отклика на сигналы оператора, в слежении за правильностью работы оборудования и действий оператора. Сопутствующее программное обеспечение должно содержать языки и трансляторы для формирования самого программного обеспечения робота, средства тестирования и отладки.
Вместе с тем программирование роботов имеет существенные отличия от программирования вычислительных машин, связанные со значительно меньшей определенностью состояний внешней среды, самого робота и операционной обстановки. Рассмотрим эту проблему более подробно.
В цифровых вычислительных машинах неопределенности и погрешности физических процессов исключаются на аппаратурном Уровне. Поэтому с точки зрения программиста сама цифровая вычислительная машина работает детерминированно. Внешняя неопределенность операционной обстановки сводится к неопределенности
моментов времени возникновения сигналов от присоединенного оборудования и поступления заказов на выполнение различных работ от программ решения задач в мультипрограммном режиме.
В робототехнических системах значительная часть погрешностей и неопределенностей физических процессов должна парироваться на уровне программного обеспечения. Неопределенность операционной обстановки усиливается дополнительной неопределенностью требуемого характера поведения робота (с точки зрения безопасности, отсутствия брака и т. п.) при априорно незафиксированных отклонениях хода технологического процесса. Особенности программного обеспечения роботов связаны также с необходимостью ориентации не на квалификацию системного программиста, а на квалификацию специалиста-технолога, программирующего функционирование робота в цехе, и оператора, обслуживающего робот в составе производственного участка. Программные функции контроля за правильностью работы оборудования и действий оператора осложняются повышенными требованиями к надежности и, главное, безопасности функционирования робота.
Важным обстоятельством, оказывающим большое влияние на программное обеспечение роботов и сроки его разработки, является наблюдаемое противоречие между требованиями режима реального времени и стоимостью системы управления, приводящее к сравнительно большому разнообразию технических средств и архитектур управляющих вычислительных систем. Традиционно системы управления делятся на цикловые, позиционные и контурные; датчики информации — на аналоговые и дискретные разных типов; привод — на следящий и шаговый; кинематические схемы роботов — на ортогональные, цилиндрические, сферические и антропоморфные. В связи с этим существенное сокращение стоимости и сроков разработки программного обеспечения подобных роботов достижимо только путем придания ему свойства «транспортабельности» — возможности адаптации к системе управления робота другого типа без значительной переделки. При этом следует иметь в виду различие характеристик и ресурсов оборудования применяемых систем управления и роботов (разрядность и быстродействие преобразователей сигналов, быстродействие управляющей ЭВМ, объем ее памяти, наличие внешней памяти, арифметического и тригонометрического расширителя системы команд процессора, вид кинематической схемы робота и т. д.).
Имеется еще одно обстоятельство, отличающее от программного обеспечения вычислительных машин программное обеспечение роботов — его незамкнутость. В условиях современного производства робот представляет собой единицу оборудования в составе производственного участка или при более высоком уровне автоматизации — в составе гибкой производственной системы. Поэтому программное обеспечение робота должно в процессе работы взаимодействовать с другими программными системами: числового программного управления (ЧПУ) обслуживаемых станков; автоматизированной системы управления (АСУ) и системы автоматизированного
проектирования (САПР) технологических процессов (ТП) и АСУ производством. Соглашения о связях при подобном взаимодействии весьма разнородны, поэтому к системе управления робота предъявляются требования определенной гибкости интерфейса с внешними системами.
Перечисленные обстоятельства позволяют выделить проблему создания программного обеспечения роботов ввиду ее сложности и новизны в отдельное, научно-техническое направление в общей цепи проблем автоматизации производственных процессов. Техническое содержание этого направления связано с необходимостью разработки общего и специального программного обеспечения серийно выпускаемых промышленностью систем управления промышленных роботов п подготовки соответствующей документации. Эта задача требует тесного взаимодействия разработчиков программного обеспечения с разработчиками аппаратных систем устройств управления и механики роботов.
В обсуждаемой проблеме имеется глубокое научное содержание, связанное с необходимостью разработки алгоритмического обеспечения систем управления роботов и методических средств их создания. Эти задачи могут быть полностью решены только после создания оборудования робота и его системы управления. Для решения научных проблем до завершения разработки робота и его системы управления широко используются лабораторные макеты элементов оборудования робота и математические модели.
Рассмотрим более подробно научное содержание проблем создания программного и алгоритмического обеспечения роботов.
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ РОБОТОВ
Оптимизация программ. Вычислительно-логические возможности ЭВМ являются мощным инструментом в руках программиста. Однако именно богатство этих средств приводит к неоднозначности принимаемых решений и трудности выбора оптимального варианта. Поэтому написанная программа часто является отражением стиля и опыта программиста, а не результатом применения объективных методов синтеза оптимальных процедур работы ЭВМ.
Проблема оптимизации программ наиболее остро стоит в связи fc требованиями режима реального времени в программном обеспе-..
I чении робототехнической системы. Иными словами, для робототех-~Чч и нических систем важным критерием качества является быстродей- \ \ 1 ствие программных модулей, в том числе модулей операционной I системы.
С другой стороны, требования простоты системы управления робота и ее низкой стоимости приводят к ограниченным объемам оперативной и внешней памяти устройств управления роботов по сравнению с вычислительными системами. В связи с этим не менее остро стоит проблема оптимизации суммарного объема программного обеспечения робота и объема резидентных программ с учетом разделения на переменную и постоянную части.
Многокритериальный характер оптимизационной задачи порождает известные трудности ее решения и требует разработки специальных методов оптимизации [1, 2]. Эффективными отечественными средствами здесь являются оптимизирующий транслятор ФОРЕКС [3] и языки Астра [4] и МЭЛ [5].
Распределение или централизация функций? Все функции программного обеспечения (прием и передача сигналов, вычисления и выбор альтернатив) могут быть в наиболее общем виде описаны как процессы обработки информации, обладающие двумя характеристиками: временем исполнения и локализацией. При проектировании программного обеспечения имеется некоторая свобода варьирования состава процессов, их быстродействия и способов взаимодействия, дающая возмояшость оптимизации критериев качества программного обеспечения. Вместе с тем всегда можно выделить «нулевой) уровень описания проблемы управления роботом с учетом имеющейся конфигурации технических средств, на котором состав и структура процессов фиксированы. Это исходное описание процессов не содержит указания на способы организации их взаимодействия и синхронизации. На нулевом уровне описания нет также информации о распределении исходных процессов по процессорам многопроцессорной системы управления робота.
Р1сходная совокупность процессов управления, определяемая с помощью содержательного анализа задач управления и наличных аппаратных средств, должна быть дополнена служебными процессами, выполняющими административные операции для синхронизации и организации взаимодействия исходных процессов. Программная реализация служебных процессов может быть оформлена в виде отдельной централизованной операционной системы или может быть распределена по программным модулям, реализующим исходные процессы. Локализация служебных процессов оказывает значительное влияние на эффективное быстродействие программного обеспечения, занимаемый им объем памяти и способы развития.
Централизация функций административных процессов, удобная с позиций структурной простоты организации процедур управления, снижает эффективное быстродействие системы управления и качество управления в режиме реального времени. С другой стороны, распределение функций операционной системы в системе проблемно-ориентированных программ приводит к увеличению необходимого объема памяти и сложности организации оптимального распределения работ в динамике функционирования системы управления. Поиск наилучшого соотношения централизации и распределения функций управления в системе процессов является актуальной научной проблемой, решение которой позволит получить максимальную эффективность управления для заданной архитектуры аппаратных средств.
В настоящее время накоплен значительный опыт эмпирических методов решения указанной проблемы. Созданы операционные системы программного обеспечения роботов с различной степенью децентрализации. Анализ интегральных характеристик накладных
щ
расходов и затрат памяти в этих системах позволяет получить необходимые данные для построения формальных методов определения оптимальной степени децентрализации системы [6, 7].
Процесс или память? Из практики программирования хорошо известно, что уменьшение длины программы в памяти машины можно получить, используя более длительный процесс вычислений при сохранении характера требуемой функциональной обработки исходных данных. И наоборот, если требуется сократить время вычислений, то наилучший путь — замена процесса вычислений обращением к табличным данным, запасаемым в памяти машины. Таким образом, время исполнения данного функционального оператора связано с длиной исполняющей его программы обратной зависимостью, по крайней мере в некоторой части области определения этой функции.
Проблема выбора оптимального соотношения времени исполне- \ ния программы и объема занимаемой ею памяти при создании про- \ граммного обеспечения роботов стоит особенно остро из-за малой мощности применяемых ЭВМ и большой вычислительной сложности решаемых задач (высокая требуемая относительная точность движения, большое число степеней подвижности робота, сложность его кинематической схемы, требования работы в режиме реального времени и т. п.). В связи с этим необходима разработка специализированных библиотек стандартных программ робототехники, приспособленных для эффективного решения задач кинематики и динамики роботов. При этом следует учитывать известные для этих роботов диапазоны изменения обобщенных координат, допустимые точности вычисления тригонометрических функций и возможность проведения предварительных вычислений в процессе обучения робота [8, 9].
Для решения этих проблем необходимо развитие инструментальных средств и методов, ориентированных на использование современной микропроцессорной элементной базы с учетом присущих ей характерных свойств и ограничений (влияние архитектуры спецпроцессора на время и точность исполнения операций, соотношение процесс—память на уровне микропрограммирования, наличие быстрых регистровых и сдвиговых операций трансформации чисел и т. п.). Следует отметить, что строгое формальное описание этих свойств и ограничений, позволяющее развивать аналитические и численные методы варьирования альтернатив при оптимизации программ, развито еще недостаточно. Разработка такого описания путем анализа особенностей современной элементной базы с точки зрения программиста является самостоятельной научной проблемой, имеющей важное значение для правильной постановки и решения задач оптимизации программ.
Как работать с памятью? Обращение к памяти ЭВМ в общем случае представляет собой не однократную машинную операцию, а многоуровневый процесс доступа к данным, реализуемый на аппаратном, микропрограммном и программном уровнях, причем последний может содержать уровни операционной системы, файловой системы и прикладных программ. При большом объеме данных
процессы доступа могут занимать большое время и рассмотренная выше проблема «процесс или память?» превращается в проблему «процесс вычислений или процесс обращения к памяти?», решение которой зависит от принятого способа организации работы с памятью ЭВМ [10]. Как известно, имеются два аспекта этой проблемы: доступ к данным (распределение памяти, «уборка мусора», выбор оптимальной функции адресации и т. п.) и организация обмена данными между программными модулями (формальные параметры, «common-блоки», data flow и т. п.).
Способы решения возникающих вопросов тесно связаны с особенностями средств, предоставляемых файловой системой, макрогенератором и трансляторами инструментальной системы программирования, видом внешней памяти устройства управления и возможностями организации баз и банков данных с абстрактными типами данных, реализации идей «отложенной трансляции» академика A. II. Ершова и создания универсальных средств генерации версий программного обеспечения. Недостатки принятых способов организации работы с памятью, как правило, становятся очевидными только на поздней стадии создапия программного обеспечения или позже — в процессе его развития. Изменение принятого способа организации работы с памятью означает коренную переработку всех программ. Поэтому формулирование научно обоснованных рекомендаций и соответствующих программных средств имеет большое значение.
Проблемы организации памяти важны и с точки зрения стандартизации программного обеспечения. Быстрое совершенствование и развитие вычислительной техники и средств программирования, так же как и возникновение новых производственных систем, делают несостоятельными попытки стандартизовать непосредственно структуру данных программного обеспечения производства. Для примера достаточно сравнить различающиеся структуры данных устройств ЧПУ для металлообработки, устройств управления роботов, роботизированных технологических участков, систем САПР— АСУ ТП и гибких производственных систем. Хотя все эти системы принципиально могут быть реализованы на однотипных ЭВМ с одним и тем же базовым программным обеспечением и структурой данных, этого не произошло ввиду их создания в разное время. И, безусловно, здесь крайне полезным явился бы стандарт, описывающий не саму структуру данных, а методы организации памяти и язык для определения используемой структуры данных.
Решение перечисленных проблем, видимо, следует искать на пути разработки средств генерации трансляторов и загрузчиков, позволяющих изменять способы работы с памятью без изменения текста программ [4].
. Язык или языки? Ответим сразу: языки и язык. Программное i обеспечение роботов представляет собою сложную многоуровневую систему средств, элементы которой отличаются как по областям применений роботов, так и по стадиям использования программ в ; процессе подготовки производства. Языковая поддержка этих
средств также является совокупностью непохожих наборов операций и структур данных, реализуемых в различных устройствах. Можно указать, например, на такие принципиально разные языки, как язык программирования робота с помощью пульта обучения, язык предварительного описания деталей и видов рщбот, используемый для получения управляющих программ, язык генератора версий программного обеспечения, языки систем программирования инструментальных ЭВМ. Множество языков безусловно усложняет систему, однако отсутствие какого-либо из них усложняет ее эксплуатацию и развитие.
Важно отметить, что всякий язык программирования представляет собой совокупность типов данных, операторов и транслятора, причем от качества транслятора зависят в большой мере эксплуатационные характеристики системы программирования. При создании трансляторов для языков программирования мини- и микро-ЭВМ, используемых в робототехнике, необходимо обеспечить высокую скорость трансляции и надежность получаемых программ.
Обеспечение надежной трансляции в заводских условиях представляет серьезную проблему ввиду необходимости во многих случаях использования лишь простейшего терминального оборудования-- перфоленточных устройств ввода—вывода или же кассетного магнитофона малой емкости с последовательным доступом. При этом следует учитывать возможность сбоев или отказов терминального оборудования при его эксплуатации в неблагоприятных условиях.
Надежность трансляции может быть обеспечена путем придания программному обеспечению специальных свойств, позволяющих уменьшить его зависимость от качества и состава применяемого в процессе трансляции оборудования,— простоты обработки текстовых данных и функциональной избыточности.
Под простотой обработки текстовых данных мы подразумеваем минимизацию числа проходов транслятора, отказ от промежуточных обращений к внешней памяти, простоту редакции и сопряжения новых программных модулей с уже существующими. Для этого необходима разработка наиболее рациональных с этой точки зрения принципов сочленения и распределения функций между средствами макрогенерации, трансляции, редакции и загрузки в системе программирования и операционной системе используемой ЭВМ. Сложность проблемы связана с необходимостью серьезной модификации операционной системы и других системных средств, поставляемых заводом — изготовителем ЭВМ.
Правильно организованная программно-аппаратная система позволяет отключать элементы оборудования в случае отказа, используя путем программной переконфигурации заложенную в систему фун кциональную избыточность. Это требует развития средств проверки готовности оборудования и правильности работы программы, а также средств автоматического поиска способа исправления найденных неправильностей. Последняя проблема особенно сложна, Так как для ее решения необходимы методы синтаксического и,
главное, семантического анализа тяжести ошибки и метйды принятия решения о способах ее исправления или локализации с минимальными затратами труда и времени. Весьма перспективным представляется создание интерактивных систем трансляции и загрузки программ.
Анализ проблемы и опыт разработки системного программного обеспечения робототехники говорят о необходимости использования специального базового языка программирования и транслятора с загрузчиком, позволяющих эффективно создавать трансляторы для языков программирования роботов, обладающие описанными выше свойствами. Наличие такого базового языка облегчает стандартизацию и унификацию программного обеспечения и, главное, резко снижает трудозатраты при создании программ обработки сигналов от оборудования робота и при распределении параллельных процессов по процессорам многомашинного комплекса. В настоящее время версия такого отечественного языка прошла опытную эксплуатацию !га машинах М-6000, СМ-2, СМ-4 и «Электроника-60» с их операционными системами [5]. Перспективы для использования в качестве базового языка робототехники имеют также язык «С» в операционной системе «UNIX» и язык Паскаль.
Таким образом, для решения проблемы языковой поддержки программного обеспечения роботов необходима разработка:
проблемно-ориентированных языков программирования роботов в виде совокупностей типов данных и операторов, адекватных содержанию технологических задач;
единого базового языка, обеспечивающего возможность создания эффективных и надежных трансляторов для прикладных языков с учетом особенностей оборудования на конкретном производстве.
Транспортабельность программного обеспечения. Решение упомянутой проблемы транспортабельности систем упирается в построение оптимальной архитектуры программного обеспечения (аналогично архитектуре ЭВМ — особенностям ее устройства, влияющим на системное программное обеспечение, архитектура программного обеспечения — особенности системного программного обеспечения, влияющие на облик прикладных программ). Трудность задачи в отсутствии достаточного опыта создания систем управления роботов для различных видов производственных процессов и, как было отмечено выше, в значительной вариативности конфигураций известных систем. Роботы даже с одинаковым функциональным назначением могут различаться: по составу позиционных датчиков (кодовые, импульсные, потенциометрические), силомоментных (проволочные, полупроводниковые), фотометрических (фоторезисторы, фотодиоды, видикон, прибор зарядовой связи), локационных (оптические, ультразвуковые) и т. п.; по виду привода (электропривод постоянного или переменного тока, шаговые двигатели, электрогидропривод, пневмопривод); по виду внешней памяти (перфолента, . кассетный магнитофон, магнитная лента на бобинах, магнитные диски); по числу процессоров (один—десять). Однако нет уверенности, что этот список обладает необходимой полнотой и что приведенная
совокупность вариантов оборудования взаимно однозначно отображается на совокупность программных средств.
Если даже считать, что задачи транспортабельности программных систем полностью определены, остается неопределенность методов их решения. Необходима разработка языка и средств генерации версий программного обеспечения, облегчающих процесс переноса программных систем. Реализация таких средств возможна на базе библиотеки программных модулей, соответствующих характеристикам используемого оборудования роботов. На этом пути методически важно правильно решить задачу декомпозиции программной системы на модули, с тем чтобы при изменении конфигурации оборудования и вида работ существовала возможность получить требуемое программное обеспечение путем изменения состава вызываемых из библиотеки программных модулей.
Подобный способ реализации процесса переноса программных систем является наиболее подходящим для начальной стадии развития систем управления производственными процессами, так как он обеспечивает наибольшую простоту адаптации к непредусмотренным изменениям конфигурации оборудования. Именно по этой причине он используется в разрабатываемых программных системах, причем в некоторых из них предусмотрены специальные средства управления процессами, облегчающие перенос и адаптацию программ.
Важной проблемой является выбор правильного метода работы с библиотекой. С точки зрения скорости программирования наиболее простыми являются библиотеки стандартных программ в виде модулей загрузки, позволяющие статически (до начала работы про-г{ймм) или динамически (в процессе работы) загружать в память требуемые стандартные программы и передавать им управление по мере необходимости. Как показал опыт разработки алгоритмов управления движением робототехпических систем, накопленный в Институте прикладной математики им. М. В. Келдыша АН СССР, подобный метод весьма эффективен при отработке функциональной структуры и состава программного обеспечения робота, когда требования экономии ресурсов используемой ЭВМ не являются определяющими.
На заключительной стадии создания программного обеспечения более рационально использование библиотеки макроопределений и средств макрогенерации, позволяющих экономить ресурсы ЭВМ. В настоящее время опыт разработки подобной библиотеки накапливается на базе макросредств системы РАФОС. Анализ этого опыта позволит оценить эффективность существующих средств макропрограммирования и выработать рекомендации для разработки новых макрогенераторов. Однако уже и сегодня очевидны требования к подобной системе, связанные с необходимостью многократных выходов на машину в процессе макрогенерации, трансляции и загрузки программ [11, 12].
Оптимальная степень доступности. Это свойство системных программ тесно связано с решением проблем уменьшения накладных
расходов системного программного обеспечения и увеличением его консервативности. Недоступность модулей операционной системы для программиста, реализующего создание и использование совокупности прикладных программных модулей, не позволяет «подгонять» архитектуру программного обеспечения под конкретную структуру аппаратных средств и задач робота. С другой стороны, простота изменении модулей операционной системы порождает множественность несовместимых версий и реализаций с различными линиями развития.
Разработка каких-либо стандартов в этой области, регламентирующих творческую деятельность программиста, при создании конкретной робототехнической системы исключительно трудна. Тенденция развития в настоящее время — создание генератора операционных систем с их заданными свойствами и соглашениями о связях с драйверами оборудования и проблемно-ориентированными программными модулями. Входной язык такого генератора должен представлять возможность описания специализированных операционных . систем с «усеченными» применительно к задачам робота функциями, заданными дисциплиной обработки запросов, методами синхронизации процессов, ограничениями резидентной памяти, требования- " ми реального времени и, как это обычно делается в существующих генераторах вычислительных операционных систем, конфигурацией , оборудования. Подобный генератор может быть представлен в виде кросс-компилятора, объектными программами которого являются модули операционной системы в виде, приспособленном для программируемых постоянных запоминающих устройств (ППЗУ) и для внешней памяти, а также модули трансляторов системы программирования робота, взаимодействующие с операционной системой. Устройство компилятора при этом остается известным только системному программисту и не влияет на деятельность программи- . ста прикладного. Заметим, что в настоящее время устройство операционной системы, разрабатываемой системным программистом, , часто влияет на деятельность прикладного программиста. Это обстоятельство и является основной причиной попыток изменения уровня доступности системных программ.
Описанный подход к оптимальной организации доступа прикладного программиста к системным средствам исследовался в Институте прикладной математики им. М. В. Келдыша АН СССР в процессе создания транслятора базового языка МЭЛ [5].
АЛГОРИТМИЧЕСКОЕ ОБЕСПЕЧЕНИЕ РОБОТОВ
Создание программного обеспечения роботов невозможно без разработки алгоритмов обработки информации и управления движением. Задачи создания алгоритмического обеспечения роботов связаны с необходимостью преодоления формализма системы управления, придания ей детерминированного характера функционирования, повышения уровня восприятия операционной обстановки и автоматизма управления и, наконец, с решением задач обучения роботов.
Ограниченность формальных систем. Она вытекает из фундаментальной теоремы Геделя и присуща также системам управления роботов. В силу этого обстоятельства к любому алгоритму функционирования робота можно подобрать контрпример, показывающий несостоятельность алгоритма. Задача, однако, заключается в том, чтобы согласовать уровень формализма робота с уровнем формализма выполняемых им видов работ, т, е. перевести все возможные контрпримеры в разряд на практике не встречающихся.
Задача преодоления ограниченности формализма алгоритмического обеспечения, решаемая сегодня на интуитивном уровне, допускает формальную постановку и решение. Проблема заключается в синтезе языка описапия операционной обстановки при выполнении работ различного вида и, главное, правил взаимодействия робога с внешней средой, обеспечивающих необходимое отображение практически значимой области операционных обстановок на фазовое пространство системы управления роботом. В этом случае все практически значимые состояния внешней среды будут фор-, мально различимы в системе управления роботом, а «контрпримеры» останутся вне заданной области возможных ситуаций.
При таком отображении важным обстоятельством является конечность пространства состояний системы управления робота, вытекающая из конечной разрешающей способности его датчиков и органов управления движением. В то же время пространство состояний самого робота хотя и является конечномерным (число степеней свободы робота ограничено), но в виду особенностей его конструкции (наличие люфта и зон нечувствительности) в общем случае конечным не является.
Правила взаимодействия робота с внешней средой, обеспечивающие перевод операционной обстановки в конечное фазовое пространство системы управления робота, адекватное его задачам, упрощаются, если использовать активное пространственное совмещение элементов конструкции робота с объектами внешней среды. Подобное направление синтеза аппаратно-алгоритмических правил взаимодействия робота с внешней средой плодотворно развивается в процессе разработки алгоритмического обеспечения сборочного робота (работа по упорам с применением податливости и специальной логической обработки информации от датчиков в степенях подвижности [13]).
Детерминизация работы. Прямое решение этой проблемы заключается в создании роботов, работающих с точностью выше уровня требуемой дискретности описания операционной обстановки, т. е. в придании роботу детерминизма на аппаратном уровне. Однако такой путь не всегда возможен ввиду недетерминированности реакции внешней среды на действия робота. В то же время использование логических возможностей управляющей ЭВМ позволяет в ряде случаев получить детерминированную систему алгоритмическим путем.
Парирование аппаратных неопределенностей алгоритмическим путем порождает проблему логической обработки неточных данных,
описываемых неопределенными множествами [14]. Подобная обработка, учитывающая специфику выполняемых роботом движений, заключается в реализации трех процессов: контроля правильности сигналов обратной связи, уточнения неопределенной ситуации и формирования реакции на ситуацию. Последняя функция специфична именно для робототехнической системы в отличие от вычислительных систем, в которых активное взаимодействие с внешней средой (системами ввода—вывода) существенно беднее.
Алгоритмическое обеспечение системы управления робота представляет собой многоуровневую систему алгоритмов обработки данных: технический уровень (драйверы устройств), предметный уровень (алгоритмы обработки сигналов датчиков и алгоритмы построения движений), процедурный уровень (алгоритмы мониторов систем), системный уровень (операционная система, программный контроллер), уровень обучения (языки и алгоритмы обучения .робота). Проблема алгоритмической детерминизации работы системы управления заключается, в частности, в определении места алгоритмов детерминизации в системе уровней. Локализация этих алгоритмов является наиболее желательной на уровне драйверов.
В этом случае вся остальная система управления робота с точки зрения прикладного программиста является цифровой системой со всеми вытекающими удобствами.
Реализация подобной системы приводит к необходимости разработки алгоритмов следящих цифровых систем для использования их в драйверах робота [15] и алгоритмов детектирования операционной обстановки путем программируемой логической фильтрации сигналов от датчиков информации [16]. Подчеркнем, что на уровне драйверов речь идет именно об алгоритмах детектирования ситуации, а не о процессах распознавания образов в классическом смысле.
Супервизорное управление. Повышение уровня автоматизма управления и восприятия операционной обстановки обеспечивает воз- можности создания сунервизорных систем, в которых оператор управляет роботом, обращаясь к его системе знаний, т. е. на достаточно высоком уровне команд. Одной из важных проблем здесь является оптимальное распределение функций между человеком и роботом в рамках производственной системы. Необоснованная автоматизация функций планирования работы с учетом всех мыслимых производственных ситуаций удорожает робот и снижает экономическую эффективность его использования. Сохранение за человеком функции принятия решения о режимах работы, особенно в нештатных ситуациях, и придание системе управления средств суперви-зорного управления позволяют (как это показывает, в частности, опыт разработки шагающего аппарата [17]) существенно упростить алгоритмы управления. На этом пути, однако, существуют два препятствия, преодоление которых требует тщательных предварительных исследований и отработки в процессе эксплуатации системы: необходимость декомпозиции возможной активности робота на систему независимых функциональных режимов, покрывающих всю область возможных способов реакций на множестве возможных ситуаций, и требование обеспечить реакцию системы на команды оператора с минимальным временем отклика.
Первая проблема связана с противоречием между требованиями подробности алфавита функциональных команд и его укрупнения в супервизорном режиме (исходя из упрощения деятельности оператора). Решение основывается на анализе задач управления движением и строгом соблюдении основного принципа программирования: «г,се независимое — раздельно, все зависимое — вместе». Имеющийся опыт создания супервизорных систем управления [18, 19] показывает, что лучше иметь избыточность функциональных средств, чем их связанность, которая может привести к выполнениюненужных действий.
Вторая проблема возникает в связи с неопределенностью будущих команд оператора и их возможным «неудобством» для системы управления. В полностью автоматической системе активность робота разворачивается в зависимости от операционной обстановки по плану, сформированному заблаговременно и наилучшим образом соответствующим заданным целям движения. В супервизорноп системе оператор может выдать команду, несогласованную с текущим состоянием системы управления робота. Поэтому степень управляемости супервизорного робота в общем случае ниже автоматического — за внезапность команд приходится «платить». Уменьшение нежелательных последствий внезапных команд, как показал опыт создания системы супервизорного управления шагающей машиной, управляемой водителем [18], возможно тремя способами:
разработкой алгоритмов управления движением, расширяющих область достижимости в каждой текущей точке фазового пространства состояний робота;
разработкой для оператора средств индикации текущей области достижимости или грашщ области управляемости в пространстве управляющих команд;
разделением команды оператора на предварительную (задающую тенденцию управления) и исполнительную (формирующую движение в обозначенной предварительной командой области).
Режимы обучения. Эта группа проблем создания алгоритмического обеспечения роботов связана с режимами программирования их работы. Супервизорный режим был рассмотрен выше с точки зрения его внутреннего содержания. Внешняя сторона этого режима — интерфейс с человеком. Наиболее популярный способ супервизорного управления — использование управляющих рукояток [20]. Менее традиционным является использование алфавитно-цифровых или графических дисплеев, хотя в современных системах ЧПУ и гибких автоматизированных производств (ГАП) они находят довольно широкое применение даже в условиях цеха. В таких случаях необходима разработка специальных языков программирования работы и проблема заключается в обеспечении полноты и удобства использования принятого состава операторов и типов данных. В частности, язык описания плана сборочных операций двурукого
сборочного робота ориентирован на использование алфавитно-цифрового дисплея. Этот язык рассматривается в публикации [21]. Он обладает небольшим (около десяти) набором операторов и позволяет на естественном языке описывать три графа: план сборки, планы сборочных операций и планы проверки условий выполнения сборочных операций [22].
Специальный пульт обучения робота является обычным средством программирования его работы. Проблемы алгоритмического обеспечения робота связаны с сокращением времени обучения и повышением точности работы. Они очень похожи на проблемы ввода информации в ЭВМ с помощью светового пера и графического дисплея. Путь решения аналогичный — с помощью специальных команд ввода положения робота и алгоритмов интерполяции между введенными точками. Отличие робототехнических систем обучения от графических средств ввода информации заключается в наличии трех пространств: конфигурационного пространства робота, предметного пространства, связанного с обрабатываемой деталью и пространства запоминаемых при обучении показаний датчиков. При обучении снимаются показания датчиков, соответствующие задан--ному положению робота в его конфигурационном пространстве, в то время как интерполяция движения между точками обучения должна выполняться в предметном пространстве. Это порождает проблемы решения прямой и обратной кинематических задач в условиях дефицита времени. Опыт решения таких задач применительно к реализации робототехнической системы дуговой сварки показал возможность реализации процесса обучения в режиме реального времени.
Отдельной алгоритмической проблемой является коррекция программы работы робота в связи с изменением начальной установки детали или изменения рабочих органов робота (износ, смещение и т. п.). С этой целью в процессе обучения должны быть запрограммированы контрольные движения со специальными свойствами (фиксированное направление поиска детали, колебания, сканирование и т. п.). Алгоритмы установочной адаптации и предоперационной коррекции управляющих программ особенно важны в условиях Г АП. Главными проблемами в этом случае являются обеспечение надежности и быстродействия этих алгоритмов. Пример одного из алгоритмов установочной адаптации сварочных роботов приведен в публикации [23].
KOHEЦ ФPAГMEHTA КНИГИ
|
