Робототехника на изнанку

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

Ситуация в робототехнике, к сожалению, пока что еще находятся в ожидании встречи с таким будущим, специалистами нового мышления и иных подходов к проблеме.

Наглядный пример Китай, с его быстро растущими темпами роботизации в экономически приоритетных областях, который отчаянно нуждается в пяти миллионах специально подготовленных инженеров и техников, особенно междисциплинарных и высококлассных, говорится в анализе газеты The Paper, передает 26 сентября 2022 г. издание Yicai Global.

Лишь несколько выпускников ежегодно отвечают требованиям робототехнического сектора страны, говорится в отчете со ссылкой на инсайдера отрасли. Обучение не успевает за темпами роста и обновлениями технологий. Кроме того, обучение персонала обходится дорого, поэтому очень распространено переманивание в другие IT сферы, добавил собеседник.

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

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

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

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

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

— Почему, спросите Вы?
Там робототехнику штурмуют снизу вверх, по «кубикам — пазликам», зачастую с ограничениями учебной программно аппаратной концептуальной платформы — продвинутого конструктора в объеме коробки с футуристической механикой.
Создать конечный автомат там легко, с определенным количеством датчиков во взаимодействии с драйверами нагрузок.

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

Эволюция неизбежна и ждет появления новых автоматизированных технологий разработки.

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

В последние годы, по сути, закончился золотой век IT.
Еще в начале 2000-х был дикий дефицит кадров, а сейчас сотни откликов на любую вакансию, HR отсеивает толпы студентов и айтишников после курсов Java, Python и т.д.

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

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

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

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

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

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

Framework BEEPTOOLKIT (СISC x86, OC Windows LTSC) формирует сообщество разработчиков нового поколения.

История создания Фреймворка Beeptoolkit (программная среда ускоренного прототипирования и разработки робототехники, автоматики и смарт систем), это результат многолетнего (более 25 лет) опыта работы автора — разработчика, Капитульского Александра во многих Hi-Tech робототехнических организациях, от животноводства до медицины и оборонной промышленности, обобщения результатов и нескольких лет научной работы в лаборатории стартапа.

По состоянию дел на сегодня, Beeptoolkit, благодаря нескольким успешным проектам в сфере приборостроения, медицины и автомобилестроения, был замечен рядом известных публичных изданий, таких к примеру, как Welp Magazine (Лондон), включен в национальные научные реестры израильских технологических стартапов и вовлечен в проекты приоритетных направлений в сфере вендинговой робототехники.

Краткая характеристика:

Как есть в коробке с расширяемым I/O USB комплектом до 10...1600 входных и 16...160 выходных DAC/ADC каналов, востребован структурами R&D, которые заинтересованы иметь в своих программно-аппаратных решениях:

• Большое количество различных по длине, формату и количеству команд, выполняемых за несколько тактов CPU;

• Управление с помощью программируемой логики (визуальное кодировка инструкций);

• Преобладание двухадресной адресации и развитый механизм адресации операндов (переменная, над которой производят операции в коде);

• Много поточность, применение конечных автоматов (FSM), микро сервисов и т.д.

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

Нет необходимости создавать аппаратную часть с нуля, писать, компилировать код и загружать его в контроллеры на базе RISC MCU с дизайном на разнесенных коммуникациях с сопутствующим букетом проблем, знакомых всем классическим разработчикам эмбеддерам встраиваемого программного обеспечения под Arduino, STM, ESP, Raspberry Pi, других DSP платформ и контроллеров на их базе.

Если Вы все еще сомневаетесь, посмотрите на этих примерах решение одной и той же простой задачи разными платформами, но если понимаете, можно продолжить чтение не заостряя внимание на этих фактах:

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


Подводная часть айсберга.

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

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

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

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

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

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

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

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

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

В результате, если вы объедините все это с тем, как работают многие организации, где тестирование и проверка не выполняются до тех пор, пока кодирование не будет завершено или почти завершено, Beeptoolkit выглядит как Джин в бутылке, которую страшно открыть.

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

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

Это определенно не серебряная пуля. Я предполагаю, что некоторые R&D команды сдаются слишком рано, прежде чем они осознают истинный потенциал Beeptoolkit.

IT евангелист, если ты существуешь,буду безмерно рад твоему приходу в храм Beeptookit!Скрытая сила ядра Beeptoolkit.

Настоящая сила ядра платформы фреймворка заключается в том, что оно создавалось в среде LabVIEW, которая позволяет инженерам практикам создавать комплексные целевые фреймворки с визуализацией инструкций обработки и анализа данных, получаемых от реальных физических объектов. Принципиально для LabVIEW нет разницы между использованием виртуальных инструментов (функций или библиотек), посредством I/O комплекты. Это концептуальный язык G, который разработан, скомпилирован на С++ и частично на Qt, специально для инженерных групп, изначально не классических скрипт кодеров.

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

Ошибки будут всегда, так как человеческий фактор никто не отменял.

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

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

В первом случае:

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

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

Во втором случае ошибки так называемого человеческого фактора:

1. Весь алгоритм построен верно, но не происходит обращение к коммуникациям.
Вариант ошибки:
— Не указан, или указан неверно ID USB I/O номер обращении к выходному модулю;
— Физический адрес подключения приводит к аппаратному конфликту, срабатывает защита на программном уровне.

2. Одна или серия введенных инструкций нарушает работу системы на аппаратном уровне;
Вариант ошибки:
— Отсутствует или неправильно введена программная параметрическая настройка в инструкциях порта.

3. Комплект USB используется не по назначению или выполнено некорректное его подключение в обход или с нарушением технических требований и т.д.

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

Резюме.

Черт возьми, но я сделал это! Мне потребовалось несколько лет работы с ядром Beeptoolkit, прежде чем я действительно понял, насколько мощным и масштабируемым он может быть как в команде разработчиков, так и в одиночку.

К сожалению, даже сейчас я не уверен, что смог донести это до вас и широкого круга крупных скрипт — скептиков, в любом случае, я искренне благодарю вас за то, что вы уделили немного времени прочтению этого текста и дошли до этого места.

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

Пожалуйста напишите в комментариях, что Вы думаете об этом.