Архитектуры
Behavior Trees (деревья поведения) — одна из ключевых архитектур, на которых строится поведение современных автономных роботов. Почему инженеры отказались от конечных автоматов? Как дерево поведения позволяет беспилотнику, наземному роботу или автономной платформе принимать решения в условиях постоянно меняющейся обстановки? В первой части большого инженерного цикла PardAiLab мы подробно разберем историю появления Behavior Trees, их внутреннее устройство, механизм Tick, основные типы узлов, преимущества перед FSM и роль в современных робототехнических системах. Статья основана на научных публикациях, открытых промышленных проектах и многолетней практике разработки автономных систем.
Behavior Trees — одна из самых влиятельных технологий современной робототехники. Если вы когда-либо видели, как четвероногий робот Boston Dynamics самостоятельно обходит препятствия, беспилотный автомобиль перестраивает маршрут, промышленный манипулятор адаптируется к изменению производственной линии или автономный дрон продолжает выполнять миссию после потери GPS, то, скорее всего, за этими действиями скрывается архитектура принятия решений, построенная на деревьях поведения.
Несмотря на огромную популярность этой технологии, в русскоязычной литературе ей уделяется удивительно мало внимания. Большинство публикаций ограничиваются объяснением нескольких типов узлов или демонстрацией простых примеров на библиотеке BehaviorTree.CPP. Однако Behavior Trees — это не библиотека и даже не алгоритм. Это архитектурный подход к проектированию интеллектуального поведения автономных систем.
Сегодня деревья поведения используются в игровой индустрии, робототехнике, промышленной автоматизации, сервисных роботах, исследовательских платформах и проектах на базе ROS 2. Они позволяют строить сложные сценарии поведения, которые остаются понятными человеку, легко расширяются и могут работать совместно с современными системами искусственного интеллекта.
В этой статье мы подробно разберем, почему инженеры постепенно отказались от конечных автоматов, как появились Behavior Trees, из каких компонентов они состоят и почему именно эта архитектура стала одной из основ современных автономных систем.
Представьте беспилотный летательный аппарат, выполняющий задачу по поиску нарушителя.
Первые минуты миссии проходят идеально. Автопилот успешно вывел аппарат в заданный район. Камера обнаружила объект наблюдения. Началось сопровождение цели.
Но затем события начинают развиваться значительно быстрее.
Возникает главный инженерный вопрос.
Как определить, какое действие беспилотник должен выполнить первым?
Продолжать сопровождение?
Вернуться домой?
Игнорировать новую цель?
Попытаться восстановить навигацию?
Подняться выше?
Ожидать решения оператора?
Подобные ситуации возникают практически во всех автономных системах. И чем сложнее становится робот, тем быстрее растет количество возможных сценариев развития событий.
На протяжении нескольких десятилетий основным способом описания поведения машин оставались конечные автоматы (Finite State Machine, FSM).
Идея казалась практически идеальной.
Есть несколько состояний.
Ожидание ↓ Взлет ↓ Полет ↓ Поиск ↓ Сопровождение ↓ Возврат ↓ Посадка
Между состояниями существуют заранее определенные переходы.
Например:
Подобная схема долгое время прекрасно работала.
Она была понятной.
Простой.
Легко реализовывалась практически на любом языке программирования.
Именно поэтому конечные автоматы десятилетиями использовались в промышленности, авиации, космической технике, игровых движках и первых роботах.
Настоящие трудности появились тогда, когда роботы начали самостоятельно принимать решения.
Представим, что теперь беспилотник должен учитывать не четыре события, а пятьдесят.
Каждый новый фактор потенциально влияет на поведение аппарата.
Теперь практически каждое состояние должно знать, как реагировать на десятки различных событий.
Количество переходов начинает увеличиваться не линейно, а практически лавинообразно.
Поиск
↙ ↓ ↘
GPS Цель Связь
↓ ↓ ↓
Сопровождение ← Возврат
↑ ↖ ↓ ↗
Заряд Оператор РЭБ
Подобные диаграммы быстро превращаются в сложную сеть взаимосвязей, которую инженеры нередко называют spaghetti state machine — «автомат из спагетти».
Изменение даже одного условия может потребовать переработки десятков переходов между состояниями.
Добавление новой функции иногда приводит к необходимости перепроектировать практически весь автомат.
Именно этот эффект стал одной из главных причин поиска новой архитектуры поведения.
Интересно, что увеличение вычислительной мощности только усугубило проблему.
Современный робот способен одновременно:
Но чем больше информации поступает в систему, тем сложнее становится определить последовательность действий.
Получается своеобразный парадокс.
Проблемой автономных систем постепенно перестала быть нехватка информации. Главной проблемой стало принятие правильного решения среди множества возможных вариантов поведения.
Именно в этот момент инженеры начали искать архитектуру, которая позволила бы описывать сложное поведение не как огромный граф переходов между состояниями, а как последовательность независимых, логически связанных задач.
Так постепенно родилась идея, которая спустя несколько лет полностью изменила подход к проектированию интеллектуального поведения роботов.
Эта идея получила название Behavior Trees — деревья поведения.
На первый взгляд может показаться, что Behavior Tree работает так же, как обычная блок-схема: один раз запустилось, прошло по веткам и завершилось.
На самом деле это совершенно не так.
Именно здесь находится главное отличие деревьев поведения от большинства других архитектур принятия решений.
Behavior Tree не выполняется один раз.
Оно живет постоянно.
Пока робот включен, дерево непрерывно анализирует окружающую ситуацию и принимает новые решения.
Этот процесс называется Tick.
Представьте обычного человека.
Во время прогулки он не принимает решение один раз на всю жизнь.
Каждую долю секунды мозг повторяет один и тот же цикл.
Behavior Tree работает практически аналогично.
Через определенный интервал времени корневой узел дерева получает команду:
Tick()
После этого дерево начинает обход сверху вниз.
ROOT
│
Tick()
│
┌────────┴────────┐
▼ ▼
Navigation Mission
Такой обход может происходить десятки или даже сотни раз в секунду.
Например:
| Частота | Назначение |
|---|---|
| 5 Гц | простые мобильные роботы |
| 20 Гц | наземные платформы |
| 50 Гц | манипуляторы |
| 100 Гц и выше | контуры управления движением |
Важно понимать, что Tick — это не цикл программы.
Это событие, которое инициирует очередную проверку дерева.
Представим беспилотник.
В момент времени T0 происходит обычный полет.
Mission └── Fly
Через 20 миллисекунд приходит следующий Tick.
Ничего не изменилось.
Дерево снова выбирает полет.
Еще через 20 миллисекунд камера обнаруживает цель.
Следующий Tick полностью меняет маршрут обхода дерева.
Mission ├── Track Target └── Fly
Еще через несколько Tick связь с оператором пропадает.
Mission ├── Lost Communication ├── Return Home └── Track Target
Никаких переходов между состояниями инженер не прописывает.
Дерево самостоятельно принимает новое решение во время следующего обхода.
Каждый узел дерева после выполнения возвращает всего одно из трех состояний.
Задача успешно выполнена.
SUCCESS
Например:
Выполнить задачу невозможно.
FAILURE
Например:
Задача еще выполняется.
RUNNING
Например:
Именно состояние RUNNING делает Behavior Trees такими мощными. Действие может продолжаться множество Tick подряд, пока не завершится успешно или с ошибкой.
Пусть робот должен открыть дверь.
Open Door
Первый Tick.
Рука только начала движение.
RUNNING
Второй Tick.
Замок еще поворачивается.
RUNNING
Третий Tick.
Дверь полностью открылась.
SUCCESS
Если же дверь оказалась заблокированной, дерево получит:
FAILURE
После этого сможет сразу перейти к альтернативному варианту поведения.
Это один из самых непривычных моментов для инженеров, которые раньше работали только с конечными автоматами.
Каждый новый Tick начинается с корня дерева.
ROOT ↓ Mission ↓ Search ↓ Track ↓ Attack
На первый взгляд кажется, что это неэффективно.
Зачем снова проверять верхние узлы?
Ответ прост.
Мир постоянно меняется.
За время выполнения предыдущего Tick могли произойти десятки событий:
Если бы дерево продолжало работу с того же места, где остановилось ранее, оно могло бы просто не заметить эти изменения.
Поэтому каждый Tick начинается заново.
Однако это вовсе не означает, что дерево выполняет всю работу повторно.
Большинство узлов принимают решение практически мгновенно.
Проверить уровень батареи занимает микросекунды.
Проверить наличие цели — тоже.
В результате даже очень большие деревья способны выполняться десятки раз в секунду без заметной нагрузки на процессор.
Главное следствие механизма Tick заключается в том, что робот начинает постоянно реагировать на окружающую среду.
Поведение больше не определяется заранее заданной последовательностью действий.
Оно формируется заново при каждом обходе дерева.
Именно поэтому автономные системы способны практически мгновенно менять свои действия после появления новых обстоятельств.
Behavior Tree не хранит заранее подготовленный сценарий. Оно непрерывно вычисляет, какое действие является наиболее правильным именно сейчас.
В следующей части мы подробно разберем строительные блоки дерева поведения — Sequence, Fallback (Selector), Parallel, Decorator, Action и Condition. Именно эти узлы позволяют из небольших логических элементов собирать сложное поведение современных автономных систем.
Если представить Behavior Tree в виде конструктора LEGO, то все поведение робота собирается из небольшого набора универсальных элементов.
Это одна из главных причин популярности данной архитектуры.
Инженеру не приходится создавать новый механизм принятия решений для каждой задачи. Вместо этого он комбинирует стандартные узлы, каждый из которых выполняет очень простую функцию.
Практически любое дерево поведения — от промышленного манипулятора до автономного беспилотника — строится всего из нескольких типов узлов.
Любое дерево начинается с единственного корневого узла.
ROOT │ ▼ Mission
Сам по себе Root ничего не делает.
Его единственная задача — получить очередной Tick и передать его первому дочернему узлу.
Можно сказать, что Root — это точка входа во всю систему поведения.
Action — это узел, который действительно что-то выполняет.
Именно здесь происходит взаимодействие с окружающим миром.
Например:
TakeOff MoveTo Land Fire ReturnHome
После выполнения Action возвращает один из трех результатов.
| Возвращает | Что означает |
|---|---|
| SUCCESS | действие завершено |
| FAILURE | выполнить действие невозможно |
| RUNNING | действие еще продолжается |
Condition ничего не делает.
Она только отвечает на вопрос.
Истинно ли некоторое условие прямо сейчас?
Например:
Battery > 30% Target Visible GPS Available Operator Connected Wind < 15 m/s
Условие выполняется практически мгновенно.
Поэтому оно никогда не возвращает RUNNING.
| Ответ | Результат |
|---|---|
| Да | SUCCESS |
| Нет | FAILURE |
Это очень важное отличие Condition от Action.
Sequence — один из самых часто используемых узлов.
Он означает:
«Выполняй задачи одну за другой. Если одна из них завершилась ошибкой — остановись».
Схематично это выглядит так.
Sequence ├── TakeOff ├── Navigate ├── Search └── Land
Работа Sequence очень проста.
| Шаг | Что происходит |
|---|---|
| 1 | Выполняется первый ребенок |
| 2 | Если SUCCESS → следующий |
| 3 | Если FAILURE → Sequence завершается ошибкой |
| 4 | Если RUNNING → Sequence возвращает RUNNING |
Фактически Sequence похож на логический оператор AND.
Все действия должны успешно завершиться.
Mission
└── Sequence
├── Arm Motors
├── TakeOff
├── Fly To Target
└── Capture Photo
Если аппарат не смог взлететь, до фотографирования дело вообще не дойдет.
Этот узел долгое время назывался Selector.
Сегодня во многих библиотеках используется название Fallback.
Логика его работы противоположна Sequence.
Он говорит:
«Попробуй первый вариант. Если не получилось — переходи к следующему.»
Fallback ├── GPS Navigation ├── Visual Navigation ├── Manual Control └── Emergency Landing
Порядок работы следующий.
По сути это аналог логического оператора OR.
Допустим, беспилотник должен определить свое местоположение.
Determine Position
└── Fallback
├── GPS
├── Visual Odometry
├── SLAM
└── Dead Reckoning
Если GPS работает — используются спутники.
Если GPS потерян — дерево автоматически перейдет к Visual Odometry.
Если камеры также недоступны — можно использовать SLAM или инерциальную навигацию.
Никаких дополнительных переходов между состояниями писать не требуется.
Очень часто инженеры объединяют проверку условий и действия в одной последовательности.
Sequence ├── Battery OK? ├── GPS Available? ├── Arm Motors ├── TakeOff └── Mission
Если хотя бы одно условие не выполнено, выполнение остановится автоматически.
Это делает дерево очень читаемым.
Даже человек, впервые увидевший такую схему, почти сразу понимает логику работы системы.
Интересно, что большинство современных Behavior Tree библиотек содержит значительно больше типов узлов — десятки, а иногда и сотни.
Однако практика показывает, что около 90% поведения автономных систем можно построить всего на четырех базовых элементах:
Остальные узлы лишь делают дерево компактнее, удобнее для повторного использования или повышают эффективность выполнения.
Главная сила Behavior Trees заключается не в количестве доступных узлов, а в том, что из нескольких простых строительных блоков можно собрать практически любое поведение автономной системы.
В следующей части мы познакомимся с более продвинутыми элементами — Parallel, Decorator, Reactive Sequence, Reactive Fallback и механизмом Blackboard, который позволяет различным ветвям дерева обмениваться информацией и совместно принимать решения.
До этого момента мы рассматривали только базовые строительные блоки Behavior Trees. Уже их достаточно для построения большинства сценариев поведения.
Однако современные автономные системы значительно сложнее.
Робот может одновременно двигаться, анализировать видеопоток, следить за уровнем заряда батареи, избегать столкновений и получать новые команды оператора.
Для подобных задач появились специальные типы узлов, значительно расширяющие возможности дерева поведения.
В реальном мире робот редко выполняет только одну задачу.
Во время полета беспилотник одновременно:
Последовательно выполнять эти действия невозможно.
Для таких случаев используется узел Parallel.
Parallel ├── Flight Controller ├── Vision ├── Collision Avoidance ├── Telemetry └── Battery Monitor
Важно понимать, что Parallel далеко не всегда означает настоящий параллелизм на уровне потоков процессора.
В большинстве реализаций Behavior Tree дочерние узлы просто получают Tick во время одного цикла обхода дерева.
Для инженера это выглядит как одновременная работа нескольких подсистем.
Decorator можно представить как оболочку вокруг другого узла.
Он не выполняет самостоятельную задачу, а изменяет поведение дочернего элемента.
Например:
Retry └── Connect Radio
Если соединение не удалось установить с первого раза, Decorator автоматически повторит попытку несколько раз.
Другой пример.
Timeout 10 sec └── Search Target
Если поиск продолжается слишком долго, выполнение будет остановлено независимо от состояния дочернего узла.
Часто используются Decorator следующего типа:
Последний вариант особенно интересен.
Он меняет SUCCESS на FAILURE и наоборот.
NOT(Target Visible)
Без написания дополнительного кода.
Обычный Sequence после получения RUNNING продолжает выполнение с текущего узла.
Reactive Sequence работает иначе.
При каждом новом Tick он снова начинает проверку с самого первого дочернего элемента.
Это кажется незначительной деталью, однако именно она делает автономную систему действительно реактивной.
Представим беспилотник.
Reactive Sequence ├── Battery OK? ├── Link Available? ├── Fly To Target
Аппарат уже летит к цели.
Во время очередного Tick батарея резко разряжается.
Reactive Sequence немедленно обнаружит изменение.
В результате выполнение команды полета будет остановлено еще до завершения движения.
Если бы использовался обычный Sequence, робот мог бы продолжать движение значительно дольше.
Этот узел особенно полезен при выборе между несколькими альтернативами.
Reactive Fallback ├── GPS Navigation ├── Visual Navigation └── Dead Reckoning
Допустим, GPS перестал работать.
Следующий Tick автоматически переключит дерево на Visual Navigation.
Через несколько секунд спутниковая навигация восстановилась.
Reactive Fallback снова вернется к GPS.
Никаких специальных переходов программисту писать не нужно.
До сих пор мы рассматривали узлы как независимые элементы.
Но как один узел может передать информацию другому?
Для этого используется механизм Blackboard.
Blackboard можно представить как общую оперативную память дерева.
Blackboard Target_ID Target_Position Battery_Level Mission_State Operator_Command Wind_Speed
Любой узел может записывать данные.
Любой узел может их читать.
Например:
Vision ↓ Target Position ↓ Blackboard ↓ Navigation ↓ Move To Target
Камера определила координаты цели.
Навигация сразу получила новые данные.
При этом эти две подсистемы вообще ничего не знают друг о друге.
Именно Blackboard обеспечивает слабую связанность компонентов.
Современные библиотеки, такие как BehaviorTree.CPP, используют механизм Ports.
Каждый узел явно объявляет:
MoveTo Input: Target_Position Output: Arrival_Status
Такое решение значительно облегчает сопровождение крупных проектов.
Инженер сразу видит зависимости между различными частями дерева.
Представим, что несколько различных роботов используют одинаковую процедуру возврата домой.
Вместо копирования десятков узлов создается отдельное поддерево.
Return Home ├── Check Battery ├── Build Route ├── Fly └── Land
Теперь любой проект может использовать этот модуль как единый элемент.
Mission Alpha ↓ Return Home
или
Mission Bravo ↓ Return Home
Такой подход резко снижает объем повторяющегося кода.
Современные автономные системы могут содержать не десятки, а тысячи узлов.
Возникает естественный вопрос.
Почему такая архитектура не превращается в хаос?
Ответ заключается в трех инженерных принципах.
Именно эти принципы позволяют строить очень большие системы, остающиеся понятными даже спустя годы эксплуатации.
Behavior Tree — это не просто дерево условий. Это модульная архитектура принятия решений, в которой каждая часть выполняет строго определенную функцию и взаимодействует с остальной системой через четко определенные интерфейсы.
В заключительной части статьи мы сравним Behavior Trees с конечными автоматами, GOAP, HTN и Utility AI, а также рассмотрим, почему деревья поведения стали одной из ключевых технологий современной робототехники и какую роль они могут сыграть в будущем автономных систем и искусственного интеллекта.
Теперь, когда мы познакомились с устройством деревьев поведения, можно ответить на главный вопрос.
Почему практически вся современная робототехника постепенно отказалась от конечных автоматов?
Ответ не связан с производительностью компьютеров.
Современные процессоры без труда способны выполнять и конечные автоматы, и деревья поведения.
Причина заключается исключительно в инженерии программного обеспечения.
Behavior Trees позволяют проектировать сложные автономные системы значительно проще, быстрее и безопаснее.
| Критерий | FSM | Behavior Trees |
|---|---|---|
| Расширяемость | Низкая | Очень высокая |
| Повторное использование компонентов | Практически отсутствует | Есть |
| Количество переходов | Растет очень быстро | Практически не зависит от размера проекта |
| Читаемость | Снижается с ростом проекта | Сохраняется благодаря иерархии |
| Поддержка несколькими командами | Сложная | Удобная |
| Работа с ИИ | Ограниченная | Естественная интеграция |
| Модульность | Низкая | Очень высокая |
| Реакция на изменение ситуации | Требует большого количества переходов | Происходит автоматически при следующем Tick |
При этом важно понимать, что конечные автоматы вовсе не стали «плохой» технологией.
Для простых устройств они по-прежнему остаются отличным решением.
Если автомат управляет, например, светофором, кофемашиной или автоматической дверью, использование Behavior Tree будет излишним.
Преимущества деревьев поведения раскрываются тогда, когда количество возможных сценариев становится очень большим.
Последние несколько лет активно обсуждается вопрос:
Если появились большие языковые модели и современные нейронные сети, нужны ли вообще Behavior Trees?
На практике ответ оказался положительным.
Сегодня все чаще используется гибридная архитектура, в которой нейронные сети и деревья поведения выполняют совершенно разные функции.
Сенсоры
│
▼
Компьютерное зрение
│
▼
Нейронные сети
│
▼
Обнаружение объектов
│
▼
Behavior Tree
│
▼
Принятие решений
│
▼
Исполнительные механизмы
Нейросеть отвечает на вопросы:
Behavior Tree отвечает совсем за другое.
Таким образом, современные автономные системы все чаще строятся на разделении ответственности.
Искусственный интеллект воспринимает окружающий мир.
Behavior Tree определяет последовательность действий.
За последние два десятилетия Behavior Trees стали одной из наиболее распространенных архитектур управления сложным поведением.
Их можно встретить в самых разных областях.
Во многих случаях деревья поведения работают совместно с другими архитектурами, такими как планировщики маршрутов, системы компьютерного зрения, алгоритмы построения карт и модули управления исполнительными механизмами.
Как и любая инженерная технология, Behavior Trees не являются универсальным решением.
По мере роста проекта появляются новые вызовы.
Именно поэтому современные проекты редко используют только одну архитектуру принятия решений.
Наиболее эффективными оказываются гибридные системы, объединяющие сильные стороны различных подходов.
Автономные системы становятся сложнее с каждым годом.
Количество сенсоров увеличивается.
Появляются новые алгоритмы компьютерного зрения.
Искусственный интеллект способен анализировать огромные объемы информации.
Однако вместе с этим возрастает сложность принятия решений.
Именно поэтому архитектуры поведения приобретают все большее значение.
Behavior Trees позволяют разделить сложную задачу на множество небольших независимых компонентов, каждый из которых легко понять, протестировать и повторно использовать.
Это делает проекты более надежными и значительно упрощает их развитие в течение многих лет.
Behavior Trees нельзя рассматривать как очередной шаблон программирования или специализированную библиотеку для робототехники.
Это фундаментальный архитектурный подход к проектированию интеллектуального поведения автономных систем.
Именно благодаря деревьям поведения современные роботы способны непрерывно анализировать окружающую обстановку, быстро адаптироваться к изменениям и принимать последовательные решения без огромного количества жестко запрограммированных переходов между состояниями.
Сегодня эта технология продолжает активно развиваться. Новые библиотеки, инструменты визуального проектирования и интеграция с системами искусственного интеллекта делают Behavior Trees одной из ключевых архитектур современной робототехники.
При этом деревья поведения вовсе не конкурируют с нейронными сетями или большими языковыми моделями. Напротив, именно сочетание методов восприятия окружающего мира, интеллектуального планирования и архитектур поведения становится основой автономных систем нового поколения.
В следующей статье цикла мы перейдем от теории к практике и подробно рассмотрим BehaviorTree.CPP — одну из самых популярных библиотек для построения деревьев поведения. Мы разберем ее архитектуру, XML-описание деревьев, механизм Blackboard, визуальный редактор Groot 2 и покажем, как с помощью нескольких десятков строк кода можно создать промышленную систему управления поведением автономного робота.
Behavior Trees активно исследуются уже более двадцати лет. За это время появились десятки научных публикаций, несколько крупных библиотек, промышленные инструменты разработки и целые курсы по робототехнике.
Ниже приведены наиболее авторитетные источники, с которых рекомендуется начать глубокое изучение данной архитектуры.
Авторы: Michele Colledanchise, Petter Ögren.
Фундаментальная книга, которая считается главным современным руководством по деревьям поведения. Именно она сформировала единый язык описания Behavior Trees в робототехнике.
О чем книга:
Ссылка:
https://btirai.github.io/
Книга также доступна бесплатно на сайте авторов.
Предварительная научная версия книги.
Практически полностью повторяет опубликенное издание.
https://arxiv.org/abs/1709.00084
Одна из первых крупных публикаций, посвященных использованию Behavior Trees в игровой индустрии.
Именно игровые разработчики первыми столкнулись с проблемой масштабирования поведения сотен автономных агентов.
https://www.gameaipro.com/
Особенно рекомендуется глава, посвященная Behavior Trees.
Авторы рассматривают различные способы построения поведения автономных роботов и сравнивают их между собой.
Поиск:
https://arxiv.org/search/?query=Behavior+Trees+Three+Ways+of+Cultivating+Robot+Behavior&searchtype=all
Интересная работа, посвященная объединению классического планирования и реактивного поведения.
https://arxiv.org/search/?query=Reactive+Planning+Behavior+Trees&searchtype=all
Практические исследования применения Behavior Trees для мобильных манипуляторов.
https://arxiv.org/search/?query=Behavior+Trees+Mobile+Manipulation&searchtype=all
На сегодняшний день самой популярной библиотекой для построения деревьев поведения считается BehaviorTree.CPP, разработанная Давиде Факонтти (Davide Faconti).
Она широко применяется в проектах на базе ROS 2 и поддерживает:
GitHub:
https://github.com/BehaviorTree/BehaviorTree.CPP
Документация:
https://www.behaviortree.dev/
Практически все современные проекты используют визуальное проектирование Behavior Trees.
Для библиотеки BehaviorTree.CPP создан редактор Groot 2.
Он позволяет:
Сайт:
https://www.behaviortree.dev/groot/
Одним из самых известных открытых проектов, использующих Behavior Trees, является стек навигации Navigation2 (Nav2).
Именно здесь можно увидеть промышленное применение деревьев поведения для:
Документация:
https://navigation.ros.org/
Behavior Trees в Nav2:
https://navigation.ros.org/behavior_trees/
Официальные пошаговые руководства.
https://www.behaviortree.dev/docs/intro
На конференциях ROSCon регулярно публикуются доклады по применению Behavior Trees в промышленной робототехнике.
YouTube:
https://www.youtube.com/@roscon
Behavior Trees — лишь один из компонентов современной архитектуры автономных систем. Для более глубокого понимания темы рекомендуется последовательно изучить следующие направления:
Behavior Trees уже давно перестали быть технологией исключительно игровой индустрии. Сегодня это зрелая архитектура, лежащая в основе множества робототехнических платформ, промышленных решений и исследовательских проектов по всему миру.
Понимание принципов работы деревьев поведения становится важным навыком для инженеров, занимающихся автономными роботами, беспилотными летательными аппаратами, мобильными платформами и интеллектуальными системами управления.
Именно поэтому цикл статей PardAiLab продолжится подробным разбором BehaviorTree.CPP, архитектуры ROS 2 Navigation, а затем — сравнением Behavior Trees с GOAP, HTN и другими современными подходами к построению интеллектуального поведения автономных систем.
Напишите, что не сходится в этом материале.
Адрес нужен, чтобы ответить. Другим читателям сообщение не показывается.
Дальше
Новая модель LFM3 от Liquid AI показывает, что будущее искусственного интеллекта — не только в огромных облачных дата-центрах. Разбираем, как компактные модели могут работать прямо на смартфоне без подключения к интернету, помогать инженерам, врачам, операторам БПЛА и другим специалистам, а также почему локальный ИИ становится одним из главных технологических трендов ближайших лет.
