Роботизированная платформа — это не «рама плюс моторы». Самая дорогая ошибка в начале проекта — рассматривать детали по одной: батарея кажется задачей электрика, колёса — задачей механика, а потеря связи — задачей программиста. В движении они встречаются одновременно. Команда превращается в ток, ток — в момент, момент — в движение; датчики сообщают, что произошло, а отказ в любой стрелке должен привести не к сюрпризу, а к заранее определённому состоянию.
Четыре потока вместо списка компонентов
Оператор / задача / среда
│ команда и ограничения
▼
Управление и связь ──────────► Логика запрета и остановки
│ команда │ safe state
▼ ▼
Привод и ходовая ◄──────────── Энергия и защита питания
│ движение │ V / I / T
└────────── Датчики и наблюдение ──┘
│
▼
версия → условия → данные → выводЭто не схема конкретной «Зари 40» и не электрическая принципиальная схема. Это карта вопросов. У каждой стрелки нужно уметь назвать: что передаётся, какие пределы действуют, что будет при обрыве и чем это подтверждено.
Пройдём один путь: от пальца до колеса
Представим, что оператор дал команду медленно ехать вперёд.
- Интерфейс и связь принимают команду и должны отличать свежую команду от старой или потерянной.
- Управление решает, разрешено ли движение в выбранном режиме. Нулевая команда в приложении не равна автоматически безопасному состоянию силовой части.
- Драйвер и силовой каскад превращают слабый управляющий сигнал в ток двигателя, измеряют или ограничивают его так, как позволяет конкретная архитектура.
- Механика и ходовая превращают момент в силу на контакте с поверхностью. Скольжение, нагрузка и разный эффективный радиус колёс могут изменить траекторию, хотя оба мотора вращаются.
- Датчики измеряют не «всё»: энкодер сообщает о вращении, датчик тока — о части электрического режима, камера — о сцене. Наличие датчика не доказывает, что по нему принимается решение.
- Запись связывает версию, условия и фактический результат. Без неё повторная проверка начинается с догадок.
Такой разбор сразу показывает, почему фраза «робот сам поехал» не является диагнозом. Нужно искать, на каком переходе команда, энергия, обратная связь или ограничение перестали соответствовать ожиданию.
Второй путь: что должно произойти при отказе
Полезный системный вопрос звучит не «есть ли E‑Stop?», а «какое опасное действие должно прекратиться, каким независимым путём и что останется под энергией?»
| Событие | Где его обнаруживают | Что должно быть определено | Чего это само по себе не доказывает |
|---|---|---|---|
| Нет свежей команды | связь или контроллер | как фиксируется таймаут и кто запрещает момент | промышленную функцию безопасности |
| Перегрев / сверхток | драйвер, BMS или датчик | порог, реакция, способ восстановления | корректность порога для чужой сборки |
| Неожиданное движение | наблюдатель, датчик или тест | стоп-событие, зона, журнал конфигурации | причину без измерения |
| Работа с узлом | человек и процедура | изоляция всех релевантных источников энергии | что кнопка Stop обесточивает систему |
Блок «безопасность» проходит через всю карту. Он не живёт в одной красной кнопке, одном чек-листе или одной строке прошивки. У «Зари 40» контур безопасной остановки ещё предстоит подтвердить; поэтому эта страница объясняет модель, а не обещает реализованное свойство платформы.
Где начинается собственная идея пользователя
Базовая платформа в перспективе должна закрывать повторяющуюся сложность: несущую конструкцию, движение, питание, базовые интерфейсы и документацию. Пользовательский слой начинается там, где появляется своя функция: камера, контейнер, датчик, алгоритм или сценарий. Но «подключить модуль» безопасно можно лишь после объявления четырёх границ:
- механика — крепление, масса, габарит, вибрация;
- энергия — напряжение, ток, защита, разъём и порядок включения;
- данные — команда, состояние, частота, таймаут;
- отказ — что модуль и база делают при обрыве или ошибке.
Наличие разъёма или отверстий не доказывает модульность. Её доказывает проверенный контракт конкретных версий.
Практический шаг: нарисуйте один отказ
Не начинайте с покупки ещё одного компонента. Нарисуйте четыре прямоугольника: «команда», «управление», «драйвер», «движение». Затем выберите один отказ — например, «команда перестала приходить» — и заполните:
Как это обнаруживается:
Кто имеет право запретить движение:
Какое состояние считается безопасным в этой задаче:
Что остаётся под энергией:
Как будет записан результат теста:Пустое поле здесь — ценная находка. Оно показывает, какую повторяющуюся сложность нужно закрыть до того, как добавлять новую функцию.
Источники
- NASA Systems Engineering Handbook — системные границы, интерфейсы и проверка требований.
- ROS 2 URDF — модель робота как узлы и связи, а не плоский список деталей.
- ROS 2 hardware interfaces — различение команды, наблюдаемого состояния, параметров и пределов.
Дальше: как оформить версию и доказательство или что должен делать привод при потере связи.