roboforum.ru

Спустя 2 года с момента создания своего робототехнического фреймворка, я все свои мысли собрал в единую кучу где рассмотрел все проблемы современной робототехники сквозь призму множественных проблем и сдерживающих факторов.
Я не претендую на истинность своих суждений, надеюсь каждый кто осилит блог (на прочтение 14 минут) до конца, найдет там для себя что-то личное и полезное.
Мне интересно здесь в сообществе услышать коллективное мнение, вопросы возражения и т.п.
https://beeptoolkit.blogspot.com/2023/03/normal-0-false-false-false-ru-x-none-he.html

Так выглядит фрагмент аппаратного дизайна одного из проектов на базе Beeptoolkit:

Приветствую,
Если я правильно понял - Вы Александр ?
Тут вот какое дело.
Фреймворк выбирают под задачи, для профессиональных задач тыкать в графике огромное количество переключателей и полей гораздо сложнее чем править и контролировать текстовый код.
А для новичков такое кол-во настроек это черезчур много и сложно для понимания.
НО! мое суждение субъективно, я реально не пробовал фреймворк в работе. Пока к сожалению времени не хватает.

А что касается идеи в целом, проблема выращивания новых спецов в любой области существует и существовала всегда.
Именно поэтому Спецы высокого уровня так ценятся.
Ну а методы передачи опыта - тоже отработаны веками, и на мой взгляд наиболее интересным является работа в "шарашке" (это термин применителен к малому коллективу разработчиков времен CCCP)
и "институт" (не организация а метод) наставничества.

Фреймворк выбирают под задачи, для профессиональных задач тыкать в графике огромное количество переключателей и полей гораздо сложнее чем править и контролировать текстовый код.
А для новичков такое кол-во настроек это черезчур много и сложно для понимания.
НО! мое суждение субъективно, я реально не пробовал фреймворк в работе. Пока к сожалению времени не хватает.

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

По ходу визуальная консоль инструмента претерпела существенные изменения по сравнению с той версией скриншота, которая здесь выставлена, С тем же успехом можно было бы выставить и консоль Visual Studio, глядя через нее поверх всего остального, что естественно для кодера со скилами на нем, будет тьма, критика, отсутствие интереса в погружении в нечто неизвестное, а гланвое он скажет -"зачем?".

Относительно профессиональных задач? Попробуем под алгоритм вендингового робота по приготовлению напитков смузи, шейков построить исходник с клиентским интерфейсом, к примеру на малине из под RTOS с его GPIO и на Beeptuulkit?
Если захотите, я здесь такой алгоритм скину.

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

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

Стартап достойный, и, несомненно, найдет своего потребителя. Видно, что проделана большая и качественная работа. Вполне решает задачу быстрого и наглядного получения результата. В чем, собственно, и преимущество всех конструкторов.
Что он «выстрелит» как ардуино я сомневаюсь. У них основная фишка в открытости. Масса людей пишут библиотеки, масса производителей клепают железо. Среда программирования оказалась настолько популярна, что под нее начали выпускать промышленные контроллеры. А это уже не игрушки.
Популяризация программирования, путем максимального упрощения – это тоже вред. Давайте приучим молодежь собирать программные конструкторы, потому что им лень думать. Потом удивляемся, что у молодежи клиповое мышление, что они не могут сосредоточиться на задаче.
Понятно, что специалистов, умеющих работать на станке, пока еще надо гораздо больше, чем тех, кто этот станок разрабатывает. Но, разработчика надо с детства учить решать более сложные задачи, чем решало предыдущее поколение.
Я, конечно, тоже предпочитаю AppInventor чем Android Studio, когда надо сделать управлялку по БТ с 3-мя кнопками. А, когда требуется что-то с освоением нового языка, то не хватаюсь за толстый учебник, а беру готовый пример и изменяю его под свою задачу. Благодаря огромному количеству информации порог вхождения понижается. Но, программистов моего уровня скоро заменит чат GPT и ему подобные. А будущих разработчиков синхрофазатронов на одних конструкторах не научишь. Пусть думать учатся.

Робототехника, это, к счастью, не только конечные автоматы и не только предположение о замкнутости окружающего робота мира.
Ваш фреймворк, конечно же имеет право на существование.

Scorpio писал(а):...
Популяризация программирования, путем максимального упрощения – это тоже вред. Давайте приучим молодежь собирать программные конструкторы, потому что им лень думать. Потом удивляемся, что у молодежи клиповое мышление, что они не могут сосредоточиться на задаче.
Понятно, что специалистов, умеющих работать на станке, пока еще надо гораздо больше, чем тех, кто этот станок разрабатывает. Но, разработчика надо с детства учить решать более сложные задачи, чем решало предыдущее поколение.

Хороший пример разработки станка. Старые станки требуют нереальный опыт и знания от юзера, по сравнению с новыми CNC когда достаточно ввести в него пакет софта и нажать на кнопку. Разработчик 1 и 2 станков изначально должны обладать всеми знаниями металообработки, причем 2-й разраб должен еще и иметь опыт создания программно аппаратной части автоматики.
Это почти идеальная аналогия когда под одну и ту же задачау одному кодеру - разрабу дают среду написания кода, к примеру С++, а другому кодеру FreeRTOS c набором готовых библиотек, третему разрабу дают визуализированную среду с абстракцией интерфейса на уровне детской пирамидки под интуитивно, понятными инструкциями. Чувствуете разницу, насколько создатели таких инструментов глубоки в базовых знаниях и насколько они друг от друга отличаются в понимании юзеровских потребностей? 1-й будет юзеру втирать мозги , чтоб учил мат часть, а 2-й и 3-й будут просто демонстрировать как все это просто работает без завышенных требований от своих юзеров к матчасти и вопрос цены таких инструментов под в.у. категории юзеров, ох как не прост...

Scorpio писал(а):Я, конечно, тоже предпочитаю AppInventor чем Android Studio, когда надо сделать управлялку по БТ с 3-мя кнопками. А, когда требуется что-то с освоением нового языка, то не хватаюсь за толстый учебник, а беру готовый пример и изменяю его под свою задачу. Благодаря огромному количеству информации порог вхождения понижается. Но, программистов моего уровня скоро заменит чат GPT и ему подобные. А будущих разработчиков синхрофазатронов на одних конструкторах не научишь. Пусть думать учатся.

Это и есть ответ, на мой предыдущий вопрос.
Что касается GPT, это чисто мое субъективное мнение - Джин из бутылки тот еще.
Как Вы думаете, откуда технология вытаскивает готовые решения к примеру по части генерирования скрипт кода и кто эти источники формирует?
Какова будет цена ошибки, если все пустить на самотек, каков должен быть уровень постановщика задачи и состав R&D группы. Особенно это важно, когда речь идет о критически важном софте в медицине или в том же автоматизированном поточном производстве.... Пока что вопросов больше чем ответов по допускам технологии в те или иные сферы.

Виктор Казаринов писал(а):Робототехника, это, к счастью, не только конечные автоматы и не только предположение о замкнутости окружающего робота мира.
Ваш фреймворк, конечно же имеет право на существование.

Ну в общем то мой фреймворк поддерживает все н.у. типы управления, которые классифицированы обще принятыми признаками робототехники:

1. Удаленное управление - дистанционное управление посредством специального интерфейса;
2. RPA - программная реализация предсказуемых процедур, объеденных в один сценарий, когда все действия повторяются до завершения задачи или циклично после запуска, к примеру станок CNC;
3. Адаптивный - наличие обратной связи, посредством сбора внешних данных от сенсорной части (Бортовая система жизнеобеспечения космической станции).
4. Дифференциальный, где все предыдущие типы могут быть объедены в одном комплексе.
Одинакое имеются и альтернативы (Бортовая космическая автоматика с внешним ЦУП, с возможностью перевода в ручное управление пилотным составом).

Виктор Казаринов писал(а):Среди прочих то, над чем я сейчас работаю.
Это язык общения интеллектуальных систем, который пока не имеет финального названия.
Он опирается не на конечные автоматы, а на отологическую модель незамкнутого или замкнутого мира.
Еще - на движок, основанный на динамически создаваемых планировщиках и экзекуторах. Первые планируют, вторые исполняют планы.
Язык поэтому сочетает как декларативную, так и процедурную парадигмы.
Если что-то определено декларативно, группа планировщиков пытается самостоятельно найти решение.
Кроме того, этот язык позволяет не только доносить искусственным системам что и как сделать, но и лежит в основе самого механизма деятельности этих систем.
Это позволяет накапливать роботу собственный опыт и использовать его в дальнейшей детельности.

Т.е. с применением Machine Learning. Есть подозрение, что Ваши попытки подачи материала в таком стиле, вызывали бурную реакцию в IT сообществах.
Я для себя извлек жестокие уроки такой подачи и отказался от неоднозначной в понимании терминологии. Вместо этого я демонстрировал реальные простые сравнительные примеры того, как это работает и строится в разных инструментах в сравнении с моим. В блоге моя концепция Machine Learning так же имеет место в виде методов вербального обучения. На точке 4:11...
Хотел сказать что словесного описания своих решений до неприличия мало, для массовой положительной оценки. Народ любит зрелищьность и не любит пространные тексты.