Роботандем: у крохотного робота-трансформера STAR появился старший брат

    Источник

    Несколько лет назад ученые из Университета имени Бен-Гуриона создали компактного робота — Rising STAR (RSTAR). Сейчас у него появился напарник с аналогичной конструкцией — Big STAR (BSTAR), вот только, размер нового робота больше в 6 раз. Предполагается, что тандем увеличит производительность, улучшит универсальность роботов и сделает их менее уязвимыми. RSTAR и BSTAR станут применять в поисково-спасательных операциях, когда требуется перемещение по бездорожью и пересеченной местности.

    Роботов семейства STAR создал ученый Дэвид Заррук (David Zarrouk) с коллегами из Университета имени Бен-Гуриона. В своих первых разработках Заррук уделял максимум внимания автономности конструкций. Первые версии STAR получились действительно достаточно автономными и маневренными. Роботы легко трансформируются в зависимости от условий окружающей среды. Так, RSTAR имеет несущие винты — умеет облетать препятствия. Помимо этого, у робота есть надувные баллоны для плавания. Увидев, что конструкция получилась удачной, команда разработчиков решила пойти дальше. В итоге у RSTAR появился старший брат — BSTAR.

    Особенности BIG STAR




    Робот BSTAR обладает следующими характеристиками:

    • скорость движения конструкции до 1,4 м/с;
    • полезная нагрузка робота > 5 кг;
    • длина конструкции от оси заднего колеса до оси переднего колеса — 82,5 см;
    • выдвижной «хвост» для переноса RSTAR;
    • раздвижная конструкция;
    • минимальная высота в сложенном виде — 21 см;
    • 2 литий-полимерных аккумулятора емкостью по 5200 мА *ч;
    • масса — 9,8 кг.

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

    Размеры BSTAR

    Робот BSTAR подойдет для перевозки большого объема полезного груза: батарей, камер, коммуникационного оборудования и других датчиков для поисково-спасательных операций.

    Робот управляется контроллером на Arduino Uno и двух контроллерах RobotClaw ECS.

    Первая израильская звезда


    Робот RSTAR. Источник

    Многофункциональный робот RSTAR появился в 2018 году. За счет адаптивного изменения конструкции он умеет передвигаться по горизонтальной и вертикальной поверхности, а также ползти или ездить на колесах. Робот быстро адаптируется к внешним условиям: может менять угол между колесными рамами, перемещать их параллельно корпусу вперед и назад.

    Размеры робота RSTAR. Источник

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

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

    Конструкция робота RSTAR. Источник

    Для увеличения мобильности робота можно оснащать колесами или опорами со спицами. Он может бегать вверх ногами и с помощью черепашьей походки переползать через препятствия превышающие по высоте диаметр его колес.

    Робот оснащен одним LiPO-аккумулятором емкостью 800 мА*ч, но в планах — сделать его более автономным. Минимальная высота маневренного робота составляет 3,5 см, поэтому он может перемещаться по очень узким и труднодоступным местам. Максимальная скорость робота — до 0,8 м/с. Масса конструкции — 0,38 кг.

    Союз двух звезд



    С одной стороны, BSTAR и RSTAR имеют аналогичные конструкции, только выполненные в масштабе 6 к 1. Однако из-за больших размеров BSTAR некоторые его части пришлось заменить.

    В BSTAR используют металлический каркас, в то время как у RSTAR — пластиковый.

    Важным новым элементом конструкции робота является его выдвижной «хвост» — подвижная площадка в задней части. Площадка может изменять угол наклона в отрицательную и положительную стороны. Основное предназначение «хвоста» — перевозить крохотного RSTAR. Всего на родительской площадке может уместиться 3 «роборебенка».

    Площадка может применяться в разных случаях для дополнительных маневров. Например, RSTAR, заезжая на площадку BSTAR, способен осматривать препятствия с высоты.

    Как и говорилось выше, малютка заряжается от аккумулятора своего «родственника».

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

    Selectel
    IT-инфраструктура для бизнеса

    Comments 36

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

      Самая фантастическая способность большего из двух — быть старшим братом своему старшему брату. А вообще техника, конечно, интересная.
        0
        Кто нибудь может мне ответить, для чего человеческий мозг на уровне университетского и не только образования непрерывно создает такие футуристические роверы?
        Или это как дань разновидности технофилии со времен Сибирского цирюльника?
        Я согласен что доля полезных решение все же находит свою нишу и даже ограниченное их производство по цене их содержания в 1000 землекопов, лесорубов, прочих членистоногих…
          0
          Предполагаются роботы-спасатели и ликвидаторы, т.е. машинки, которые могут уехать в завалы, огонь и ядовитый дым и там что-то сделать, при этом не очень понятно, что понадобится: ехать, прыгать, карабкаться или лететь (у RSTAR вообще странная схема локомоции). Есть у меня предположение, что при определенном риске для человека его просто по закону нельзя посылать на задание, но при этом делать что-то надо.
            0
            В таком случае, почему на сегодня отсутствует массовое производство таких систем для нужд общества.
            В то время когда космические спутники бороздят просторы космического океана… мы по прежнему наблюдаем вертолетные спасательные бригады бороздящие океаны и моря в поисках рухнувших лайнеров, горных ликвидаторов и спасателей в связке с собаками, пожарников, вытаскивающих погорельцев, спецназовцев, штурмующих террористов с заложниками и т.п.
              0
              Я согласен, что многие обзоры это «разработан робот, который позволит...», но вот серийные и полусерийные: 1,2,3. Самые популярные — поисковики, пожарные и водные спасатели.
              А так-то в большинстве случаев люди надежнее, качественнее и дешевле.
                0
                Ответ на поверхности — производство роботов, пусть даже и в единичном исполнении, процесс дорогой на всех этапах от программно аппаратной части до финальной верификации в сборе с механикой. Дальнейший сервис в течение жизненного цикла всех компонентов, из которых собрана система, в конечном итоге мы имеем «швеицарские часы» х N что по карману не каждому гурману.
                Здесь требуется переосмысление ситуации на всех этапах начиная с разработки.
                  0
                  RSTAR это стенд, имхо, он никогда не будет использован как есть. Это не значит, что он не нужен, CENTAURO тоже когда-то был смешным и пластиковым, сейчас это взрослая проходимая машина, готовая к внедрению.
                    0
                    При всем Вашем оптимизме, из личного опыта ответ однозначный — многое то, что готово к внедрению, далеко не готово к серийному производству. Сегодня ARM манипуляторы с минимальными промышленными функциями (как правило от 4 до 6 осей) сумели наладить не более 4 — 6 заводов, все остальное, это выпуск кустарных опытных партий с опытной командой интеграторов. Что естественно сказывается на стоимости и узости ниши рынка потребителей.
                    Тяга разработчиков наделить робототехнику «искусственным интеллектом», «умным зрением», бионическими решениями, увы пока что есть предмет демонстрации интеллекта разработчиков, которые таки, да могут воспроизвести робота — верблюда и подтвердить право на жизнь научной темы, но не далее как занимательная робототехника.
                    Серийное производство робототехники, прежде всего требует договоренности между разработчиками и производителями в вопросах единого правила — plug and play, независимо от назначения системы, будь то кухонный бытовой робот или многоцелевой космический смарт комплекс с наращиваемыми функциями.
                      0
                      Что сказывается на стоимости и узостью нишевого рынка потребителей.
                      Да. Но я же не кричу про «робота в каждый дом». Ниши есть, и в них уже есть роботы.
                      Развитие робототехники требует договоренности между разработчиками и производителями в вопросе единого правила plug and play независимо от назначения системы
                      А вот тут не соглашусь: много раз развивались решения от разных вендоров для одной и той же задачи, а потом оставались один-два самых популярных или поддерживаемых. А могут и остаться много разных, такое тоже бывало. Или Вы про PnP буквально?
                        0
                        В идеале должен присутствовать принцип интерфейсной I/O совместимости по аналогии с PC IBM, при этом программные инструменты разработчиков, независимо от того, на чем построено их ядро, должны в себя включать GUI настраиваемый кросс платформенный фреймворк с обращением к Finite-state machines.
                        Все что выходит за рамки в.у. есть плод научно исследовательского футуризма.
                          0
                          Не согласен. Во-первых, роботы являются промышленным оборудованием, а там с совместимостью на всех уровнях очень большая проблема, тем не менее, все обычно работает, когда обслуживается квалифицированным специалистом. Во-вторых, а зачем?
                          Должны в себя включать GUI настраиваемый кросс платформенный фреймворк с обращением к Finite-state machines
                          Ну и тем более, почему именно так? У такого подхода куча плюсов, и в проектировании, и в отладке, но уж очень неортодоксально, я не помню, где сейчас так делают и делают ли вообще.
                            0
                            Несовместимость промышленной автоматики и робототехники, есть результат стремления производителей к монополизации. От того и железо дорогое и сервисный персонал и жизненный цикл. Это к вопросу зачем.
                            Что касается н.у. подхода, хм, скажем так, сам по себе факт гипотетического подхода имеет право на его апробирование.
                            Противоположный взгляд на всем очевидные и вошедшие подавляющей массой кодеров привычки выражать свои методы и способы кодирования, неизбежно и вопреки их неприятию есть факт битвы с ветряными мельницами.
                            99,9% Python кодеров ни за какие уговоры не вернутся к Fortran. Это результат языковой эволюции, она не останавливается и неровен тот час когда «100 млн кодеров сядут на забор» это прогноз (2017) от мега хранителя кода GitHub CEO Chris Wanstrath.
                            www.idgconnect.com/article/3578431/github-ceo-the-future-of-coding-is-no-coding-at-all.html?fbclid=IwAR16vCT4e8hkaBE82UnPL2RAVcApjLg-N6cRjdOHMUtHCkUPBy8NLltIyyY
                              0
                              Вот давайте не мешать производство, продажи и политику. Пляшем от конечного покупателя, которому нужна гарантия соответствия спецификации — это то место, где действительно нужны ансамбли FSM, просто потому. что это чуть ли не единственный способ делать верификацию. И тут внезапно оказывается, что так даже в медицине, аэрокосмосе и военке не делают — в областях с самых зарегулированным процессом разработки и приёмке. Почему? Во-первых, это долго, во-вторых, дорого, в-третьих, тут мы попадаем в уже занятую нишу — однозначные и устойчивые решения такого уровня обычно делаются на релейной логике.
                              0
                              Еще как делают. Угадайте с 3 раз на каком софте и под какими осями Маск запустил свой проект SpaceX?
                                0
                                Я буквально сегодня разместил здесь на Habre свою развернутую публикацию, в данный момент статья на премодерации к принятию решения, если по каким то причинам не пройдет, выставлю на других ресурсах, о чем здесь сообщу.
                                  0
                                  Почитаем. Но один пример хоть и рушит квантор всеобщности, но не доказывает ни применимость и удачность инструмента, ни тем более популярность.
                                    0
                                    В общем habr бесследно сдул мою публикацию без каких либо комментариев, подозреваю что узрели там какую либо рекламу или запретный пиар…
                                    Ну и лады, google им судья.
                                    Публикация в ее английском варианте имела резонанс в популярном IT лондонском издательстве Welp Magazine, буквально после ее размещения на linkedin где мы попали в топовый список стартапов в своей сфере.
                                    Здесь оригинал русскоязычной версии
                                      0
                                      Прочёл по ссылке, там действительно либо «Я пиарюсь», либо вообще корпоративный блог, ну и через спеллчекер прогнать нелишне, ошибок и опечаток куча. Ну и по сайту в профиле полазил. Давайте по порядку, как я понял:
                                      1. Чтоб полноценно пользоваться описанной No code платформой, требуется довольно неплохо знать классическое программирование. Она реально сложнее, чем LabView, STM Cube или кодогенерация по UML. Отдельный минус в том, что она ни на что не похожа.
                                      2. Платформа является лишним слоем абстракции, не являясь гуем компилятора, т.е. она должна поддерживать платформу, под которую ведется разработка.
                                      3. Непонятно, почему сделано именно так и каков численный выигрыш. Хотелось бы посмотреть на проект, который решается по классике и через платформу.
                                      4. Что там за КА? Синхронные/асинхронные, активные/пассивные? Гикпорно в студию :)
                                        0
                                        Относительно кучи, мой спелчекер не особо возмущался, даже не знаю где и в чем там у меня обнаружены лингвистические баги.
                                        1. Что у Вас вызвало такое суждение? В чем сложность?
                                        Что в образовательном видео ролике смущает и требует опыта в классическом программировании?
                                        Она реально сложнее, чем LabView, STM Cube или кодогенерация по UML.

                                        В чем это выражается? Приведите сравнительный пример, если владеете в.у. средой программирование и инструкциями.
                                        Отдельный минус в том, что она ни на что не похожа.

                                        Ну так и простейший арифметический калькулятор так же не похож на косточковые счеты. В чем трагедия?
                                        2. Платформа представляет из себя настраиваемый фреймворк с внешними коммуникациями. В отличие от PLC или DSP архитектур и отличается концептуально, как встраиваемое ПО (инструментальная RT среда) на базе PC (CPU Intel, AMD x 64) под OS для внешнего управления и сбора данных. Логическое ядро платформы как и внешний графический интерфейс скомпилированы на G.
                                        Программная часть адаптирована к внешним драйверам нагрузок и сенсорике посредством аппаратного I/O USB модуля (возможно расширение USB коммуникаций в пределах деклараций в.у. архитектур поддерживаемых OS). И всё.
                                        3,4. В источнике и на сайте продукта есть наглядные примеры, демонстрация в работе, так же есть ссылки на отраслевые проекты (медицина, автомобилестроение, наука, промышленное приборостроение). Сори, мне не хотелось бы сюда в подкаст перетаскивать всю публикацию цитируя буквально все, что там написано и демонстрируется.
                                        Если есть желание, предлагаю там продолжить более предметный разговор. Здесь это, похоже мало кого интересует.
                                          0
                                          Вопросы по платформе no code у меня делятся на два категории, про product placement и чисто технические.
                                          1. На кого ориентирован Ваш продукт? Как я понял из информации на сайте, платформа предназначена для экономии на профильном специалисте. Окей, эмбедщика убрали автомат поставили, кто будет писать код? Какой специалист? Насколько я понял, условного фронтэндщика не посадишь без обучения: лично я, если бы не читал Хоровица и Хилла, не понял бы назначение разных полей. Т.е. чтобы понимать куда и зачем тыкать нужно как минимум общее понятие о встраиваемой электронике и архитектуре микроконтроллеров. Похоже на путь, который прошла 1С: предполагалось, что её пользователями будут непосредственно бухгалтеры, но довольно быстро оказалось, что без прокладки в виде 1С-программистов система не работает. Следующий вопрос про конечный продукт разработки: получаем на выходе прототип, который после тестирования переписывается «по классике», или готовое к внедрению решение?
                                          2. Техническая часть. Сразу оговорюсь, что не стал тратить несколько часов на ознакомление с инструментом, которым не планирую пользоваться.
                                          Платформа представляет из себя настраиваемый фреймворк с внешними коммуникациями
                                          Эту фразу я не понял. Значит ли это, что на стороне МК остался только ногодрыг, а вся логика живет на десктопе, передавая по USB команды вида «дёрнуть ногами по такой-то маске»?
                                          В источнике и на сайте продукта есть наглядные примеры, демонстрация в работе
                                          А можно без видео? Хочу классическую текстовую аппноту с кодом. Классическим «миганием диодиком» является такой набор:
                                          — Моргание светодиодом на задержках
                                          — Моргание светодиодом на таймере с фиксированной частотой при разной частоте ядра или периферии (если МК поддерживает независимое тактирование)
                                          — Моргание светодиодом, когда интервал выше разрядности встроенного счётчика таймера.
                                          мой спелчекер не особо возмущался, даже не знаю где и в чем там у меня обнаружены лингвистические баги.
                                          Если вам нужен корректор, то я готов выполнить эту работу.
              0
              Ок, давайте все разложим по полкам:
              1. На кого ориентирован Ваш продукт?

              Это:
              — R&D No coders, те, которые понимает бинарную логику управления на аппаратном уровне, или готов уделить этому понятию свои 30 минут;
              — Такие разработчики должны владеть навыками алгоритмизации на вербальном уровне для сигнального процессинга;
              — категории пользователей, это стартапы, малые бизнесы, инжиниринговые фирмы или отделы производственных фирм, студенты выпускники профильных вузов и т.д. и т.п.
              Т.е. чтобы понимать куда и зачем тыкать нужно как минимум общее понятие о встраиваемой электронике и архитектуре микроконтроллеров.....

              В том то и проблема что новые инструменты многие разрабы пытаются рассматривать в ракурсе того, что им знакомо. Нас кодеры не любят и всегда скептицизма льют ведрами и это понятно.
              Понятие «встраиваемая электроника», как таковое имеет право на озвучку но не в нашем случае. Есть встраиваемое firm ПО реального времени под DSP архитектуры, как впрочем и для PLC. В нашем случае такие понятия, о которых Вы говорите юзерам не нужны равно как и тем кто подключает к PC принтер и прочую периферию. Но, они должны понимать принцип управления на бинарной логике, чтоб подключить к I/O то, чем нужно управлять или собирать данные. Чтоб не изобретать новую терминологию, а наоборот как можно проще адаптировать процесс освоения платформы, мы применяем традиционную терминологию от контроллеров, которая несет на себе те же смысловые функции, которые соответствуют классической терминологии и да, в том числе от микроконтроллеров.
              Следующий вопрос про конечный продукт разработки: получаем на выходе прототип, который после тестирования переписывается «по классике», или готовое к внедрению решение?

              После проведения прототаипинга, когда вся логика на аппаратном уровне решена:
              1. Юзер сохраняет конфигурацию совсеми инструкциями (исходный код) своей автоматики в отдельном бинарном файле, предусмотрена возможность формирования множества библиотек из таких файлов, обращение к ним и редактирование с сохранением под другим именем;
              2. В случае необходимости индивидуальной интерфейсной панели для конечных клиентов, исходный код отправляется юзером в нашу сервисную поддержку, где разрабатывается внешний HMI. Примеры стилей таких интерфейсных панелей можно загрузить на сайте продукта. Если по каким-то причинам нет необходимости в мониторинге или элементах управления, созданная автоматика может работать под инструментом без подключения дисплея или с ограничениями клиентов по доступам к изменениям кода.
              В конечном итоге исходный код с внешним интерфейсом компилируется в пользовательский исходник и может быть передан в пользование конечным клиентам.
              Собственно прототип может вполне стать конечным продуктом готовым к серийному производству. Все очень индивидуально. Мы же продаем лицензии на инструмент, а так же сопутствующий сервис по интерфейсным решениям.
              Значит ли это, что на стороне МК остался только ногодрыг, а вся логика живет на десктопе, передавая по USB команды вида «дёрнуть ногами по такой-то маске»?

              Вся логика живет на десктопе, взаимодействует с аппаратной периферией посредством I/O модуля(ей). Кроме DSP и PLC контролеров, на минутку существуют так же и промышленные PC под специализированным софтом под разными OS, коммуникациями и так же рулят автоматикой и робототехникой. Самый примитивный простой пример — кассовый аппарат совмещенный с весами где применен PC SBC под Win x.
              А можно без видео? Хочу классическую текстовую аппноту с кодом. Классическим «миганием диодиком» является такой набор:
              1. Моргание светодиодом на задержках
              2. Моргание светодиодом на таймере с фиксированной частотой при разной частоте ядра или периферии (если МК поддерживает независимое тактирование)
              3. Моргание светодиодом, когда интервал выше разрядности встроенного счётчика таймера.

              2 и 3 алгоритмы в случае FSM сформулированы с нарушением правила «верно» поэтому они не заложены к применению логикой ядра. Если Вы их сформулируете более определенно, в соответствии принципами управления аппаратной частью, тогда задаче решается.
              Так выглядит инструкция 1 алгоритма:
              1. После нажатия в ручном режиме кнопки Start, или автоматически через 10 с запускается основной цикл в режим ожидания завершения работы вложенных циклов;
              2. Порт 1, 7 канал OUT, 10 циклов с прерыванием 3 с. Результат Led включается 5 раз с задержками в 3 с;
              3. Переход в основной цикл и завершение.
              Led после запуска главного цикла (задержка 1s)
              https://drive.google.com/file/d/1gD6JvCLweN-VuTxLb38vaJhc5q_b7_2C/view?usp=sharing
                0
                2. Моргание светодиодом на таймере с фиксированной частотой при разной частоте ядра или периферии (если МК поддерживает независимое тактирование)
                3. Моргание светодиодом, когда интервал выше разрядности встроенного счётчика таймера.

                2 и 3 алгоритмы? Нет никаких внешних МК, ядро платформы обслуживается PC CPU Intel на его частоте а так же параметрически задаваемыми значениями программных циклов MFS.
                Сдается мне, что Вы о чем то своем додумываете, но как сформулировать, не так чтоб очень…

                  0
                  Видимо, действительно что-то своё. На сайте вижу
                  NO-CODE software platform for creating automatics tools, robotics and controlled devices
                  И на картинке вокруг МК различная встраиваемая электроника, в том числе подразумевающая SoC.

                  Поскольку тема для меня не совсем чужая, я архитектуру решения представляю так: конечное устройство-эффектор, на борту у него МК, поддерживающий real-time обработку и берущий на себя низкоуровневую часть «как работать». Он (возможно) подключен к десктопу, на котором никакого реального времени нет, но есть высокоуровневая прожорливая часть «как» и «что делать».
                  Вся логика живет на десктопе, взаимодействует с аппаратной периферией посредством I/O модуля(ей).
                  Вот этот момент мне непонятен. Что такое i/o модули? Как реализуется real-time обработка приходящих сигналов?
                  Если мы берём USB, то предсказать, когда сигнал придёт с конечного устройства на концентратор ПК в принципе можно точно через data frames, это в стандарте есть, но вот когда провернётся планировщик ОС, чтобы сигнал от прерывания достиг программы-обработчика в user space — это вообще никак не регламентируется. Так что если прерывание на МК просто передаётся на десктоп, там обрабатывается и пересылается обратно — это никакого риалтайма, джиттер может быть в сотни миллисекунд.

                  По поводу модельного примера, я хочу что-то такое, можно даже без CTC и OVF. Вот давайте представим, что я хочу сделать с помощью вашей no-code платформы гирлянду на ёлку, без раздельного управления диодами, но чтоб могла моргать с определенным интервалом, пусть даже фиксированным, 3 секунды. Но это должны быть честные 3 секунды. Какое оборудование мне понадобится и как будет выглядеть разработка?
                    0
                    Вот этот момент мне непонятен. Что такое i/o модули? Как реализуется real-time обработка приходящих сигналов?

                    А вот на этом моменте и разберемся, все остальные домыслы беспредметны.
                    I/O USB модуль это USB внешие, наращиваемые ADC (надеюсь Вы знаете что это), на борту первого стартового комплекта (10 Inputs, 16 Output) типа преобразователей. Вся логика платформы включая генераторы сигналов и обработчики, а так же задаваемые сценарии и параметры (обращения и запросы) к ADC, это исключительно десктоп программная часть и всё, никаких внешних CPU, MCU и разного рода DSP архитектур.
                    Поскольку тема для меня не совсем чужая

                    Многое, что я здесь разъясняю, как и то, что люди желающие глубоко копнуть это решение все же достаточно хорошо должны понимать принципы сигнального процессинга, то к чему я шел не год и не 5 лет. Ко всему мы здесь обсуждаем то, что до этого читалось по диагонали. Тем не менее я терпеливо здесь выкладываю многие фундаментальные понятия, увы абсолютно все я не в состоянии здесь расписать, к примеру что есть фреймворк, или как устроен FSM, все же рассчитываю на инженерный подход достижения истины. Уже и пример No code инструкций выставил «ногодрыг», в результате 1 из нас мыслит весьма субъективно и 1 ответ порождает очередной водопад вопросов. Админы Habr не сочли публикацию интересной, в итоге мы вдвоем здесь ведем потусторонний разговор не имея первоисточника. Полемика мало по малу перерастает в публичную консультацию. Если хотите обратитесь ко мне в личку или напишите на мейл. В противном случае я скопирую сюда всю статью в подкаст Вашей темы, глядишь появится народ и добавит понятную мне критику.
                      0
                      Давайте поступим проще: я расскажу, что я понял из этой беседы, сайта у вас в профиле и статьи на vc, на которую вы давали ссылку выше, а вы скажете, где я неправ.
                      1. К компьютеру подключаются USB-IO или USB-ADC модули, идеологически подобные старичку eserial, только проприетарные. Они необслуживаемые, принимая команду по USB они выставляют значения IO на своих ногах/каналах ЦАП либо сообщают по USB состояние ног и/или АЦП, больше ничего не умеют. Модули являются ведомыми и не могут инициировать обмен данными с ПК. Характеристики модулей на сайте разработчика платформы отсутствуют.
                      2. Логика выставления значений задаётся в no-code платформе. По окончании работы с платформой генерируется программа, которая должна крутиться на компьютере, к которому подключены модули.
                      3. Real time не обещается.
                        0
                        Все верно за исключением 2 и 3 пунктов.
                        Это самый что ни на есть Real Time. Платформа начинает выполнять все процедуры с по факту окончания процесса конфигурирования (алгоритмизации сценария) командой Start, при этом есть 2 режима — симуляция без подключения внешней аппаратной части проекта или с подключением. Имеется возможность сохранения построенного сценария в отдельном бинарном файле, приступить к следующему проекту и так же сохранить его конфигурацию. Эти библиотеки конфигураций можно формировать по темам, задачам, отдельным режимам, к примеру управление шаговым мотором(ами) и т.п. Можно редактировать.
                        Для распространения своих проектов (3 варианта):
                        1. Вы приобретаете у нас лицензию на установку логического ядра под инструментом;
                        2. Без графического интерфейса (на панели отображается кнопка старт, стоп, настраиваемый таймер обратного отсчета до запуска, а так же ввод значения на циклическое повторение;
                        3. С пользовательским графическим интерфейсом по 1 из предлагаемых дизайнов (см. сайт с описанием и условиями интерфейсной агрегации).
                        Как работает платформа
                        Так выглядит вариант пользовательского интерфейса в проекте создания ATE (автоматизированное тестирование климатического контроллера).
                          0
                          Как гарантируется даже soft real-time? Не-RTOS не гарантирует фиксированное время попадания данных из страницы, ассоциированной с программой в user space, в буфер USB-концентратора (обычно такое попадание вызывает железное прерывание, которое запускает отправку данных).

                          И более философский вопрос — а зачем вообще так? Чем плохо исполнение непосредственно на микроконтроллере?
                            0
                            Как гарантируется даже soft real-time? Не-RTOS не гарантирует

                            Среда и ядро и язык G инструмента под которым создавалась платформа, однозначно гарантирует, это класс операционных систем, которые гарантируют временные циклы. Т.е поставил loop-цикл с временем 100 мкс — с заданной точностью он будет выполняться, независимо от того, захотел пользователь подключиться к примеру в веб-серверу или никаких задач нет.
                            Понятие реального времени довольно сложное и очень многое зависит от нюансов. Обычно разделяют на системы «жесткого» реального времени и «мягкого» (не жесткого). Windows и подобные системы обеспечивают мягкое реальное время. В традиционных OC ПО будет работать, как одна из десятков параллельно запущенных программ и каждой из них, ОС будет выделять ресурсы. Может оказаться, что когда вашей программе срочно понадобились ресурсы, то в этот момент ОС будет занята антивирусом, обновлением ОС, каким-то другим процессом. Поэтому такие системы не могут гарантировать реакцию системы на событие за определенный промежуток. Однако в 90-99% случаев эта реакция обеспечивается.
                            В системах жесткого реального времени наша платформа работает практически с наивысшем приоритетом и может приостанавливать фоновые процессы для обеспечения обработки события в заданное время. Вы сами определяете приоритеты процессов при программировании. Однако для таких систем требуется и специализированная ОС. В нашем случае мы рекомендуем версию LTSC, которая минимизирована фоновыми процессами и собрана именно для таких решений как наше.
                            При этом мы понимаем что USB устройства не являются жестким интерфейсом для штатной работы в RT-системах, поскольку у них недетерминированные интервалы обмена. USB-камера в том числе или плохой код на Си может быть не детерминированным не говоря уже про RT. Но тут уж программисту некого винить кроме самого себя.
                            Вопрос в том, что считать критическими измерениями. Когда система измерений находится в контуре управления технологическим процессом, с тактом 10-20мс — это будет скорее подходить под критические измерения, чем система регистрации событий с тактом 1с.
                            И более философский вопрос — а зачем вообще так? Чем плохо исполнение непосредственно на микроконтроллере?


                            Можно ответить по философски, — зачем Python, когда есть Си…
                            Так же на Ваш вопрос хорошо ответил Chris Wanstrath
                            Co-founder, CEO GitHUB:
                            Кодирование больше не является главным событием. Создание программного обеспечения — главное событие. Кодирование — это лишь небольшая часть этого. Мы думаем, что будущее кодирования — это вообще без программирования. мы думаем, что автономное кодирование вполне реально.

                            Дороже в разработках, высокие требования к уровню R&D персонала, долго, жесткая привязка к аппаратным архитектурам MK CPU конкретных производителей, быстро устаревающие, так же больше производственных затрат, можно долго перечислять.
                            Кстати еще раз вернусь, в качестве аргумента, программная часть проекта SpaceX частично была реализована именно на G, что не есть случайным выбором Маска, как обычно происходит у тех R&D структур, где по сложившейся ситуации переизбыток не загруженных программеров на C++, С#, FPGA… Codesys и т.п.
                              0
                              Среда и ядро и язык G инструмента под которым создавалась платформа, однозначно гарантирует, это класс операционных систем, которые гарантируют временные циклы. Т.е поставил loop-цикл с временем 100 мкс — с заданной точностью он будет выполняться, независимо от того, захотел пользователь подключиться к примеру в веб-серверу или никаких задач нет.

                              За счёт какого механизма? Я на всякий случай освежил свои знаний про обработку прерываний в windows
                              и получается, что windows, даже LTSC IoT, не может гарантировать даже soft realtime. Нет, мы можем и драйвер свой написать, и даже модуль ядра подменить, превратив Win10 в однозадачную Win98, но это совершенно лишняя плясовая про геморрой. Да, если мы обрабатываем медленные события (сотни миллисекунд), мы можем игнорировать отсутствие реального времени, но таких событий не так много. Даже если нам не нужно ловить единицы тактов, пропуск шага шаговым двигателем, потеря тика энкодера или расползание фаз в BLDC нас расстроит. Вы скорее всего знаете, что заставить LinuxCNC/Mach3 идеально работать это отдельное развлечение при сборке ЧПУ.
                              Кодирование больше не является главным событием. Создание программного обеспечения — главное событие.
                              Я читал про создание ПО без кодирования: prolog, COBRA, UML, abstract automata… Было много попыток, но результат очень спорный, получаются или очень нишевые, или непригодные к внедрению из-за требований к ресурсам продукты. Ну, будем посмотреть.
                              программная часть проекта SpaceX частично была реализована именно на G
                              Я не маскофил :) Будет хайп — почитаю, будет ISO — стану пользоваться.
                                0
                                Да, если мы обрабатываем медленные события (сотни миллисекунд), мы можем игнорировать отсутствие реального времени, но таких событий не так много. Даже если нам не нужно ловить единицы тактов, пропуск шага шаговым двигателем, потеря тика энкодера или расползание фаз в BLDC нас расстроит.

                                Не расстороит, и вот почему:
                                настройка ШИМ для управления шаговиками не имеет отношения к прямомой программной функции платформы, она реализуется на стороне драйвера шаговика. Счет значений от энкодеров в нашем цикле происходит с прерыванием в 0,005 с и соответственно триггерное срабатывание.
                                Вы не поверите тонны авиационного, военного, медицинского и прочего диагностического измерительного оборудования прекрасно уживаются на WinLab и LTSC, Linux ( в нашем случае под х 32) так же не вопрос. Еще раз обращаю Ваше внимание на приборы Agilent, Rode & Shcwarz, Fluke… которые оснащены PXCI и DAQ интерфейсными модулями и десктопными кроссплатформенным ПО, зайдите на минутку к NI на сайт и посмотрите на их сотни программно аппратных стендов и систем автоматики для всех без исключения отраслей, по ходу у них на все в.у. аппаратуру предоставляются драйвера начиная от GPIB-USB, Modboos, Can (пожалуйста Вам ISO 11898–1), Ethernet и прочие скоростные шины и протоколы.
                                Многие сервисные фирмы, которые занимаются QL в соответствии с ISO имеют в своем арсенале калибраторы для проведения верификации этих приборов 1 раз в год. Измерения ведутся многоканальными счетчиками с математическими перерасчётом довольно сложных формул в во многих радиотехнических и физических измерениях (Оптика, RF, механика...).
                                Я не маскофил :) Будет хайп — почитаю

                                Почитайте.
                                Пользуйтесь если гурману по карману.

                                Я читал про создание ПО без кодирования: prolog, COBRA, UML, abstract automata… Было много попыток, но результат очень спорный, получаются или очень нишевые, или непригодные к внедрению из-за требований к ресурсам продукты.

                                Интересуюсь их неудачным опытом, буду благодарен за ресурс, где можно посидеть.
                                  +1
                                  не имеет отношения к прямомой программной функции платформы
                                  Слушайте, но вот чего я из вас всё клещами вытягиваю? На сайте NI плотно пасся, LabView пользовался, аппноты читал. Там я хотя бы понимаю, какое оборудование мне понадобится и что вообще происходит между составлением блок-схемы и поворотом ШД на столько-то оборотов с заданным профилем ускорения, документы "Измерения в LabVIEW" и LabVIEW
                                  Real-Time Module User Manual
                                  дают хороший старт. В частности, я помню, что совсем без микроконтроллеров с немаленьким буфером и с обычной сишной прошивкой, которую трогать не надо, но которая разрабатывается под задачу, не обойтись. Т.е. LabView это удобный софт для интеграторов, но с закрытым списком поддерживаемого оборудования. Если у вас примерно так же, то можно считать, что я узнал всё, что хотел.

                                  Интересуюсь их неудачным опытом, буду благодарен за ресурс, где можно посидеть.
                                  Тема старая, но чтобы все подробно и в одной книге вспомнить не могу. Для обзора можете посмотреть «Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools».

                                  пожалуйста Вам ISO 11898–1
                                  Я надеялся на что-то типа ISO 26262 и ISO/IEC TS 17961
                                    0
                                    Слушайте, но вот чего я из вас всё клещами вытягиваю?

                                    Я дал Вам линк, а Вы его проигнорировали
                                    Я не маскофил :) Будет хайп — почитаю

                                    Так же предлагал сюда закинуть свою публикацию.
                                    Так что клещи отдыхают;)

                                    По части LabVIEW все верно и логическое ядро написано именно на нем. Вы просто не интересовались, я и не уделял этому внимания, достаточно было упоминания со сноской на G, моих здесь линков и в целом, отсутствующей здесь на глазах в хедере публикации.
                                    Я не пользуюсь списком поддерживаемого ими оборудования, а строю свои аппаратные интерфейсы и не по цене самолета. Мой I/O никакого отношения к NI не имеет.
                                    Среди разработчиков есть категория специалистов, которые создают собственные коммуникационные и управляющие интерфейсы для работы с LV, я один из них.
                                    Я надеялся на что-то типа ISO 26262 и ISO/IEC TS 17961

                                    Поддерживаются и эти.
                                      0
                                      Меня интересовал методический и идеологический подход, теперь я его части от вас услышал, а частично додумал :) Такой вот вопрос, с которого ветка и началась: почему КА? Есть ли внутри вашей платформы средство формальной верификации пользовательской программы, типа TLA+?
                                      Поддерживаются и эти.
                                      Спасибо, теперь я знаю, как LabView умудряется упихиваться в злые ISO 26262, IEC 60601 и DO-254
                                        0
                                        Очень полезный, надеюсь для нас обоих, был дискус, т.к. это для меня большое подспорье в описании системы. Многие вопросы для меня звучат впервые и они не должны оставаться без ответов.
                                        Аппаратная часть платформы активно обсуждается здесь где я отвечаю иногда ответами ои нашего диалога или наоборот.
                                        Благодарю за интерес, со мной всегда можно связаться по доступным Вам контактам, по всем линкам в т.ч. и здесь.
                                      0
                                      Обнаружил соратников по цеху, но они не обсуждают и не раскрывают свой концепт. Понимаю что они построили HMI к линейкам популярных PLC для распространенных манипуляторов.
                                      www.ready-robotics.com
                                        0
                                        Насколько я понял, они запилили свою станцию forge/ctrl, на которой крутится самописная rtos forge/os. Вообще у промроботов своя атмосфера, на хабре уже писали.

                  Only users with full accounts can post comments. Log in, please.