Почему использован x264enc, а не аппаратный кодек? В статье специально приведён универсальный программный кодек (x264enc), чтобы пример был доступен на любых платформах, а не только на NVIDIA. Например, тот же робот Unitree B2 поставляется с Jetson только в качестве дополнительной опции, а не в базовой комплектации. В продакшене мы, естественно, перешли на аппаратный кодек. Согласны, об этом стоило явно указать в статье — добавим уточнение.
Почему Wi-Fi вместо wfb-ng? Здесь причина простая: на предприятии уже была развернута Wi-Fi-сеть, и заказчик хотел интегрировать робота именно в существующую инфраструктуру, не создавая отдельную радиолинию. Поэтому весь основной обмен телеметрией и видеопотоками идёт по Wi-Fi. Для задач прямого управления (режим «точка-точка») мы сохранили заводской штатный радиоканал, который изначально предназначен производителем именно для удалённого ручного управления и обеспечивает лучшую пробивную способность и отказоустойчивость.
Почему отказались от ROS? На текущем этапе ROS показался нам избыточным, поскольку полноценного SLAM-картографирования и автономного планирования маршрутов по карте сейчас нет — маршрут задаётся и корректируется по GPS-точкам. Однако, вы совершенно правы: если в будущем понадобится более сложная логика навигации и детализированное картографирование, скорее всего перейдём на ROS.
Что насчёт OpenCV? На самом деле мы активно используем OpenCV. В статье приведены его базовые функции (cvtColor, resize.), но после обнаружения целевого объекта мы используем трекинг с помощью одного из OpenCV-трекеров. Просто этот момент не вошёл в статью, чтобы не перегружать её деталями. Вероятно, в следующих материалах распишем более подробно.
Спасибо за обратную связь! Если вопросов и заинтересованных читателей будет много, мы с удовольствием выпустим отдельный материал, где более подробно разберём интересующие детали.
Что касается стоимости, то на самом деле качественные газоанализаторы и веб-камеры для промышленного применения сами по себе довольно дорогие, и часто установка десятков таких устройств стационарно выходит не дешевле одного автономного робота. Плюс у робота есть большое преимущество — возможность удалённого реагирования на нестандартные ситуации вместо человека.
Конечно, подобные роботизированные системы в России пока находятся на начальном этапе развития. Но мы думаем, со временем спрос на них будет расти, что позволит производителям снизить стоимость.
Рад, что вдохновило! Современные платформы и SDK позволяют многие задачи решать на высоком уровне, оставляя низкоуровневые тонкости(в т. ч. ходьба/езда) на совести производителя платформы.
В нашем случае проект от первоначальной постановки задачи до рабочей версии занял примерно 4 месяца. Первый месяц ушел на обсуждение вопросов с производителем и его модификации(смазка, дальномеры), а также на выбор и закупку дополнительного оборудования и сенсоров, а затем началась основная часть: программирование, тестирование, решение возникших проблем и доработки. Последние недели были посвящены на обучение сотрудников заказчика и первичное тестирование на его территории.
Сейчас робот уже полноценно трудится но пока под наблюдением сотрудников, а мы продолжаем поддерживать систему и постепенно вносим улучшения, исходя из обратной связи от эксплуатации.
Да, проходимость поразительная) У разработчика в ТГК много видео техники в работе.
Отличный вопрос! Давайте разберём по пунктам:
Почему использован x264enc, а не аппаратный кодек?
В статье специально приведён универсальный программный кодек (x264enc), чтобы пример был доступен на любых платформах, а не только на NVIDIA. Например, тот же робот Unitree B2 поставляется с Jetson только в качестве дополнительной опции, а не в базовой комплектации. В продакшене мы, естественно, перешли на аппаратный кодек. Согласны, об этом стоило явно указать в статье — добавим уточнение.
Почему Wi-Fi вместо wfb-ng?
Здесь причина простая: на предприятии уже была развернута Wi-Fi-сеть, и заказчик хотел интегрировать робота именно в существующую инфраструктуру, не создавая отдельную радиолинию. Поэтому весь основной обмен телеметрией и видеопотоками идёт по Wi-Fi. Для задач прямого управления (режим «точка-точка») мы сохранили заводской штатный радиоканал, который изначально предназначен производителем именно для удалённого ручного управления и обеспечивает лучшую пробивную способность и отказоустойчивость.
Почему отказались от ROS?
На текущем этапе ROS показался нам избыточным, поскольку полноценного SLAM-картографирования и автономного планирования маршрутов по карте сейчас нет — маршрут задаётся и корректируется по GPS-точкам. Однако, вы совершенно правы: если в будущем понадобится более сложная логика навигации и детализированное картографирование, скорее всего перейдём на ROS.
Что насчёт OpenCV?
На самом деле мы активно используем OpenCV. В статье приведены его базовые функции (cvtColor, resize.), но после обнаружения целевого объекта мы используем трекинг с помощью одного из OpenCV-трекеров. Просто этот момент не вошёл в статью, чтобы не перегружать её деталями. Вероятно, в следующих материалах распишем более подробно.
Cпасибо за внимание и полезные замечания!
Спасибо за обратную связь! Если вопросов и заинтересованных читателей будет много, мы с удовольствием выпустим отдельный материал, где более подробно разберём интересующие детали.
Что касается стоимости, то на самом деле качественные газоанализаторы и веб-камеры для промышленного применения сами по себе довольно дорогие, и часто установка десятков таких устройств стационарно выходит не дешевле одного автономного робота. Плюс у робота есть большое преимущество — возможность удалённого реагирования на нестандартные ситуации вместо человека.
Конечно, подобные роботизированные системы в России пока находятся на начальном этапе развития. Но мы думаем, со временем спрос на них будет расти, что позволит производителям снизить стоимость.
Рад, что вдохновило! Современные платформы и SDK позволяют многие задачи решать на высоком уровне, оставляя низкоуровневые тонкости(в т. ч. ходьба/езда) на совести производителя платформы.
В нашем случае проект от первоначальной постановки задачи до рабочей версии занял примерно 4 месяца. Первый месяц ушел на обсуждение вопросов с производителем и его модификации(смазка, дальномеры), а также на выбор и закупку дополнительного оборудования и сенсоров, а затем началась основная часть: программирование, тестирование, решение возникших проблем и доработки. Последние недели были посвящены на обучение сотрудников заказчика и первичное тестирование на его территории.
Сейчас робот уже полноценно трудится но пока под наблюдением сотрудников, а мы продолжаем поддерживать систему и постепенно вносим улучшения, исходя из обратной связи от эксплуатации.