Каковы причины того, что робототехнических фреймворков мало

История Фреймворка Beeptoolkit (Beeptec Engineering 2019 г.), наглядный пример того, как и добрая дюжина других фреймворков, по предположению, не достаточно широко присутствуют  в информационном поле среди их потенциального сообщества, так же и тех кто может делиться такой информацией, а те кто каким то образом все же наткнулся на  сведения, сразу не могут понять, насколько он мощный, как его оседлать и разогнать, что лежит тяжелым бременем на их разработчиках.

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

Framework BEEPTOOLKIT (СISC x86, OC Windows LTSC)
Краткая характеристика:

Востребован структурами R&D, которые заинтересованы иметь в своих программно-аппаратных решениях:

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

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

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

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

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

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

Проблема маркетинга

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

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

Обращение к целевой аудитории

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

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

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

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

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

На деле все очевидно, мы очень старались чтоб было хорошо, а что плохо Вы и сами нам скажете:

Это легко понять, но трудно решиться.

Наконец, я считаю, что робототехника — это мощный инструмент, и к нему нужно относиться соответственно, как и в случае со многими универсальными промышленными инструментами, которому для полного раскрытия своего потенциала, все же требуется немного опыта и знаний.
Если вы хотите получить максимальную отдачу от Beeptoolkit, вам нужен кто-то, кто посвятит значительное количество времени тому, чтобы бы Вы приняли решение в пользу нового инструмента.
Это определенно не серебряная пуля. Я предполагаю, что некоторые R&D команды сдаются слишком рано, прежде чем они осознают истинный потенциал Beeptoolkit.

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

Скрытая сила ядра Beeptoolkit

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

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

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

Резюме

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