Реализовать вычисление позиции захвата для детали #1
Labels
No labels
bug
construct
design
doc
documentation
duplicate
enhancement
feature
good first issue
help wanted
In Progress
integration
invalid
programming
question
research
schematics
test
wontfix
не срочно
срочно
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: robossembler/framework#1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Нужно использовать какой-то из стандартных сборочных верстаков FreeCAD для добавления позиции захвата.
Механизм работы следующий:
Отредактировать имеющийся скрипт:
Пользователю нужно обеспечить удобный интерфейс для задания разметки
assigned to @openfablab
http://docs.ros.org/en/noetic/api/geometry_msgs/html/msg/Pose.html
Позиция захвата точка с указанием углов поворота
Для задания растояния между пальцами необходима константа просто
По стандарту yaml всё это конфигурируется
Также если реализовывать запись на сервер параметров ROS2 необходимо иметь следующие изменения
Это требут проверки, удобней ли так будет или нет
В настоящий момент позиция определяется автоматически, но не корректно. Приходится подправлять
unassigned @openfablab
assigned to @ius.mark.alex
changed the description
changed the description
changed the description
changed the description
changed the description
changed the description
К вопросу задания позиции захвата.
С одной стороны привязка к конкретной модели гриппера надёжна, с другой стороны несколько сужает пространство выбора. Ведь, задачу можно решать разными методами.
Мне нравится идея использовать какой-то существующий (желательно используемый конструкторами) верстак, потому что задание относительных позиций - наважно чего - деталей, подсборок, захватного устройства, стола или кондуктора - это всё частные случаи сборок. Можем назвать их для удобства временными сборками. Временные сборки - это подсборки с использованием специальных приспособлений, которые не войдут в итоговое изделие. Однако, у них есть ряд свойств - они обеспечивают процесс сборки. И у них будут определённые свойства - ведь часто эти вспомогательные элементы(типа захватного устройства) являются подвижными. Даже элементарное размещение двух кубиков на столе - это тоже временная сборка двух кубиков и стола - ведь два кубика не могут просто висеть в пространстве. Эти временные подсборки должны быть как-то заданы. Как их задать? Самый простейший вариант - просто задать вспомогательный элемент временной сборки - добавить в сборку стол, гриппер, кондуктор. Но тогда у нас в значительной степени сокращается свобода манёвра - позиции кубиков заданы жёстко, хотя мы понимаем, что поставить их можно на любое плоское место - лишь бы не свалились. По идее, для обеспечения гибкости робот должен понимать, что два кубика, лежащих на столе, и два кубика, лежащих на торце цилиндра, это оба варианта валидной сборки. То есть нужно задавать не напрямую оснастку, а какие-то другие параметры - например, свойства сопряжения с учётом обеспечения стабильности положения. Чтобы у нас роботы могли использовать свои грипперы или какие-то другие свои части для создания ситуативных временных подсборок. Как это делают фрактальные тиски, но более умные.
assigned to @brothermechanic
@movefasta @solid-sinusoid
как насчет обойтись для начала вообще без программирования, а на имеющихся плагинах как assembly4, Frames, и пр. "протоптать" тех процесс?
Думаю можно. Программирование в любом случае необходимо. Т.к. цель у нас обеспечить наибольшую автономность какую можем обеспечить. Дабы другие наши направления не застаивались в ожидании какого-либа препроцессинга, можно ввести упрощённый, основанный на уже готовых плагинах. Но этот инструмент если и вводить, то это не решение issue, так что, следует ввести генерацию захватных позиций так быстро как это возможно, потом заменяя уже своим разработанным модулем. @brothermechanic считай готовый плагин просто как временную затычку которые следует пока удерживать, пока реальный инструмент не будет готов. Моё мнение. Что считает @movefasta?
Что подразумевается под программированием? Программирование робота?
Сейчас задачу задания последовательности сборки и генерации PDDL на базе assembly4 реализуют @IDONTSUDO и @ius.mark.alex в рамках #33. Было бы здорово тебе подключиться к процессу и рассмотреть assembly4 для задания позиции захвата. Так или иначе, останется необходимость подгрузить SDF/URDF-модель захвата и любой другой оснастки, чтобы однозначно ассоциировать позицию захвата с конкретной моделью захвата/оснастки, а также с спецификацией задачи в PDDL. Думаю, что логично именно тебе это реализовывать.
mentioned in issue #35
@movefasta я думаю что имеется в виду задача типа gpd алгоритма, который я недавно вкинул в телеграмме
@solid-sinusoid в нашем сценарии позиции захвата расставлены инженером в соответствии с захватным приспособлением. Насколько я знаю, GPD может сгенерировать большое количество вариантов позиций, но остаются вопросы: 1. Будет ли среди множества позиций наша, заранее предусмотренная позиция? 2. Если будет, то каким образом алгоритм предпочтет именно её?
@movefasta здесь нужны некоторые исследования и конкретно качество сгенерированных позиций и будет предметом исследования. Естественно всё зависит от способа фильтрации позиций захвата, а как это будет производиться, будет уже от конкретной реализации. Возможно стоит учесть, что пользователь инженер не захочет расставлять все позиции самостоятельно, а захочет сделать это автоматически. Тут нам и пригождаются подобные алгоритмы. После выполнения которых, оставить возможность лишь подправить позиции. Так или иначе, захватные позиции должны будут располагаться в тех областях, которые будут находиться вне области контакта с подсборкой, куда эта деталь вставляется. Тогда есть смысл банально ограничивать пространство выбираемое пользователем инженером, дабы инженер не выстрелил себе в ногу выставляя позиции захвата. Вы имеете в виду сценарий реализации сборки робота с подготовленными контактными площадками. Это решение стоило усилий на стадии проектирования, но мы все знаем, что не каждое собираемое устройство будет оснащено такими элементами. В таком случае следующее будет разумно:
mentioned in issue #39
@solid-sinusoid Да, нужно провести исследование по методам генерации захватных позиций. Создал задачу #39 - прошу дополнить описание, если требуется.
"Либо" - не очень подходящий термин. Оба метода могут взаимно дополнять друг друга.
unassigned @ius.mark.alex
assigned to @ius.mark.alex
unassigned @brothermechanic
mentioned in merge request !35