Механизм — это данные, а не код

Поэтому файл приносится вместе с картой {канал: имя в файле}. Судить первый пункт договора будет карта, а не написание имён внутри файла.

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

Путь меша указывается ровно так, как он написан внутри URDF (meshes/frame.stl): файлы приезжают тем же запросом, что и текст механизма, — одна транзакция, один владелец записи. Общий предел на комплект геометрии — 30 МБ.

Принимаются меши подвижных звеньев и опорного — того самого корня дерева, подошвы, на которой механизм стоит. «Подвижное» — это вывод, а не список исключений: звено подвижно, если путь от корня до него содержит хотя бы один не-fixed шарнир (кожух, прикрученный fixed к плечу, едет вместе с плечом и потому подвижен). Не принесённый меш такого звена — отказ; меш прочего неподвижного (кожух, декор) не кладётся, и об этом говорится строкой предупреждения, а не молчанием.

Геометрию импорт не снимает. Запрос без поля meshes — в том числе загрузка одного файла механизма — оставляет уже лежащие меши на месте и говорит об этом строкой. Заменить геометрию можно тем же запросом (поле meshes), снять — только вместе с механизмом.

На бокс уезжают три вещи: текст механизма, таблица имён и принятые меши.

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

Файлы xacro принимаются. Реальные модели ROS почти всегда приходят макросами и включениями — разворачивание идёт до того же единственного судьи. Вместе с файлом механизма присылаются его соседи (включения, макросы, параметры). Аргументы xacro на этом шаге не задаются: берутся умолчания, а объявленные файлом аргументы называются в ответе — у файла с $(arg …) разворачиваний несколько, и мы взяли одно.

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

Разграничение владения записи жёсткое: поле, которое КРУГ URDF выводит сам (тип шарнира, ход, порядок каналов), в паспорте не дублируется — это была бы вторая правда о том же. Паспорт несёт ровно то, чего URDF не может сказать в принципе.

lead_mm умолчания не имеет. Ход винта — свойство ЭКЗЕМПЛЯРА оборудования, не механики. Не назван в паспорте — прямая ось честно остаётся без хода винта (в 3D не поедет, и это видно) вместо того, чтобы поехать по придуманному числу. Образец галереи ewellix_lift ровно в этом положении: программа-пример для него не собрана, потому что lead_mm паспортом не назван.

Чего в паспорте нет и быть не должно — фактов КОНКРЕТНОГО СТЕНДА: слейв, пин, шарнир привода, датум нуля. Узел в каталоге один, стендов, куда его поставят, много; эти числа называет наладчик у железа, а не карточка образца.

Ключ канала паспорта — его ИМЯ (srv0, di0), то же самое, которым его зовут URDF и программа; отдельного порядкового номера паспорт не хранит.

Объявления оборудования в файле нет. Пролог rig({ axes, outputs, inputs }) — вторая запись состава узла — платформа ПЕЧАТАЕТ сама из паспорта и механизма, на место метки // @rig в начале файла. Написать этот пролог рукой нельзя: состав узла жил бы в двух местах сразу и расходился бы молча, как только один из них поправят. Метка бывает и в форме // @rig inline — печать входит прямо в неё, без переноса строки.

Файла нет — программы у узла нет. Не подставляется ни пустой шаблон, ни программа по умолчанию: логика не объявлена, и вывести её из механизма с паспортом не из чего. Это видно строкой на экране узла, а не молчанием.

Файлом программу можно принести не у всякого узла. У образцов, чья программа-пример ВЫЧИСЛЯЕТСЯ из <limit> принесённого механизма (motopos_d500, flir_ptu_d46, ewellix_lift), она остаётся вычисляемой, а не файлом: замените механизм — программа обязана поехать за новыми пределами хода, а статический текст файла этого не умеет. Это граница формата, а не недоделанная функция.

Шестой файл — program.spec.json, и его не пишут руками

Текст program.plc — единственный ИСТОЧНИК; рядом с ним лежит program.spec.json — то же самое, разобранное в шаги. Он нужен потому, что собирает шаги ОДИН движок, и живёт он в браузере: без этого файла узел из каталога пришлось бы сперва открыть в лаборатории и сохранить, иначе играть было нечем.

Это порождённый файл, а не вторая правда. Правят только program.plc, а спеку пересобирают — команда пересборки записана в самом файле, в поле _source. Прогон сверяет её с исходником байт в байт и краснеет, если текст поправили, а спеку не пересобрали.

Пересборки требует и смена СОСТАВА узла в passport.json — каналы, выходы, входы: спека несёт отпечаток обоих входов сразу, текста программы и состава. Поэтому «поправил паспорт — пересобери спеку» — то же правило, что и для текста.

Замкнутую цепь дерево не выражает. У гексапода подвижная платформа держится на шести штангах — это шесть родителей у одного звена, тогда как дерево допускает ровно одного. Сферических шарниров в URDF нет вовсе.

Из этого не следует, что параллельной машине механизма не полагается. 3 породы из 15 объявлены параллельными (Гексапод (платформа Стюарта, 6 ног) · Линейная дельта (3 каретки, уровневая платформа) · Трипод (3-PRS наклонная голова, Sprint-Z3-класс)), и механизм им печатается: их A/B/C наклоняют платформу вокруг её же центра, поэтому совпадение пивотов — правда о машине, а не потеря геометрии. Отказом это было до 06.09, и отказ врал.

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

Токарный станок, наоборот, ложится на дерево отлично — двумя ветвями от станины:

Осторожно, если шпиндель работает и как ось C. Тип шарнира называется один раз: шпиндель — это continuous, вращение без границ. Пределы и подача оси C живут отдельным полем паспорта, а не вторым шарниром на том же валу. Иначе получится одно имя с двумя смыслами — и разъедется не значение, а смысл.

Родитель и origin приходят из структуры даром. Человеку остаются три вещи: тип шарнира, ось и пределы. Дальше — тот же единственный судья и тот же дом, что у принесённого URDF.

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

Ручки: POST /api/automation/rigs/{id}/mechanism/from-step и POST /api/machines/{id}/step. Сегодняшние входы механизма — URDF, xacro и STEP.

Доноры взяты из открытых репозиториев ROS с зафиксированным коммитом и датой загрузки; лицензия и источник указаны рядом с каждым. Все образцы проходят тот же интерфейс приёма, что и ваш файл: образец, не проходящий её, означает ошибку либо в образце, либо в правиле.

Дальше — типы станков и кинематики: какая порода что умеет и почему гексапод программируется движениями, но не режет по G-code.