Comments 75
О да, знакомо. Мне несколько лет назад надо было запрограммировать движение двух Фанук роботов по одной траектории, но изюминка была в том, что они стояли развёрнутыми на 90 градусов. Казалось бы — учишь одного, у другого разворачиваешь систему координат и всё пучком. Но это в теории, а на пратике — три недели работы и так и сяк и с калибровками по трём точкам и всё такое.

Кука мне чуть больше нравится — там в своё время WinXP стояла (c Wind River VxWorks, ясен пень). Я ещё всем, кто скептически к «винде на производстве» относился, показывал, как он грузится. Сейчас с АББ работаем. А, ещё был опыт с Adept Cobra, там, кстати, точность позиционирования была где-то микрон 10-20, так что не всё так плохо.

Вообще это просто чуть другой мир. Я вот в данный момент программирую B&R ПЛК, который должен вызывать методы в стороннем OPC Ua сервере, и хотя делаю это на C++ (благо Automation Studio позволяет), но нормальным программированием назвать это никак не могу.
Приходя в робертов из стройного мира server-side/desktop разработки, какое то время ходишь с подвязанной скотчем пачкой, чтобы не падала постоянно. Но в целом — очень интересно, ну и мальчишеский фактор «смотри, как эта штука летаеть!!!» отбрасывать тоже нельзя)
Подход к удалённому вызову практически один и тот же. Универсальный обработчик, который ожидает тег «флаг выполнения» принимает теги «имя функции», «параметр1» итд и вызывает нужную функцию, по завершении выставляет флаг выполнения в 0
Ну это навскидку.
>методы в стороннем OPC Ua
о каких методах идёт речь?
Да да, я про них. Дело в том, что чтобы поднять мне сервер в ПЛК, то надо просто его включить, указать порт и смаппить переменные (ну с методами там своя история, но тем не менее) — это без единой строчки кода делается. Однако у меня ПЛК является клиентом, а сервер крутится в стороне. Вот казалось бы — сделайте такую же упрощённую настройку, но нет. Вначале мне нужно установить соединение через UA_Connect, мониторить его через UA_ConnectionGetStatus, затем получить индекс пространства имён через UA_GetNamespaceIndex, затем разработчик сервера заботливо разложил методы по папочкам, а строковые имена нодам не дал, они численные и при каждом запуске меняются, так что вначале UA_TranslatePath для каждой папочки, затем мне хендл каждого метода надо получить через UA_MethodGetHandle, и вот лишь затем UA_MethodCall. При вызове мне надо указать в какие переменные класть результат — в доках ни слова про форматы строк. С переменными сервера, которые маппятся на переменные ПЛК и автообновляются — та же фигня. Умножим это всё на то, что это в циклической программе выполняется, со взводом флага Execute, затем проверкой Error/Busy/Done, среда разработки «привет из девяностых» (ну окей, я наловчился писать всё в vscode и компилять через командную строку из терминала), при указании точки останова весь ПЛК встаёт колом, а при исключении не может показать, где оно там возникло, и так далее. Я общался с коллегами по цеху — типа Beckhoff TwinCAT вроде прямо в Visual Studio умеет, но они сказали, что и там нет совершенства. Сименс тиа портал не пробовал — мы на B&R перешли.
Не, в принципе оно нормально, но весь мир старается постоянно упрощать всё более усложняющиеся вещи, но не здесь. Кроме того, реализация С++ у B&R сильно специфическая. Коллега наворотил универсальный конечный автомат — всё по учебнику — ООП, методы, темплейты, все дела. И оно стало спонтанно падать на ровном месте.
Я ещё молчу про чехарду с версиями пакетов.
Не работал с B&R, что за модель? вроде они x86, а значит там просто обязаны быть какие-то распространённые средства для отладки (и контроля утечек памяти). И фреймворки для реализации связи со внешним миром. А лучше драйверы для внешних устройств, например — для ПК, которые к адресному пространству ПЛК позволяют обеспечить доступ. Не знаю, как ПЛК изнутри предоставляет данные, может тогда сокет организовать? Или надо все авторизации поддерживать upcUAшные?
Это вот это поделие — X20 CP3586:

Мощь этой штуки поражает — там интел атом 1.6 МГц да пол гига памяти (и это у меня ещё мощный вариант).
Там естественно есть библиотеки и модули на любой вкус — хоть Modbus, хоть Profinet, в случае OPC UA они в общем-то следуют стандартам, тут нормально всё, просто слишком много рутинной работы и далеко не всё так удобно, как могло бы быть.
В принципе можно статью написать, как на нём моргать светодиодами, но не уверен, что кому-то будет интересно.
Любопытный сегмент, мало контроллеров на x86 процессорах, а написание статьи — это для того, чтобы занять нишу тех, кого будут находить первым при попытке начинания работы с этим ПЛК. И результатом могут быть в т.ч. и контракты на разработку. Так что пишите, кто бы чего ни говорил.
Ну а на сей момент я пока продолжу считать allen bradley эпплом в мире ПЛК. Насколько там удобно в несколько кликов «поморгать светодиодом» с одного ПЛК на IO соседнего ПЛК.
Я бы хотел выдвинуть некоторые ограничения по порядку преподношения материала, этого очень не хватает Хабру чтобы перерасти в более взрослый вариант существования. Т.о. в начале ветки материалов должны быть описаны:
особенности платформы; коммуникационные возможности (протоколы, каким образом они поддерживаются); методы интеграции с системами верхнего-нижнего уровня. Ну а потом… кажется — мне тоже уже пора писать статью :-) Статья должна становиться методичкой для начинающего инженера, который уже не путает аплоад и даунлоад
Обычно начинающих инженеров просто отправляют на обучение (что для ПЛК, что для роботов). Я провёл в Австрии несколько недель на курсах. Теперь умею не только светодиодом моргать, но и с красивой визуализацией, могу и в безопасность, моторы умею крутить, в том числе безопасно, даже связанные оси могу сделать, скажем конвейерную сырорезку забацать.
и хотя делаю это на C++ (благо Automation Studio позволяет), но нормальным программированием назвать это никак не могу.

Почему? Не получается соблюдать ооп? или в чем то другом?
иногда из -185 в +180 едет корректно, а иногда — из -165 в +175 может рвануть не туда

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

По-любому же есть в фануке команда как в абб MoveAbsJ в углы осей или как на яскаве MOVJ в пульсы? Неужели неотключаемая оптимизация? Ведь приехать в -390 и -30 это же совсем разные траектории.
Есть. И едет он в пульсах ровно туда, куда его и просят. Т.е. угол он выдерживает филигранно. Только не в ту сторону. Это касается и фанука, и яскавы.
Не может быть! За столько лет яскава ни разу с пульсами не подвела, т.к. яскава в пульсах крутит ось в сторону уменьшения разницы с таргетом. Неужели у фанука с абсолютными углами такая подстава, что он реально корректирует значение при переходе через ±180?
Это абсолютно точно справедливо и для яскавы. По итогам крайнего проекта на этих роботах, GP20HL
С яскавой сомнений и не было. А фануком-то как в абсолютную позицию выехать?
когда роберту залезаешь очень далеко под юбку.

Можно я не буду это комментировать?

В статье и в комментариях густо замешаны роботы и Роберты, это всё Т9 шалит или начало восстания машин? Или это какой то узкоспециальный сленг?
Автор, безусловно, имеет право выражать свои мысли так, как хочет, хотя, вероятно, делает это несколько эмоционально.

У нас вот как-то наоборот — эмоции прут из юных падаванов, у которых Питон, мемасики, котики, аджайл, куча амбиций и нуль опыта. В отделе автоматизации же работают суровые дядьки, которым уже за пятьдесят, и которые программировали Сименс Степ 5 в те дни, когда юные падаваны ходили в начальную школу. Отдел автоматизации не вылезает из командировок. Работу такого инженера на объекте наблюдать одно удовольствие — он программирует чёткими, уверенными движениями, не «пробуя», а чётко понимая что ему нужно, ибо «убей себя ап стену» может иметь для него совершенно реальный смысл — у него в руках несколько сот килограмм железа с мощными приводами (впрочем там так устроено — если этот пульт выпадет из ослабевших рук, либо пальцы сожмут его в предсмертной агонии, то робот мгновенно остановится, ибо первый закон робототехники). С одной стороны роботов, равно как и ПЛК надо программировать именно так, но с другой стороны довольно часто что-то идёт не по плану, и вот тогда надо иметь хороший запас психической устойчивости для общения с техподдержкой и поиска обходных путей.
Хотя робот — просто куча мощных серв, да контроллер реального времени и минимум магии.

Как ни странно, отдел автоматизации у нас довольно скучный и неразговорчивый — не участвует в корпоративах, в командировках практически не пьёт, и работает «от звонка до звонка», за весь день от них можно услышать «привет» да «пока». В этом смысле отдел сервиса и пусконаладки куда как круче — после обильного ужина у греков пойти в ирландский паб, зависнуть там до полуночи, и так несколько недель кряду на каком-нибудь заводе. Ну а потом мы видим все эти красивые видео, где роботы «как живые» собирают автомобильчики. Особенно доставляет, когда сюда примешивают искусственный интеллект, хотя я бы сказал, что конкретно в области робототехники сейчас наблюдается «технологическая полка» — за последние четверть века принципиального скачка технологий нет.
роботы с навешенным техзрением — это очень даже скачок, сразу вносится поправка на угол последней оси.
Лишь бы кабели flex были :)
Особенно доставляет, когда сюда примешивают искусственный интеллект, хотя я бы сказал, что конкретно в области робототехники сейчас наблюдается «технологическая полка» — за последние четверть века принципиального скачка технологий нет.

Погодите ещё пяток лет, экспонента она такая — тридцать лет тишины, а потом внезапно заменили всё старое всем новым. :)

Ну из тех трендов, что я вижу — довольно скоро таки придёт 5G, ну станет у нас парой проводов меньше. Ещё то, что называется Predictive Maintenance — робот сам скажет, что моторчики да шестерёнки поизносились и скоро пора менять. Это уже потихоньку внедряется. Объединение машинного зрения с роботами — сейчас уже есть, но вот чтобы до уровня полной автономности — ну это примерно как Тесла с автопилотом — оно уже может ехать само, но далеко не во всех ситуациях. А так — поживём-увидим.
Второй мне укор ко второй статье в такой стилистике. В целом — по другому мне писать не интересно. Вокруг меня куча интеграторов/заказчиков/коллег, которые на серьёзных щах относятся к этому вопросу. И я согласен, что на начальном этапе это правильно, нельзя вот так, с моим подходом к общению, прыгать к заказчику на установочную встречу (на самом деле — можно). Но потом, когда новизна знакомства пропадает, если немножко потереть, там внутри сидят дядьки с таким же отношением к процессу. И юмор — единственное, что может помочь в сложных ситуациях. Замечено, что если коммуникация остаётся в строгой и чуть пафосной манере, то неизбежно прибегают проблемы уже в процессе работы.
Это да, плюс в автоматизации всегда есть куча весёлых и не очень историй, которые я иногда рассказываю юному поколению. Вот, намедни заглянул в отдел машинного зрения — они там сражаются с состоянием гонки в многопоточном приложении. Я рассказываю им как и где можно расставить семафоры, а попутно расчехляю планшет и показываю фото раздолбанного в хлам конвейера — вот как выглядит настоящее состояние гонки, и что происходит, когда вместо критической секции вы пытаетесь синхронизировать потоки банальными задержками — вы можете получить в итоге кучу вполне реального металлолома, а не выброшенное исключение.
Вот сейчас как набегут коллеги по цеху, и как расскажут, что груда железа — это чушня, а вот из-за ошибки сотни миллионов не туда уплыли))).

А в целом — да, весёлых историй всегда куча. И они, как правило, мотиватор не бросать куда более сильный, чем увещевания и покер-фейс. Это вовсе не значит, что все должны обратиться в мою веру и начать фривольно и фамильярно относиться к серьёзным железякам. Скорее я предлагаю просто принять, что и такой подход к работе тоже имеет право на существование)
Я как заметил, что нарочито серьёзные щи – это всегда, в любой коммуникации, повод насторожиться. Как и про музыку. Статистику никто не проводил, наверное, но думаю звук led zeppelin в качестве рингтона у собеседника очень быстро разряжает атмосферу и повышает веру в адекватность в айтишно-электронной, да и не только, среде.
А есть какая-то объективная причина, по которой все описанные в статье баги, затупы и пользовательский дискомфорт до сих пор не исправлены? Вроде как отрасль более полувековую историю имеет, не монополизирована, а, тем не менее, простейший поворот из одного положения в другое выполняет абы как, не говоря уже про проблемы с отладкой и вообще всё, что было описано автором?
UFO landed and left these words here
А вторая часть — потому что многие вещи не нужны. Робот — это один раз отстроил и вкалывай по программе тыщу часов без остановки. И пусть настройка и идёт через тернии, но далее он действительно чапает ровно так, как просили.

Ну и третья — это инертность самой отрасли. Выпустила, к примеру, Кука новый робот с новым интерфейсом и удобным языком программирования и новой оболочкой. А теперь прикиньте объем работ для переналадки автозавода, где этих оранжевых — сотни.
Сложно сказать — тут целый набор причин. Общая «инерционность» (мы вот только что закончили переход с Win 7 на десятку), устаревшие методологии и инструменты разработки, особые требования к безопасности — каждый релиз проходит кучу стадий проверок и как результат время от баг репорта до решения просто чудовищно. В общем «так уж сложилось». Ну вот, к примеру, мы сейчас неспешно запускаем систему с двумя одинаковыми роботами, сначала был куплен один, а чуть позже, когда убедились, что нам это подходит — второй.

И что б вы думали — они приехали с разными версиями микрокода и разными библиотеками для ПЛК. Работает либо один, либо другой, а вместе — никак. При этом обновить первый, равно как и понизить версию на втором своими силами нет никакой возможности. Так и живём.
Роботы тут — не самое интересное, интереснее — как работает система принятия решений. Какие данные в неё попадают, и что занимается вычислением годности детали.
У нас на инспекции лобового стекла это сетка из квадратов, и камера с другой стороны, отсылающая изображение на машину с Martox Imaging Library, которая разбивает изображение на куски и отправляет на видеокарточку radeon7770, где происходит вычисление отклонения относительно соседних кусков
www.synergx.com/products/automotive/windx
Там тоже не так чтобы очень сложно. Это для проверки аккумуляторов система (но можно и другие небольшие детальки просвечивать). Деталь просвечивается рентгеном, изображение захватывается с плоскопанельного детектора (грубо говоря сцинтиллятор, который светится под рентгеном, склеен с матрицей как в цифровом фотоаппарате, только размером сильно больше). Шаговый мотор крутит это дело на 360 градусов, картинки гонятся по оптоволокну в компьютер. После накопления он реконструирует объёмное изображение — это самая классическая томография. Вот так это выглядит:

Ну а дальше производится анализ анодов и катодов батарейки (в общем-то более-менее стандартные методы машинного зрения). Они могут торчать слишком сильно, либо быть сжаты. Это всё для того, чтоб смартофоны в штанах не самовозгорались.
У нас на предприятии стоит (работает) Fanuc. Используется для покраски красками на основе растворителя. красим мелкие изделия, наложенным на рамки. С роботом проблем нет, машина хороша. А вот интегратор с линией накосячил. Много точек отказа. Конечно. частично вина начальства, хотели. универсальности, что пошло в ущерб надёжности. Пишу программы для этого робота. Прошел курсы от Fanuc. Да, писать на пульте — боль, но программа для написания весьма не дешёвая, а производство не слишком большое.
Не вы первый. На самом деле как раз в такие истории мы и ходим — когда нужна универсальность. Но согласен, в целом — это не дёшево.

Подскажите, пожалуйста, использовался ли ещё какой-нибудь другой софт для оффлайн-программирования? Delmia, RobCad, ProcessSimulate?

Список ПО для автопрограммирования гораздо шире. И, как правило, страдает либо недостаточной проработанностью, либо сложностью в интеграции и техподдержке. На производствах не раз встречались с коллегами/конкурентами, отзывы 50/50. Кто-то доволен, кто-то плюётся. Вы намекаете на тему для статьи в виде разбора существующих решений?)

1) На одном из проектов с роботами KUKA (KRC4) использовалась Delmia. Потом многое пришлось руками через пульт переписывать (оптимизировать траектории). Для ABB (irc5) — родной софт от АВВ — изменений онлайн было меньше.
2) Решений много. Как и универсальных, так и нишевых — каждый автропроизводитель выкатывает свой стандарт автоматизации (и для роботов, и для ПЛК, и для прочих средств автоматизации). Для личного использования мне понравился RoboDK (есть триальный период и поддержка python).
3) Меня интересует использование тех.пакетов в Fanuc: для сварки, нанесения герметика, видео-контроль и прочее. Есть ли SDK для самостоятельного написания тех.пакетов?

У фанука немало опций, которые облегчают интеграцию с системами технического зрения, контролем за техпроцессом сварки и иже с ним. Не могли бы вы в личку чуть подробнее описать задачу — возможно, я смогу помочь чем то конкретным.
А насколько далеко можно залезть «под юбку» без нарушения соглашения пользователя? Про поворот кажется дичью, причём достаточно просто решаемой, да и задача допусков в рычагах это классическая обратная кинематика: приняли допущение об отсутствии допусков, подрыгали лапой, померили, например, фактическое положение и обратную ЭДС, не сошлось — уточняем модель. А вот если эти правки может внести только производитель, тогда ой, ситуация как с первыми числомолотилками: дорогой компьютер, дорогой программист, который идёт к этому компьютеру в ремкомплекте, одна задача.
В теории — лазить можно куда угодно, а потом если что то и сломалось — накатить образ. Если накатится.

Про «подрыгали» — так и делают, только денег за это просят немало.
Так, стоп. А автоматической калибровки по камере, встроенным датчикам положения и кинематической схеме нет?
Есть. Только оборудование, которое это выполняет, стоит сотни тысяч евро. что и позволяет существовать компаниям, которые, имея это оборудование, могут приехать и за 5-10 тыс евро выполнить калибровку на предприятии. Процедура-то практически однократная, часто не требуется.
Калибровка осей у kuka осуществляется по специальным меткам, в определённые места осей (когда робот в определённом положении, в месте, где спецметки) подключается прибор, у прибора шток, который едет по метке (управляем с пульта осью) — шток до какого -то момента проваливается в метку, а потом начинает из неё выезжать. В этот момент срабатывает триггер, и переустанавливается ноль на этой оси.
Но можно и измерительной головкой выставить.
Автоматическая хрень, которая делает то же, что можно выполнить измерительной головкой (как и было на Kuka krc2), стоит 5к евро.
Никакая камера пока такую задачу решить не может.image
Это решение, чтобы найти калибровочное положение осей механически как можно точнее. Оно даёт возможность получить максимально близкое калибровочное состояние после вмешательства в механическую часть. А для наших целей фрезеровки по CAD модели нужно калибровать рабочий объем (21 параметр в идеале). Мы берем лазерный интерферометр руку FARO, двигаем робота в позиции и меряем действительные координаты. На выходе у нас расхождения в каждой позиции и тут мы понимаем, что всё кривое и косое. (При чем для другой конфигурации манипулятора карта ошибок будет совсем другая) В какой виде и как скормить коррекцию роботу?
Ну вот я в связи с этим про фрезеровку и попорсил рассказать :) Там наверняка даже от температуры частей робота зависит поправка.
Что подразумевается под конфигурацией манипулятора? Вместе со множеством точек и форматом, в котором их надо посетить, меняется что-то ещё?

Наверно термин неподходящий — конфигурация. Типа комбинация положительных/отрицательных поворотов осей для достижения одного и того же положения инструмента

Видимо, я недооцениваю задачу. Какая точность (плюс-минус 3 сигмы) считается допустимой для робота? Эта точность касается только рабочего конца, или положения каждой точки тела робота?
Точность зависит от задачи, и если положить стекло в пирамиду с допуском в ±2 мм ещё можно без проблем, то уже при резке стекла такой допуск невозможен(на следующих операциях обработки кромки, осуществляющихся на весьма жёстких, в отличии от робота, ЧПУ, будет постоянная перегрузка шпинделя, который вращает круг. Износ круга, подшипников шпиндельного узла, а шпинделя (renaud, fischer) иностранные, дорогие. Ремонт в Новосибе стоил 400к рублей за штуку) Наверное поэтому кука стекло не режет, а японцы фануками, вроде как, смогли (м.б. у них уравнения вычисления координат точнее). В теории точность нужна только для рабочего конца, а на практике любая неточность на любой из осей влияет на точность на конце.
Я просто к тому, что щупом мы ловим единицы микрон, а камерой — десятые миллиметров. Где-то хватит, где-то нет.
А если брать покраску — то там допуски в мм-другой вполне допустимы
Не на всех моделях есть камера и прочее. Плюс датчики положения и схема могут расходится из за допусков. Тут помогает только написать программу, запустить и измерить где расхождение, корретировать программу.
Я думал проблема позиционирования только у дешевых моделей. Взяли как-то лазерный резак за 25к $, а там 100 деталей в поле охвата, да надписи по окружности и прочее. В итоге пришлось делать разметку на 100 деталей с видом сверху и делать коррекцию каждой позиции в программе. Пришлось положить 300-400 заготовок на то чтобы оно резало и гравировало там где надо. И ещё пару багов выхватил, chain Numbering не работает от слова совсем, приходитса для каждой надписи вручную прописывать от кого какой номер брать и сколько добавлять.
Лазерный резак за 25к$ -это дешёвая модель. Чуть ли не на шаговых двигателях, да без обратной связи за такие деньги он может оказаться. Видимо — сырое ПО тоже в эту цену входило. Наладка всего этого пошла плюсом.
Вы правы. Сразу после ознакомления с данным аппаратом об этом было сказано начальству, в том числе и о том что для каждого набора новых заготовок нужно будет заново проводить корректировку. В общем пришлось мне гробить заготовки и свое время.
Осмелюсь заметить, что у вас не совсем точное описание сингулярности робота. Сингулярность не связана с превышением скорости.
Сингулярность это конфигурация или траектория, в которой щупальце робота блокируется в определенных направлениях, т.е. теряет степени свободы. Это, примерно, как взять яблоко со стола, держа локоть строго вниз.
Связь со скоростью, тут скорее всего оттого, что на больших скоростях труднее избегать таких ситуаций, можно пройти где-то рядом и попасть.
PS. Спасибо за статьи. Интересно видеть взгляд со стороны (как разработчику серводрайверов).
Название, марка. Ну раз не в рублёвой зоне, то наверное не важно. Вне рублёвой зоны рынок огромен.
Драйвы в основном Custom для крупных фирм, поэтому внешнему рынку мы не известны. Раньше много делали для Staubli, сейчаc есть проекты с Kuka — некоторые новые модели будут иметь наши драйвы и Motion Controller
Отлично :) Значит теперь, когда неведомая куковская документация будет гласить что-то типа ksp error 23478923 (произвольный набор цифр, я не помню, что тогда было) и куча вариантов чего проверить, то теперь можно будет спросить — как лучше диагностировать, чтобы уменьшить круг поиска — не только по невнятным официальным каналам :)?
Про них, да. Походу будут.
Было несколько кейсов с плохим коннектом. Всё же не промышленный разъём, а работает в условиях вибрации, и т.п. Такие кейсы не уверен, что доходят до производителя.
Так у нас ещё завод маленький, роботов всего штук 30
Не помню если это молексы, я больше по алгоритмической части (Control Loops: Position/Veloсity/Torque, Фильтры etc). Вообще-то это внутренние коннекторы и они с винтами. Т.е. просто так, от вибрации не должны выпасть. Да и соответствующие тесты на вибрацию они проходят… Вы имеете ввиду коннекторы внутри кабинета или снаружи?
Внутри, там куча молексов. Физически тот, что (при мне) имел плохой контакт, был не в приводе, а в плате под приводами. 6-пиновый.
Позвонил инженеру, он напомнил мне — раньше Lenze для них делали сервы. А я никак не мог названия вспомнить, слегка сменил сферу.
На самом драйве стоят похожие коннекторы (как на картинке). Кстати не факт, что молекс, может и феникс или ампфенол. А как дальше подключаются, я не в курсе, мы кабинет не делаем, это уже прерогатива Куки.
image
Это все прикольно конечно, но пропиетарные игрища закончатся скорее всего когда китайцы на мини-экскаватор типа «самоходная табуретка с тентаклем» прикрутят удаленное управление.
Пример самоходной табуретки с тентаклем


Вот тут-то всем производителям роботов-манипуляторов и поплохеет. Зато будет хоть какой-то прогресс — и над софтом поработают и над эргономикой пульта подумают. Ну просто от балды — 6 степеней свободы это всего 3 джойстика — например палка, на ней грибок под большой палец и грибок под указательный — вот вам и три джойстика в одной руке. Мега сложный анализ однако.
Фактически статья сужает круг проблем, упирающихся в жизненный цикл механики. Не зря все эти суставы продаются на Ali с указанием сроков эксплуатации, Такие манипуляторы идут в процессы с более высокими допусками на точность и доживают свой век, пока их не пускают на капитальное восстановление в те страны, которые могут это себе позволить.
На мой взгляд проблема износа механики должна решаться программными путями с упором в обратную связь с алгоритмами исправления растущих погрешностей.
Что касается трудоемких процессов построения координат перемещения, тот же случай. Нужно, можно и некоторыми лабораториями успешно демонстрируется инструменты векторизации с обратной связью К примеру WandelBots, тот же Baxter, Boston Dynamics.
К чему я все это, наш стартап изучает такие методы и в своей NO CODE (таки да) инструментальной платформе мы уделяем этому вопросу много сил и времени. Кому интересно welcome www.beeptoolkit.com
Only those users with full accounts are able to leave comments. Log in, please.