Comments 10
Я далек от мира серьезной разработки, но это меня вдохновило. Особенно удивила относительная простота кода, ибо я представлял разработку робота как максимально низкоуровневое 01010011101.
Подскажите, а сколько проект занял времени от момента постановки задачи до реализации версии робота из статьи ?
В итоге, запустили его в продакшн или еще разрабатываете ?
Рад, что вдохновило! Современные платформы и SDK позволяют многие задачи решать на высоком уровне, оставляя низкоуровневые тонкости(в т. ч. ходьба/езда) на совести производителя платформы.
В нашем случае проект от первоначальной постановки задачи до рабочей версии занял примерно 4 месяца. Первый месяц ушел на обсуждение вопросов с производителем и его модификации(смазка, дальномеры), а также на выбор и закупку дополнительного оборудования и сенсоров, а затем началась основная часть: программирование, тестирование, решение возникших проблем и доработки. Последние недели были посвящены на обучение сотрудников заказчика и первичное тестирование на его территории.
Сейчас робот уже полноценно трудится но пока под наблюдением сотрудников, а мы продолжаем поддерживать систему и постепенно вносим улучшения, исходя из обратной связи от эксплуатации.
обогрев каким‑то магическим образом был реализован с помощью основных тяговых приводов
В электрических радиоуправляемых моделях функция торможения реализована через высокочастотную попеременную подачу напряжения в разных направлениях. Может, подогрев сделан именно так, а батарея сама себя разогревает при протекании тока.
Звучит очень круто и вдохновляюще!
Было бы здорово, если вы могли бы раскрыть больше деталей про маршрутизацию на местности, объезд препятствий и избегание столкновений/пересечений с другим транспортом и пешеходами на местности, но и так спасибо за интересный материал.
Правда, лично у меня остался вопрос - такие роботы стоят очень и очень недёшево. При этом он может перемещаться, но не может быть в двух местах одновременно.
Установить стационарно полсотни таких вот газовых анализаторов и несколько десятков вебкамер в ключевых местах не дешевле вышло бы? А даже если нет, не надёжнее ли?
Спасибо за обратную связь! Если вопросов и заинтересованных читателей будет много, мы с удовольствием выпустим отдельный материал, где более подробно разберём интересующие детали.
Что касается стоимости, то на самом деле качественные газоанализаторы и веб-камеры для промышленного применения сами по себе довольно дорогие, и часто установка десятков таких устройств стационарно выходит не дешевле одного автономного робота. Плюс у робота есть большое преимущество — возможность удалённого реагирования на нестандартные ситуации вместо человека.
Конечно, подобные роботизированные системы в России пока находятся на начальном этапе развития. Но мы думаем, со временем спрос на них будет расти, что позволит производителям снизить стоимость.
Интересная статья!
@MyTechnoBlog А почему на jetson'е вы используете программный x264enc а не аппаратный кодек? Он там есть и отлично работает в gstreamer'е. Плюс вместо обычного wifi можно взять более подходящий wfb-ng. Ну и как я понял вы не используете ROS и OpenCV, что тоже странно, так как там почти все вам нужное уже реализовано и протестировано.
Отличный вопрос! Давайте разберём по пунктам:
Почему использован 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пасибо за внимание и полезные замечания!
Сделать мобильного робота автономным? Это просто