#роботехника
Изучаю тут 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, оставив Эрлангу контроль обработки и формирование управляющих событий.
В общем, переделывать никто не будет, поэтому основной вопрос - как сделать сразу хорошо и не потерять накопленное годами.
Изучаю тут 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, оставив Эрлангу контроль обработки и формирование управляющих событий.
В общем, переделывать никто не будет, поэтому основной вопрос - как сделать сразу хорошо и не потерять накопленное годами.