Расширять нельзя рефакторить

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

Все стартаперы (и не только они) сталкиваются со стандартной проблемой развития проекта - добавление нового функционала, который заранее не был заложен. Причины тому могут быть самые разные - как недостаточно детальное планирование при составлении ТЗ, так и объективная ситуация поступления новой информации, на которую надо оперативно реагировать. Выходов из затруднительного положения традиционно два - упаковка новой функции в условно-свободное место старой архитектуры или полная глубокая переработка программной и/или аппаратной части.

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

Первый прототип

MVP - комплекс из тренажера на ноги XM1 (на заднем плане) и мультистанции на верхнюю часть тела XM2 (на переднем плане)

В чем состояла "пропасть" между прототипом и MVP удобнее показать в виде таблицы (весьма похожей на таблицы выбора комплектаций автомобилей)

Из списка видно, что расширение функционала было достаточно существенным. Существующих ресурсов (мощная, но все же ARDUINO DUE) не хватало, как ни крути.

Спасли ситуацию 3 идеи:

1. Опереться в большей степени на готовые отработанные решения;

2. Разделить функционал системы на критический/не критический по времени и добавить несколько SLAVE подсистем;

3. Использовать максимально возможности пред/пост обработки данных.

Далее расскажу подробнее о роли каждой из идей.

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

Вторым важным шагом в понимании системы стал отход от идеи, что головная система управления должна непосредственно сама контролировать ВСЕ исполнительные узлы. Мы обратили внимание, что у нас есть явное разделение ролей между приводами - основные работают в момент упражнения, их быстродействие критично и алгоритм движения сложный; привода настройки положения пользователя работают между упражнениями и по самым простым правилам и некритичны по быстродействию. В результате было решено организовать отдельную SLAVE-подсистему управления приводами положения пользователя и взаимодействовать с ней по простейшему командному протоколу на основе UART. Быстродействие и надежность такого канала, разумеется, ниже, но т.к. тут не требуется мгновенная реакция, всегда можно в ручном и/или автоматическом режиме дублировать отправку команд и добиться достаточной стабильной работы по ощущению пользователя.

Третьим направлением стала идея использовать максимально интенсивно пред/пост обработку. Была написана математическая модель последовательности выполнения упражнения и многочисленных параметров его динамики, причем вся обработка этой модели делается при помощи Python. Результатом обработки является библиотека для основного кода, представляющая собой примитивную последовательность геометрических точек со свойствами, формирующих в итоге упражнение. Уровень абстракции в основном коде в итоге стал достаточно низкий для того, чтобы изменения общей математической модели его не затрагивали. "Расплатой" за полученные сверхгибкость и надежность стала необходимость перекомпиляции основного кода при любых изменениях модели, что на практике вполне приемлемое действие.

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

Резюмируя, скажу, что применение описанных в этой статье идей позволило нам в условиях чрезвычайно сжатых ресурсов (тем более для hardtech стартапа) за срок чуть более 4 месяцев создать полноценный MVP, открывший нам доступ к систематическим пользовательским данным, без которых невозможно создать законченный продукт. Несмотря на то, что наша система уже отлично работает и люди ощущают уникальный эффект от наших тренировок на себе, мы постоянно совершенствуем алгоритмы и аналитику. Мы приглашаем всех, кто любит новые технологии, экономит свое время и с вниманием относится к своему телу, к участию в наших исследованиях!

P.S. Если статья получит активный отклик, то я планирую писать о количественных характеристиках силовых тренировок, которые мы собираем и обрабатываем в настоящее время [первые в мире!] )))