Robossembler - Открытая робототехника
06.04.202506:30
Дорисовал 1ю и 2ю ось.
Сначала тест всех особенностей прежде чем дорисовывать другие оси.
1️⃣ Электроника в печатных корпусах на molex mini-fit jr коннекторах. Обжимать провода буду сам. Идея сделать базовые корпусные части с разводкой и подсоединять к этим базовым частям контроллеры, входное питание-управление, соединения между корпусами.
2️⃣ Скользящий контакт. Никогда с ними не работал. Сделал огромный запас прочности. Комплектующие для него очень дешевые. Но боюсь как бы колхоз не вышел.
3️⃣ Медные трубки в основании и между блоками. Межу блоками должно хорошо сработать. Очень много пластика сэкономит. Плюс опция легко менять длину плеча.
4️⃣ Концевик. Не знаю куда его принято в роботах ставить. Везде не удобно будет собирать. И не понятно стоит ли это вообще того. Но дело сделано. Соберу проверю.
5️⃣ И конечно же металлический редуктор. Посмотрим стоит ли он своих денег в контексте пластикового робота=)
#робот #печать
Сначала тест всех особенностей прежде чем дорисовывать другие оси.
1️⃣ Электроника в печатных корпусах на molex mini-fit jr коннекторах. Обжимать провода буду сам. Идея сделать базовые корпусные части с разводкой и подсоединять к этим базовым частям контроллеры, входное питание-управление, соединения между корпусами.
2️⃣ Скользящий контакт. Никогда с ними не работал. Сделал огромный запас прочности. Комплектующие для него очень дешевые. Но боюсь как бы колхоз не вышел.
3️⃣ Медные трубки в основании и между блоками. Межу блоками должно хорошо сработать. Очень много пластика сэкономит. Плюс опция легко менять длину плеча.
4️⃣ Концевик. Не знаю куда его принято в роботах ставить. Везде не удобно будет собирать. И не понятно стоит ли это вообще того. Но дело сделано. Соберу проверю.
5️⃣ И конечно же металлический редуктор. Посмотрим стоит ли он своих денег в контексте пластикового робота=)
#робот #печать
02.04.202512:32
KiCad как система проектирования электрических схем общего назначения
Когда мы разрабатывали намотчик, возникла идея описать электрическую схему станка не в рандомной рисовалке, а непосредственно в KiCad, где мы разрабатываем другие электрические схемы устройств. В случае удачного исхода эксперимента можно было бы описать подобным образом что-то по-сложнее - например, робота-манипулятора.
Разумеется, для систем разного масштаба существуют свои инструменты - для микросхем уже давно существуют языки описания аппаратуры и никто там принципиальные схемы не рисует по понятным соображениям, однако ту же простую электроустановку или даже схемы электропроводки здания вполне могут быть описаны той же или похожей нотации (граф из узлов-компонентов и рёбер-соединений), в которой это делается с печатными платами, не плодя лишних зависимостей и не прибегая к таким монстрам как EPLAN. Тем более, что в KiCad существует возможность создавать иерархические проекты.
Довольно быстро возникла проблема, что для формирования BoM-листа из проекта такой установки необходимо каким-то образом явно задавать кабель. Дело в том, что линии или рёбра графа в EDA символизируют собой электрическое соединение с около-нулевым сопротивлением, имплементированным в конструкции печатной платы в виде медного полигона/дорожки определённой толщины. Эти дорожки являются некой фигурой умолчания и не включаются в перечень комплектующих. Даже сама плата без компонентов не фигурирует в перечне по умолчанию. Кабель же нужно учитывать и включать явно в схему, чтобы он попал в закупочную ведомость. В противном случае высок шанс про него забыть. Помимо этого, кабель может быть нестандартным - с какими-нибудь перекрёстными соединениями вместо простых шлейфоподобных соединений (как в случае соединения шагового двигателя и контроллера в станке), поэтому в ходе экспорта документации нужно формировать для него отдельный чертёж, чтобы на производстве всё сделали правильно.
Если выделить такой кабельный коннектор в подпроект, то для формирования его BoM-листа нужно оформить оба разъёма на концах кабеля в виде отдельных компонентов, а также расположить на каждой из линий соединения ещё один компонент (можно в виде кастомного 0-резистора), отражающий позицию кабеля определённых характеристик (цвет, толщина, сплав). Тогда перечень комплектующих для такого соединителя будет сформирован корректно. В общем, решение не столь изящно как хотелось бы, но вполне может работать, особенно если придумать интеграцию с какой-нибудь CAD-системой.
Экспериментальный проект находится в git-репозитории Намотчика в отдельной ветке.
#hardware #kicad #winder
Когда мы разрабатывали намотчик, возникла идея описать электрическую схему станка не в рандомной рисовалке, а непосредственно в KiCad, где мы разрабатываем другие электрические схемы устройств. В случае удачного исхода эксперимента можно было бы описать подобным образом что-то по-сложнее - например, робота-манипулятора.
Разумеется, для систем разного масштаба существуют свои инструменты - для микросхем уже давно существуют языки описания аппаратуры и никто там принципиальные схемы не рисует по понятным соображениям, однако ту же простую электроустановку или даже схемы электропроводки здания вполне могут быть описаны той же или похожей нотации (граф из узлов-компонентов и рёбер-соединений), в которой это делается с печатными платами, не плодя лишних зависимостей и не прибегая к таким монстрам как EPLAN. Тем более, что в KiCad существует возможность создавать иерархические проекты.
Довольно быстро возникла проблема, что для формирования BoM-листа из проекта такой установки необходимо каким-то образом явно задавать кабель. Дело в том, что линии или рёбра графа в EDA символизируют собой электрическое соединение с около-нулевым сопротивлением, имплементированным в конструкции печатной платы в виде медного полигона/дорожки определённой толщины. Эти дорожки являются некой фигурой умолчания и не включаются в перечень комплектующих. Даже сама плата без компонентов не фигурирует в перечне по умолчанию. Кабель же нужно учитывать и включать явно в схему, чтобы он попал в закупочную ведомость. В противном случае высок шанс про него забыть. Помимо этого, кабель может быть нестандартным - с какими-нибудь перекрёстными соединениями вместо простых шлейфоподобных соединений (как в случае соединения шагового двигателя и контроллера в станке), поэтому в ходе экспорта документации нужно формировать для него отдельный чертёж, чтобы на производстве всё сделали правильно.
Если выделить такой кабельный коннектор в подпроект, то для формирования его BoM-листа нужно оформить оба разъёма на концах кабеля в виде отдельных компонентов, а также расположить на каждой из линий соединения ещё один компонент (можно в виде кастомного 0-резистора), отражающий позицию кабеля определённых характеристик (цвет, толщина, сплав). Тогда перечень комплектующих для такого соединителя будет сформирован корректно. В общем, решение не столь изящно как хотелось бы, но вполне может работать, особенно если придумать интеграцию с какой-нибудь CAD-системой.
Экспериментальный проект находится в git-репозитории Намотчика в отдельной ветке.
#hardware #kicad #winder
22.03.202519:43
Open source курильщика?
На этой неделе состоялся значимый для нашего сообщества пресс-релиз:
В России впервые открыли общий доступ к конструкторской и технической документации на образовательный ровер DH:Contact компании “Дронсхаб групп”. За пять лет конструкторской документацией могут воспользоваться свыше 1,5 млн учащихся и робототехников.
Речь идет о предоставлении общего доступа на чертежи, описания и схемы сборки, в том числе электроники и узлов крепления, а также – на изготовление всех деталей, подключение оборудования и вычислительных модулей.
Открытие доступа к документации связано, в первую очередь, с желанием компании содействовать развитию робототехники в России, появлению новых технологических проектов и решений, и облегчению подготовки новых кадров по данному направлению. Открытая документация позволит избежать многим стартапам и проектам ненужных ошибок, и сосредоточиться сразу на разработке своих проектов на базе готовой открытой платформы. Компания планирует поддерживать, обновлять и актуализировать документацию на платформу в течение пяти лет. За это время ей смогут воспользоваться свыше 1,5 млн учащихся и робототехников.
“Мы открываем общий доступ к конструкторской документации на ровер DH:Contact со всеми исходниками. Заинтересованные в сотрудничестве компании и образовательные организации получат полный комплект всей документации, для дальнейшего использования роверов в любых своих проектах. Мы делаем образовательную робототехнику РФ открытой и доступной как никогда ранее. Считаем, что для обучения и развития реальной робототехники гораздо лучше бесплатно пользоваться открытой и официальной российской конструкторской документацией, делая при этом на ее базе свои проекты, чем покупать роботов неизвестного происхождения”, – поделился генеральный директор “Дронсхаб групп” Максим Томских.
Полагаю, что у коллег возникло рассогласование между подразделениями, подготавливающими КД к публикации и PR-службой компании, потому что ни в одном из источников мне так и не удалось найти ссылок на опубликованную конструкторскую документацию. Если у кого-то получилось найти? Поделитесь, пожалуйста, в комментариях.
#open #hardware #russia
На этой неделе состоялся значимый для нашего сообщества пресс-релиз:
В России впервые открыли общий доступ к конструкторской и технической документации на образовательный ровер DH:Contact компании “Дронсхаб групп”. За пять лет конструкторской документацией могут воспользоваться свыше 1,5 млн учащихся и робототехников.
Речь идет о предоставлении общего доступа на чертежи, описания и схемы сборки, в том числе электроники и узлов крепления, а также – на изготовление всех деталей, подключение оборудования и вычислительных модулей.
Открытие доступа к документации связано, в первую очередь, с желанием компании содействовать развитию робототехники в России, появлению новых технологических проектов и решений, и облегчению подготовки новых кадров по данному направлению. Открытая документация позволит избежать многим стартапам и проектам ненужных ошибок, и сосредоточиться сразу на разработке своих проектов на базе готовой открытой платформы. Компания планирует поддерживать, обновлять и актуализировать документацию на платформу в течение пяти лет. За это время ей смогут воспользоваться свыше 1,5 млн учащихся и робототехников.
“Мы открываем общий доступ к конструкторской документации на ровер DH:Contact со всеми исходниками. Заинтересованные в сотрудничестве компании и образовательные организации получат полный комплект всей документации, для дальнейшего использования роверов в любых своих проектах. Мы делаем образовательную робототехнику РФ открытой и доступной как никогда ранее. Считаем, что для обучения и развития реальной робототехники гораздо лучше бесплатно пользоваться открытой и официальной российской конструкторской документацией, делая при этом на ее базе свои проекты, чем покупать роботов неизвестного происхождения”, – поделился генеральный директор “Дронсхаб групп” Максим Томских.
Полагаю, что у коллег возникло рассогласование между подразделениями, подготавливающими КД к публикации и PR-службой компании, потому что ни в одном из источников мне так и не удалось найти ссылок на опубликованную конструкторскую документацию. Если у кого-то получилось найти? Поделитесь, пожалуйста, в комментариях.
#open #hardware #russia
05.04.202516:37
В заключении про 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
28.03.202508:41
Всем пятница! ;)
19.03.202514:30
Мартовский Журнал разработки Robossembler
Давно не было новостей по нашему проекту, а рассказать есть о чём! Восполняю пробел.
Интеграции. Большая веха - мы наконец вышли на первый договор внедрения! Наш робот будет устанавливать заготовки шильдиков небольшого размера и веса на станок, запускать гравировку и забирать готовые. Задача достаточно простая (что хорошо), но много ньюансов как для железа (которое также в процессе разработки), так и для нашего софта. Проект потянул за собой разработку специального приспособления пневматического захвата, а также интеграцию с API гравировального станка. Управляющую программу делаем полностью на деревьях поведения в ROS2 Jazzy в нашем Runtime.
Манипулятор. Робот претерпел существенные изменения в связи с необходимостью решать прикладные задачи. Вместе с этим циклом доработок также были добавлены и новые фичи: удобный индикатор, который показывает как закрывать крышки на редукторах, новая система для вкручивания винтов в прокручивающиеся резьбы, универсальный крепеж для гриппера через стандартный винт и спрятанный в корпусе концевик для определения крайних положений в некоторых осях.
Сервоконтроллер. Контроллер прошёл опробацию на движках (подробности тут). Сейчас активно дорабатываем встроенное ПО контроллера сервопривода - добавили и тестируем загрузчик прошивки по CAN (чтобы, не разбирая самого робота, обновить его прошивку), делаем запись параметров привода в постоянную память.
Намотчик. Наш новый генератор GCode, написанный на Pascal, формирует достаточно оптимальную программу намотки - много лучше, чем у более скоростных китайских намотчиков. Мы купили несколько готовых намотанных китайских статоров и есть с чем сравнить.
В целом, 5-я версия работоспособна, но пока весьма капризна по отношению к наладке и обслуживанию. Есть понимание как сделать 6-ю версию станка более неприхотливой в сборке, наладке и эксплуатации, что соответствует изначальной идее. Мы планируем возобновить активную работу над станком после завершения блока работ по интеграции робота.
Если у вас есть желание помочь в этом процессе или ещё какие-то интересные проекты, где мы можем быть полезны - пишите @brylev
#robossembler #devlog
Давно не было новостей по нашему проекту, а рассказать есть о чём! Восполняю пробел.
Интеграции. Большая веха - мы наконец вышли на первый договор внедрения! Наш робот будет устанавливать заготовки шильдиков небольшого размера и веса на станок, запускать гравировку и забирать готовые. Задача достаточно простая (что хорошо), но много ньюансов как для железа (которое также в процессе разработки), так и для нашего софта. Проект потянул за собой разработку специального приспособления пневматического захвата, а также интеграцию с API гравировального станка. Управляющую программу делаем полностью на деревьях поведения в ROS2 Jazzy в нашем Runtime.
Манипулятор. Робот претерпел существенные изменения в связи с необходимостью решать прикладные задачи. Вместе с этим циклом доработок также были добавлены и новые фичи: удобный индикатор, который показывает как закрывать крышки на редукторах, новая система для вкручивания винтов в прокручивающиеся резьбы, универсальный крепеж для гриппера через стандартный винт и спрятанный в корпусе концевик для определения крайних положений в некоторых осях.
Сервоконтроллер. Контроллер прошёл опробацию на движках (подробности тут). Сейчас активно дорабатываем встроенное ПО контроллера сервопривода - добавили и тестируем загрузчик прошивки по CAN (чтобы, не разбирая самого робота, обновить его прошивку), делаем запись параметров привода в постоянную память.
Намотчик. Наш новый генератор GCode, написанный на Pascal, формирует достаточно оптимальную программу намотки - много лучше, чем у более скоростных китайских намотчиков. Мы купили несколько готовых намотанных китайских статоров и есть с чем сравнить.
В целом, 5-я версия работоспособна, но пока весьма капризна по отношению к наладке и обслуживанию. Есть понимание как сделать 6-ю версию станка более неприхотливой в сборке, наладке и эксплуатации, что соответствует изначальной идее. Мы планируем возобновить активную работу над станком после завершения блока работ по интеграции робота.
Если у вас есть желание помочь в этом процессе или ещё какие-то интересные проекты, где мы можем быть полезны - пишите @brylev
#robossembler #devlog
04.04.202512:31
EDA, системная инженерия и IEC 81346
Задача с проектированием кабеля в KiCad заставила задуматься о том как в существующих инструментах разработки правильно описывать такого рода интерфейсы в проектах сложной много-составной электроники (роботах). Одной из мета-моделей для таких описаний служит системная инженерия и связанные с ней косвенно стандарты разработки. Например, ISO/IEC 81346, предписывающий правила обозначений для электротехнических систем с поправкой на множественность описаний для одних и тех-же физических объектов (multi-view). Для каждого компонента/системы стандарт выделяет, по меньшей мере, три вида описания: функциональное (как работает: функциональные блоки, порты, потоки), конструктивное (из чего собрано: бом-лист, модули и интерфейсы) и пространственное (где размещается: координаты и габариты мест размещения). Каждое из описаний представляет собой структуру типа дерево (breakdown structure), с декомпозицией по частям/целым. В новой версии стандарта 2022 года было добавлено разбиение по типу, в учебниках Анатолия Левенчука по системному мышлению добавляются также разбиения по стоимости и работам.
Для простоты мы пока остановимся на трёх базовых видах разбиений и попробуем отразить их на KiCad. Функциональным описанием является принципиальная схема, которая определяет количество, тип, номиналы компонентов и их соединения/порты. Однако, в чертёж принципиальной схемы добавляется также и информация о кодах производителей (manufacturer part number, MPN) и типах интерфейсов компонент (в случае с печатной платой это посадочные места - 0603, 1210, SOIC-8), что формально относится к конструктивному описанию (из чего собирается и как соединяется физически). Уже это делает затруднительным гибкое версионирование такого рода описаний - поставщики и их компоненты могут регулярно меняться из-за ситуации на рынке, что по идее должно приводить только к обновлению закупочных позиций, не затрагивая основной чертёж, но разработчики вынуждены вносить изменения в принципиальную схему без существенных на то оснований. В свою очередь, проект топологии печатной платы .kicad-pcb содержит в себе информацию как о количестве и типах посадочных мест, которые размещаются на плате, так и о размещении.
Так вот, возвращаясь к нашему кабелю, можно предположить, что интерфейсом между шаговым двигателем и портом на плате контроллера является сам кабель (как говорит нам принципиальная схема). Но это будет ошибкой, как я писал выше - тут теряется сам физический модуль кабеля, который не так уж и примитивен - он имплементирует два интерфейса - со стороны двигателя и со стороны контроллера, состоит из следующих подмодулей: разъём для двигателя, провода 1...N, разъём для контроллера, между которыми будут реализованы механические контактные интерфейсы, которые также могут быть не столь просты, как кажется на первый взгляд.
А в случае с печатной платой всё ещё интереснее: "голая" печатная плата имплементирует N интерфейсов (посадочных мест) и в попыке описать модули для этих интерфейсов в EDA возникает вторая фигура умолчания: припой. Да, припой никак не упоминается в проекте печатной платы, однако для точного моделирования он необходим - в больших изделиях он может влиять на конечный вес, не говоря уже о том, что про него надо не забыть и включить в закупочные ведомости! Так вот каждый интерфейс на печатной плате (как модуле) сделан не для самих электронных компонентов, а для припоя - то есть интерфейсом тут является химическое соединение медной плёнки и оловянно-свинцового сплава (как также модуля) с одной стороны и соединение припоя и ножек компонента с другой.
#iso #iec #kicad
Задача с проектированием кабеля в KiCad заставила задуматься о том как в существующих инструментах разработки правильно описывать такого рода интерфейсы в проектах сложной много-составной электроники (роботах). Одной из мета-моделей для таких описаний служит системная инженерия и связанные с ней косвенно стандарты разработки. Например, ISO/IEC 81346, предписывающий правила обозначений для электротехнических систем с поправкой на множественность описаний для одних и тех-же физических объектов (multi-view). Для каждого компонента/системы стандарт выделяет, по меньшей мере, три вида описания: функциональное (как работает: функциональные блоки, порты, потоки), конструктивное (из чего собрано: бом-лист, модули и интерфейсы) и пространственное (где размещается: координаты и габариты мест размещения). Каждое из описаний представляет собой структуру типа дерево (breakdown structure), с декомпозицией по частям/целым. В новой версии стандарта 2022 года было добавлено разбиение по типу, в учебниках Анатолия Левенчука по системному мышлению добавляются также разбиения по стоимости и работам.
Для простоты мы пока остановимся на трёх базовых видах разбиений и попробуем отразить их на KiCad. Функциональным описанием является принципиальная схема, которая определяет количество, тип, номиналы компонентов и их соединения/порты. Однако, в чертёж принципиальной схемы добавляется также и информация о кодах производителей (manufacturer part number, MPN) и типах интерфейсов компонент (в случае с печатной платой это посадочные места - 0603, 1210, SOIC-8), что формально относится к конструктивному описанию (из чего собирается и как соединяется физически). Уже это делает затруднительным гибкое версионирование такого рода описаний - поставщики и их компоненты могут регулярно меняться из-за ситуации на рынке, что по идее должно приводить только к обновлению закупочных позиций, не затрагивая основной чертёж, но разработчики вынуждены вносить изменения в принципиальную схему без существенных на то оснований. В свою очередь, проект топологии печатной платы .kicad-pcb содержит в себе информацию как о количестве и типах посадочных мест, которые размещаются на плате, так и о размещении.
Так вот, возвращаясь к нашему кабелю, можно предположить, что интерфейсом между шаговым двигателем и портом на плате контроллера является сам кабель (как говорит нам принципиальная схема). Но это будет ошибкой, как я писал выше - тут теряется сам физический модуль кабеля, который не так уж и примитивен - он имплементирует два интерфейса - со стороны двигателя и со стороны контроллера, состоит из следующих подмодулей: разъём для двигателя, провода 1...N, разъём для контроллера, между которыми будут реализованы механические контактные интерфейсы, которые также могут быть не столь просты, как кажется на первый взгляд.
А в случае с печатной платой всё ещё интереснее: "голая" печатная плата имплементирует N интерфейсов (посадочных мест) и в попыке описать модули для этих интерфейсов в EDA возникает вторая фигура умолчания: припой. Да, припой никак не упоминается в проекте печатной платы, однако для точного моделирования он необходим - в больших изделиях он может влиять на конечный вес, не говоря уже о том, что про него надо не забыть и включить в закупочные ведомости! Так вот каждый интерфейс на печатной плате (как модуле) сделан не для самих электронных компонентов, а для припоя - то есть интерфейсом тут является химическое соединение медной плёнки и оловянно-свинцового сплава (как также модуля) с одной стороны и соединение припоя и ножек компонента с другой.
#iso #iec #kicad
27.03.202511:14
О национальной стратегии в области открытого кода
Отличное интервью Александра Нозика, директора Scientific Programming Centre, о научном программировании, open source в России и не только:
"Я глубоко убежден, что не может быть никакого «национального open source». Так же как не может быть в 21 веке сугубо национальной науки. И то, и другое развивается настолько успешно, насколько много участников процесса и связей между ними. Возможно, Китай может себе позволить что-то подобное, просто потому что там живет очень много людей, но мы видим, что даже Китай пытается интегрироваться в мировую систему разработки и науки, а не изолироваться от нее. Поэтому историю о том, что «нам не нужен американский open source, мы сделаем свой» я считаю исходно бредовой. Продвигать ее могут только совершенно далекие от реальности политики.
Тем не менее, есть ряд действий, которые можно предпринять, чтобы open source-разработки и их внедрение в России шли активнее. В первую очередь речь об информационной политике. В России у компаний нет культуры собственной разработки, много лет они занимались тем, что покупали готовые (в основном американские) продукты, чем снимали с себя все риски.
Сейчас до многих внезапно (а что случилось?) дошло, что зависимость от проприетарных решений, у которых нет альтернатив — вещь опасная. А разрабатывать свои не умеем. Да и не то, что разрабатывать, адаптировать готовый open source не умеем. Потому что для адаптации тоже надо иметь какую-то свою разработку и брать на себя риски за нее.
Считаю, что (как минимум) в больших компаниях должны появиться офисы по исследованиям и разработкам, которые бы, в том числе, занимались развитием и адаптацией open source решений. Эти офисы могут работать с вузами и, возможно, другими типами инжиниринговых хабов, которые станут поставщиками новых решений."
Полная версия
#interview #science
Отличное интервью Александра Нозика, директора Scientific Programming Centre, о научном программировании, open source в России и не только:
"Я глубоко убежден, что не может быть никакого «национального open source». Так же как не может быть в 21 веке сугубо национальной науки. И то, и другое развивается настолько успешно, насколько много участников процесса и связей между ними. Возможно, Китай может себе позволить что-то подобное, просто потому что там живет очень много людей, но мы видим, что даже Китай пытается интегрироваться в мировую систему разработки и науки, а не изолироваться от нее. Поэтому историю о том, что «нам не нужен американский open source, мы сделаем свой» я считаю исходно бредовой. Продвигать ее могут только совершенно далекие от реальности политики.
Тем не менее, есть ряд действий, которые можно предпринять, чтобы open source-разработки и их внедрение в России шли активнее. В первую очередь речь об информационной политике. В России у компаний нет культуры собственной разработки, много лет они занимались тем, что покупали готовые (в основном американские) продукты, чем снимали с себя все риски.
Сейчас до многих внезапно (а что случилось?) дошло, что зависимость от проприетарных решений, у которых нет альтернатив — вещь опасная. А разрабатывать свои не умеем. Да и не то, что разрабатывать, адаптировать готовый open source не умеем. Потому что для адаптации тоже надо иметь какую-то свою разработку и брать на себя риски за нее.
Считаю, что (как минимум) в больших компаниях должны появиться офисы по исследованиям и разработкам, которые бы, в том числе, занимались развитием и адаптацией open source решений. Эти офисы могут работать с вузами и, возможно, другими типами инжиниринговых хабов, которые станут поставщиками новых решений."
Полная версия
#interview #science
12.01.202518:01
Железные времена
Продолжая тему Rust в робототехнике, проект Ferrocene - Rust for critical systems, разрабатываемый компанией Ferrous Systems. Если коротко, по сути это форк официального репозитория rustc (в который они, как утверждают, регулярно направляют свежие фиксы), сертифицированный согласно стандартам для safety critical систем: ISO 26262 (ASIL D) для автомобилей, IEC 61508 (SIL 4) для промышленности, IEC 62304 для медицины.
https://ferrocene.dev/en/
https://github.com/ferrocene/ferrocene
#rust #certified
Продолжая тему Rust в робототехнике, проект Ferrocene - Rust for critical systems, разрабатываемый компанией Ferrous Systems. Если коротко, по сути это форк официального репозитория rustc (в который они, как утверждают, регулярно направляют свежие фиксы), сертифицированный согласно стандартам для safety critical систем: ISO 26262 (ASIL D) для автомобилей, IEC 61508 (SIL 4) для промышленности, IEC 62304 для медицины.
https://ferrocene.dev/en/
https://github.com/ferrocene/ferrocene
#rust #certified
03.04.202508:55
Open Toolchain Foundation
Open Toolchain Foundation (OTFN) - международная некоммерческая организация, направленная на развитие экосистемы инструментов с открытым исходным кодом для современного проектирования и разработки в области машиностроения, производства и других инженерных задач. Основная цель фонда — сделать открытые инструменты стандартом в инженерии, заменив проприетарные решения, которые часто дороги и создают зависимость у пользователей.
Как заявляют создатели, фонд стремится к созданию мира, где все программные инструменты взаимодействуют друг с другом через открытые форматы файлов, избавляя пользователей от зависимости от закрытых решений.
Они финансируют проекты с открытым исходным кодом, помогают объединять сообщества разработчиков и обеспечивает качество их работы, активно продвигают использование открытого ПО в академической среде, предоставляют образовательные ресурсы и консультации.
Кратко о поддерживаемых фондом проектах (увы, из них живой только последний, который поддерживается непосредственно Йориком, основателем FreeCAD):
GitPDM
https://gitlab.fabcity.hamburg/OTFN/git-pdm-mockups
Прототип системы управления данными изделия (PDM), основанной на Git, который демонстрирует важность интеграции таких решений в открытые инженерные цепочки инструментов.
Snapping in the FreeCAD Sketcher Workbench
https://github.com/PaddleStroke/FreeCAD/tree/otfn-snapping-tool
Реализация функции привязки (snapping) в Sketcher Workbench FreeCAD, позволяющая автоматически выравнивать геометрию при проектировании и успешно интегрированная в основной код программы.
Curve drawing in the FreeCAD Sketcher Workbench
https://github.com/Ondsel-Development/FreeCAD.git
Добавление инструментов для рисования кривых в Sketcher Workbench FreeCAD, что расширяет возможности создания 2D-геометрии и успешно внедрено в программу.
Interoperability Database
https://github.com/occi-cad
Разработка базы данных для обеспечения совместимости между CAD-программами через REST API, которая стала важным шагом к унификации работы с параметрическими моделями.
Implementation of electromagnetic simulations
https://github.com/donovaly/FreeCAD
Реализация электромагнитных симуляций в FreeCAD, позволяющая моделировать магнитные поля в 2D и 3D и успешно интегрированная в основной код программы.
Improvement of FreeCAD’s Architectural Modeling
https://github.com/yorikvanhavre/FreeCAD-NativeIFC
Улучшение поддержки файлов IFC в FreeCAD для архитектурного моделирования, что позволяет напрямую просматривать, редактировать и сохранять IFC-файлы. Начиная с версии FreeCAD 1.0 проект интегрирован в BIM workbench.
Сайт: Open Toolchain Foundation
#fund #open #source
Open Toolchain Foundation (OTFN) - международная некоммерческая организация, направленная на развитие экосистемы инструментов с открытым исходным кодом для современного проектирования и разработки в области машиностроения, производства и других инженерных задач. Основная цель фонда — сделать открытые инструменты стандартом в инженерии, заменив проприетарные решения, которые часто дороги и создают зависимость у пользователей.
Как заявляют создатели, фонд стремится к созданию мира, где все программные инструменты взаимодействуют друг с другом через открытые форматы файлов, избавляя пользователей от зависимости от закрытых решений.
Они финансируют проекты с открытым исходным кодом, помогают объединять сообщества разработчиков и обеспечивает качество их работы, активно продвигают использование открытого ПО в академической среде, предоставляют образовательные ресурсы и консультации.
Кратко о поддерживаемых фондом проектах (увы, из них живой только последний, который поддерживается непосредственно Йориком, основателем FreeCAD):
GitPDM
https://gitlab.fabcity.hamburg/OTFN/git-pdm-mockups
Прототип системы управления данными изделия (PDM), основанной на Git, который демонстрирует важность интеграции таких решений в открытые инженерные цепочки инструментов.
Snapping in the FreeCAD Sketcher Workbench
https://github.com/PaddleStroke/FreeCAD/tree/otfn-snapping-tool
Реализация функции привязки (snapping) в Sketcher Workbench FreeCAD, позволяющая автоматически выравнивать геометрию при проектировании и успешно интегрированная в основной код программы.
Curve drawing in the FreeCAD Sketcher Workbench
https://github.com/Ondsel-Development/FreeCAD.git
Добавление инструментов для рисования кривых в Sketcher Workbench FreeCAD, что расширяет возможности создания 2D-геометрии и успешно внедрено в программу.
Interoperability Database
https://github.com/occi-cad
Разработка базы данных для обеспечения совместимости между CAD-программами через REST API, которая стала важным шагом к унификации работы с параметрическими моделями.
Implementation of electromagnetic simulations
https://github.com/donovaly/FreeCAD
Реализация электромагнитных симуляций в FreeCAD, позволяющая моделировать магнитные поля в 2D и 3D и успешно интегрированная в основной код программы.
Improvement of FreeCAD’s Architectural Modeling
https://github.com/yorikvanhavre/FreeCAD-NativeIFC
Улучшение поддержки файлов IFC в FreeCAD для архитектурного моделирования, что позволяет напрямую просматривать, редактировать и сохранять IFC-файлы. Начиная с версии FreeCAD 1.0 проект интегрирован в BIM workbench.
Сайт: Open Toolchain Foundation
#fund #open #source
25.03.202507:29
В комментариях к предыдущему посту поступили подробности об опенсорс ровере от Дронсхаб.
Порядок получения исходников следующий:
- запросы на доступ к документации принимаются только от юридических лиц, заявку необходимо направить по адресу: info@droneshub.ru;
- документация передается в рамках двухстороннего соглашения между заказчиком и "Дронсхаб групп".
Порядок получения исходников следующий:
- запросы на доступ к документации принимаются только от юридических лиц, заявку необходимо направить по адресу: info@droneshub.ru;
- документация передается в рамках двухстороннего соглашения между заказчиком и "Дронсхаб групп".
29.10.202411:58
Линус и 11 мейнтейнеров
Если кто не в курсе недавнего скандала вокруг разработчиков ядра Linux, то кратко:
22 октября из списка мэйнтейнеров ядра Linux удалено 11 участников, предположительно работающих в российских компаниях. В качестве причины удаления заявлено "выполнение различных требований комплаенса" (various compliance requirements). После чего по спискам рассылки запустилась бурная дискуссия, к которой позже подключился Линус Торвальдс и написал, что необходимость блокировки ему и другим мэйнтейнерам пояснили юристы.
(подробнее тут, тут и тут)
В чём тут мораль? Подобно тому как экономисты марксистской школы находят противоречия между общественным характером труда и частным присвоением его результатов, в этой, ставшей типичной для нынешнего времени, ситуации можно найти противоречия между глобальным распределённым характером современной разработки, обусловленной существованием трансграничной сети компьютеров под названием интернет, и наличием территориальных юрисдицкий, унаследованных миром из времён до-интернетовской эпохи. В особенности это касается Open source проектов, где результаты работы расползаются по всему земному шару в кратчайшие сроки без каких-либо ограничений, а войти в состав разработчиков можно и вовсе не имея гражданства.
Сейчас поднялось довольно много шума, потому что речь идёт об одном из влиятельнейших open source проектов, на котором без шуток держится современная IT-индустрия. Но история с ядром Linux довольно типичная. Она повторяется из раза в раз. : как только начатый изначально энтузиастами проект открытого ПО садится на юридическую основу, то есть обзаводится фондом или коммерческой фирмой, тут же возникают предпосылки для его подчинения - смены лицензий, изменения политики внесения изменений в код или состав управления. Например, в близком мне сообществе Nix не так давно разгорелся скандал вокруг попыток протащить гендерную квоту в совет правления, то есть зарезервированное место для представителя гендерных меньшинств, который должен привнести уникальную точку зрения. Иногда сообщество сопротивляется, что выражается в расколе между ключевыми разработчиками и созданием форка (см историю Gitea -> Forgejo), но часто просто молча принимает новые правила. Питер Хинтьенс в своей книге об open source "Социальная архитектура" указывает на значимость правильного лицензирования и обоснованность применения т.н. вирусных лицензий. В пермиссивных лицензиях (Apache, BSD, MIT) вы можете форкнуть проект, закрыть его и "купить" какую-то часть разработчиков. Зачастую, этого достаточно, чтобы исходный проект загнулся. Поэтому, помимо организационно-правовой формы, большое значение имеет де-факто сложившаяся в сообществе структура управления. Проекты, где многое держится на каком-то одном авторитетном лидере, также будут подвержены уязвимостям через воздействие на данного человека.
Очевидно, что для обеспечения безопасности открытых проектов нужна иная организационная форма, независимая от причуд регуляторов отдельно взятой страны. Наряду с децентрализацией технической, которая де-факто сложилась в интернет, нужна децентрализация социально-экономическая. И об этом не стоит забывать.
#open #source #economics
Если кто не в курсе недавнего скандала вокруг разработчиков ядра Linux, то кратко:
22 октября из списка мэйнтейнеров ядра Linux удалено 11 участников, предположительно работающих в российских компаниях. В качестве причины удаления заявлено "выполнение различных требований комплаенса" (various compliance requirements). После чего по спискам рассылки запустилась бурная дискуссия, к которой позже подключился Линус Торвальдс и написал, что необходимость блокировки ему и другим мэйнтейнерам пояснили юристы.
(подробнее тут, тут и тут)
В чём тут мораль? Подобно тому как экономисты марксистской школы находят противоречия между общественным характером труда и частным присвоением его результатов, в этой, ставшей типичной для нынешнего времени, ситуации можно найти противоречия между глобальным распределённым характером современной разработки, обусловленной существованием трансграничной сети компьютеров под названием интернет, и наличием территориальных юрисдицкий, унаследованных миром из времён до-интернетовской эпохи. В особенности это касается Open source проектов, где результаты работы расползаются по всему земному шару в кратчайшие сроки без каких-либо ограничений, а войти в состав разработчиков можно и вовсе не имея гражданства.
Сейчас поднялось довольно много шума, потому что речь идёт об одном из влиятельнейших open source проектов, на котором без шуток держится современная IT-индустрия. Но история с ядром Linux довольно типичная. Она повторяется из раза в раз. : как только начатый изначально энтузиастами проект открытого ПО садится на юридическую основу, то есть обзаводится фондом или коммерческой фирмой, тут же возникают предпосылки для его подчинения - смены лицензий, изменения политики внесения изменений в код или состав управления. Например, в близком мне сообществе Nix не так давно разгорелся скандал вокруг попыток протащить гендерную квоту в совет правления, то есть зарезервированное место для представителя гендерных меньшинств, который должен привнести уникальную точку зрения. Иногда сообщество сопротивляется, что выражается в расколе между ключевыми разработчиками и созданием форка (см историю Gitea -> Forgejo), но часто просто молча принимает новые правила. Питер Хинтьенс в своей книге об open source "Социальная архитектура" указывает на значимость правильного лицензирования и обоснованность применения т.н. вирусных лицензий. В пермиссивных лицензиях (Apache, BSD, MIT) вы можете форкнуть проект, закрыть его и "купить" какую-то часть разработчиков. Зачастую, этого достаточно, чтобы исходный проект загнулся. Поэтому, помимо организационно-правовой формы, большое значение имеет де-факто сложившаяся в сообществе структура управления. Проекты, где многое держится на каком-то одном авторитетном лидере, также будут подвержены уязвимостям через воздействие на данного человека.
Очевидно, что для обеспечения безопасности открытых проектов нужна иная организационная форма, независимая от причуд регуляторов отдельно взятой страны. Наряду с децентрализацией технической, которая де-факто сложилась в интернет, нужна децентрализация социально-экономическая. И об этом не стоит забывать.
#open #source #economics
Ko'rsatilgan 1 - 12 dan 12
Ko'proq funksiyalarni ochish uchun tizimga kiring.