Встречайте, Buddy

По словам создателей, робот Buddy станет первым в мире доступным по цене роботом-компаньоном для всей семьи. Его запуск планируется на 2018 год. В этой статье мы поделимся опытом его разработчиков по развёртыванию архитектуры с высокой гибкостью, а также примером расчёта стоимости этого решения.

Blue Frog Robotics — стартап, основанный два года назад в Париже. Сейчас он занимается разработкой Buddy. Разработчики утверждают, что Buddy как социальный робот объединяет и защищает всех членов семьи, взаимодействуя с каждым из них.

В ходе краудфандинговой кампании 2015 года Blue Frog удалось собрать планируемую сумму в размере 100 000 долларов США всего за сутки, а к концу кампании — поднять ее до 620 000 долларов США. Предпродажи продолжились на сайте Blue Frog, и общая сумма достигла 1,5 миллионов долларов США.

Контроль за распространением Buddy останется у Blue Frog Robotics, а продажи робота будут осуществляться через различные региональные сети магазинов. Именно поэтому важно создать систему для учета фактического развёртывания и использования робота Buddy по всему миру. Это обеспечит оптимальный уровень его обслуживания в зависимости от популярности.

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

Во время хакфеста Blue Frog Robotics и Microsoft DX France совместно работали над решением с точки зрения производственной перспективы, о котором вы узнаете ниже.

О роботе BUDDY

Buddy разрабатывался с помощью популярных инструментов (Arduino, OpenCV и Unity 3D), чтобы разработчикам было проще создавать проекты с ним. Кроме того, создатели сейчас реализуют полнофункциональные API. Для взаимодействия с роботом, помимо программного обеспечения, разработчики смогут создавать аппаратные решения.

В комплект входит мобильное приложение-компаньон для членов семьи, чтобы связываться с Buddy на расстоянии, поддерживающее функции видеонаблюдения, видеозвонка и удаленного управления. Оно разработано с помощью C# и Unity 3D, и будет доступно на iOS, Android и Windows.

Особенности Buddy:

• Высота 56 см, вес 5 кг, время автономной работы — 8–10 часов.
• Интегрированный «мозг» — 8-дюймовый умный планшетный ПК со встроенной беспроводной сетью и Bluetooth.
• С помощью платформы Arduino механические компоненты робота выполняют команды «мозга».
• Полную мобильность обеспечивают три колеса и множество датчиков: робот может двигаться, обучаться и взаимодействовать с окружающим миром.
• Технология 3D Vision. С помощью стандартной камеры, ИК-камеры и ИК-лазерного излучателя Buddy с легкостью отслеживает и распознает движения рук и головы, различает объекты, лица, животных, растения и много другое, измеряет глубину объектов в зоне видимости.
• Ультрасовременная технология искусственного интеллекта позволяет распознавать лица, объекты и отслеживать движения.
• Робот умеет слушать, разговаривать и кивать головой.
• Робот обладает индивидуальностью и реагирует на происходящее с помощью широкой гаммы эмоций, что позволяет ему лучше взаимодействовать с членами семьи. Высокий уровень кавайности при проявлении любой эмоции. От холода он даже может застучать зубами!

Типы данных

Buddy отправляет в облако два типа данных.

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

Технические данные и сведения об использовании — это данные, полученные планшетным ПК и картой Arduino с технических индикаторов робота (например, уровень заряда батареи, местоположение, активность серводвигателей). Эти данные отправляются с высокой частотой, не подлежат изменению и записываются в формате JSON. Данные закодированы в системе Base64, что сокращает длину сообщения.

Создание архитектуры

Основные критерии при создании архитектуры: стоимость, масштабирование и безопасность. Поэтому важно минимизировать затраты на инфраструктуру.

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

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

При развёртывании выбранной архитектуры были выделены три области:

• Хранилище больших двоичных объектов: сохранение и восстановление данных из формата двоичных объектов и наоборот с помощью подписи совместного доступа (SAS).
• Сбор сообщений: сбор записей из журнала событий, команд и результатов мониторинга, создание отчетов Power BI.
• Автоматизация: создание всех файлов Azure Resource Manager и сценариев автоматизации для непрерывного развертывания инфраструктуры.

Сбор сообщений: от робота к Power BI

В качестве приемника данных были выбраны концентраторы событий. Чтобы отправлять сообщения в концентраторы событий, каждый Buddy должен получить подпись совместного доступа. SAS передается с помощью Azure Function.

Пример кода Azure Function:

#r "Microsoft.ServiceBus"

using System.Net;
using Microsoft.ServiceBus;
using System.Configuration;

public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log)
{
    log.Info("Generate Shared Access Signature for Event Hub");

    // parse query parameter
    string publisherName = req.GetQueryNameValuePairs()
        .FirstOrDefault(q => string.Compare(q.Key, "publisherName", true) == 0)
        .Value;

    string tokenTimeToLiveParam = req.GetQueryNameValuePairs()
        .FirstOrDefault(q => string.Compare(q.Key, "tokenTimeToLive", true) == 0)
        .Value;

    // Get request body
    dynamic data = await req.Content.ReadAsAsync<object>();

    // Set name to query string or body data
    publisherName = publisherName ?? data?.publisherName;
    tokenTimeToLiveParam = tokenTimeToLiveParam ?? data?.tokenTimeToLive;

    if( publisherName == null)
        return req.CreateResponse(HttpStatusCode.BadRequest, "Please pass a publisherName on the query string or in the request body");

    TimeSpan tokenTimeToLive;

    if( tokenTimeToLiveParam == null)
        {tokenTimeToLive = TimeSpan.FromMinutes(60);}
    else
        {tokenTimeToLive = TimeSpan.FromMinutes(double.Parse(tokenTimeToLiveParam));}

    var appSettings = ConfigurationManager.AppSettings;
    var sas = CreateForHttpSender(
                                appSettings["EH_1_SAS_PolicyName"],
                                appSettings["EH_1_SAS_Key"],
                                appSettings["EH_1_SAS_Namespace"], 
                                appSettings["EH_1_SAS_HubName"], 
                                publisherName, 
                                tokenTimeToLive);

    if (string.IsNullOrEmpty(sas))
            {return req.CreateResponse(HttpStatusCode.NoContent, "No SaS found!");}
        else
            {return req.CreateResponse(HttpStatusCode.OK, sas);}
}

public static string CreateForHttpSender(string senderKeyName, string senderKey, string serviceNamespace, string hubName, string publisherName, TimeSpan tokenTimeToLive)
{ 
            var serviceUri = ServiceBusEnvironment.CreateServiceUri("https", serviceNamespace, String.Format("{0}/publishers/{1}/messages", hubName, publisherName))
                .ToString()
                .Trim('/');
            return SharedAccessSignatureTokenProvider.GetSharedAccessSignature(senderKeyName, senderKey, serviceUri, tokenTimeToLive);
}

Робот отправляет данные в концентратор событий.

С помощью приложения Unity 3D робот получает токен SAS, созданный выше Azure Function:

    ```       
   /// Methode call with StartCoroutine();
    private IEnumerator GetSaS(string publisherName)
    {
        WWW wwwSas = new WWW(string.Format("https://tbrblobsasfunapp.azurewebsites.net/api/EventHubSasTokenCSharp?code=YourAccessKey&publisherName={0}", publisherName));

        yield return wwwSas;

        // check for errors
        if (wwwSas.error == null)
        {
            SaS = wwwSas.text.Trim(new Char[] { ' ', '"' });
            Debug.Log("Get SaS OK: " + wwwSas.text.Trim(new Char[] { ' ', '"' }));
        }
        else
        {
            Debug.Log("Get SaS Error: " + wwwSas.error);
        }
    }
    ```

В функции есть ключ управления концентратором событий:

Данные также отправляются через веб-запрос из Unity. Это эквивалентный cURL:

Данные поступают в концентратор событий Azure:

Далее они обрабатываются через Azure Stream Analytics:

Azure Stream Analytics отправляет копию всех данных в хранилище больших двоичных объектов:

Для поиска данных используется Azure Data Lake Analytics:

Так данные выводятся в Power BI:

Расчёт стоимости инфраструктуры

Чтобы рассчитать стоимость робота, нужно выделить ряд ключевых элементов:

• Число развертываемых роботов: 2200
• Число активных приложений-компаньонов на робота: 2
• Средний объём технических данных и сведений об использовании: 100 КБ
• Средний объём контекстных и профильных данных: 3 МБ
• Частота отправки запросов технических данных и сведений об использовании: 5 минут
• Синхронизация контекстных и профильных данных в день на робота или устройство: 1
• Окончание срока действия токенов SAS: 1 час
• Средняя длительность Azure Functions: 100 мс
• Потребление памяти Azure Functions: 512 МБ

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

Общие совокупные затраты составили 122,1797 долларов США.
Совокупные затраты на 1 Buddy в месяц = 122,1797 / 2200 = 0,05554 долларов США.

Подробный расчёт по каждому пункту затрат можно найти в спойлерах ниже.

Затраты на хранилище Blob для контекстных и профильных данных = 14,8896 долларов США

Для хранения больших двоичных объектов используется «горячее» локально избыточное хранилище.

Набор данных обычно состоит из пяти файлов различных размеров и форматов (.json, .png, cartography). Стоимость хранилища Azure рассчитывается по двум критериям: хранение и доступ. В данном случае стоимость хранения составляет 0,024 долларов США на Гб в месяц. Рассчитаем общую стоимость хранения данных для всех роботов:

Общая стоимость хранения = число развертываемых роботов * средний объем контекстных и профильных данных * стоимость хранения на Гб = 2200 * 0,003 * 0,024 = 0,1584 долларов США.

Стоимость доступа зависит от типа операции, и каждый месяц точный тип и число операций установить трудно. Поэтому берём для расчета максимальную стоимость.

Расчетное число операций на робота или устройство: 10
Общее число операций в месяц = число развертываемых роботов * (число активных приложений-компаньонов на робота + 1) * расчетное число операций на робота/устройство * 31 = 2200 * 4 * 10 * 31 = 2 728 000 операций.

Общая стоимость доступа = общее число операций в месяц / 10000 * 0,054 = 14,7312 долларов США.

Затраты на хранилище больших двоичных объектов для контекстных и профильных данных = 14,8896 долларов США.

Затраты на концентраторы событий = 22,55 долларов США

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

Стоимость концентраторов событий рассчитывается исходя из числа входящих событий и единиц развертываемой пропускной способности. Чтобы установить пропускную способность, рассчитаем количество Мб/секунду на входящее событие, отправляемых роботами.

Мб/с на входящее событие = средний объем технических данных и данных об использовании (в Мб) * число развертываемых роботов / частота отправки запросов технических данных и данных об использовании в секундах = 0,1 * 2200 / 300 = 0,7333 Мб/с.

Для показателя пропускной способности в одну единицу лимит ограничен в 1 Мб/с на входящее событие. Здесь число входящих запросов на 27% ниже лимита, поэтому нам нужна всего 1 единица пропускной способности. Теперь рассчитаем число входящих событий, отправляемых роботами.

Число входящих событий = минут в день / частота отправки запросов технических данных и сведений об использовании * число развертываемых роботов * дней = 1440 / 5 * 2200 * 31 = 19 641 600 событий.

Стоимость входящих событий = число входящих событий/ 1 000 000 * 0,028 = 0,55 долларов США.

Стандартная единица пропускной способности стоит приблизительно 22 доллара США в месяц, а совокупные затраты на использование концентраторов событий составляют:

Затраты на концентраторы событий = 22 + 0,55 = 22,55 долларов США.

Затраты на Azure Functions = 1,1094 долларов США

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

Стоимости Azure Functions рассчитывается на основе времени выполнения и общего числа выполнений. Наш токен SAS действует 1 час, поэтому каждая функция вызывается 24 раза в сутки на робота или приложение. Функции для доступа к большим двоичным объектам вызываются роботами или приложениями. Функции для доступа к концентраторам событий вызываются только роботами.

Совокупное число выполнений = ((число развертываемых роботов + число развертываемых роботов * (число активных приложений-компаньонов на робота) * 24 * дней) + ((число развертываемых роботов * 24 * дней) = ((2200 + 2200 * 2) * 24 * 31) + (2200 * 24 * 31) = 4 910 400 + 1 636 800 = 6 547 200.

Совокупные затраты на выполнение = (6 547 200 — 1 000 000) / 1 000 000 * 0,20 = 1,1094 долларов США.

Инструмент для мониторинга Azure Functions на портале Azure помог рассчитать среднее время выполнения. В данном случае это 80 мс. Объём памяти функций составляет 512 Мб. Эта информация помогла в расчёте стоимости времени выполнения.

Потребление ресурсов (в секундах) = выполнения * время выполнения (в секундах) = 6 547 200 * 0,08 = 523,776 с.

Потребление ресурсов (Гб-с) = потребление ресурсов, преобразованное в Гб * время выполнения (в секундах) = 512/1 024 * 523 776 = 261 888 Гб-с.

Потребление ресурсов, подлежащее оплате = потребление ресурсов — ежемесячная скидка = 261 888 — 400 000 = 0 Гб-с.

Затраты на потребление ресурсов каждый месяц составляют 0 долларов США!

Затраты на Azure Functions = совокупные затраты на выполнение + ежемесячные затраты на потребление ресурсов = 1,1094 долларов США.

Затраты на Stream Analytics = 25,0281 долларов США

Стоимость Stream Analytics зависит от объема обрабатываемых данных и от числа модулей потоковой передачи, требуемых для обработки.

Объём данных, обрабатываемых потоковой передачей = средний объём технических данных и данных об использовании (в Мб) * число развёртываемых роботов * частота отправки запросов технических данных и данных об использовании (в днях) * дней = 0,1 * 2200 * 288 * 31 = 1 964 160 Мб = 1964,16 Гб.

Затраты на объем обработанных данных = 1 964,16 * 0,001 = 1,9641 долларов США.

Для такого объёма понадобится всего лишь 1 единица потоковой передачи:

Затраты на единицу потоковой передачи = 0,031 * 24 * 31 = 23,064 долларов США.

Затраты на Stream Analytics = затраты на объем обработанных данных + затраты на единицу потоковой передачи = 25,0281 долларов США.

Затраты на хранилище Blob для технических данных и сведений об использовании = 54,7398 долларов США

Хранилище больших двоичных объектов содержит только данные, полученные от Stream Analytics. Общий размер файла больших двоичных объектов в хранилище равен объёму данных, обработанному Stream Analytics.

Стоимость хранения = объем данных, обрабатываемых потоковой передачей * стоимость 1 Гб хранения = 1964,16 * 0,024 = 47,1398 долларов США.

Чтобы рассчитать стоимость доступа, рассмотрим 1 единицу доступа на сообщение, обработанное входящими событиями в концентраторе событий для обновления доступа.

Стоимость доступа = число входящих событий * затраты на операции (на 10000) = 19 641 600 / 10000 * 0,004 = 7,60 долларов США.

Затраты на хранилище Blob для технических данных и сведений об использовании = стоимость хранения + стоимость доступа = 54,7398 долларов США.

Затраты на пропускную способность = 3,8628 долларов США

Здесь подразумеваются затраты на перемещение данных в оба конца ЦОД Azure, а не стоимость сети доставки содержимого или ExpressRoute. Учитывается загрузка данных мобильным приложением. Полагаем, что каждое приложение синхронизируется с целым файлом дважды в месяц.

Объем загруженных данных = средний объем контекстных и профильных данных в Гб * 2 * число активных приложений-компаньонов на робота * число развертываемых роботов = 0,003 * 3 * 2 * 2200 = 39,6 Гб.

Затраты на исходящую передачу данных = (объем загруженных данных — ежемесячная скидка) * затраты на передачу 1 Гб = (39,6 — 5) * 0,087 = 2,5752 долларов США.

Между Azure и роботом передача небольшого объема данных осуществляется множество раз, например, для получения токена SAS. Было решено прибавить к затратам еще 50 %, чтобы покрыть эти расходы.

Затраты на пропускную способность = затраты на исходящую передачу данных + 50% = 2,5752 + 1,2876 = 3,8628 долларов США.

Заключение

Всего за три дня Blue Frog Robotics настроили полнофункциональную внутреннюю систему. Теперь компания сможет наблюдать за развёртыванием и вводом роботов в эксплуатацию после запуска, который скоро состоится.

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

Если вы заинтересованы в развёртывании подобной архитектуры или её компонента, исходный код доступен на GitHub.

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

Автор: Microsoft

Источник