[Перевод] Встречайте, Buddy

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

8649edf4917444a39da209eeafe011c1.jpg

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 совместно работали над решением с точки зрения производственной перспективы, о котором вы узнаете ниже.

9388ca877986400db86a4aada72b5ee6.JPG

О роботе 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 реализовано несколько типов шифрования и изоляции данных. Чтобы гарантировать защиту в облаке, передаваемые данные анонимны и возможность их чтения и записи существует только для авторизованных систем.

330e90b4b9ec4c74ac0970d0c3f28f39.jpg

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

  • Хранилище больших двоичных объектов: сохранение и восстановление данных из формата двоичных объектов и наоборот с помощью подписи совместного доступа (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 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();

    // 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);
        }
    }
    ```

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

e66e80fa080548b5adb1613b17c74c15.png

7f3ea21cd6124a16999a020d4573ca90.png

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

d53bc0e5f61e4c8ca16ca64cfe6fda39.png

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

e7d5d801a0e84ff7980833a17fab6f7e.png

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

10224a8ecfa845e5bc62fd540b6de88d.png

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

a93a60805843467aa057f1c7102e2ba9.png

5b6e4fc04f7e47fbb4fc31a0b5697103.png

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

b7fb4592385841518650cb8a240b9cbf.png

5d2a0e3084c64baa9ee9a2fbe0a3ef8a.png

e772008ac5d24b0cb8ff425a8925261d.png

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

372e44ede23a46ffb75369c26f2a6efd.png

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


Чтобы рассчитать стоимость робота, нужно выделить ряд ключевых элементов:
  • Число развертываемых роботов: 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 для бизнеса, в рамках которой можно будет пообщаться с экспертами в области интернета вещей, машинного обучения и предиктивной аналитики.

Комментарии (0)

© Habrahabr.ru