Командно-информационный интерфейс Описание и необходимость введения
Одной из задач, решаемой системой является возможность использования алгоритмов поведения команды роботов, написанных сторонними разработчиками. При этом необходимо было выработать термины, в которых описывается этот алгоритм. Эти термины должны обладать стандартными в таких случаях свойствами обобщения, позволяющими разработчику не вникать в тонкости системы.
Общее описание задачи для этого алгоритма: по получаемым картинам поля. (Напоминание: картина поля – это продукт модуля распознавания, содержит координаты объектов интереса: роботов своей команды, роботов противника, мячика) вырабатывать стратегию командной игры для роботов в терминах действий, описываемых человеческим языком.
Задание движений. Возможные подходы
Существует несколько походов к тому, насколько надо обобщать термины действий. Опишем их.
Первый подход имеет самую низкую степень обобщения, он позволяет программисту алгоритма управлять скоростью каждого колеса робота. Система в этом случае гарантирует только точность этих скоростей. Пользователю же потребуется самому синтезировать траектории движения робота. Несмотря на простоту, этот метод востребован многими потенциальными авторами алгоритмов, т.к. он совпадает со способами, используемыми в симуляторах футбола роботов (FIRA Simurosot, Robocup Soccer Simulation, а также известному в России симулятору кафедры теоретической механики МГУ). Также по косвенным данным мы можем судить, что этот подход используется многими противниками. Однако людям опытным в игре на симуляторах приходится сталкивать с некоторыми специфическими проблемами, не отраженными в симуляторах (за исключением Robocup Soccer Simulator, не распространенного в России); это проблемы ошибок определения, проблема задержки между фиксированием изображения и исполнением команд роботами и проблема нечеткой отработки команд. Существует много работ по преодолению этих проблем, но тогда автору алгоритма приходиться вникать в управление роботами, что наша система должна стараться исключать. Поэтому появились еще несколько подходов.
Второй подход чуть более общий. Он основан на том, что автор алгоритмов задает траектории движения путем складывания их из шаблонных траекторий. В качестве шаблонных траекторий (примитивов) используются отрезок прямой, дуга окружности и нереализуемый в терминах первого подхода поворот на месте. Этот подход появился первым, т.к. задачи стабилизации траекторий являются классическими задачами управления роботами. Казалось бы, автор алгоритмов мог бы с легкостью графического редактора рисовать пути, составленные из примитивов, для успешного выполнения роботом заданий. Однако, в этом случае траектория пользователя будет иметь разрыв в момент переключения с одной траектории на другую и поведение робота на переключении может быть далеко от запланированного. Для исправления подобных ошибок разрабатывается третий подход.
Третий подход облает наибольшей абстракцией. Роботы управляются командами, такими как приехать в точку с заданным конечным положением, повернуться на месте, проехать прямо, а также более общими, такими как ударить по мячику, сделать пас в направлении, объехать робота противника. При третьем подходе автор не заботится о том, как построиться траектория робота и как он будет ее выполнять. Он только может оценить время выполнения и знать, что система будет отрабатывать действие оптимальным (в некотором смысле) способом, т.е. не поедет в точку сделав петлю по всему полю. Первая часть функций этого подхода является адаптацией второго подхода с попыткой исправить ошибки разрывов траекторий, перенося задачи перехода от одного примитива к другому внутрь каждого робота. В этом случае робот сам внутри знает свои координаты и управляет собственным движением, но без учета информации с камеры ошибки измерений приведут к скорому уходу робота с траектории. Так что, при этом подходе коррекция роботов становится еще одной задачей сервера.
В дополнение ко всему сказанному, заметим, что более высокая степень обобщения дополняет задачи сервера еще более сложной задачей предоставления интерфейса в этих обобщенных терминах и при разных внутренних реализациях управления роботами на сервер выпадает разная доля вычислений по управлению роботами.
Все эти возможности задания управления роботами должны поддерживаться интерфейсом внешнего алгоритма с возможностью использовать любой из них. На текущий момент в интерфейсе отражены только первые два подхода.
Реализация интерфейса
Автор игрового алгоритма должен иметь возможность разрабатывать и отлаживать алгоритм максимально удобно и быстро.
Например, при разработке структуры внешнего алгоритма мы отталкивались от следующей идеи: автор алгоритма должен иметь возможность многократного запуска, не останавливая работу сервера и не производя никаких длинных последовательностей действий снова и снова.
Поэтому, естественно, что игровой алгоритм реализован как динамически подключаемая библиотека (DLL), с возможностью ее подключения и отключения во время работы сервера.
Необходимость введения функций отладки
Обрисуем две особенности системы, которые затрудняют отладку игрового алгоритма.
Подключаемая библиотека (DLL) чаще всего в совокупности с сервером, представленным лишь исполняемым файлом, делает невозможной отладку в терминах языка C++.
Большинство ошибок и особенностей проступают только в динамике системы, т.е. при ее безостановочной работе, обрабатывая все новые и новые данные.
Поэтому пользователь алгоритма может производить обработку результатов только постфактум, т.е. записывая информацию по тесту в файл, и затем по записанным данным, определяя ошибки. Система должна обеспечивать интерфейс для таких действий, позволяя просматривать записанные данные, как во время теста, так и после его окончания.
Кроме того весьма полезным на практике оказалась возможность рисования простых примитивов поверх изображения, пришедшего с камеры. Автор игрового алгоритма рисование таких примитивов производит в метрических координатах поля (т.е в мм). Система же переводит метрические координаты в координаты изображения для отображения их.
Управление параметрами
Практика показала, что для увеличения скорости разработки, программист игрового алгоритма должен иметь быстрый доступ к некоторому набору настраиваемых параметров, которые присутствуют в его коде. Для этого он может из библиотеки или стороннего приложения создать диалоговое окно с настройкой параметров или изменять текстовой файл, постоянно читаемый алгоритмом. Первый способ требует от него времени на разработку, второй не всегда удобен. Большая часть таких параметров выглядят как целочисленные или дробные (можно считать с постоянным числом знаков после точки), ограниченные некоторым интервалом изменения. Поэтому в системе был разработан стандартный подход быстрого доступа к этим параметрам.
В графическом интерфейсе программы был выделено некоторое количество мест со стандартизованным составным объектом диалогового окна для изменения параметров. Этот объект состоит из элемента графического интерфейса типа Static Text для названия, элемента типа Slider Bar для отражения интервала изменения и элемента типа Edit Box для отражения значения параметра. Цена деления Slider Bar равна минимально возможному изменению параметра (для целочисленного это 1, для параметра с фиксированной точкой это 10-p, где p – число точек после запятой).
Реализация интерфейса: функции, экспортируемые из DLL
Функции DLL вызываются системой при следующих событиях: загрузка DLL, выгрузка DLL и получение информации от модуля распознавания. Все эти три события отражены в модуле в качестве функций, внутри которых автору внешнего алгоритма разрешается добавление своего программного кода.
Функции интерфейса имеют свои функции контейнеры, описанные в DLL.
Все функции интерфейса вызываются из DLL, а тела их располагаются в программе-сервере. Для того, чтобы можно было вызывать эти функции необходима передача их адресов в DLL. Для этой цели существует специальная служебная функция.
Эта функция вызывается несколько раз сразу после загрузки DLL и каждый раз в качестве аргумента имеет адрес функции и номер вызова. И в программе-сервере и в DLL внешнего алгоритма заложен один и тот же порядок функций.
Адреса функций сохраняются, и когда внешний алгоритм вызывает функцию интерфейса, описанную в DLL, та вызывает соответствующую ей функцию программы сервера, располагаемую по полученному адресу.
При таком построении, автор внешнего алгоритма имеет в своем распоряжении набор функций в обычном понимании, с которым и работает.
|
