Почему оно такое?

#роботехника

Как известно, для роботов нужны актуаторы, чтобы убить всех людей перемещаться в пространстве, поднимать ноги/лапы, подавать грузы, драться и танцевать. Актуатор - это такая комбинация электромотора, редуктора и электроники, которая позволяет перемещать по кругу одну из конечностей робота в одной плоскости. Число актуаторов в роботе равно числу степеней свободы.

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

С электромоторами тож не все просто. Есть шаговые моторы (их применяют для роборук и стационарных роботов), есть коллекторные, но к ним всем есть вопросики. Бесколлекторные моторы условно просты, вся сложность управления скинута на электронику (и уже наработано много чего), достаточно дешевы, не искрят (почти) и если что - можно собрать дрон и улететь.

Однако и они - не апофеоз инженерного гения. Тут пришли двигатели с осевым магнитным потоком (axial flux motor) и попросили подвинутся. По сути, это те же BLDC, но у которых обмотки статора развернуты не вдоль оси вращения, а поперек. В результате оказалось, что это еще лучше и тоньше, и характеристики не самые поганые, и заморачиваться с намоткой медной проволоки на статор уже не очень надо, что, конечно, изрядно всех подбешивало.

Ноучные хитроученые пошли еще дальше. "Ну, раз у нас только медь - то че мы будем напрягаться, давайте сразу сделаем статор из печатных плат стопочкой, а еще лучше - бутерброд ротор-статор-ротор-статор!" И у них таки вроде даже получилось. Это явление назвали PCB Motor (PCB - печатная плата по-буржуйски).

Известный популяризатор этого явления среди рукоблудов-дуитёсельщиков - это Карл Бугея (Carl Bugeja), про него все давно известно и с ним всё ясно. Полистайте его канал - https://www.youtube.com/@CarlBugeja - там много приключений на этот счет. Но и серьезные дядьки на сложных щщах тоже не хотят быть самыми лысыми:
— https://goinfinitum.com/technology-overview/ (более бизнесово)
— https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/iet-epa.2020.0141 (ноучно)

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

#роботехника

Немного базы про механические приводы актуаторов - редукторы, моторы, вот это вот всё
https://www.youtube.com/playlist?list=PL1KVSZBJtW0rHjU7qthPjwXhjSQ31a6zL

Ну и чтобы два раза не вставать - https://www.youtube.com/watch?v=MwIBTbumd1Q

Первый закон Ашманова о роботах: Робот не может не причинить вред человеку.

🙃

#роботехника

Изучаю тут ROS2 по книжке, и не отпускает чувство дежавю. У них реально получилась копия Эрланга.

Во-первых, вся функциональность разбита по пакетам (драйвер камеры - пакет, сервис навигации - пакет, управление механикой - пакет). Они их называют нодами. Каждая нода - это запускаемый файл (+ обвязка), который имеет некоторый набор интерфейсов для обмена сообщениями. В Эрланге такое называется приложениями (applications), а ноды - это просто экземпляры запущенной виртуальной машины. Т.е. похоже, хотя и непонятно, кто на ком стоял.

Во-вторых, на сообщения надо подписываться по строке темы. Это, конечно, ближе к MQTT, но я не помню ни одного своего проекта без gproc, который делает тоже самое. Ну и в штатной поставке OTP есть pg, который позволяет делать похожее.

В-третьих, базовых типов интерфейсов взаимодействия три:
— тема (.msg) - прямой аналог gen_server:cast, односторонняя отправка сообщения;
— служба (.srv) - аналог gen_server:call, механизм "запрос-ответ";
— действие (.action) - выполнение чего-то длительного с обратной связью по статусу выполнения. Аналога в Эрланге нет, потому что длительное выполнение в активно взаимодействующем процессе не приветствуется, но всегда можно сделать через порождение временного процесса (это дешево) с периодической отправкой состояния действия основному, чтобы он уже дальше передал вопрошающим.

Поскольку в ROS2 основные языки С++ и Python, то все эти интерфейсы надо описывать статично, а потом еще по описанию генерировать код, который будет использоваться при программировании ноды. Это, конечно, вызывает вьетнамские флешбеки (CORBA! IDL!!!), но тут иначе никак — если в Python и завезли pattern matching, то в плюсах он, скорее всего, будет доступен через адские костыли, чем сведет к нулю безопасность статической типизации. В Эрланге с его динамической типизацией и сопоставлением с образцами всё много проще. С другой стороны — строгое описание включено в пакет и его можно подглядеть через стандартные механизмы ROS2, динамическая типизация же требует погружения в исходный код и написания дополнительной документации.

Разумеется, встает вопрос, а чего изначально-то не сделать всё на Эрланге, раз по факту получилась его костыльная копия.

Причин тому несколько:
— ROS и ROS2 тянутся с 2003-2005 года (отсюда и такие концепции распределенного взаимодействия, актуальные в научной среде для того времени), реставрация Эрланга началась, ЕМНИП, в 2010 и только 2-3 года назад получились релизы с JIT (для основных платформ amd64 и arm64), которые делают его пригодным для батарейного питания и всяческого эмбида;
— уже наработано огромное легаси для кучи устройств, сенсоров, конструкций и прочего, перелопатить подобное без шансов, разве что поглотить;
— в ROS2 через сообщения могут пролетать довольно большие объемы данных (например, несжатые кадры с камеры), которые серьезно нагрузят виртуальную машину Эрланга, даже если не будут копироваться туда-сюда. Этот принцип мне кажется сомнительным с точки зрения архитектуры, но оно вроде работает. В случае применения Эрланга проще перевести тяжелые потоки на цепочки gstreamer-а с добавлением функциональности на C/Rust, оставив Эрлангу контроль обработки и формирование управляющих событий.

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