ВВЕДЕНИЕ
В конце 1990-х и начале 2000-х годов технология VoiceXML характеризовала передовые технологии интерактивной речи. Пользователь может позвонить в голосовую систему, управляемую меню, чтобы узнать, например, погоду в определенном городе или подтвердить бронирование авиабилета. Аппарат задавал вопросы, и распознавание речи основывалось на оптимальном соответствии ответа вызывающего абонента и меню правильных ответов. С тех пор многое изменилось с точки зрения технологий искусственной речи. Сегодня человек может задавать вопросы "голосовым помощникам", таким как Сири или Алекса, в более открытой форме для получения информации. Однако многое также осталось прежним. Языковая передача информации, как правило, остается фактической целью речевого взаимодействия человека и машины. Более естественный и эффективный коммуникационный интерфейс предполагает интеграцию визуальной информации, аффективных и эмоциональных сигналов и форм совместного внимания между пользователем и машиной. Иными словами, передача лингвистической информации на основе звука, это всего лишь часть проблемы, с которой сталкивается человеко-машинный речевой интерфейс.
МАТЕРИАЛЫ И МЕТОДЫ
Разработка программного обеспечения влечет за собой ряд практических целей и ограничений. Одна из целей разработки программного обеспечения состоит в том, чтобы после сборки робота, можно было быстро протестировать его и запрограммировать для выполнения интересного задания без резкого и кривого обучения. Вторая цель состоит в том, чтобы конструкция системы управления была достаточно гибкой для удовлетворения непредвиденных потребностей пользователей. Проектирование должно также позволить разработчикам делиться друг с другом результатами своей работы. Чтобы решить эти проблемы, будет предоставлено нечто вроде "браузера - операционной системы" или интерпретатора, который отображает то, что мы называем "FluidScript" файлы. Файл FluidScript, это XML-файл, в котором описывается протокол VoiceXML. Дизайн Fluidscript также заимствован из других протоколов, таких как язык разметки синтеза речи, язык разметки поведения и язык разметки восприятия. Интерпретатор разработан для операционной системы Linux, но версии Windows и Apple могут быть доступны по запросу.
Аппаратная система
Оборудование робота с открытым исходным кодом состоит из деталей с 3D печатью, серводвигателей, двух USB-камер, стандартных аудио микрофонов и динамиков, а также системы управления двигателем на базе USB (Arduino). Любой, у кого есть 3D-принтер и доступ к интернет-магазинам, должен иметь возможность построить этого робота менее чем за несколько сотен долларов. Размер головы робота примерно такой же, как у взрослого человека. Обе камеры установлены в виде глаз робота и приводятся в действие поворотным механизмом. Пользователь может легко увидеть, куда направлены камеры - или куда "робот смотрит". Каждая глазная камера робота имеет крышки и брови для передачи зрительных аффективных сигналов, т.е. ценности (брови) и возбуждения (веки). Громкоговоритель для производства речи и вокального звука расположен на задней стороне короткой трубки, а две механические "губы" - на передней части трубки.
При движении губ характерная для результирующего звука, побуждает слушателя перцептивно локализовать звук. Всего голова робота имеет 9 отдельных степеней:
1) наклон глаз
2) правое веко,
3) левое веко,
4) брови над правым глазом
5) брови над левым глазом
6) открытые губы
7) вращение головы
8) повороты головы
9) шея
Конструкция оборудования обеспечивает легкий доступ к двигателям и компонентам и позволяет легко заменять или адаптировать детали в зависимости от потенциальных потребностей пользователя. Разработка робота также включает в себя дополнительный набор рук, хотя основное сосредоточение основывается на голову робота. Поскольку электроника робота использует компьютерные стандарты (USB веб-камеры, стандартный компьютерный аудиовыход, последовательный порт для управления двигателем и тд), программное обеспечение для робота может быть разработано с нуля любым опытным разработчиком или командой.
Приоритетной задачей является создание платформы, которая была бы доступной и легкой в обслуживании для целей взаимодействия исследований и разработки программного обеспечения.
P.s В статье указанные скрипты разработки и HTML файлы, были вырезаны для упрощения статьи
ПРОБЛЕМЫ РАЗВИТИЯ
Надеюсь, что вы сможете представить себе построение некоторых базовых моделей поведения и роботизированных взаимодействий с помощью Fluidscript. Теперь давайте рассмотрим некоторые вопросы.
Одна из проблем заключается в том, что интерпретатор Fluidscript построен для использования внешних программ. Пользователи записывают (и делятся) файлы Fluidscript, программы компьютерного зрения, программы обработки звука и моторные последовательности. Короче говоря, переводчик в основном отвечает за управление двигателем. Переводчику принадлежит последовательный порт, управляющий двигателями робота. Однако переводчик не "владеет" USB-камерами, используемыми в программах технического зрения, и не "владеет" аудиоканалами, используемыми в аудио-программах. То есть, переводчик является всего лишь контроллером трафика, который управляет роботом.
При такой системе управления, основанной на VoiceXML, возникают две проблемы с разработкой поведения роботов:
1) прерывание поведения
2) совместное использование и интеграция датчиков.
“Поведенческие прерывания" означают, что один скрипт запущен, а другой должен переопределить первый скрипт. Вспоминается пример из предварительного исследования с участием робота в школе для детей, страдающих аутизмом. Когда ребенок быстро двигает рукой перед глазными камерами робота, он может лучше всего реагировать с помощью маневра избегания и вокального звука. Или, когда ребенок щекочет подбородок робота, управляющий может захотеть, чтобы он остановился и, например, хихикал. Еще лучше, если робот будет хихикать, продолжая при этом свое прежнее поведение. Как определить прерывания в поведении является проблемой для жесткого пошагового характера Fluidscript-протокола.
Например, скажем, разработчик создает программу распознавания выражений лиц, в которой результаты должны изменить характер голосового вывода аудио-программы (которая уже запущена). Как программа технического зрения может передать информацию в аудио-программу? Создание единой программы, использующей как аудио, так и видео, возможно, но блокирует, например, другие программы от использования видеокамер во время производства речи.
Продолжение скоро будет. Спасибо за внимание!
