Футурологи часто предвещали будущее, в котором роботы способны сами проектировать и создавать себе апгрейды, прошивать новые модули, настраивать стороннюю технику и даже создавать себе подобных. Насколько это близко к реальности? С текущим темпом развития ИИ вопросы отпадают всё быстрее. Вряд ли кто-то сегодня усомнится, что ИИ способен написать код, самостоятельно отладить и протестировать его. Но с какими ограничениями и рисками придётся столкнуться на практике? Расскажу на примере реализации в проекте OpenGrall.
Постараюсь излагаться общедоступными терминами, дабы уровень осведомленности в теме не препятствовал прочтению, как это было в прошлой статье.
Два режима, две зоны ответственности
Робототехника традиционно сложна. Инверсная кинематика манипулятора с тремя суставами требует решения систем нелинейных уравнений. Фильтр Калмана для слияния одометрии с IMU — это матрицы ковариации, настраиваемые под каждое железо отдельно. SLAM, детекция дверей по облаку точек, стереозрение, калибровка камеры — за каждым термином стоят сотни строк формул и алгоритмов. Добавление нового сенсора означает написание драйвера. Смена колёсной базы — пересчёт модели движения. Каждое изменение влечёт за собой недели разработки.
Появление LLM и VLM изменило правила игры. Модель способна посмотреть на кадр и выдать результат: «дверь, за ней коридор, слева диван, справа человек». Без формул. Без фильтра Калмана. Без каскадов Хаара, гистограмм, HOG-дескрипторов, оптического потока Лукаса-Канаде, RANSAC и минимизации Левенберга-Марквардта.
В OpenGrall мы разделили интеллект робота на две роли: Пилота и Инженера.
Пилот — локальная LLM (например на 1.5B-3В параметров, в перспективе fine-tuned под JSON ответы). Работает на бортовом железе, принимает решения за доли секунды, управляет движением. Имеет доступ на чтение файлов проекта и запись в песочницу — может сохранить заметку или обновить файл памяти. Не может редактировать код системы.
Инженер — облачная LLM (YandexGPT, DeepSeek). Запускается только по необходимости. Обладает полным доступом к коду проекта, конфигурациям и документации. Создаёт плагины, правит существующие, выполняет код в песочнице и взаимодействует с владельцем.
Переключение между режимами происходит автоматически по ключевым словам. «Поверни налево» — Пилот. «Настрой манипулятор» — Инженер.
Инструменты Инженера
Инженер — не чат-бот, которому отдали команду «напиши код». Это полноценный разработчик с набором инструментов:
-
search_web— поиск рабочих примеров, документации и драйверов -
web_fetch— чтение статей и спецификаций -
read_file— изучениеGRALL_SELF.md, текущих возможностей робота и структуры проекта -
list_files— анализ устройства других плагинов -
write_fileиapply_patch— создание и точечное редактирование кода -
execute_code— проверка написанного в изолированной песочнице -
focus_on— визуальная верификация через камеру и VLM -
ask_human— уточняющие вопросы владельцу
При генерации длинного файла Инженер может создать RAG-инструкцию — документ с целями, архитектурой и ограничениями — и опираться на неё в процессе стриминговой генерации. Если этого недостаточно — способен расширить собственный инструментарий, создав плагин get_rag(topic) для использования в будущих сессиях.
Механизмы безопасности: песочница, бэкапы, стриминг
Три механизма обеспечивают безопасность автономного программирования.
Песочница. execute_code запускает код в изолированном окружении с ограниченным набором разрешённых модулей. Системные вызовы запрещены. Процесс выполняется с таймаутом. При ошибке процесс уничтожается, основная система не затрагивается.
Автоматические бэкапы. Перед каждым изменением файла создаётся копия с временной меткой: servo.py.20260429_153022.bak. Откат к любому состоянию выполняется вручную или командой Инженеру. Потеря рабочего кода исключена.
Стриминговая генерация. YandexGPT поддерживает режим потоковой выдачи ответа. Инженер сначала формирует скелет класса с методами-заглушками (при желании человек оценивает архитектуру и утверждает её либо указывает на ошибки). Затем Инженер заполняет методы последовательно, не перегенерируя файл целиком. Такой подход позволяет портировать решения объёмом в десятки тысяч строк — контролируемо, с верификацией на каждом этапе.
Практический пример: интеграция сервопривода
Рассмотрим типичный сценарий. Вы установили сервопривод для поворота камеры, подключили его к отдельной ESP32, зарегистрировали на WebSocket-сервере с ролью servo. Микроконтроллер уже принимает команды — драйвер не требуется. Необходимо лишь описать доступные команды.
Шаг 1. Описание в GRALL_SELF.md. В разделе «Пользовательские модули» указывается:
text
### Сервопривод камерыРоль: servo. Подключение: ESP32, WebSocketКоманды: servo_set(angle) — угол от 15° до 190°Ответ: {"status": "ok", "angle": текущий_угол}Задача Инженера: создать плагин plugins/servo/
Шаг 2. Запуск Инженера. Команда: «Гралл, настрой сервопривод камеры». Инженер читает GRALL_SELF.md, анализирует структуру существующих плагинов через list_files, генерирует скелет класса, получает утверждение человека, затем стримингово заполняет методы и создаёт plugins/servo/__init__.py.
Шаг 3. Калибровка с участием человека. Инженер использует ask_human для получения опорных точек: «Поместите предмет прямо перед камерой по центру — это ноль градусов. Теперь поставьте ладонь/предмет прямо над камерой — это девяносто градусов». Человек выполняет, Инженер фиксирует показания сервопривода в крайних положениях, вычисляет диапазон и записывает калибровочные значения в конфигурацию. При необходимости процедуру можно повторить, меняя угол обзора VLM через focus_on для визуального контроля.
Или если мы говорим о лидаре: Инженер обращается через ask_human: «Измерьте расстояние от центра объектива лидара до правого края корпуса в миллиметрах». Полученное значение записывается в конфигурацию.
Шаг 4. Отладка. Код выполняется в песочнице. При ошибке Инженер читает логи, анализирует причину, вносит исправления и повторяет тестирование.
Шаг 5. Передача владельцу. Инженер докладывает: «Плагин servo создан. Инструмент servo_set(angle) зарегистрирован. Подключите плагин в конфигурации агента». Из соображений безопасности Инженер не интегрирует модуль в основной цикл самостоятельно — финальное решение остаётся за человеком.
Ограничения подхода
Технология не лишена ограничений. Качество первичного кода знакомо всем, кто работал с генеративными моделями: устаревшие форматы API, некорректные обёртки, избыточные зависимости, несовместимость с окружением. Агент способен на автономную отладку — чтение логов, анализ ошибок, пересборку, — но процесс может занимать часы реального времени.
Существуют и архитектурные границы применимости. Для манипулятора генерация кода оправдана: VLM распознаёт суставы, LLM интерпретирует геометрию. Однако для управления походкой гексапода сгенерированный код окажется либо слишком медленным, либо недостаточно адаптивным. Подобные задачи требуют обучения TinyML в симуляции, где нейросеть за миллионы итераций вырабатывает оптимальные паттерны движения. Инженер — мощный инструмент, но не универсальная замена специализированным методам.
Стратегическое значение архитектуры
Выше был показан базовый сценарий — подключение нового устройства. Однако истинная ценность режима Инженера заключается в способности робота переписывать собственные фундаментальные подсистемы.
В OpenGrall реализован SLAM-навигатор (осталось оформить комменты/шапки, привести в единый формат, вот вот будет commit и реструктуризация проекта, Tools переедут в отдельные плагины и кое что ещё) . Полторы тысячи строк ручного кода: A*, BFS, угловатые векторы движения. Робот перемещается по помещению дискретно: остановка — поворот — движение — остановка. Контроль динамических препятствий во время движения возложен на LLM, которая по определению имеет задержку принятия решений.
При подключении Инженера картина меняется. Владелец формулирует задачу: «Сделай движение плавным, убери рывки на поворотах». Инженер выполняет поиск алгоритмов сглаживания траекторий: кривые Безье, potential fields, предиктивный анализ пересечения траектории с динамическими объектами. Генерируется новая версия навигатора объёмом пятнадцать тысяч строк вместо полутора. Угловатые векторы заменяются плавными дугами. Повороты вписываются в движение. Траектория перестраивается на ходу без остановки.
И эта возможность существует уже сейчас. Каждая подсистема робота — навигатор, картограф, обработчик сенсоров — представляет собой отдельный Python-файл. Инженер способен прочитать его, проанализировать и заменить улучшенной версией. Без пересборки системы, без перекомпиляции ядра. Путём создания нового файла с последующим перезапуском агента.
Полторы тысячи строк кода, написанные вручную — не предел возможностей системы. Это стартовый минимум, расширяемый до любого разумного объёма под конкретную задачу, среду и требования владельца.
Почему это безопасно
Пилот изолирован от редактирования кода системы. Инженер работает в песочнице с ограниченным набором модулей и таймаутом. Каждое изменение файла предваряется автоматическим бэкапом. Генерация кода выполняется пошагово, с верификацией на каждом этапе. Финальное решение об интеграции принимает человек.
Заключение
Робот перестаёт быть связкой «железо + софт, написанный программистом». Он трансформируется в платформу, способную настраивать себя по текстовому описанию от владельца. Ручное написание драйверов уходят в прошлое — не потому что создана библиотека для их решения, а потому что LLM и VLM работают с задачей иначе: через семантику вместо формул.
Это не отказ от программирования. Это переход на новый уровень абстракции, где рутину берёт на себя робот, а человек оставляет за собой принятие решений.
Общая статья об архитектуре OpenGrall: Максимально эффективная интеграция ИИ в робототехнику
Исходный код: github.com/Ferum93/OpenGrall
ссылка на оригинал статьи https://habr.com/ru/articles/1030526/