Разработка коллаборативного автономного робота экскурсовода

Во время тестирования работы программы для FPGA в случайный момент времени плата перезагружалась. По какой-то причине плата De10-nano, в частности HPS часть, пытался обратиться к несуществующему участку памяти и перезагружался, инициируя перезагрузку FPGA. Данная проблема решилась с помощью настройки FPGA-HPS bridge and HPS-FPGA bridge.



3.5 Модуль построения карты

Карта помещения формируется пользователем через web-интерфейс. Алгоритмы по обработке действий пользователя, формирования карты и построения маршрута функционируют на сервере, не накладывая дополнительную нагрузку на аппаратную часть робота. Она делится на клетки заданного размера, сопоставимого с размерами робота. Пользователь через интерфейс задает размеры помещения, после чего генерируется поле для карты из клеток. На фон поля можно подложить изображение плана помещения для удобства пользователя. Далее оператор с помощью определенных цветов закрашивает клетки, обозначая доступные для перемещения места и статические препятствия (рисунок 11).

Рисунок 11 – Web интерфейс построения карты.

Карту помещения, представленную матрицей, содержащей в себе информацию о препятствиях, можно представить в виде ненаправленного графа. После формирования карты, оператор может также специальным цветом обозначать точки, из которых и куда должно осуществляться перемещение, на основе чего алгоритм строит кратчайший путь между двумя точками. Также у пользователя есть возможность самостоятельно обозначить желаемую траекторию движения. Матрицу с точками можно представить в виде ненаправленного графа, для решения задачи поиска кратчайшего маршрута. В Таблице 2 представлен ряд алгоритмов для решения данной задачи и их вычислительная сложность, где n -- число вершин, m -- число ребер.

Таблица Алгоритмы определения кратчайшего расстояния между вершинами графа

Алгоритм	Вычислительная сложность
Алгоритм Дейкстры	О(n^2+m)
Алгоритм поиск в ширину	О(n+m)
Алгоритм Беллмана-Форда	О(n*m)
Алгоритм Флойда Уоршелла	О(n^3)

В разработанном web-приложении был использован алгоритм поиска в ширину [26], поскольку он имеет достаточно малую вычислительную сложность и прост в реализации. Примерная последовательность работы алгоритма следующая: на каждой итерации список рассматриваемых вершин графа увеличивается на количество связанных узлов графа с узлами на предыдущем шаге; цикл повторяется до тех пор, пока не будет достигнута желаемая вершина. Данный алгоритм гарантированно находит кратчайшее расстояние, но из-за большого размера карты построение маршрута с помощью обхода в ширину может занимать продолжительное время. Для разрабатываемой системы это не является ограничивающим фактором, поскольку карта подготавливается заранее, до запуска робота, и не накладывает ограничений на время работы алгоритма. На вход алгоритм получает координаты двух точек начала и конца движения. После формирования карты оператором, она сохраняется на сервере в базу данных в виде матрицы. В матрице хранятся обозначения различных статических препятствий на карте, а также отмечаются точки, соответствующие местам зарядки, и т.д. (1 - обозначает препятствие, 0 - свободное для перемещения пространство, 2 - текущее местоположение, 3 - точка назначения, 4 - маршрут для передвижения). После построения маршрута алгоритмом, все новые маршруты сохраняются в очередь, ожидая пока робот освободится от предыдущего задания. Оператор может удалить задание (точку прибытия) из очереди.

3.6 Модуль управления роботом

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

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

Данный массив заполняется объектами трех «классов» MoveClass, RotationClass, StopClass представленных ниже.



MoveClass при инициализации получает на вход в качестве параметров направление движения (назад или вперед), а также количество «шагов», которое нужно сделать. Если forward_direction имеет значение True, то направление движения «вперед», иначе назад. При умножении количества «шагов» на время, за которое робот проходит один «шаг», получаем расстояние, на которое должен проехать робот. Несколько объектов типа MoveClass, стоящих в массиве-последовательности сливаются в один. При выполнении шага класс MoveClass, алгоритм подает управляющий сигнал на колеса b'1100' или b'0011' в зависимости от направления движения. Время подачи сигнала сохраняется в объекте с помощью метода set_time_start. Далее постоянно сверяется значение времени, прошедшего с момента начала движения. Как только прошло время равное времени прохождения заданного количества шагов, алгоритм подает сигнал b'0000' для остановки. Нельзя просто сделать метод, в котором между подачей сигнала на начало и конец движения стоит delay, поскольку во время всего движения необходимо проверять наличие препятствий по направлению движения, а также ожидать поступления внешних команд.

RotationClass инициализируется значениями угла поворота в градусах и также направлением вращения (по часовой стрелке или против часовой стрелки). Если переменная clockwise_direction имеет значение True, то вращение происходит по часовой стрелке, иначе против. Также, как и объекты «класса» MoveClass, несколько объектов RotationClass стоящих подряд объединяются в один. При выполнении шага с объектом данного «класса», инициализируется время начала вращательного движения, и подается управляющий сигнал на моторы b'1001' или b'0110' в зависимости от направления вращения.

StopClass введен для работы при возникновении препятствий по время движения, поскольку динамические препятствия (такие как человек) могут сами обойти робота, и поиск объездного маршрута не потребуется. При возникновении таких ситуаций в массив добавляется объект данного «класса». Также останавливается любое движение подачей сигнала b'0000'. Объект, согласно которому выполнялось движение до этого, остается в массиве, но из значения угла поворота или количества «шагов» вычитается величина уже пройденного расстояния.

Итерирование по полученному массиву происходит в отдельном потоке. Такое решение позволяет продолжать получать команды управления во время всего движения робота. Команды управления:

- остановка движения;

- запуск движения;

- получение текущего положения.

Остановка движения может прийти с параметром, в котором указывается время, на которое требуется остановить движение. При этом в массив-последовательность добавляется объект класса StopClass, и прохождение по массиву не прерывается. В противном случае, происходит остановка движения по массиву.

При возникновении препятствия на пути следования робота, кроме добавления в массив-последовательность объекта класса StopClass, формируется зарпос к плате Cubeboard4.Если же препятствие не исчезло, робот активирует модуль построения объездного маршрута, который будет описан ниже. Если робот доехал до края части карты, он запрашивает сервер на получение новой части, и процесс повторяется.

3.7 Модуль объезда препятствий с построением карты локальных препятствий

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

В программе клетка, на которой возникло препятствие помечается как недоступная. После этого происходит поиск нового маршрута от текущего положения робота до следующей точки маршрута. Вносятся корректировки в массив-последовательность действий в соответствии с новым маршрутом. Например, уменьшается количество шагов в выполнявшемся объекте «класса» MoveClass, если препятствие возникло по ходу движения робота, удаляется объект «класса» RotationClass, если в связи с новым маршрутом поворот должен произойти в другом месте и т.д. После этого движение возобновляется. Если снова возникают препятствия, процесс повторяется.

3.8 Модуль взаимодействия с посетителем

Вся логика работы со слушателем реализована на плате Cubeboard4. Как и на De10-nano плата находится в постоянном ожидании входящих команд, поэтому все алгоритмы, занимающие продолжительное время, выполняются в отдельном потоке. Команды управления:

- передать номер точки, на которой происходит обслуживание посетителя;

- воспроизвести звуковую дорожку;

- включить ожидание пользователя (с распознаванием лиц);

- показать изображение.

При получении номера точки, на которой происходит обслуживание посетителя, Cubeboard4 делает запрос к главному серверу и получает json данных, с информацией, какие картинки требуется показать, какой текст воспроизвести и в какой последовательности требуется это сделать.

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

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

3.9 Модуль распознавания лиц

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

Распознавание лиц происходит с помощью библиотеки OpenCV для Python. Классификаторов происходит на основе признаков Хаара с использованием расширенного каскада простых функций - эффективный метод обнаружения объектов, предложенный Полом Виолой и Майклом Джонсом. Это подход, основанный на машинном обучении, где Каскадная функция обучается из множества положительных и отрицательных изображений. Затем он используется для обнаружения объектов на других изображениях. Классификатор, предоставленный в библиотеке, является уже предобученным. Для обнаружения нужных образов используется функции Хаара, показанные на рисунке 12, которые являются по сути сверточным ядром алгоритма.

Рисунок 12 – Функция Хаара.

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

Рисунок 13 – Пример работы модуля.



4. Тестирование аппаратно-программных модулей и анализ полученных результатов

Для оценки работоспособности разработанной коллабративной роботизированной системы было проведено тестирование аппаратно-программных модулей и анализ полученных результатов.

4.1 Тестирование модуля управления ультразвуковыми датчиками

Первоначально каждый датчик по отдельности подключается к плате для проверки на работоспособность и корректность выдаваемых значений. Полученный массив от ультразвукового датчика передается через FPGA-HPS bridge на HPS ядро, где с помощью скрипта на языке программирования C массив байт конвертируется в переменную типа Integer - расстояние до объекта. На этом этапе выявлено два нерабочих датчика.

Далее проводится ряд тестов относительно количества замеров расстояния до объекта, которое требуется для усреднения получаемого значения и нивелирования влияния ошибочных измерений. Каждый датчик имеет свою степень погрешности. Эмпирическим путем установлено, что шести измерений достаточно для получения корректных данных со всех ультразвуковых датчиков. Также в документации к ультразвуковому датчику HC-SR04 указано, что рекомендованный период между измерениями следует установить на значение не меньшее 50мс [27]. Таким образом значение, получаемое по каждому датчику, обновляется трижды в секунду.

В процессе проведения измерений выявлено, что ультразвуковой датчик некорректно измеряет расстояние до пористых и мягких поверхностей, так они хорошо поглощают ультразвук. В следующей версии колесной платформы следует в дополнение к установленным ультразвуковым датчикам добавить инфракрасные.



4.2 Тестирование модуля управления моторами

Для тестирования корректности подключения моторов, написан модуль на языке программирования C, который записывает четырехбитное число в память HPS-FPGA bridge, а программный модуль на Verilog в соответствии с полученными битами передает сигналы на пины, к которым подключены драйверы двигателей. В первую очередь проверяется, что двигатели подключены корректно и вращаются в одну сторону. После этого был проводится ряд тестов:

- тестирование поворота на месте (по часовой стрелке и против часовой стрелки);

- тестирование движение (вперед и назад);

- тестирование движения по заданному маршруту (комбинированные движение вперед и повороты).

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

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

4.3 Тестирование модуля построения карты

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

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

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

В результате проведенных тестов сервер функционирует без ошибок. В следующей версии проекта следует добавить возможность оператору ставить несколько точек остановки, а также реализовать возможность добавления нескольких слоев на одной карте, чтобы избежать пересечения маршрутов.

4.4 Тестирование модуля объезда препятствий

При последующем тестировании модуля объезда препятствий учитывается целый ряд граничных случаев поведения робота. Например, когда препятствие находится в точке маршрута, на которой должен был произойти поворот, после объезда препятствия и возврата на маршрут нужно определить текущее и требуемое направление движения и, при необходимости, развернуть коллаборативную роботизированную систему. Если препятствие занимает несколько клеток подряд, то каждый раз приходится искать новую конечную точку, на которую следует вернуться. Если препятствие находится на конечной точке маршрута, следует отправить информацию о данной ошибке оператору.

В следующей версии модуля объезда препятствий необходимо уменьшить клетки матрицы, по которым строятся карта. Связано это с тем, что существуют ситуации, где два соседних препятствия находятся в центре клетки, но не занимают ее целиком. В данной версии робот посчитает всю клетку, как недоступную. Разбиение клеток на более мелкие позволит роботу проехать между описанными препятствиями.

4.5 Тестирование модуля распознавания лиц

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

В процессе проведения тестов выявлено, что распознавание лиц при камере, направленной снизу-вверх относительно лица, работает с большой погрешностью. Связано это с тем, что обучающий датасет содержит в себе набор фотографий с объективом на уровне лица. Это обусловило места расположение камеры на Роботе - камера расположена на жерди, примерно, на высоте лица среднестатистического человека - 1.7 метров.

Модуль способен распознавать несколько лиц одновременно. Эмпирически выяснено, что корректное распознавание и трекинг лиц сохраняется при одновременном присутствии в кадре 5 лиц. При большем количестве лиц, некоторые из них начинают теряться из зоны распознавания. Скорее всего данная проблема обусловлена небольшим разрешением камеры или алгоритма обработки видео потока. В новой версии робота, следует добавить распознавание всей фигуры человека и ее частей, чтобы определять присутствие посетителя в кадре не только, когда он стоит лицом.



4.6 Тестирование взаимодействия всех компонентов Робота

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

Процесс работы с роботом начинается с оператора. Оператор в систему заводит новую карту, затем в нее добавляет несколько маршрутов, как нарисованных самим оператором, так и с помощью автоматического построения модулем построения карты.

На следующем этапе оператор назначает картинки, текст и звуковые дорожки, которые будут воспроизводится в точках остановки. После завершения всех первоначальных настроек оператор передает команду на начало движения Роботу (плате De10-nano).

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

По прибытии в точку взаимодействия с посетителем, конечную точку маршрута, плата De10-nano передает управление Cubeboard4. Cubeboard4 в свою очередь запрашивает последовательность контента для показа посетителю и ожидает начала взаимодействия. После завершения воспроизведения аудиофайлов и показа картинок, управление передается обратно плате De10-nano, и процесс повторяется снова до тех пор, пока на главном сервере не закончатся маршруты движения, либо пока не придет от оператора управляющий сигнал на остановку.



Заключение

Роботы в современном мире проникают во многие сферы жизни человека. От работы на конвейере на заводе до доставки посылок в дом. Незаслуженно недооцененной сферой, в которую можно интегрировать робота является профессия экскурсовода. В соответсвии с результатами проведенного анализа существующих решений, у каждого из них присутствует ряд своих недостатков. Следовательно, было принято решение разработать собственный прототип, который устранят часть явных недостатков предыдущих разработок и предлагает собственные решения.

В данной работе предложено комплексное решение по разработке электромеханической и программной частей коллаборативной роботизированной платформы. Корпус спроектирован таким образом, чтобы удовлетворять всем поставленным требованиям. Программное обеспечение выполнено в виде независимых модулей, реализованных на двух разных платах. При этом поднят главный сервер с web_интерфейсом для взаимодействия с оператором. На сервере хранится вся необходимая информация для функционирования коллаборативной роботизированной системы, и в частности - карта помещения, построенный маршрут и медиа файлы.

Апробация реализованной роботизированной системы была выполнена как на уровне программной логики, так и на уровнена собранного прототипа на базе платы прототипирования с ПЛИС.

Дальнейшим направлением развития данной работы является реализация и внедрение выявленных во время тестирования новых возможностей по улучшению робота.

В рамках данной работы студентом Арцыбашевой Вероникой были выполнены следующие задачи:

- анализ существующих технических решений в области разработки роботов гидов и коллаборативных роботов помощников;

- проектирование корпуса;

- подключение периферийных устройств;

- разработка модуля управления моторами на языке Verilog;

- разработка алгоритма объезда препятствий;

- обоснование выбора элементной базы объекта разработки и языков программирования;

- обоснование выбора инструментальных и программных средств для решения задач ВКР;

- создание прототипа коллаборативного робота экскурсовода;

- разработка программного модуля для обработки данных с ультразвуковых датчиков на языке Verilog.

Студентом Дмитриевым Сергеем были выполнены следующие задачи:

- анализ существующих технических решений в области разработки роботов гидов и коллаборативных роботов помощников;

- разработка модуля для обработки загружаемых данных по перемещению по заранее заданному маршруту;

- обоснование выбора элементной базы объекта разработки и языков программирования;

- обоснование выбора инструментальных и программных средств для решения задач ВКР;

- создание прототипа коллаборативного робота экскурсовода;

- разработка алгоритма распознавания лиц на видео-потоке;

- разработка модуля получения видео с подключенной к плате камеры;

- разработка web_интерфейса для оператора и серверной части;

- разработка модуля для обработки загружаемых данных по перемещению по заранее заданному маршруту.



Список литературы



Размещено на Allbest.ru

...