Моя глава о исследованиях в робототехнике

Этот пост рассказывает о моём пути в робототехнике, начиная с того, как я открыл для себя свою страсть к робототехнике в FRC во время старшей школы в 2015 году, и заканчивая моим временем в качестве научного ассистента в Лаборатории робототехники, ориентированной на человека (HCR) Колорадской школы горного дела с февраля 2021 года по сентябрь 2021 года. Обратите внимание, что с конца 2022 года HCR Lab переехала из Colorado School of Mines в Университет Массачусетса в Амхерсте, вместе со своим сайтом с hcr.mines.edu на hcr.cs.umass.edu.

Предыстория

Я начал учиться на бакалавриате в Colorado School of Mines осенью 2018 года. Моей специальностью была информатика с упором на робототехнику и интеллектуальные системы. А окончил я обучение весной 2022 года.

Мне повезло рано найти своё призвание в жизни. Во время старшей школы я потратил немало времени, чтобы понять, что мне нравится и в чём я могу быть хорош. После некоторых проб и ошибок я смог понять, что моей страстью является информатика. Но именно в это время я также обнаружил, что у меня есть всепоглощающая любовь к созданию через код.

В Mines у меня появилась возможность работать в Лаборатории робототехники, ориентированной на человека (HCR), под руководством д-ра Хао Чжана. Я впервые познакомился с д-ром Чжаном весной 2020 года на его курсе «Human Centered Robotics» (CSCI473), и после хаоса COVID и учебной нагрузки в начале весны 2021 года я начал работать в его лаборатории.

Курс Human Centered Robotics (CSCI473)

Курс Human Centered Robotics (CSCI473) в Mines был одним из немногих курсов за время моего обучения в колледже, оказавших на меня глубокое влияние. Курс преподавал д-р Хао Чжан. Вся наша итоговая оценка по курсу складывалась всего из трёх проектов, каждый из которых ставил сложную задачу и знакомил с базовыми концепциями робототехники. Эти проекты включали:

1. Изучение Robot Operating System (ROS)
2. Обучение с подкреплением для следования робота вдоль стены
3. Понимание роботом человеческого поведения с использованием скелетных представлений

Изучение Robot Operating System (ROS)

Это был первый проект, который нам задали. Проект состоял из трёх задач:

1. Настройка среды разработки
2. Понимание симулятора Gazebo
3. Написание ROS «Hello World»

Для задач 1 и 2 нам нужно было лишь настроить среду разработки и пройти вводный туториал по Gazebo. Это включало:

• Настройку ROS Melodic, которую я делал на своём ноутбуке HP 2011 года, и его было достаточно
• Установку и настройку ROS и Gazebo
• Прохождение руководства gazebosim и руководства e-manual.

Задача 3, с другой стороны, была настоящим вызовом. Нужно было использовать turtlesim и заставить черепаху нарисовать логотип Mines «M»:

Эта задача, хотя и звучала просто, оказалась сложнее, чем выглядела. Этот проект в итоге познакомил меня с концепцией систем с разомкнутым и замкнутым контуром. Полное описание проекта можно посмотреть в csci473-p1.pdf, либо вы можете узнать больше об этом проекте и моём решении на странице проекта ROS Move Turtle.

Обучение с подкреплением для следования робота вдоль стены

Это был второй проект, который нам задали, и один из самых сложных проектов, над которыми я когда-либо работал в колледже. Описание проекта было следующим:

В этом проекте студенты спроектируют и реализуют алгоритмы обучения с подкреплением, чтобы научить автономного мобильного робота следовать вдоль стены и избегать столкновений с препятствиями. Студенты будут использовать симуляцию Gazebo в ROS Melodic для моделирования омнинаправленного мобильного робота по имени Triton и использовать предоставленную карту среды. Студенты будут использовать лазерный сканер дальности на роботе для выполнения восприятия и обучения, при этом робот управляется командами руления и скорости. Студенты обязаны реализовать этот проект на C++ или Python в ROS Melodic, работающем на Ubuntu 18.04 LTS (то есть в той же среде разработки, что и в Проекте 1). Также студенты обязаны написать отчёт, следуя формату стандартных робототехнических конференций IEEE, используя LATEX.

Для алгоритма обучения с подкреплением нам было предписано использовать Q-Learning. Мы также использовали симуляционную среду Gazebo Stingray, предоставленную на курсе. Stingray состоял из модели Triton и логики физики. Нам также предоставили лабиринт, по которому должен был двигаться робот. В целом среда выглядела так:

Я никогда не публиковал своё решение на GitHub или в интернете, потому что оно было не очень хорошим и сильно flawed. Кроме того, заставить код работать в нужной среде довольно сложно и раздражает. Однако у меня есть демонстрационное видео, которое я сдавал на курсе, показывающее моё решение. Посмотреть его можно здесь:

Полное описание проекта можно посмотреть в csci473-p2.pdf

Понимание роботом человеческого поведения с использованием скелетных представлений

Для третьего проекта описание было следующим:

В этом проекте студенты реализуют несколько скелетных представлений (Поставка 1) и используют машины опорных векторов (SVM) (Поставка 2) для классификации человеческого поведения с использованием общедоступного набора данных о действиях, собранного с сенсора Kinect V1. Кроме того, студенты обязаны написать отчёт в формате стандартных робототехнических конференций IEEE с использованием LATEX в Поставке 3.

Этот проект был сложным, но не таким трудным, как второй проект. Основная цель заключалась в использовании данных сенсора Kinect V1 из MSR Daily Activity 3D Dataset и машин опорных векторов для классификации определённых человеческих действий/поведений. Полное описание проекта можно посмотреть в csci473-p3.pdf, либо вы можете узнать больше об этом проекте и моём решении в записи блога Предсказание человеческих действий с использованием LIBSVM.

Заключение по CSCI473

CSCI473 — один из, если не лучший, курс, который я проходил во время бакалавриата в Mines. Все эти проекты многому меня научили и позволили мне иметь классный каталог проектов, на который можно оглядываться и ссылаться в моём резюме. Это также был первый курс, где я чувствовал, что нахожусь на своём месте, поскольку я никогда не был хорош в сдаче тестов, но отлично справлялся с выполнением проектов. Именно благодаря этому курсу я познакомился с д-ром Хао Чжаном, который в итоге помог мне получить должность научного ассистента в Лаборатории робототехники, ориентированной на человека (HCR), в Mines.

Сессия по компьютерным наукам (лето 2020)

Летом 2020 года, между завершением CSCI473 и поступлением в HCR Lab, я прошёл CSCI370 или «Продвинутая программная инженерия» в рамках своей бакалаврской программы по компьютерным наукам в Colorado School of Mines. CSCI370 — это курс, который заставляет студентов проектировать, реализовывать и документировать программные решения для компании. Он позволяет студентам применять знания, полученные на занятиях, к реальным задачам информатики. Подробнее о курсе можно узнать здесь.

В рамках курса вы сами выбираете, над каким проектом/для какой компании будете работать. Курс предоставлял PDF-файлы с описанием каждого проекта и компании. В итоге я решил работать над проектом, опубликованным компанией Lunar Outpost, под названием «Обнаружение проскальзывания колёс в реальном времени и коррекция ошибок для улучшенной лунной навигации». Поскольку название длинное, давайте дадим проекту псевдоним «Обнаружение проскальзывания колёс».

Проблема

Lunar Outpost — это стартап, пытающийся создать автономные лунные роверы. На Луне очень много лунной пыли, которая, как известно, вызывает сильное проскальзывание колёс. Это нежелательно, потому что проскальзывание колёс может привести к тому, что автономные системы потеряют отслеживание своего реального местоположения. На Земле эта проблема решается с помощью GPS-данных для корректировки любого смещения, вызванного проскальзыванием колёс. Но проблема GPS в том, что для его работы необходимо, чтобы 30+ навигационных спутников постоянно вращались вокруг Земли на орбите и передавали уникальные сигналы, позволяющие компьютерам вычислять своё положение. Но на Луне сейчас не существует никакого GPS. Учитывая это, для обнаружения проскальзывания колёс нужно использовать другой метод, отличный от GPS. Более подробный отчёт о проблеме проекта можно посмотреть здесь.

Команда

Этот проект не был простым, поэтому его нужно было делать в команде. Команда состояла из пяти сокурсников из Colorado School of Mines:

Этот проект не был простым, поэтому его нужно было делать в команде. Эта команда состояла из Mehmet Yilmaz (я), Kane Bruce, Braedon O’Callaghan, Liam Williams и Kevin Grant.

Проект требовал от нас знания ROS, C++, Python, Linux, Raspberry Pi и Arduino. У большинства из нас был опыт работы с одной или несколькими из этих технологий, но только у меня был опыт работы с ROS, поскольку я использовал ROS на своём курсе Human Centered Robotics (CSCI473) в весеннем семестре 2020 года. Из-за этого в начале я помогал всем быстро разобраться с ROS и тем, как для него разрабатывать.

Вызовы

В этом проекте было много сложностей. Но самой большой сложностью, с которой мы столкнулись, было отсутствие доступа к настоящему роботу для тестирования. Это было связано с COVID, из-за которого всё перешло в удалённый формат и не позволяло нам работать в лаборатории/зданиях Lunar Outpost. Из-за этого нам пришлось использовать симуляции.

Также мы изучили некоторые академические исследования из WVU Navigation Lab, чтобы получить представление о том, как можно было бы решить проблему проскальзывания колёс для сценария использования Lunar Outpost, что для нас, как для второкурсников и третьекурсников бакалавриата, оказалось сложнее, чем мы ожидали.

Ещё одной проблемой, с которой мы столкнулись, было количество времени, которое у нас было на работу над этим проектом. CSCI370 — это месячный курс. Но сама проблема — это масштабная задача, которую многие компании и учёные пытаются решить/усовершенствовать уже десятилетиями. Так что одного месяца далеко не достаточно, чтобы решить эту проблему. Но, несмотря на все эти сложности, мы продолжали работать и позаботились о том, чтобы выполнить поставленную задачу.

Заключение

После работы над исследованием и разработкой мы пришли к выводу, что практически невозможно точно цифровым способом имитировать правильную физику Луны, поэтому по-настоящему тестировать этот алгоритм в симуляции бесполезно и это не даст какого-либо значимого исследования в области обнаружения проскальзывания колёс в космосе и на Луне. Мы заключили, что настройка подходящей тестовой среды с использованием чего-то вроде песка и реального оборудования, например робота Husky, намного важнее для такого рода исследований. Мы действительно обновили код обнаружения проскальзывания колёс, чтобы он работал как узел ROS, и он функционировал корректно, а также мог быть легко перенесён на реальное оборудование для тестирования. Этот проект позволил мне взять на себя руководящую роль, обучить своих сверстников разработке под ROS и получить опыт работы с Python, ROS и Gazebo, одновременно решая сложную проблему, с которой я никогда раньше не сталкивался. Что важнее всего, этот опыт ещё больше укрепил мою страсть к робототехнике и подтвердил моё желание заниматься исследованиями в этой области, задав основу для того, что должно было произойти дальше в моём робототехническом пути.

Начало в HCR Lab

После завершения CSCI473, моей летней полевой сессии по CS в 2020 году и осеннего семестра 2020 года я решил заняться исследованиями в области робототехники. У меня был такой замечательный опыт и с CSCI473, и с полевой сессией по CS, что я решил, что хочу заниматься исследованиями в HCR Lab. Поскольку я познакомился с доктором Чжаном за год до этого, я решил написать ему письмо и спросить о возможных вакансиях в лаборатории в январе 2021 года. Примерно через 2 недели доктор Чжан проявил интерес, предложил мне варианты исследований и предложил мне роль в лаборатории. Затем я начал работать в лаборатории в феврале 2021 года.

Вводное видео

Вот моё вводное видео, которое я записал через несколько месяцев после того, как начал работать в HCR Lab. Оно было записано в мае 2021 года и рассказывает об исследованиях, на которых я сосредоточусь в HCR Lab летом 2021 года:

Мой проект

В течение всего времени, проведённого мной в HCR Lab, я в основном занимался проектом Triton. Проект Triton — это мобильный робот, разработанный Human Centered Robotics Lab в Colorado School of Mines. Это треугольный наземный робот с омни-колёсами, работающий на NVIDIA Jetson Nano.

Triton, в простом обзоре, состоял из следующих частей:

• NVIDIA Jetson Nano
• Плата-носитель NVIDIA Seed Studio A205
• Arduino Mega
• microSD-карта на 64 ГБ
• Пользовательский корпус, напечатанный на 3D-принтере
• 3 колеса mecanum
• 1 аккумулятор AR
• Пользовательские схемы для оптимизированного распределения питания и проводки
• Камера Intel Realsense D435
• Некоторые светодиоды

Он был спроектирован, собран и изготовлен примерно в 2018–2020 годах как робот в образовательных целях. К тому времени, когда я присоединился, Triton уже был довольно устоявшейся платформой, и лаборатория рассматривала возможность создания новой версии. Однако основной проблемой Triton было его программное обеспечение. Triton мог двигаться, заряжаться и функционировать в базовом смысле, но на самом деле ничего умного не делал. У него даже не было возможности выполнять более сложные движения.

Чтобы начать решать эту проблему, лаборатория организовала зону, где мы могли отслеживать Triton. Для этого они создали область размером 2 метра на 2 метра с 8 камерами Optitrack Flex (инфракрасными) в квадратоподобной конфигурации примерно на высоте 6–7 футов над полом.

Вместе с созданием этой зоны на каждый Triton сверху корпуса были прикреплены три серых шарика-маркера.

С такой настройкой мы фактически построили собственную маломасштабную GPS-систему, которая позволяла нам получать точные координаты Triton в метрах в интересующей нас области. Используя инфракрасные камеры Optitrack и серые сферы Optitrack в треугольной конфигурации, мы могли точно определить координаты Triton в нашей зоне. Это позволило нам применить замкнутую систему для большей точности движения.

Система Optitrack обеспечивала данные о положении и ориентации примерно с частотой 120 Гц и субмиллиметровой точностью при правильной калибровке. Три отражающих маркера Triton образовывали уникальный треугольный рисунок, который система могла отслеживать как жёсткое тело. Система координат была откалибрована так, что (0,0) находилось в центре зоны отслеживания, а оси X и Y были выровнены по геометрии комнаты. Но, несмотря на эти точные данные о позиционировании, Triton всё равно испытывал трудности с движением.

С такой настройкой одной из ключевых функций, которую мы хотели обеспечить для Triton, была возможность перемещаться к конкретной координате. Пользователь или его программное обеспечение могли задать координату (x, y) в пределах интересующей области. Затем робот должен был переместиться к этой координате как можно быстрее, точнее и плавнее. Когда я присоединился, эта функция уже существовала, но работала не очень хорошо. Вот простая анимация, показывающая, как работала исходная логика движения:

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

1. Он очень медленный
2. Из-за него роботу нужно занимать много места, чтобы просто добраться до определённой точки. Это затрудняло использование этого решения, когда несколько Triton перемещались одновременно.

Так почему же происходило такое поведение? Проблема заключалась в том, что Triton сначала поворачивался, изменяя свой alpha, пока не начинал смотреть на целевую точку в пределах определённой погрешности. Затем он резко двигался вперёд, и после того как его theta отклонялась от цели на определённую величину, он останавливался и снова начинал поворачиваться, пока alpha не попадала в допустимый диапазон для целевой точки. Затем он снова ускорялся и продолжал делать это до тех пор, пока не достигал точки. Кроме того, по мере приближения к целевой точке скорость поворота и ускорения становилась всё меньше, чтобы гарантировать, что он не проскочит мимо. В результате Triton двигался неестественно, добирался до целевой точки целую вечность и требовал слишком много пространства только для того, чтобы достичь конкретной цели. Поэтому, учитывая все эти проблемы и то, насколько важной была эта функция для развития проекта Triton, когда я начал работать в HCR Lab, моей первой задачей было разработать более эффективные решения, которые позволили бы Triton лучше навигировать к целевой точке.

Понимая это, я потратил много времени на исследование наилучшего способа решения этой проблемы. Иронично, но я как раз проходил курс под названием Introduction to Feedback Control Systems (EENG307) в Mines. В начале этого курса мы узнали о концепции Open-loop controllers и Closed-loop controllers. Учитывая это и после обсуждения, которое я провёл с преподавателем этого курса и моим умным соседом по комнате, стало ясно, что эта цель — заставить Triton добраться до целевой точки — является задачей системы с обратной связью.

Теперь, после обширного тестирования и исследований, я разработал два различных подхода к управлению для Triton:

Метод 1: Контроллер расстояния и theta

Этот подход использовал два отдельных пропорциональных контроллера, работающих одновременно:

• Контроллер расстояния: вычислял евклидово расстояние до цели и применял пропорциональный коэффициент для определения скорости вперёд/назад
• Контроллер theta: вычислял угловую ошибку между текущим направлением робота и желаемым направлением на цель, применяя отдельный пропорциональный коэффициент для угловой скорости

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

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

Метод 2: Контроллер координат X-Y

Этот подход рассматривал робота как 2D-плоттер с независимым управлением движением по X и Y:

• Контроллер X: Непосредственно управлял движением восток-запад на основе ошибки по координате X
• Контроллер Y: Непосредственно управлял движением север-юг на основе ошибки по координате Y

Реализация независимо вычисляла ошибки по координатам X и Y, применяла отдельные пропорциональные коэффициенты усиления, а затем преобразовывала эти глобальные компоненты скорости в локальную систему координат робота с использованием матриц вращения. Это преобразование было необходимо, потому что омни-колёсная ходовая часть робота требовала скоростей в собственной системе отсчёта, а не в глобальных координатах. Этот метод обеспечивал самые прямые траектории к целям и был значительно быстрее, но курс робота со временем дрейфовал, поскольку не было явного управления ориентацией.

Для метода #1 я подробно рассказал об этом методе в своём блоге про Move Turtle (TurtleSim). Я настоятельно рекомендую вам прочитать этот блог, чтобы получить все детали о том, как в целом работают ПИД-регуляторы, а также о том, как работает метод #1. Я разработал метод #1, используя TurtleSim от ROS, а затем перенёс этот код на Triton и обновил его с учётом более реалистичной среды.

Метод #2 использовал довольно иной, но столь же эффективный подход. Вместо того чтобы думать об ориентации робота и расстоянии до цели, этот метод рассматривает движение как задачу на координатной плоскости. Контроллер непрерывно вычисляет ошибку по направлениям X и Y отдельно. Например, если роботу нужно переместиться из (0,0) в (2,3), он воспринимает это как необходимость исправить ошибку в 2 метра по X и в 3 метра по Y. Два пропорциональных контроллера работали одновременно: один корректировал скорость робота по X на основе ошибки по X, а другой отвечал за движение по Y на основе ошибки по Y. Это создавалo более прямой путь к цели, похожий на то, как движется головка 3D-принтера, и позволяло выполнять плавные диагональные перемещения. Роботу не нужно было явно поворачиваться, чтобы смотреть на цель, что делало этот метод особенно эффективным в тесных пространствах или когда требуется точное позиционирование.

Оба метода оказались значительно быстрее и надёжнее исходного подхода. Чтобы увидеть эти новые методы в действии, посмотрите плейлист Tritons in Action, где показаны все Triton в работе с новыми методами.

То, что раньше занимало 30–45 секунд для простого перемещения из точки в точку, теперь занимало около 8–12 секунд. Что ещё важнее, Triton теперь мог эффективнее ориентироваться в тесных пространствах, что стало полезно для наших сценариев с несколькими роботами.

Трудности разработки и отладки

Реализация этих контроллеров была неочевидной и сопровождалась несколькими серьёзными задачами по отладке:

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

Реальное поведение vs. идеальное поведение: Самой большой проблемой был учёт реальных факторов, которые не появляются в учебной теории управления. Колёса робота имели разные характеристики трения, двигатели не реагировали одинаково, и в цепочке связи от Optitrack к управляющему ПО и далее к Arduino робота всегда присутствовала некоторая задержка. Я потратил недели на настройку пропорциональных коэффициентов и добавление фильтров мёртвой зоны, чтобы учесть эти физические особенности.

Проблемы с колебаниями и устойчивостью: Мои первые реализации страдали от проблем с колебаниями, когда роботы перелетали через цель и начинали покачиваться туда-сюда. Это научило меня важности производных членов в ПИД-регуляторах и необходимости правильной настройки коэффициентов. В итоге я остановился преимущественно на пропорциональном управлении с тщательно подобранными коэффициентами, а не на полном ПИД, поскольку естественного демпфирования системы было достаточно для большинства применений.

Взаимное влияние нескольких роботов: Когда несколько роботов работали одновременно, я обнаружил неожиданные эффекты взаимного влияния. Роботы иногда «боролись» за одно и то же пространство или создавали ситуации взаимной блокировки, когда они бесконечно мешали друг другу. Это побудило меня реализовать механизмы координации и алгоритмы предотвращения столкновений.

Система управления несколькими Triton

Как только я решил проблему перемещения одного Triton, следующей задачей лаборатории стало одновременное взаимодействие нескольких Triton. Это стало одной из моих основных областей работы и в итоге оказалось значимым вкладом в проект.

Изначальная система могла управлять только одним Triton за раз, что сильно ограничивало исследовательские возможности. Лаборатория хотела моделировать сценарии, в которых нескольким автономным транспортным средствам нужно координировать свои перемещения, например когда беспилотные автомобили обмениваются данными друг с другом, чтобы оптимизировать поток транспорта и создавать более качественные карты SLAM (одновременной локализации и построения карты).

Чтобы решить эту задачу, я реализовал многопроцессный подход с использованием библиотеки multiprocessing Python. Каждый Triton получал свой выделенный процесс, который мог работать независимо, но при этом координировался центральной системой управления. Это позволяло нескольким Triton двигаться одновременно, не мешая циклам управления друг друга.

Проектирование архитектуры многороботной системы

Разработанная мной архитектура системы состояла из нескольких ключевых компонентов:

Главный процесс управления: Он служил центральным координатором, обрабатывая взаимодействие с пользовательским интерфейсом, планирование траекторий и высокоуровневую координацию между роботами. Он поддерживал глобальное состояние и распределял команды отдельным процессам роботов.

Отдельные процессы роботов: У каждого Triton был свой выделенный процесс Python, который выполнял:

• вычисления управления PID в реальном времени с частотой около 50 Гц
• связь с аппаратной частью робота (Arduino/Jetson)
• выполнение локальных траекторий и обход препятствий
• отправку статуса обратно в главный контроллер

Обмен через разделяемую память: Я использовал объекты multiprocessing.shared_memory и Queue в Python для эффективного обмена данными между процессами. Это обеспечивало координацию в реальном времени без накладных расходов на сетевую коммуникацию.

Механизмы синхронизации: Чтобы предотвратить конфликты, когда нескольким роботам нужно было координироваться (например, избегать столкновений), я реализовал семафоры и блокировки, которые позволяли роботам запрашивать эксклюзивный доступ к определённым областям рабочего пространства.

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

Система с несколькими Triton открыла совершенно новые исследовательские возможности. Теперь мы могли моделировать:

• сценарии связи между транспортными средствами
• координированное планирование траекторий с обходом препятствий
• поведение роевой робототехники
• SLAM-картографирование с несколькими агентами
• управление построением и поведение следования

Вот как выглядела лабораторная установка с несколькими Triton, работающими одновременно:

Я также разработал удобный интерфейс, который позволял исследователям визуально задавать траектории для каждого Triton. Можно было буквально нарисовать путь, по которому должен следовать каждый робот, и они выполняли бы эти траектории с идеальной координацией. Это было невероятно полезно для подготовки сложных экспериментов без необходимости вручную программировать каждое перемещение.

Система могла одновременно обслуживать до 5 Triton, каждый из которых работал со своими собственными контроллерами PID, при этом координировался через центральную систему управления. Производительность была впечатляющей: все роботы сохраняли индивидуальную точность, работая при этом вместе как команда.

Вот плейлист, показывающий Triton в действии — от управления одним роботом до координации нескольких роботов: Плейлист Tritons in Action

Интеграция датчика глубины и коррекция координат

Ещё одним крупным достижением, над которым я работал, было использование камер глубины Intel RealSense D435, установленных на каждом Triton. Хотя система Optitrack обеспечивала нам невероятно точные данные о положении, я хотел исследовать, как роботы могут использовать собственные датчики для улучшения пространственной осведомлённости и корректировки ошибок координат.

Идея заключалась в том, что Triton могли использовать свои датчики глубины для обнаружения других Triton в своей близости и сопоставления их положений. Это служило бы нескольким целям:

1. Коррекция ошибок: Если в системе Optitrack возникал какой-либо дрейф калибровки или временное перекрытие обзора, роботы могли использовать визуальное подтверждение положений друг друга для поддержания точных систем координат.

2. Улучшенный SLAM: При совместной работе нескольких роботов с датчиками глубины мы могли создавать гораздо более насыщенные карты окружающей среды с избыточными точками данных.

3. Предотвращение столкновений: Обнаружение глубины в реальном времени позволило бы роботам обнаруживать друг друга и избегать столкновений даже в случае задержек связи в центральной системе управления.

Я начал экспериментировать с алгоритмами, которые позволили бы Triton-ам:

• Обнаруживать других Triton-ов, используя их характерную треугольную форму и отражающие сферические маркеры
• Вычислять относительные положения и ориентации с использованием данных глубины
• Сравнивать эти измерения с данными Optitrack для выявления расхождений
• Потенциально корректировать их систему координат в реальном времени для поддержания точности

Эксперименты по компьютерному зрению

Я потратил значительное время на эксперименты с конвейером компьютерного зрения, который работал в несколько этапов:

Обработка данных глубины: Intel RealSense D435 предоставлял как RGB, так и потоки данных глубины. В основном я работал с данными глубины, которые приходили в виде массива измерений расстояния 640x480 с частотой 30 Гц. Первой задачей было отфильтровать эти шумные данные глубины, чтобы извлечь значимую геометрическую информацию.

Попытки обнаружения объектов: Я экспериментировал с многоэтапными алгоритмами обнаружения. У меня был некоторый успех в сегментации изображения глубины, чтобы выявлять объекты на уровне пола (отфильтровывая стены, потолок и т. д.) и искать объекты с правильными характеристиками размера, с примерным основанием 0,3x0,3 метра. Я пробовал использовать обнаружение границ и геометрический анализ для идентификации характерного профиля Triton-а, но результаты были смешанными.

Эксперименты по распознаванию маркеров: Три отражающие сферы на каждом Triton-е казались наиболее перспективной особенностью для обнаружения. Я экспериментировал с алгоритмами обнаружения блобов, чтобы идентифицировать характерный треугольный узор из трех ярких точек на изображении глубины. У меня были многообещающие результаты в контролируемых условиях освещения, хотя это и не было стабильно надежным.

Исследование объединения координат: Я изучал подходы к объединению оценок положения на основе зрения с данными Optitrack, включая базовые реализации фильтра Калмана. Идея заключалась в том, чтобы при наличии данных Optitrack придавать им больший вес, но при необходимости переходить на зрение, хотя мне так и не удалось полностью реализовать это до окончания моей работы в лаборатории.

Проблемы производительности: Оказалось сложной задачей обеспечить выполнение всей этой обработки в реальном времени одновременно с контурами управления робота. Я экспериментировал с подходами к оптимизации, чтобы запускать алгоритмы примерно на 10-15 Гц, не перегружая вычислительные возможности Jetson Nano.

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

Вот видео, как я тестировал алгоритмы компьютерного зрения:

Вот как выглядело изображение с датчика глубины во время моих экспериментов:

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

Документация и сохранение знаний

Одним из моих самых важных вкладов в HCR Lab, и, возможно, тем, которым я больше всего горжусь, было упорядочивание и сохранение всей проектной документации. Когда я присоединился к лаборатории, знания о проекте Triton были разбросаны по нескольким платформам и форматам. Критически важная информация была распределена между:

• Различными учетными записями Google Drive, принадлежащими разным студентам, которые уже выпустились
• Старыми письмами, затерянными во входящих
• Случайными папками Dropbox
• Несколькими репозиториями GitHub
• Репозиториями GitLab с непоследовательной организацией
• Рукописными заметками, которые могли понять только определенные люди

Эта фрагментированная документация была огромной проблемой. Новые студенты тратили недели только на то, чтобы понять, с чего начать, а ценные знания постоянно терялись, когда люди выпускались или покидали лабораторию.

Я взялся решить эту проблему системно. Я потратил бесчисленные часы на поиск каждого фрагмента документации, кода, видео и заметок, связанных с проектом Triton. Затем я организовал все это в централизованный репозиторий GitLab с четкой, логичной структурой.

Централизованная документация включала:

• Руководства по сборке: Пошаговые инструкции по сборке Triton-ов с нуля
• Настройка программного обеспечения: Полные руководства по настройке среды разработки
• Документация по коду: Хорошо прокомментированный код с понятными пояснениями
• Аппаратные спецификации: Подробные перечни деталей, схемы подключения и проекты печатных плат
• Руководства по устранению неполадок: Распространенные проблемы и их решения
• Видеоуроки: Я создал и загрузил обучающие видео на YouTube, включая подробные уроки по калибровке Optitrack:

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

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

Эффект был немедленным и долгосрочным. Новые студенты могли войти в курс дела за дни вместо недель. Созданный мной репозиторий документации до сих пор используется лабораторией, спустя годы после моего ухода. Он стал единым источником истины для проекта Triton и сэкономил бесчисленные часы/дни будущим исследователям.

Наставничество и передача знаний

Одним из самых полезных аспектов моего времени в HCR Lab была возможность наставлять других и делиться знаниями, которые я получил. По мере того как моя работа продвигалась и я становился более опытным в системах Triton, на меня возлагалась все большая ответственность за обучение новых членов команды.

Наставничество для преемников лаборатории

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

Я провел с ними недели, работая в тесном контакте и проходя через:

• Математические основы систем управления PID
• Архитектуру многопроцессной обработки для координации нескольких роботов
• Интеграцию датчика глубины и алгоритмы компьютерного зрения
• Систему документации и способы ее поддержания
• Методы отладки и распространенные режимы отказов

Передача знаний была невероятно тщательной. Мы вместе проходили реальные сеансы отладки, я заставлял их модифицировать и расширять существующий код, и я следил за тем, чтобы они могли самостоятельно собирать новых Triton-ов с нуля.

Программа наставничества для старшеклассников

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

Я разработал комплексную учебную программу, которая охватывала:

Основы информатики:

• Концепции программирования с использованием Python в качестве основного языка
• Введение в объектно-ориентированное программирование
• Понимание алгоритмов и структур данных

Понятия робототехники:

• Как работают датчики и как с ними взаимодействовать
• Управление исполнительными механизмами и моторными системами
• Основы автономных систем и управления по обратной связи

ROS (Операционная система для роботов):

• Понимание системы обмена сообщениями publish/subscribe
• Создание узлов и сервисов
• Работа с файлами запуска и серверами параметров

Практическая проектная работа:

• Мы совместно создали ROS-сервис, который управлял системой светодиодов на голове Triton-а
• Она научилась писать чистый, документированный код, интегрирующийся с нашими существующими системами
• Сервис управления светодиодами, который она создала, стал постоянной частью кодовой базы Triton

Особенно ценным в этом наставничестве было наблюдать за ее прогрессом — от почти полного незнания программирования до внесения значимого кода в активный исследовательский проект. Она прошла путь от вопроса «Что такое переменная?» до самостоятельной отладки проблем связи ROS и написания собственных реализаций сервисов.

Разработанная ею система управления светодиодами позволила исследователям легко менять цвета и узоры светодиодов на голове Triton-а с помощью простых команд ROS. Это может звучать просто, но для этого потребовалось понимание архитектуры ROS, взаимодействия с аппаратным обеспечением и правильных шаблонов проектирования программного обеспечения. Ее вклад до сих пор используется в лаборатории.

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

Сотрудничество в рамках докторских исследований

Одним из самых профессионально вознаграждающих аспектов моего времени в лаборатории была тесная работа с Пэном, аспирантом, чьи исследования были сосредоточены на алгоритмах для самоуправляемых автомобилей. Улучшения программного обеспечения, которые я внес в систему Triton, помогли поддержать его докторские исследования.

Исследования Пэна требовали точной, надежной координации нескольких роботов для моделирования сценариев самоуправляемых автомобилей. До моих улучшений управления движением и многороботных систем эти эксперименты было гораздо сложнее проводить. Роботы были медленнее, менее точными и не могли так эффективно работать вместе.

Мой вклад помог исследованиям Пэна в нескольких областях:

Исследования управления перекрестками: Благодаря улучшенным ПИД-регуляторам и координации нескольких роботов Пэн мог моделировать сценарии перекрестков, где нескольким «транспортным средствам» (Triton) нужно было координировать свои движения. Улучшенные синхронизация и позиционирование сделали эти исследования более осуществимыми.

Связь между транспортными средствами: Разработанный мной фреймворк многопроцессной обработки позволил Пэну реализовать и тестировать протоколы связи между моделируемыми транспортными средствами. Каждый Triton мог принимать решения, одновременно координируясь с другими, подобно тому, как это могут делать самоуправляемые автомобили.

Исследования SLAM и картографирования: Работа по интеграции датчика глубины предоставила Пэну дополнительные данные для его исследований одновременной локализации и картографирования. Наличие нескольких роботов с координированными сенсорными возможностями позволило проводить более комплексные эксперименты по картографированию.

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

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

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

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

Перспектива: эпоха разработки до LLM

Стоит отметить, что вся эта работа была выполнена в до-LLM-эпоху разработки программного обеспечения. Все это происходило в период с 2020 по 2021 год (в основном в 2021), до появления ChatGPT, Claude, Perplexity или инструментов разработки на базе ИИ, таких как Cursor IDE.

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

Это делало процесс разработки значительно более сложным, но и более образовательным. Мне приходилось:

Исследовать всё вручную: Понимание теории ПИД-управления означало чтение учебников и научных статей. Разобраться с преобразованиями координат требовало вручную прорабатывать математику. Каждую концепцию нужно было полностью понять до реализации.

Отлаживать без помощи ИИ: Когда роботы двигались в неожиданных направлениях или колебались вокруг целей, мне приходилось методично прослеживать логику, добавлять отладочный вывод и проверять гипотезы одну за другой. Не было ИИ, который мог бы предложить возможные проблемы или помочь интерпретировать ошибки.

Учиться с первых принципов: Без возможности быстро спросить: «как мне реализовать многопроцессность в Python для робототехники?» — мне приходилось глубоко понимать лежащие в основе концепции. Это заставило меня построить прочный фундамент в параллельном программировании, системах управления и компьютерном зрении.

Документация была критически важна: Поскольку я не мог полагаться на ИИ, чтобы позже объяснить код, мне приходилось писать предельно ясную документацию и комментарии. Эта дисциплина оказалась бесценной при передаче знаний другим.

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

Трудное решение уйти

Как бы сильно я ни любил работу в лаборатории HCR, к концу 2021 года передо мной встал трудный выбор, с которым сталкиваются многие студенты: как сбалансировать несколько возможностей и обязанностей. Я одновременно работал полный рабочий день инженером-программистом в eBay, завершал обучение по специальности компьютерных наук в Mines и участвовал в исследованиях в лаборатории HCR.

Возможность в eBay была значимой; это была моя первая крупная роль инженера-программиста, она дала бесценный опыт в индустрии и обеспечивала мне стабильный доход. Однако попытки совмещать полную занятость, завершение обучения и осмысленный вклад в исследования были просто нежизнеспособны. Нужно было чем-то пожертвовать.

Когда я обратился к доктору Чжану с вопросом о возможности уменьшить учебную нагрузку, чтобы больше сосредоточиться на работе в лаборатории, он решительно отговорил меня от этого. Его рассуждения были разумны: завершение обучения должно быть приоритетом, а опыт работы в eBay будет ценен для моего карьерного развития. Он считал, что отказаться от некоторых курсов ради исследований, хоть это и было заманчиво, может быть не лучшим долгосрочным решением.

Итак, в сентябре 2021 года, после примерно 8 месяцев интенсивной работы в лаборатории, я принял трудное решение отойти от роли научного ассистента, чтобы сосредоточиться на завершении обучения и работе в eBay. На тот момент это было одним из самых сложных профессиональных решений, которые мне приходилось принимать.

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

Размышления и взгляд назад

Теперь, в 2025 году, спустя четыре года, я оглядываюсь на то время со сложными чувствами. Мой карьерный путь увел меня глубоко в веб-разработку и инженерную работу в области ИИ/МО — области, которые оказались невероятно вознаграждающими и открыли огромные возможности для роста и влияния.

И все же во мне есть часть, которая задается вопросом: «а что если». Робототехника была и, честно говоря, до сих пор остается моей настоящей страстью. Есть что-то особенное в работе с физическими системами, когда видишь, как твой код превращается в реальное движение и поведение, — нечто, что веб-разработка и даже работа в ИИ не могут в полной мере воспроизвести.

Иногда я размышляю, что могло бы произойти, если бы я пошел по другому пути. Что если бы я нашел способ остаться в исследованиях по робототехнике? Что если бы я сразу после окончания бакалавриата поступил в аспирантуру? Что если бы я решил отдать приоритет работе в лаборатории, а не опыту в индустрии?

Но я также понимаю, что у каждого пути есть свои компромиссы. Навыки, которые я развил в веб-разработке и ИИ, оказались невероятно ценными. Опыт работы в индустрии научил меня программной инженерии в масштабе, проектированию пользовательского опыта и практическим трудностям создания продуктов, которыми пользуются миллионы людей. Эти опыты в целом сделали меня лучшим инженером.

Работа, которую я выполнял в лаборатории HCR, продолжает влиять на то, как я подхожу к решению задач сегодня. Системное мышление, необходимое для ПИД-систем управления, проявляется в том, как я проектирую петли обратной связи в программных системах. Навыки документирования и сохранения знаний, которые я развил, оказались бесценными в каждой последующей роли. Опыт наставничества и обучения повлиял на то, как я работаю с младшими разработчиками и участвую в обмене знаниями в команде.

И самое важное: этот опыт научил меня, что я процветаю, когда работаю над сложными техническими задачами, имеющими реальное влияние. Будь то оптимизация алгоритмов движения роботов или создание ИИ-систем, помогающих пользователям достигать своих целей, удовлетворение приходит от решения трудных задач, которые действительно важны.

Долговременное влияние

Оглядываясь на опыт в лаборатории HCR, я поражаюсь тому, как многого я достиг за относительно короткое время. Созданные мной системы фундаментально изменили работу платформы Triton, и многие из этих улучшений используются до сих пор. Репозиторий документации, который я создал, стал базой знаний для всего проекта. Отношения наставничества, которые я выстроил, оказали длительное влияние на людей, с которыми я работал.

Но, пожалуй, самое важное — этот опыт показал мне, на что я способен, когда работаю над проблемами, которыми действительно увлечен. За эти восемь месяцев я:

• Улучшил систему управления движением робота, которая ограничивала платформу
• Создал систему координации нескольких роботов с нуля
• Интегрировал возможности компьютерного зрения и слияния данных датчиков
• Создал комплексную систему документации и управления знаниями
• Наставлял нескольких людей и помогал с передачей знаний
• Поддерживал исследования уровня PhD в области автономных транспортных средств

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

Будущее и робототехника

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

Кто знает, что принесет будущее? Навыки, которые я развиваю в области ИИ и машинного обучения, становятся все более актуальными для робототехники. Полученный мной опыт работы в индустрии научил меня строить надежные, масштабируемые системы. Возможно, впереди есть будущее, где эти разные нити моего опыта неожиданным образом соединятся.

Пока что я благодарен за время, проведенное в лаборатории HCR, и за полученный там опыт. Это был формирующий период, который повлиял и на мои технические навыки, и на мое понимание того, какая работа приносит мне наибольшее удовлетворение. Хотя иногда я скучаю по нему, я знаю, что уроки, которые я усвоил, и подходы, которые я разработал, продолжают влиять на все, что я делаю.

Роботы Triton по-прежнему там, по-прежнему служат исследователям, по-прежнему позволяют выполнять важную работу. И это действительно замечательно.