Comments 36
Что ж, смотреть надо в сторону программных стоек ЧПУ станков: LinuxCNC (иии больше не помню навскидку, но только не Mach3), либо на софт управления 3d принтером (который нынче аж «12ти осевые» агрегаты поддерживает — Marlin допустим).
Вообще для анимации камеры я импользую связку Maya+Mimic. На выходе получается CSV таблица — время + повороты всех 6ти осей. инверсную кинематику расчитывает сам Mimic. Мне лишь нужно по Powerlink заставить двигатели вращаться туда куда указано в таблице.
Не знаю что такое Powerlink. Может выкинуть мозги, а степ-диры считать какой-то опен соурс платой? Почему я и предложил Marlin / LinuxCNC / grbl. Вот допустим на grbl www.youtube.com/watch?v=-LXOr3PHTPQ
Плохая идея. Хотя бы потому что они дорого стоят и их надо 6 штук. Ethernet Powerlink — это промышленная шина позволяющая управлять разными устройствами. Не такая крутая как EtherCat, но и в реализации куда проще получается. Это исключительно софтовая реализация поверх TCP/IP стэка. В итоге подключить можно к любому компьютеру обычным сетевым кабелем, а дальше из открытых исходников собрать Powerlink и дописать свои костыли под него. Собственно этим и пытаюсь заниматься, но все больше понимаю что осилить лично для меня это будет сложно
кто стоит дорого? я не понимаю: там внутря у неё неонка, предполагаю что там шаговые двигатели, контроллеры ШД, и плата мозгов. Даже если там сервы, это ничего не меняет. будет сервы / контроллеры серв / мозги.
UPD: вот же контроллеры серв:
UPD: вот же контроллеры серв:
в промышленных роботах не используются шаговые двигатели. Там стоят нормальные такие, весом по 10кг, 3х фазные движки. Конкретно в нашей руке 3 больших двигателя и 3 поменьше. Большие естественно на первые оси. Двигатели имеют скорости вращения 3000 об/мин. Так же в них установлены абсолютные энкодеры и тормоза (безопасность она важна). Все это дело подключается к драйверу двигателя который уже и крутит куда надо и общается с энкодером. Выше в цепочке стоит контроллер который управляет двигателями по Powerlink. В контроллере все мозги и зашиты по расчету кинематики и т.п. Дальше подключен Teach Pendant — это такой пульт в руках который держат и тыкают в него пальцами. Фактически это терминал для настройки и написания программы. В нашем случае мы хотим сделать свой контроллер и подключить его к компьютеру. На компьютере же считать кинематику и прочее, но это уже готово как я писал выше. Цены на всё это дело большие учитывая много-киловатные моторы, драйверы для них и т.п. Рука весит почти тонну и для её перемещения надо реально большие моторы. В холостом ходу, когда к руке не прицеплена полезная нагрузка — вся конструкция потребляет кажется 6кВт электроэнергии. Теоретический максимум (до срабатывания защиты по току в движках) — 18кВт. Можете погуглить цены — но скажу что это сотни тысяч если что…
Сотни тысяч, а «на конце» схемы сейчас стоит контроллер который не умеет то, что делает контроллер любого 3d принтера за 2 тыс. рублей: плавно перемещать оси, учитывая рывки-ускорения-скорости с планировщиком перехода от кадра к кадру (слово кадр в данном случае относится к G-code термину)
Вы не правы. он умеет перемещать точно и туда куда надо. Данный контроллер используется например в сварочном роботе и все варит и точно и куда надо. Проблема в том, что контроллер может двигать руку робота лишь как «руку робота». Видели мужиков на арбате которые роботов изображают стоя на улице? Двигаются угловато, останавливаются и всё такое. Вот именно так всё и у нас — двигается ровно. И останавливается после каждой строки G-кода. Только мне надо плавные движения, не по прямой или круговой орбите (в G-коде 2 варианта перемещения, прямо и по дуге). Мне надо нарисовать кривую движения произвольную, скорее органическую. Я могу разбить кривую на прямые отрезки и запустить — но каждый отрезок это строка G-кода и после каждой строки следует остановка руки…
В этом и отличие. Посмотрите как двигается голова 3d принтера: от кадра к кадру (от строки к строке) она переходит плавно, с учётом «рывка» и «ускорения», если там небольшой угол, то переход будет вообще без остановки.
В Mach3 (фрезерование, DSP программа) это называется параметр Exact Stop / Constant Velocity.
Он даёт либо полный останов в точке, либо прохождение её аппроксимацией в дугу.
И ещё. В G-code есть кадры G2/G3 — робот умеет их?
UPD: посмотрите видео www.youtube.com/watch?v=XT2Jq76NChM тайминги 1:40 и 3:40
В Mach3 (фрезерование, DSP программа) это называется параметр Exact Stop / Constant Velocity.
Он даёт либо полный останов в точке, либо прохождение её аппроксимацией в дугу.
И ещё. В G-code есть кадры G2/G3 — робот умеет их?
UPD: посмотрите видео www.youtube.com/watch?v=XT2Jq76NChM тайминги 1:40 и 3:40
Посмотрите как двигается голова 3d принтера: от кадра к кадру (от строки к строке) она переходит плавно, с учётом «рывка» и «ускорения», если там небольшой угол, то переход будет вообще без остановки.
Добавьте осей и просто принтер не сдюжит. Собственно, если уж знаете про g2/g3 (которое по определению в g17/18) представьте себе перевод расширяющегося спирального движения в трех осях одновременно с удержанием направления инструмента поворотом 4й и 5й. Поверьте, это сложная фигота.
(безопасность она важна).А, кстати — на счет безопасности, которая важна… Обычно роборуки, которые работают в зоне присутствия людей, имеют очень продуманные системы безопасности, тормозящие их при малейшем взаимодействии с чем-либо (что может быть человеком).
А промышленные роботы, вроде этого — предназначены для автоматических сборочных линий, куда люди не допускаются…
У вас как в этом плане? Если под него попасть — он ведь не остановится, да?
в данный момент так и есть — никакой защиты. но мы работаем над этим вопросом параллельно. пока решение есть на основе простых оптических датчиков расстояния которые можно обвесить со всех сторон… но на практике руки которые «чувствуют» столкновения обычно в 10-50 раз меньше по весу и имеют куда более слабые движки. там просто следят за током и в случае столкновения он скакнёт и можно тормозить. в нашей руке с многокиловатными моторами — она не заметит что сбила человека, стол или стену )) там только внешние датчики. вообще в моторах есть тормоза которые просто блокируют двигатель и на них можно подавать свои сигналы мгновенно останавливая руку. в общем это в процессе, а пока стараемся так сказать «не стоять под стрелой»
Я тоже не настоящий сварщик, но станцевал бы от Ethernet'a. Вставьте в разрыв Ethernet'a хаб, подключите компьютер и перехватите трафик. Не думаю что там так уж тяжело разобраться, тем более если есть представление о протоколе и возможность посылать любые команды с пульта. Сомневаюсь что трафик шифрованый — параноя туда ещё не докатилась. В лучшем случае увидите текстовый обмен, в худшем — бинарные пакеты с фиксированными позициями переменных. Сравнить пару сотен пакетов и сможете составлять их сами…
Вот тут люди вроде бы тоже пробовали:
www.researchgate.net/publication/231167196_Application_of_Ethernet_Powerlink_for_Communication_in_a_Linux_RTAI_Open_CNC_system
Вот тут люди вроде бы тоже пробовали:
www.researchgate.net/publication/231167196_Application_of_Ethernet_Powerlink_for_Communication_in_a_Linux_RTAI_Open_CNC_system
Попробуйте связаться вот с этими товарищами, они уже бегали по этим граблям.
Механика самодельная, привода от Festo, управление через EtherCAT, самописный драйвер и ROS.
Возможно схантите оттуда программиста.
Механика самодельная, привода от Festo, управление через EtherCAT, самописный драйвер и ROS.
Возможно схантите оттуда программиста.
Спасибо. Попробую. ROS рассматривал, но не вижу смысла в нем так как программная часть на стороне компьютера уже есть, а надо лишь отправить команды двигателям куда вращаться. ROS + MoveIt рассматривал с самого начала, но потом отказался от этой идеи
Если нужно есть исходники под EtherCAT и Festo. Там без ROS, на сколько я понимаю.
yadi.sk/d/zBJ6CssnDwHrvQ
yadi.sk/d/zBJ6CssnDwHrvQ
Это очень круто
можно делать 3D даже без графики, при помощи проектора и синхронизацией с роботом.
можно делать 3D даже без графики, при помощи проектора и синхронизацией с роботом.
Вариантов применения рук для «арт-проектов» много. Но почти всегда это новая Kuka + mxAutomation. А это минимум 150 тысяч долларов за минимальный комплект. Но всё равно потом еще написание своего софта для управления рукой и всего остального. Лично у меня «хотелок» много, и в них включены и трэкинг объектов и автофокус (именно «авто» с замером расстояний до объекта). Но начинать надо с простого
На проекте «28 панфиловцев» тоже хорошо применили подобные технологии.
www.youtube.com/watch?v=MO1_NK_s9zE
www.youtube.com/watch?v=MO1_NK_s9zE
Я недавно сам заинтересовался темой роботов, так что по доброму завидую вам что можно поиграть настоящей роборукой. Я хоть и не настоящий сварщик, но может вам поможет:
1. У роборуки как и у любого станка ЧПУ есть такая штука как Планировшик. Именно он по сути отвечает за безшовное движение между строкам GCode. При этом он не тупо пускает команду одну за другой, а смотрит что бы движение укладывалось в лимиты по ускорениям, и траектории. То есть если у вас движение 10см вперед, а потом 10 см резко вправо, он и остановит руку на какой-то момент, так-как поментально повернуть под острым углом не может. Если в мозгах руки есть что-то такое, то наверно стоит покопать там.
2. Раз у вас отдельные драйвера на сервы, то скорее всего они смогут обеспечить параллельное движение без особых проблем, может быть надо поменять мозги на что-то более современное. Врядли удастся заюзать grbl, так-как основная ветка рассчитана на 3х осевой станок, хотя есть вроде форки на 4 и больше.
3. Лично я не много охренел от количества матана необходимого для рассчета движения многозвенного робота. Если матрица вращение это еще куда не шло, то расчитать все шесть матриц для обратной задачи робототехники, задача уже не тривиальная.
А если учесть что мало расчитать сообсвенно куда двинуть (насколько повернуть) каждую серву, а ще надо расчитать ускорения и торможения, да с учетом всех моментов (особенно если конечная нагрузка разная...) то на 6 матриц выше, нужно еще столько же но уже со всякими ускорениями и ограничениями.
Короче говоря, имхо написание своей системы управления, задача крайне не простая и возможно проще поискать что-то готовое типа той же ROS что писали вверху.
P.S. По последнему пункту я смотрел довольно устарешвую литературу, может сейчас есть методы попроще и поэффективние.
P.P.S. Штука способная поднять 90кг, способна так же легко запустить любого зеваку на орбиту. Не даром на производстве роботов «садят в клетку».
1. У роборуки как и у любого станка ЧПУ есть такая штука как Планировшик. Именно он по сути отвечает за безшовное движение между строкам GCode. При этом он не тупо пускает команду одну за другой, а смотрит что бы движение укладывалось в лимиты по ускорениям, и траектории. То есть если у вас движение 10см вперед, а потом 10 см резко вправо, он и остановит руку на какой-то момент, так-как поментально повернуть под острым углом не может. Если в мозгах руки есть что-то такое, то наверно стоит покопать там.
2. Раз у вас отдельные драйвера на сервы, то скорее всего они смогут обеспечить параллельное движение без особых проблем, может быть надо поменять мозги на что-то более современное. Врядли удастся заюзать grbl, так-как основная ветка рассчитана на 3х осевой станок, хотя есть вроде форки на 4 и больше.
3. Лично я не много охренел от количества матана необходимого для рассчета движения многозвенного робота. Если матрица вращение это еще куда не шло, то расчитать все шесть матриц для обратной задачи робототехники, задача уже не тривиальная.
А если учесть что мало расчитать сообсвенно куда двинуть (насколько повернуть) каждую серву, а ще надо расчитать ускорения и торможения, да с учетом всех моментов (особенно если конечная нагрузка разная...) то на 6 матриц выше, нужно еще столько же но уже со всякими ускорениями и ограничениями.
Короче говоря, имхо написание своей системы управления, задача крайне не простая и возможно проще поискать что-то готовое типа той же ROS что писали вверху.
P.S. По последнему пункту я смотрел довольно устарешвую литературу, может сейчас есть методы попроще и поэффективние.
P.P.S. Штука способная поднять 90кг, способна так же легко запустить любого зеваку на орбиту. Не даром на производстве роботов «садят в клетку».
Как раз с мозгами и пытаемся что то придумать. Лимиты и все траектории уже рассчитаны и учтены. Используется Maya + Mimic. В плагине происходит проверка всех траекторий на лимиты поворотов, чтобы робот вообще смог сделать движение которое ты задал. Так же рассчитываются скорости и ускорения и тоже сверяются с лимитами которые есть у руки. На выходе получаем не траекторию инструмента, а просто повороты каждого двигателя через промежутки времени. Эти промежутки задаются при выгрузке данных. По умолчанию там стоит 25 раз в секунду, но без проблем можно выгрузить и 1000 раз в секунду все данные.
Так что проблема как раз пока что лишь в том, чтобы достучаться до драйверов двигателей и передать им команду куда крутиться.
Кстати, ускорения и замедления делаются не на уровне контроллера, а на уровне построения траектории движения. У меня задача не в том чтобы упростить программу для робота оставив 3 строчки G-кода, а в том чтобы моя виртуальная камера в Maya двигалась на 100% как рука робота. Если же я сделаю такую анимацию которую рука не сможет воспроизвести — то сразу получу ошибку плагина который уведомит о превышении лимитов по скорости, ускорению, положению и т.п…
ps. дать поиграться с рукой — это не проблема. вопрос в том, что надо найти человека который знает что с этим делать а не просто ради любопытства постоять рядом
Так что проблема как раз пока что лишь в том, чтобы достучаться до драйверов двигателей и передать им команду куда крутиться.
Кстати, ускорения и замедления делаются не на уровне контроллера, а на уровне построения траектории движения. У меня задача не в том чтобы упростить программу для робота оставив 3 строчки G-кода, а в том чтобы моя виртуальная камера в Maya двигалась на 100% как рука робота. Если же я сделаю такую анимацию которую рука не сможет воспроизвести — то сразу получу ошибку плагина который уведомит о превышении лимитов по скорости, ускорению, положению и т.п…
ps. дать поиграться с рукой — это не проблема. вопрос в том, что надо найти человека который знает что с этим делать а не просто ради любопытства постоять рядом
Ну вот как-то странно что у вас робот останавливается после каждой строчки. На выставке роботов, видел как они фрезеруют и печатают == это сотни и 1000 строк gcodе которые проходят без заминки. Так что либо мозги напрочь устарели либо ещё что.
Про Maya + mimic не знал, прикольная штука спасибо.
Разные контроллеры — разный софт. Мне достался такой вот контроллер. Я перерыл настройки и даже связался с производителем. Те лишь подтвердили что так и есть — остановка после каждой команды… Так что придется жить с тем что есть.
Вообще в настройках нашелся один параметр который отчасти убирает остановку, но он приводит к сильному замедлению руки, а во вторых все линии бывшие прямыми становятся волнистыми. Рука в принципе идет по траектории, но так сказать «срезает углы». Искривление траектории — следствие сглаживания не пути, а движения каждого двигателя без учета остальных. Сами можете прикинуть во что превратиться прямая линия когда все 6 моторов движутся не синхронно. Там даже на глаз видно как инструмент виляет при движении.
Кстати, даже без этих вот сглаживаний не верно рассчитываются движения с доворотами. начало и конец где надо, а между этими точками все моторы едут линейно условно говоря и в итоге ты хочешь чтобы камера проехала по прямой и «следила» за объектом, а на практике в центре траектории съезжает точка куда смотрит камера. Все по той же причине — для контроллера понятие доворота не существует. Eсть движение из точки в точку и оно линейное.
Вообще в настройках нашелся один параметр который отчасти убирает остановку, но он приводит к сильному замедлению руки, а во вторых все линии бывшие прямыми становятся волнистыми. Рука в принципе идет по траектории, но так сказать «срезает углы». Искривление траектории — следствие сглаживания не пути, а движения каждого двигателя без учета остальных. Сами можете прикинуть во что превратиться прямая линия когда все 6 моторов движутся не синхронно. Там даже на глаз видно как инструмент виляет при движении.
Кстати, даже без этих вот сглаживаний не верно рассчитываются движения с доворотами. начало и конец где надо, а между этими точками все моторы едут линейно условно говоря и в итоге ты хочешь чтобы камера проехала по прямой и «следила» за объектом, а на практике в центре траектории съезжает точка куда смотрит камера. Все по той же причине — для контроллера понятие доворота не существует. Eсть движение из точки в точку и оно линейное.
Понятно, видимо 10-15 лет разницы развития и дают такую пропасть в управлении. Похоже в авто индустрии требования были "приехать из А в Б, и не врезаться при этом в С" — вообщем-то типичный режим погружчика. Как оно будет вести себя в процессе перемещения никому не интересно. Удачи вам в покорении этого "монстра".
Конечно поздно что то говорить после…
Но судя по тому что:
- Закреплено все стационарно + тыква на столе (т.е. это для павильонных сьемок)
- Вес камеры не слишком большой (не 90 кг точно)
- Больших ускорений не нужно (камера не выдержит)
Я бы например, сделал бы на основе классической кран-балки (механику можно готовую, можно сделать) с обычными шаговыми двигателями (управление проще, и дешевле если не требуются большие ускорения) и платформой с двухосевым поворотным узлом.
ПО и математика для управления положением в декартовых координатах принципиально проще для такой конструкции, чем для многоосевой "руки".
Хотя, купить конечно проще. Но в таких случаях железка — это часть проблем. А вот математика для ее управления...
Если не найдёте программиста для контроллера — можно написать напрямую авторам статей по Powerlink и CNC. Все имейлы есть в статьях, искать удобно тут, например
www.researchgate.net/search.Search.html?type=researcher&query=Powerlink%20cnc%20controller
З.Ы. Я не в теме, поэтому не понял. Это стойка (пульт оператора то есть) такая странная и допускает одну команду за раз или сами кишки контроллера не осиливают предвычисления?
З.З.Ы. Скорости и ускорения на видео визуально большие. Мне кажется, надо их уменьшать.
З.З.З.Ы. Вроде как искусство монтажа подразумевает, что камера не идеальная.
З.З.З.З.Ы. Вы пишите, что можно уменьшать паузу. Поставить паузу в ноль нельзя с одновременным разбиением траектории на очень мелкие кривые?
Наконец, есть профильные форумы по станкам и их программированию. Из мне знакомых cccp3d и chipmaker.
www.researchgate.net/search.Search.html?type=researcher&query=Powerlink%20cnc%20controller
З.Ы. Я не в теме, поэтому не понял. Это стойка (пульт оператора то есть) такая странная и допускает одну команду за раз или сами кишки контроллера не осиливают предвычисления?
З.З.Ы. Скорости и ускорения на видео визуально большие. Мне кажется, надо их уменьшать.
З.З.З.Ы. Вроде как искусство монтажа подразумевает, что камера не идеальная.
З.З.З.З.Ы. Вы пишите, что можно уменьшать паузу. Поставить паузу в ноль нельзя с одновременным разбиением траектории на очень мелкие кривые?
Наконец, есть профильные форумы по станкам и их программированию. Из мне знакомых cccp3d и chipmaker.
Стоит у меня дома(!) Kuka, для которой я написал софт, скручивающий стандартный контроллер с Maya и Mimic в реальном времени.
Все ваши проблемы приходят из за того, что купив робота подешевле, и подумав, «ай, ну и пусть не родной контроллер», вы выстрелили себе в ногу. При помощи другой ноги. Контроллеры SZGH — полухлам, предназначенный исключительно для «возьми это, дёрни релейкой, кинь туда». Конкретно в вашем экземпляре двойной выстрел в ногу произвёл ещё и «пересборщик», поставив туда самые убогие сервоприводы, которые очень не любят отсутствие жёсткости(по сравнению с большими пыщ-станками, хоть для робота жёсткости тут полно).
У настоящих производителей правильных роботов(не только Kuka) контроллеры подстраиваются под сервы годами, включая автоматическое тестирование и профилирование. Всё это уехало вместе с предыдущим контроллером в нарнию.
В оригинальных же контроллерах поддерживаются протоколы высокоскоростного управления роботами на низком уровне, в реальном времени. Для Kuka это RobotSensorInterface, и несмотря на имя, он не только для сенсоров. Стоит опция ~$5000, если брать для БУшного робота. Ну, или найти где надо ;)
Единственный для вас вариант(без сжигания денег) — выкинуть мозг SZGH(пульт и его breakout board), найти даташит сервоприводов, их полностью по одиночке оттюнить, и прикрутить к LinuxCNC, а туда уже нарисовать свой парсер для экспортов из Mimic.
Если хочется сжечь денег, то найти оригинальный KRC2… и сервы… и RDC плату… а потом купить ещё одного БУшного робота.
Если хочется посотрудничать, можно в ЛС, к диалогу готов.
Все ваши проблемы приходят из за того, что купив робота подешевле, и подумав, «ай, ну и пусть не родной контроллер», вы выстрелили себе в ногу. При помощи другой ноги. Контроллеры SZGH — полухлам, предназначенный исключительно для «возьми это, дёрни релейкой, кинь туда». Конкретно в вашем экземпляре двойной выстрел в ногу произвёл ещё и «пересборщик», поставив туда самые убогие сервоприводы, которые очень не любят отсутствие жёсткости(по сравнению с большими пыщ-станками, хоть для робота жёсткости тут полно).
У настоящих производителей правильных роботов(не только Kuka) контроллеры подстраиваются под сервы годами, включая автоматическое тестирование и профилирование. Всё это уехало вместе с предыдущим контроллером в нарнию.
В оригинальных же контроллерах поддерживаются протоколы высокоскоростного управления роботами на низком уровне, в реальном времени. Для Kuka это RobotSensorInterface, и несмотря на имя, он не только для сенсоров. Стоит опция ~$5000, если брать для БУшного робота. Ну, или найти где надо ;)
Единственный для вас вариант(без сжигания денег) — выкинуть мозг SZGH(пульт и его breakout board), найти даташит сервоприводов, их полностью по одиночке оттюнить, и прикрутить к LinuxCNC, а туда уже нарисовать свой парсер для экспортов из Mimic.
Если хочется сжечь денег, то найти оригинальный KRC2… и сервы… и RDC плату… а потом купить ещё одного БУшного робота.
Если хочется посотрудничать, можно в ЛС, к диалогу готов.
К сожалению у Вас старая система управления. Если бы была KRC2, проблем было меньше (я с ней работал), много вариантов как задавать траекторию, плавность и т.д… Так же от KUKA есть софт для оффлайн программирования.
К сожалению вам разрабатывать свой софт надо, «с матами и седыми волосами».
Не забывайте про безопасность, робот тяжелый, скорость может высокую выдать, человек столкновения не перенесет. На производстве они закрыты ограждениями, можно лазерные рамки использовать.
К сожалению вам разрабатывать свой софт надо, «с матами и седыми волосами».
Не забывайте про безопасность, робот тяжелый, скорость может высокую выдать, человек столкновения не перенесет. На производстве они закрыты ограждениями, можно лазерные рамки использовать.
Не пытайтесь сделать контроллер с нуля. Есть опенсурс Odrive и аналоги.
они вам по ваттажу не подходят но надо с чего-либо начинать.
Да я о том скорее что с текущими контроллерами может и не получиться.
слона надо кушать по частям. короче решать проблемы по мере их поступления. если выясниться что данные драйверы двигателей так же не удовлетворяют условиям эксплуатации — то буду принимать решение. потом. сейчас я пытаюсь вообще до них достучаться и не получается. Powerlink не даётся с наскока. Даже скачанный LiveCD Powerlink Demo — не видит драйверы двигателей. И вопросов пока что больше чем ответов учитывая что я мало в этом понимаю и потому и спрашивал совета или даже помощи в решении этой проблемы.
Sign up to leave a comment.
Чёрная рука бюджетной автоматизации