OpenGrall presenta el modo “Ingeniero”: el robot escribe drivers y configura módulos por sí mismo

OpenGrall описал режим «Инженера» — архитектуру, в которой робот по текстовой команде может сам создавать плагины, писать драйверы и подстраивать код под новое железо. Идея не в полной автономии любой ценой, а в том, чтобы переложить рутинную интеграцию на LLM, сохранив контроль у человека.

Как устроены роли В проекте OpenGrall интеллект робота разделён на два контура.

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

«Инженер» включается только по запросу или когда задача требует доступа к разработческим инструментам. Это уже облачная LLM, которой открывают код проекта, конфигурации и документацию. Она не просто генерирует фрагмент наугад, а действует как отдельный агент: изучает структуру плагинов, ищет примеры, редактирует файлы, запускает код в песочнице и задаёт уточняющие вопросы владельцу.

Если команда звучит как «поверни налево», работает Пилот; если как «настрой манипулятор», эстафета переходит Инженеру.

Как работает Инженер Главная идея режима — не писать всё вручную под каждый новый модуль.

Если к роботу подключили, например, сервопривод камеры на ESP32 через WebSocket, владельцу достаточно описать устройство и доступные команды в файле самоописания. После этого Инженер читает проект, сравнивает уже существующие плагины и создаёт новый модуль под конкретное железо. В OpenGrall для этого собран отдельный набор инструментов: поиск документации и рабочих примеров в сети чтение статей, спецификаций и файлов проекта анализ структуры каталогов и уже готовых плагинов точечное редактирование кода и создание новых файлов * запуск и проверка написанного в изолированной песочнице Дальше начинается не «магия одной кнопки», а управляемый цикл разработки.

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

Это особенно важно там, где чисто текстового описания недостаточно. Автор делает ставку не только на подключение новых модулей, но и на более глубокую перестройку системы. В статье приводится пример с навигатором: базовая ручная версия на примерно 1,5 тысячи строк кода может быть заменена на гораздо более объёмную реализацию с плавными траекториями, перестроением маршрута на ходу и меньшим количеством рывков.

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

«Финальное решение остаётся за человеком».

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

Где пределы подхода

Авторы OpenGrall прямо говорят, что первый сгенерированный код не стоит идеализировать. У LLM всё те же хронические проблемы: устаревшие API, лишние зависимости, неверные обёртки и несовместимость с окружением. Разница лишь в том, что агент умеет сам читать логи, перезапускать тесты и вносить правки, пока модуль не заработает.

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

Но для управления походкой гексапода или другими задачами с жёсткими требованиями к скорости и адаптивности одного самогенерируемого Python-кода уже недостаточно. Там, по мнению автора, нужны другие подходы — например, TinyML и обучение в симуляции, где поведение вырабатывается миллионами итераций, а не пишется поверхностно по текстовому запросу.

Что это значит

OpenGrall показывает интересный сдвиг: робот начинает восприниматься не как жёстко прошитое устройство, а как платформа, которую можно дообучать и достраивать текстовыми командами. До полностью самостоятельной робототехники здесь далеко, но для интеграции датчиков, плагинов и отдельных подсистем такой «Инженер» уже сейчас может заметно сократить объём ручной работы — при условии, что последний рубильник всё равно остаётся у человека.