Комментарии 36
Кроме того, большой робот может служить зарядкой для крохотного RSTAR.Почему-то напомнило выпуск Ералаша про чемодан с батарейками.
Самая фантастическая способность большего из двух — быть старшим братом своему старшему брату. А вообще техника, конечно, интересная.
Предполагаются роботы-спасатели и ликвидаторы, т.е. машинки, которые могут уехать в завалы, огонь и ядовитый дым и там что-то сделать, при этом не очень понятно, что понадобится: ехать, прыгать, карабкаться или лететь (у RSTAR вообще странная схема локомоции). Есть у меня предположение, что при определенном риске для человека его просто по закону нельзя посылать на задание, но при этом делать что-то надо.
RSTAR это стенд, имхо, он никогда не будет использован как есть. Это не значит, что он не нужен, CENTAURO тоже когда-то был смешным и пластиковым, сейчас это взрослая проходимая машина, готовая к внедрению.
Что сказывается на стоимости и узостью нишевого рынка потребителей.Да. Но я же не кричу про «робота в каждый дом». Ниши есть, и в них уже есть роботы.
Развитие робототехники требует договоренности между разработчиками и производителями в вопросе единого правила plug and play независимо от назначения системыА вот тут не соглашусь: много раз развивались решения от разных вендоров для одной и той же задачи, а потом оставались один-два самых популярных или поддерживаемых. А могут и остаться много разных, такое тоже бывало. Или Вы про PnP буквально?
Не согласен. Во-первых, роботы являются промышленным оборудованием, а там с совместимостью на всех уровнях очень большая проблема, тем не менее, все обычно работает, когда обслуживается квалифицированным специалистом. Во-вторых, а зачем?
Должны в себя включать GUI настраиваемый кросс платформенный фреймворк с обращением к Finite-state machinesНу и тем более, почему именно так? У такого подхода куча плюсов, и в проектировании, и в отладке, но уж очень неортодоксально, я не помню, где сейчас так делают и делают ли вообще.
Вот давайте не мешать производство, продажи и политику. Пляшем от конечного покупателя, которому нужна гарантия соответствия спецификации — это то место, где действительно нужны ансамбли FSM, просто потому. что это чуть ли не единственный способ делать верификацию. И тут внезапно оказывается, что так даже в медицине, аэрокосмосе и военке не делают — в областях с самых зарегулированным процессом разработки и приёмке. Почему? Во-первых, это долго, во-вторых, дорого, в-третьих, тут мы попадаем в уже занятую нишу — однозначные и устойчивые решения такого уровня обычно делаются на релейной логике.
Почитаем. Но один пример хоть и рушит квантор всеобщности, но не доказывает ни применимость и удачность инструмента, ни тем более популярность.
Прочёл по ссылке, там действительно либо «Я пиарюсь», либо вообще корпоративный блог, ну и через спеллчекер прогнать нелишне, ошибок и опечаток куча. Ну и по сайту в профиле полазил. Давайте по порядку, как я понял:
1. Чтоб полноценно пользоваться описанной No code платформой, требуется довольно неплохо знать классическое программирование. Она реально сложнее, чем LabView, STM Cube или кодогенерация по UML. Отдельный минус в том, что она ни на что не похожа.
2. Платформа является лишним слоем абстракции, не являясь гуем компилятора, т.е. она должна поддерживать платформу, под которую ведется разработка.
3. Непонятно, почему сделано именно так и каков численный выигрыш. Хотелось бы посмотреть на проект, который решается по классике и через платформу.
4. Что там за КА? Синхронные/асинхронные, активные/пассивные? Гикпорно в студию :)
1. Чтоб полноценно пользоваться описанной No code платформой, требуется довольно неплохо знать классическое программирование. Она реально сложнее, чем LabView, STM Cube или кодогенерация по UML. Отдельный минус в том, что она ни на что не похожа.
2. Платформа является лишним слоем абстракции, не являясь гуем компилятора, т.е. она должна поддерживать платформу, под которую ведется разработка.
3. Непонятно, почему сделано именно так и каков численный выигрыш. Хотелось бы посмотреть на проект, который решается по классике и через платформу.
4. Что там за КА? Синхронные/асинхронные, активные/пассивные? Гикпорно в студию :)
Вопросы по платформе no code у меня делятся на два категории, про product placement и чисто технические.
1. На кого ориентирован Ваш продукт? Как я понял из информации на сайте, платформа предназначена для экономии на профильном специалисте. Окей, эмбедщика убралиавтомат поставили, кто будет писать код? Какой специалист? Насколько я понял, условного фронтэндщика не посадишь без обучения: лично я, если бы не читал Хоровица и Хилла, не понял бы назначение разных полей. Т.е. чтобы понимать куда и зачем тыкать нужно как минимум общее понятие о встраиваемой электронике и архитектуре микроконтроллеров. Похоже на путь, который прошла 1С: предполагалось, что её пользователями будут непосредственно бухгалтеры, но довольно быстро оказалось, что без прокладки в виде 1С-программистов система не работает. Следующий вопрос про конечный продукт разработки: получаем на выходе прототип, который после тестирования переписывается «по классике», или готовое к внедрению решение?
2. Техническая часть. Сразу оговорюсь, что не стал тратить несколько часов на ознакомление с инструментом, которым не планирую пользоваться.
— Моргание светодиодом на задержках
— Моргание светодиодом на таймере с фиксированной частотой при разной частоте ядра или периферии (если МК поддерживает независимое тактирование)
— Моргание светодиодом, когда интервал выше разрядности встроенного счётчика таймера.
1. На кого ориентирован Ваш продукт? Как я понял из информации на сайте, платформа предназначена для экономии на профильном специалисте. Окей, эмбедщика убрали
2. Техническая часть. Сразу оговорюсь, что не стал тратить несколько часов на ознакомление с инструментом, которым не планирую пользоваться.
Платформа представляет из себя настраиваемый фреймворк с внешними коммуникациямиЭту фразу я не понял. Значит ли это, что на стороне МК остался только ногодрыг, а вся логика живет на десктопе, передавая по USB команды вида «дёрнуть ногами по такой-то маске»?
В источнике и на сайте продукта есть наглядные примеры, демонстрация в работеА можно без видео? Хочу классическую текстовую аппноту с кодом. Классическим «миганием диодиком» является такой набор:
— Моргание светодиодом на задержках
— Моргание светодиодом на таймере с фиксированной частотой при разной частоте ядра или периферии (если МК поддерживает независимое тактирование)
— Моргание светодиодом, когда интервал выше разрядности встроенного счётчика таймера.
мой спелчекер не особо возмущался, даже не знаю где и в чем там у меня обнаружены лингвистические баги.Если вам нужен корректор, то я готов выполнить эту работу.
Видимо, действительно что-то своё. На сайте вижу
Поскольку тема для меня не совсем чужая, я архитектуру решения представляю так: конечное устройство-эффектор, на борту у него МК, поддерживающий real-time обработку и берущий на себя низкоуровневую часть «как работать». Он (возможно) подключен к десктопу, на котором никакого реального времени нет, но есть высокоуровневая прожорливая часть «как» и «что делать».
Если мы берём USB, то предсказать, когда сигнал придёт с конечного устройства на концентратор ПК в принципе можно точно через data frames, это в стандарте есть, но вот когда провернётся планировщик ОС, чтобы сигнал от прерывания достиг программы-обработчика в user space — это вообще никак не регламентируется. Так что если прерывание на МК просто передаётся на десктоп, там обрабатывается и пересылается обратно — это никакого риалтайма, джиттер может быть в сотни миллисекунд.
По поводу модельного примера, я хочу что-то такое, можно даже без CTC и OVF. Вот давайте представим, что я хочу сделать с помощью вашей no-code платформы гирлянду на ёлку, без раздельного управления диодами, но чтоб могла моргать с определенным интервалом, пусть даже фиксированным, 3 секунды. Но это должны быть честные 3 секунды. Какое оборудование мне понадобится и как будет выглядеть разработка?
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 секунды. Какое оборудование мне понадобится и как будет выглядеть разработка?
Давайте поступим проще: я расскажу, что я понял из этой беседы, сайта у вас в профиле и статьи на vc, на которую вы давали ссылку выше, а вы скажете, где я неправ.
1. К компьютеру подключаются USB-IO или USB-ADC модули, идеологически подобные старичку eserial, только проприетарные. Они необслуживаемые, принимая команду по USB они выставляют значения IO на своих ногах/каналах ЦАП либо сообщают по USB состояние ног и/или АЦП, больше ничего не умеют. Модули являются ведомыми и не могут инициировать обмен данными с ПК. Характеристики модулей на сайте разработчика платформы отсутствуют.
2. Логика выставления значений задаётся в no-code платформе. По окончании работы с платформой генерируется программа, которая должна крутиться на компьютере, к которому подключены модули.
3. Real time не обещается.
1. К компьютеру подключаются USB-IO или USB-ADC модули, идеологически подобные старичку eserial, только проприетарные. Они необслуживаемые, принимая команду по USB они выставляют значения IO на своих ногах/каналах ЦАП либо сообщают по USB состояние ног и/или АЦП, больше ничего не умеют. Модули являются ведомыми и не могут инициировать обмен данными с ПК. Характеристики модулей на сайте разработчика платформы отсутствуют.
2. Логика выставления значений задаётся в no-code платформе. По окончании работы с платформой генерируется программа, которая должна крутиться на компьютере, к которому подключены модули.
3. Real time не обещается.
Как гарантируется даже soft real-time? Не-RTOS не гарантирует фиксированное время попадания данных из страницы, ассоциированной с программой в user space, в буфер USB-концентратора (обычно такое попадание вызывает железное прерывание, которое запускает отправку данных).
И более философский вопрос — а зачем вообще так? Чем плохо исполнение непосредственно на микроконтроллере?
И более философский вопрос — а зачем вообще так? Чем плохо исполнение непосредственно на микроконтроллере?
Среда и ядро и язык G инструмента под которым создавалась платформа, однозначно гарантирует, это класс операционных систем, которые гарантируют временные циклы. Т.е поставил loop-цикл с временем 100 мкс — с заданной точностью он будет выполняться, независимо от того, захотел пользователь подключиться к примеру в веб-серверу или никаких задач нет.
За счёт какого механизма? Я на всякий случай освежил свои знаний про обработку прерываний в windows
Список статей по теме
и получается, что windows, даже LTSC IoT, не может гарантировать даже soft realtime. Нет, мы можем и драйвер свой написать, и даже модуль ядра подменить, превратив Win10 в однозадачную Win98, но это совершенно лишняя плясовая про геморрой. Да, если мы обрабатываем медленные события (сотни миллисекунд), мы можем игнорировать отсутствие реального времени, но таких событий не так много. Даже если нам не нужно ловить единицы тактов, пропуск шага шаговым двигателем, потеря тика энкодера или расползание фаз в BLDC нас расстроит. Вы скорее всего знаете, что заставить LinuxCNC/Mach3 идеально работать это отдельное развлечение при сборке ЧПУ.Кодирование больше не является главным событием. Создание программного обеспечения — главное событие.Я читал про создание ПО без кодирования: prolog, COBRA, UML, abstract automata… Было много попыток, но результат очень спорный, получаются или очень нишевые, или непригодные к внедрению из-за требований к ресурсам продукты. Ну, будем посмотреть.
программная часть проекта SpaceX частично была реализована именно на GЯ не маскофил :) Будет хайп — почитаю, будет ISO — стану пользоваться.
не имеет отношения к прямомой программной функции платформыСлушайте, но вот чего я из вас всё клещами вытягиваю? На сайте 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
Меня интересовал методический и идеологический подход, теперь я его части от вас услышал, а частично додумал :) Такой вот вопрос, с которого ветка и началась: почему КА? Есть ли внутри вашей платформы средство формальной верификации пользовательской программы, типа TLA+?
Поддерживаются и эти.Спасибо, теперь я знаю, как LabView умудряется упихиваться в злые ISO 26262, IEC 60601 и DO-254
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Роботандем: у крохотного робота-трансформера STAR появился старший брат