Вступление
Предлагаемая система, которая отслеживает данные внутренней телеметрии и данные внешнего трафика и накладывается в единую систему. Это очень похоже на концепцию умных автомобилей, и система может иметь несколько надстроек в зависимости от использования или требований. Система состоит из двух основных компонентов.
1. Сбор данных телеметрии по CAN-шине.
2. Мониторинг и сбор внешней информации из видеорегистратора.
Вышеупомянутые компоненты затем накладываются в единый фрейм данных и затем сохраняются локально. После установления соединения с облаком данные сбрасываются. Первый вопрос решается с помощью CAN-шины и фонового процесса для публикации данных через регулярные промежутки времени. Вторая часть системы состоит из системы распознавания объектов в своей основе, и ее основная цель - обнаруживать следующее.
1. Плотность движения на дороге.
2. Тип дороги, по которой проезжает транспортное средство.
Оба вышеуказанных параметра получены с использованием распознавания объектов, реализованного в наборе данных IDD.
Последний главный узел объединяет эти две части данных и сохраняет их локально. Только когда подключение к Интернету установлено, данные публикуются в облаке. В этой статье мы узнаем, как решается каждая часть вышеупомянутого варианта использования.
Система обработки зрения (VPS):
VPS отвечает за основные компоненты обработки видео. В основе VPS лежит набор инструментов Intel® Distribution of OpenVINO ™, который выполняет логические выводы. Но перед выводом мы должны обучить модель на конкретном наборе данных.
Общий поток для VPS показан ниже.
Давайте посмотрим на тренировочную перспективу VPS.
Обучение и тестирование (разово):
Набор данных по вождению в Индии использовался для обучения главным образом по двум причинам.
1. Он полностью основан на индийских дорожных условиях.
2. Он имеет некоторые особенности, такие как управляемый и неуправляемый объект.
Набор данных доступен на https://idd.insaan.iiit.ac.in
Наше приложение основывалось на логических выводах в реальном времени на мобильном автомобиле. Это означает, что нам нужна скорость, а не точность. Вот почему в качестве архитектуры распознавания объектов использовалась мобильная сеть ssd. В качестве конвейера для обучения и оценки использовался API распознавания объектов Tensorflow. Давайте пройдемся по всем этапам.
Предварительная обработка. В зависимости от доступного API-интерфейса первым шагом является создание файла tfrecord для всего набора данных. Чтобы подогнать пример кода к нашей структуре каталогов, были внесены некоторые изменения для создания файлов csv и tfrecord.
Обучение: Обучение проводилось в течение примерно 50000 эпох с окончательным значением логарифмических потерь, колеблющимся между 1.0–3.0. Затем из окончательного файла контрольных точек был получен замороженный график вывода.
Примечание. В этой статье не будут подробно рассматриваться технические аспекты обучения. Образец обучающего кода обновлен в репозитории Github.
Результатом обучения были замороженный файл графа вывода, файл контрольной точки, файл метаданных и файл pipeline.config.
Тестирование и вывод с использованием TensorFlow:
Полученный график замороженных выводов был выведен с использованием TensorFlow, и некоторые из примеров изображений показаны ниже.
После завершения обучения и тестирования с использованием tenorflow мы можем перейти к оптимизации и логическому выводу с помощью Intel® Distribution of OpenVINO ™ toolkit.
Из предыдущего процесса мы получаем стандартную папку, в которой хранятся файлы модели. Теперь нам нужно оптимизировать модель с помощью Intel® Distribution of OpenVINO ™ toolkit, а затем сделать окончательный вывод. Оптимизация будет однократным процессом, а окончательный вывод - в режиме реального времени.
Оптимизация с использованием Intel® Distribution of OpenVINO ™ toolkit
Оптимизация модели - важный этап всего проекта. Intel® Distribution of OpenVINO ™ toolkit имеет некоторые встроенные функции для оптимизации модели тензорного потока. Давайте посмотрим на выполняемые шаги.
Предварительные условия:
1. Предполагается, что на вашем ПК установлен комплект инструментов Intel® Distribution of OpenVINO ™. Если нет, просмотрите здесь для всего процесса установки.
2. Замороженный граф вывода вместе с файлом pipeline.config. Это было получено после обучения и замораживания вашей модели.
После установки Intel® Distribution of OpenVINO ™ toolkit перейдите в следующее место.
Примечание. Я использую систему Ubuntu для всего процесса
/ opt / intel / openvino / deployement_tools / model_optimizer
Здесь, в этом месте, у нас есть скрипт Python с именем mo_tf.py. Этот скрипт будет использоваться для оптимизации модели. Для этого нам нужно передать определенные параметры.
1. –input_model: путь к модели ввода. Здесь нам потребуется замороженный граф вывода.
2. –tensorflow_use_custom_operations_config: файл конфигурации, необходимый для пользовательских моделей. Он поставляется с инструментарием OpenVINO, расположенным в следующем каталоге.
/ opt / intel / openvino / deployement_tools / model_optimizer / extensions / front / tf
3. –tensorflow_object_detection_api_pipeline_config: файл pipleline.config, который создается после замораживания пользовательской модели.
4. -o: путь к расположению выходного файла, в котором будут сохранены файлы .xml и .bin.
Процесс оптимизации завершен, и мы получаем два файла. .xml и .bin для нашей пользовательской модели. Это будет использоваться для процесса вывода. Для вывода мы будем использовать механизм вывода.
Мы собираемся использовать Python для реализации механизма вывода. Перед запуском кода давайте посмотрим на различные компоненты, которые мы собираемся использовать.
Документация по механизму вывода доступна здесь.
Реализация механизма вывода с использованием Intel® Distribution of OpenVINO ™ toolkit и Python
Этот раздел будет сосредоточен на двух основных областях.
1. Реализация движка IE
2. Отправка данных с VPS на мастер-узел
Механизм логического вывода - это унифицированный API, обеспечивающий высокую производительность на многих типах оборудования, включая ЦП Intel®, графику процессора Intel®, Intel® FPGA, Intel® Movidius ™ Neural Compute Stick и Intel® Neural Compute Stick 2.
Общий рабочий процесс движка IE упомянут ниже.
1. Прочтите промежуточное представление. Это загрузит в объект IR-файл (.xml и .bin), который был создан ранее на этапе оптимизации.
2. Подготовьте входной и выходной формат: После загрузки мы должны указать входные и выходные конфигурации сети.
3. Создайте основной объект IE. Это создаст основной объект IE, который будет работать с различными устройствами. Плагины должны управляться внутренне, используя это.
4. Скомпилируйте и загрузите сеть на устройство: этот шаг просто загружает сеть на указанное устройство.
5. Установите входные данные: когда сеть загружена, нам нужно сигнализировать входным буферам для загрузки входных и выходных данных.
6. Запуск сети. Теперь сеть должна быть запущена. Это можно сделать двумя способами.
a. Синхронно: один вывод выполняется в один момент времени.
б. Асинхронно: выполняйте асинхронно, проверяйте статус, ждите или укажите обратный вызов завершения.
7. Получение выходных данных. Получение выходных данных сети.
Примечание. Более подробную информацию и документацию по API можно найти здесь.
Https://docs.openvinotoolkit.org/latest/_docs_IE_DG_inference_engine_intro.html
Давайте посмотрим, как именно это реализовано.
В функции initialise_inference () ниже мы просто настраиваем механизм вывода со всеми параметрами, как описано выше.
Основываясь на топологии сети, мы должны определить входные и выходные BLOB-объекты. Наконец, мы вызываем класс процессора, который в точности выполняет сеть, как показано ниже.
В приведенном выше классе сначала мы выполняем сеть, а затем размещаем ограничивающие прямоугольники на основе выходных данных.
Обработка / выполнение происходит в функции processframe, в то время как наложение изображения с ограничивающими рамками и текстом происходит в функции placeBoxes.
Подводя итог всему классу, можно сказать, что код доступен на github в виде файла detect.py.
Затем нам понадобится скрипт Python для драйвера, чтобы управлять этим и обрабатывать входные данные камеры и механизм передачи сообщений. Давайте посмотрим на скрипт camera.py в репозитории, чтобы понять то же самое.
Класс с именем VideoCamera определяется с непараметрическим конструктором. Мы также используем файл конфигурации config.json для инициализации параметров.
Включена возможность предоставления видеопотока в качестве ввода или видеофайла, который можно изменить с помощью файла config.json. В конструкторе мы также инициализируем класс детектора для инициализации механизма вывода.
В функции get_frame () мы получаем наложенное изображение и возвращаем сгенерированный финальный кадр в app.py
Подводя итог сценарию camera.py, мы вызываем detect.py для инициализации и выполнения механизма вывода со всеми параметрами, определенными в config.json, наконец, получив результирующий наложенный фрейм, который возвращается в app.py.
До этого момента мы сосредоточились на обработке визуальных данных без компонента IoT.
Немного сбивает с толку, правда! Расслабьтесь и расслабьтесь, ведь именно здесь все войдет в IoT.
Видео, демонстрирующее некоторые результаты после вывода, показано ниже.
Получение данных телеметрии автомобиля:
Доступ к данным телеметрии автомобиля можно получить через специальный порт, известный как порт OBD-2. Протокол, который использует порт OBD-2, - это сеть Controlled Area или CAN. Мы собираемся использовать крошечное аппаратное устройство для доступа к данным. В идеале имеется 2 типа оборудования.
1. Интерфейс BLE
2. Интерфейс USB
В данном случае мы собираемся использовать интерфейс BLE.
Это устройство подключается к порту OBD-2. Расположение порта варьируется от машины к машине. Обычно он находится в пределах 2 футов ниже рулевого колеса. Обмен данными происходит по протоколу CAN.
Мы используем скрипт Python для получения данных. Для связи мы использовали модуль python-obd.
Https://python-obd.readthedocs.io/en/latest/
В данном случае мы заботимся о 3 параметрах.
1. Обороты двигателя
2. Скорость автомобиля
3. Температура охлаждающей жидкости двигателя.
Затем эти параметры публикуются в теме MQTT. Давайте снова посмотрим на реализованную нами архитектуру MQTT.
Мы используем локального брокера MQTT. В этом случае используется VerneMQ,
В приведенном выше случае наш скрипт python getdata.py является 1-м блоком, брокер VerneMQ - 2-м блоком, а главный узел - скриптом python app.py.
Теперь давайте узнаем, как получаются данные.
Https://gist.github.com/avirup171/f9e3685b5a869f232929655782d94b3c
Мы используем модуль obd для взаимодействия с устройством через bluetooth и клиент paho mqtt для связи с локальным брокером mqtt. Дополнительно json используется для формирования объекта json.
Первоначально мы определяем все обратные вызовы и методы, связанные с MQTT и OBD.
В основной функции мы объявляем обратные вызовы, а также получаем данные конфигурации из файла mqtt_config.json.
В приведенном выше коде on_connect запускается, когда соединение успешно происходит. Как упоминалось ранее, мы можем подписаться на темы MQTT, поэтому в качестве рекомендуемого процесса можно безопасно подписаться внутри метода on_connect, поскольку это позволит нам подписаться при восстановлении соединения.
Выше - реализация обратных вызовов для OBD. Обратите внимание, как client.publish вставлен в один из методов. Эта строка передает данные в главный узел или в этот узел, в зависимости от того, какой из них подписан на тему.
Чтобы выполнить приведенный выше код, вам нужен доступ к физическому транспортному средству, подключение к порту OBD-2 и добавление устройства Bluetooth как RFCOMM. Этот адрес необходимо ввести в файл mqtt_config.json.
На данный момент мы выполнили следующие задачи.
1. Обучение набора данных IDD
2. Оптимизация обученной модели.
3. Реализация механизма вывода
4. Реализация части IoT (OBD и MQTT)
Теперь мы собираемся поработать с главным узлом, который представляет собой приложение-флягу на Python, которое помещает все в один фрейм. Давайте посмотрим на диаграмму ниже, чтобы увидеть, как это работает.
Главный узел просто объединяет два набора данных, полученных в веб-приложении. Мы не будем вдаваться в подробности того, как мы пишем код для веб-приложения, но как это происходит, показано на изображении ниже. Здесь следует отметить, что мы разделили нашу кодовую базу на несколько подмодулей. Это позволяет нам запускать любой требуемый узел. Кроме того, этот метод можно использовать практически для любого веб-приложения компьютерного зрения. Просто убедитесь, что вы правильно обрабатываете все параметры.
Основываясь на изображении выше, давайте посмотрим на код, чтобы сделать вещи более понятными.
Сначала мы импортируем все необходимые зависимости. Flask_mqtt требуется для связи MQTT. Flask_socketio необходим для обновления данных в реальном времени.
Все параметры MQTT получаем из mqtt_config.json
Здесь мы инициализируем разные классы. Обратите внимание на параметры.
Обратные вызовы для MQTT определены выше.
Здесь мы определяем маршруты приложения, а в методе def gen (camera) мы вызываем метод get_frame из объекта камеры, который мы создали ранее. Это отображает кадр камеры в веб-приложении. У нас также есть html-файл, который в этом случае вызывается в методе index. Файл html находится в папке шаблонов.
Это чисто базовый html с socket.io, реализованный с использованием jquery и javascript. app.py является главным узлом, и мы должны запустить этот скрипт только для получения визуального канала. Однако getdata.py, который отвечал за получение данных телеметрии от транспортного средства, является полностью независимым, работает сам по себе и должен запускаться заранее. Хотя его можно вызвать из этого веб-приложения, но это не тема данной статьи. После запуска кода мы получаем хороший исходный код практически без элементов дизайна, отображающий видеопоток, за которым следуют значения RPM и SPEED.
Заключение:
Если вы прочитали всю статью, ОТЛИЧНО !!
У нас буквально была очень длинная статья, показывающая, как мы можем объединить несколько модулей, включая компьютерное зрение и IoT, в единую платформу.
Подведем итоги тому, что мы узнали из этой статьи.
1. Обучение и выводы с использованием Tensorflow и Intel® Distribution of OpenVINO ™ toolkit
а. Обучение набора данных IDD
б. Замораживание файла модели
c. Оптимизировать модель
d. Реализация механизма вывода
2. Получение данных с автомобиля
а. Получение данных телеметрии с автомобиля
б. Передавать данные как json, используя локально размещенный MQTT
3. Главный узел
а. Получить рамку изображения
б. Получите информацию телеметрии, когда она доступна, подписавшись на тему MQTT
c. Отображение всего содержимого с помощью HTML-страницы
Для тех, кто интересуется фоновой музыкой, ее можно найти здесь. Это довольно плохо, но работает.
Https://soundcloud.com/avirup-basu-833490551
Будущая работа:
Самый важный аспект этого проекта - сделать его максимально удобным для потребителей. В идеале, одним касанием элемента пользовательского интерфейса должно запускаться и настраиваться все приложение, и все это должно выполняться с помощью мобильного приложения. В настоящее время ведется работа, чтобы сделать его более удобным для пользователей. Второй интересный момент - это повторное обучение набора данных с использованием большего количества точек данных. Поскольку у меня не было времени на дополнительные тренировки, но это определенно улучшило бы результаты. Последний объем улучшений - это выполнение некоторой реальной аналитики, чтобы выяснить, как движется автомобиль. С учетом сказанного, скоро будет готовиться еще одна статья о внедрении облака поверх этого.
Более продвинутая версия этого проекта становится известна как VAMS.
