Я хотел написать этот пост год назад, но, как показала практика, тогда было еще рано. А вот сейчас — самое оно.

С самого появления LLM мне было любопытно: справятся ли они с какими-нибудь еще инженерными задачами, помимо генерации кода? Лет шесть назад я сделал DIY-роборуку, о чем написал свою первую статью на Хабре. Самым трудоемким этапом создания руки было конструирование URDF-модели для ROS: нужно было правильно поскейлить все STL-модельки, покрутить их в пространстве, описать степени свободы и соединения. И все это — в неудобном текстовом формате, без возможности накидать хотя бы черновик руками через UI.

В результате эта работа заняла у меня тогда несколько дней. И не потому, что ее настолько много, а потому что она довольно быстро изматывала.

И вот я решил испытать на этой задаче современные LLM. На входе имеем папку со STL-модельками и знание о том, что из них можно собрать аналог роборуки PhantomX Pincher Robot Arm Kit Mark II.

Вот какой промпт я прогнал год назад на Sonnet 4, Opus 4, Gemini 2.5 и GPT-4.1:

Представь, что ты опытный инженер-робототехник. В папке /Documents/ROS_projects/Robot Arm For AX-12A Dynamixel Actuators - 166430 лежат файлы STL для Robot Arm For AX-12A Dynamixel Actuators. Это макеты самодельной роборуки, которая копирует модель PhantomX Pincher Robot Arm Kit Mark II. Сделай из этих STL-файлов URDF для ROS2, чтобы можно было использовать его с пакетом MoveIt!

Не помню, кто из них справился лучше, но вот результат от тогдашнего чемпиона.

Случайные детали выстроены в случайном порядке. Но хотя бы в одну линию!

Сама LLM объяснила свою неудачу тем, что разбирать формат STL нативно она не может и использует python-скрипты, чтобы собрать информацию о соединяемых деталях. Видимо, информации из этих скриптов оказалось недостаточно.

Я тогда расстроился и забросил эту затею. Вернулся к ней только на днях — прошел ровно год.

Я задал точно такой же промпт, но теперь в качестве испытуемых у меня Opus 4.8 и Fable 5.

Начал я с Опуса. Он благополучно нашел информацию по PhantomX Pincher и проделал первую часть неприятной рутинной работы: поскейлил детальки.

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

Но дальше — самое главное. Опус понял, что детальки в STL-файлах повернуты так, чтобы их было удобно печатать, а не собирать. И да, их придется повращать и подвигать. Все это делалось, конечно же, тоже с помощью питонячьих скриптов. Читать STL нативно модель по-прежнему не умеет (да и не должна, наверное).

Ок. Попыхтев еще немного, Опус выдал финальный результат. Вот что получилось:

Уже сильно лучше, чем год назад, но:

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

Ладно. Я включил вместо Опуса его старшего брата — Fable 5 — с запросом: «Посмотри, что тут не так, и поправь».

Fable довольно четко определил проблемы.

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

Я решил не утруждать себя текстовым объяснением и просто послал ему этот самый скриншот с комментарием: «Посмотри на картинку и реши проблему с соединением».

И вот тут Fable превзошел мои ожидания: по скриншоту он абсолютно четко диагностировал проблему.

После исправления получилось следующее:

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

Итого: вместо нескольких дней монотонной и откровенно скучной работы можно получить такую же функциональную 3D-модель всего за пару часов.

В интересное время живем…