ROSSDL (ROS System Definition Language)
Свежий проект от автора PlanSys2, разработанный на EU гранты. Решает проблему согласования узлов ROS в ходе развёртывания, которые изначально разрабатываются независимо друг от друга.
Как это работает? В исходном коде пакета создаются файлы .ros2 and .rossystem, представляющие собой yaml-конфиги.
Первоначально создаётся .ros2, где описывается ROS API данного компонента: какие в пакете представлены ноды и соответствующие им издатели, подписчики и их типы, а также параметры. Далее, при запуске сборки через colcon, генерируется код, реализующий эти интерфейсы. Он состоит из базовых классов для узлов, которые абстрагируют сложность управления издателями, подписчиками и параметрами. Следовательно, программисту нужно только определить логику приложения, наследуя от этих базовых классов и придерживаясь некоторых базовых соглашений.
Далее, в ходе развёртывания, создаётся файл .rossystem, где описываются варианты систем, состоящих из компонентов, разработанных на первом этапе, включая соединения узлов через описанные интерфейсы. В ходе сборки формируются launch-файлы с Composable Nodes внутри.
Подход может быть избыточен для небольших команд и приложений, но по мере роста сложности проекта должен окупиться, потому что позволит сопровождать много конфигураций на одной кодовой базе без ручной правки большого количетсва launch-файлов. Если вы доросли до RoboDevOps, то что-то подобное стоит рассмотреть.
Хотя сам подход к декларативному описанию ROS интерфейсов не нов. Что-то похожее делали eProsima в Integration Service. Однако, тут есть кодогенерация, что теоретически может помочь при вводе в команду новых разработчиков или в координации работы архитекторов системы и программистов низкоуровневых прикладных узлов.
#ros2 #devops #systems
Свежий проект от автора PlanSys2, разработанный на EU гранты. Решает проблему согласования узлов ROS в ходе развёртывания, которые изначально разрабатываются независимо друг от друга.
Как это работает? В исходном коде пакета создаются файлы .ros2 and .rossystem, представляющие собой yaml-конфиги.
Первоначально создаётся .ros2, где описывается ROS API данного компонента: какие в пакете представлены ноды и соответствующие им издатели, подписчики и их типы, а также параметры. Далее, при запуске сборки через colcon, генерируется код, реализующий эти интерфейсы. Он состоит из базовых классов для узлов, которые абстрагируют сложность управления издателями, подписчиками и параметрами. Следовательно, программисту нужно только определить логику приложения, наследуя от этих базовых классов и придерживаясь некоторых базовых соглашений.
Далее, в ходе развёртывания, создаётся файл .rossystem, где описываются варианты систем, состоящих из компонентов, разработанных на первом этапе, включая соединения узлов через описанные интерфейсы. В ходе сборки формируются launch-файлы с Composable Nodes внутри.
Подход может быть избыточен для небольших команд и приложений, но по мере роста сложности проекта должен окупиться, потому что позволит сопровождать много конфигураций на одной кодовой базе без ручной правки большого количетсва launch-файлов. Если вы доросли до RoboDevOps, то что-то подобное стоит рассмотреть.
Хотя сам подход к декларативному описанию ROS интерфейсов не нов. Что-то похожее делали eProsima в Integration Service. Однако, тут есть кодогенерация, что теоретически может помочь при вводе в команду новых разработчиков или в координации работы архитекторов системы и программистов низкоуровневых прикладных узлов.
#ros2 #devops #systems
GitHub
GitHub - CoreSenseEU/rossdl
Contribute to CoreSenseEU/rossdl development by creating an account on GitHub.
👍2
В заключении про KiCad, системную инженерию и ISO/IEC 81346
Зачем так заморачиваться (спросит среднестатистический схемотехник)? Вроде бы вменяемых оснований для этого нет, но, если вы предпринимаете попытку полностью автоматизировать какие-либо технологические процессы, то неизбежно будете иметь дело с Парадоксом Поланьи. Этот парадокс заключается в том, что запрограммировать и автоматизировать задачу достаточно трудно, если нет полностью описанного процесса. На примере выше мы выяснили, что некоторые компоненты могут задаваться неявно, что усложняет точное моделирование с использованием системно-инженерной мета-модели. В данном случае EDA является заложником специализированности под определённую технологию производства многослойных печатных плат.
Но, не смотря ни на что, KiCad может представлять собой полигон для генерации системно-инженерных описаний по некоторым причинам:
- находится между доменами CAD и ПО, вынужден учитывать механические и программные интерфейсы;
- в нём представлены три ключевых разбиения, есть трассировка функций в конструктив с последующим переходом в 3D;
- начиная с версии 6 все исходники хранятся в текстовом формате в лиспо-подобном синтаксисе. Это делает удобным их прямую программную обработку.
Интеграция с PLM может быть реализована с помощью программных коннекторов, которые будут разбирать нативные форматы файлов KiCad-а и преобразовывать их в системно-инженерную модель во внешней БД, с которой также будут работать и другие специализированные САПРы. Да, это более сложный путь, который затрагивает вопросы семантической интероперабельности большого количества инструментов, но только он даст столь нужную гибкость в условиях непрерывно меняющихся технологических платформ, когда предстоит разрабатывать электрические устройства и топологии на каких-то иных физических принципах: например, с использованием печатных графитовых проводов, биохимических и оптических компонентов, новых аппаратных платформ для вычислителей.
Из альтернатив KiCad'у в подобного рода задачах один из подписчиков в комментариях привёл Open source ПО QElectroTech или QET, который позиционируется в качестве инструмента для разработки сложных промышленных электрических схем. Помимо принципиальных схема, в ней также можно проектировать сантехнику, геотермальные системы, кондиционирование, компоновку, гидравлику, пневматику, системы умного дома, ПИД-регуляторы, фотоэлектрические системы, схемы водоснабжения бассейнов и многое другое (скрины). Коллекция компонентов содержит более 8000 символов и в качестве системы обозначений применяется в том числе ISO 81346. Проект живой - несмотря на то, что основатели ушли в 2013, спустя 8 лет после начала, QET продолжает активно разрабатываться. Будем пробовать.
#kicad #qet #systems
Зачем так заморачиваться (спросит среднестатистический схемотехник)? Вроде бы вменяемых оснований для этого нет, но, если вы предпринимаете попытку полностью автоматизировать какие-либо технологические процессы, то неизбежно будете иметь дело с Парадоксом Поланьи. Этот парадокс заключается в том, что запрограммировать и автоматизировать задачу достаточно трудно, если нет полностью описанного процесса. На примере выше мы выяснили, что некоторые компоненты могут задаваться неявно, что усложняет точное моделирование с использованием системно-инженерной мета-модели. В данном случае EDA является заложником специализированности под определённую технологию производства многослойных печатных плат.
Но, не смотря ни на что, KiCad может представлять собой полигон для генерации системно-инженерных описаний по некоторым причинам:
- находится между доменами CAD и ПО, вынужден учитывать механические и программные интерфейсы;
- в нём представлены три ключевых разбиения, есть трассировка функций в конструктив с последующим переходом в 3D;
- начиная с версии 6 все исходники хранятся в текстовом формате в лиспо-подобном синтаксисе. Это делает удобным их прямую программную обработку.
Интеграция с PLM может быть реализована с помощью программных коннекторов, которые будут разбирать нативные форматы файлов KiCad-а и преобразовывать их в системно-инженерную модель во внешней БД, с которой также будут работать и другие специализированные САПРы. Да, это более сложный путь, который затрагивает вопросы семантической интероперабельности большого количества инструментов, но только он даст столь нужную гибкость в условиях непрерывно меняющихся технологических платформ, когда предстоит разрабатывать электрические устройства и топологии на каких-то иных физических принципах: например, с использованием печатных графитовых проводов, биохимических и оптических компонентов, новых аппаратных платформ для вычислителей.
Из альтернатив KiCad'у в подобного рода задачах один из подписчиков в комментариях привёл Open source ПО QElectroTech или QET, который позиционируется в качестве инструмента для разработки сложных промышленных электрических схем. Помимо принципиальных схема, в ней также можно проектировать сантехнику, геотермальные системы, кондиционирование, компоновку, гидравлику, пневматику, системы умного дома, ПИД-регуляторы, фотоэлектрические системы, схемы водоснабжения бассейнов и многое другое (скрины). Коллекция компонентов содержит более 8000 символов и в качестве системы обозначений применяется в том числе ISO 81346. Проект живой - несмотря на то, что основатели ушли в 2013, спустя 8 лет после начала, QET продолжает активно разрабатываться. Будем пробовать.
#kicad #qet #systems
👍12